Stephen Sinclair wrote:
I think a really nice use of serializable objects would be to take care of a complaint in that previous thread about live coding... you've written a routine to randomly generate a nice melody (based on a severely complicated algorithm of course), but when you decide to modify something, oops you've lost it because you have to restart.
So a nice feature might be to allow saving an object to a file. Next time around, the code could attempt to load the object from disk. If successful, go nuts with it, but on failure, generate a random melody and save the object to disk...
(Of course this brings up all sorts of real-time issues. I guess saving & loading would have to be done asynchronously somehow, but I think a bit of buffering could take care of that.)
I haven't looked closely enough at ChucK's architecture to know whether ChucK does so or not, but most audio software has a real-time audio thread and a "GUI" thread, where the GUI thread is pretty much everything else. On a related note, I started looking at the code today and there's already a shell of an I/O implementation with support for the most basic types. I started messing with it and then realized that I should be working on my set for Saturday, but I may play with it Sunday afternoon. -Scott