Fellow ChucKsters, I was thinking while lying awake last night.... One of the big questions at the moment is writing non-wave data to disc and recalling it. This would be useful for storing the outcome of (random) algorithms, settings tuned by the use of interfaces and any number of other useful and appealing things. I'm certain we'll have this in the future, but what about right now? One idea I had that I have yet to try in practice is that we could try abusing the call for the OS to execute a terminal command. One of the very old-fashioned commands all three OS's that ChucK runs on is writing a line to a new file or appending a line to a existing file so with some abuse of the new function to form strings we could writem then save a file. If that file would contain a array and a simple command to assign that to a static array in a public class simply executing the file we wrote would give us back the data, asuming we defined some format for this. This is roundabout and not that beautiful but it could help someone out so I thought I'd share. One thing this would lead to is a .ck file that would work on either Windows or OSX&Linux and that would decrease the communicative value of that code, I'm less then happy about that. We could work with a condition and execute either of two versions of this call if only we could detect what the host OS is but I don't believe we can. Would it be a idea to have a standard library function to simply ask the OS what it is or use the fact that upon compiling ChucK we already know what it will run on since we need to set a flag for what version we are building? That's how far I got before dozing off... Perhaps helpful or interesting to some? Cheers, Kas. PS; the same technique might conceivably be used to append lines to the program itself. This sounds like a exciting, daring and dangerous plan that I haven't yet found a use for. Abuse with care.
Kassen wrote:
Fellow ChucKsters,
I was thinking while lying awake last night.... One of the big questions at the moment is writing non-wave data to disc and recalling it. This would be useful for storing the outcome of (random) algorithms, settings tuned by the use of interfaces and any number of other useful and appealing things. I'm certain we'll have this in the future, but what about right now?
One idea I had that I have yet to try in practice is that we could try abusing the call for the OS to execute a terminal command. One of the very old-fashioned commands all three OS's that ChucK runs on is writing a line to a new file or appending a line to a existing file so with some abuse of the new function to form strings we could writem then save a file. If that file would contain a array and a simple command to assign that to a static array in a public class simply executing the file we wrote would give us back the data, asuming we defined some format for this.
If you just want line-in / line-out support, honestly, I could hack that into ChucK in a few minutes this afternoon. The problem isn't so much getting stuff into and out of files, it's doing things with it once you've got it. ChucK doesn't have any significant string manipulation functions. You could use sort of a poor-man's delimiter by using one data field per line and Std.atoi(), perhaps. Even more interesting from my perspective would be the ability to serialize ordinals (and perhaps later objects) directly to files, but that's a bit more work. -Scott
On 9/20/07, Scott Wheeler
If you just want line-in / line-out support, honestly, I could hack that into ChucK in a few minutes this afternoon. The problem isn't so much getting stuff into and out of files, it's doing things with it once you've got it. ChucK doesn't have any significant string manipulation functions. You could use sort of a poor-man's delimiter by using one data field per line and Std.atoi(), perhaps.
Even more interesting from my perspective would be the ability to serialize ordinals (and perhaps later objects) directly to files, but that's a bit more work.
You're right, we need a lot more... This little trick isn't meant as a replacement for anything but what it *could* do is allow one to quickly store something in a way that will survive the end of the VM and being able to get it back in there next time ChucK is started. Previously I couldn't think of a way to do this without also involving other things and terribly ugly and inefficient forms of abuse. Without proper string manipulation this is limited to the only sort of file ChucK can deal with properly being ChucK code, yes.... Still no parsing of strings by groups of letters to feed to the speech synth for example(I'd like that...). But, this *would* allow for permanent storage of -say- patterns of ChucKian sequencers. It's a small thing, I admit, in retrospect I have no idea why I didn't think of it earlier but it also sound like a usefull thing so that's why I shared it. Yours, Kas.
You're right, we need a lot more... This little trick isn't meant as a replacement for anything but what it *could* do is allow one to quickly store something in a way that will survive the end of the VM and being able to get it back in there next time ChucK is started. Previously I couldn't think of a way to do this without also involving other things and terribly ugly and inefficient forms of abuse.
Hello self-modifying code... ;-)
Without proper string manipulation this is limited to the only sort of file ChucK can deal with properly being ChucK code, yes.... Still no parsing of strings by groups of letters to feed to the speech synth for example(I'd like that...). But, this *would* allow for permanent storage of -say- patterns of ChucKian sequencers.
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.) Steve
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
--- Scott Wheeler
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.
That would be very cool. Anyway to quickly wrap some native C string-parsing functions as well? :-) -- robin
participants (4)
-
Kassen -
robin.escalation -
Scott Wheeler -
Stephen Sinclair