[chuck-users] chuck in a safe box?

[Stephen Sinclair]

On Tue, Jan 4, 2011 at 8:28 PM, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Tue, Jan 04, 2011 at 07:56:33PM -0500, Alan Yoder wrote:
>> thought comes to mind.
>> if the scripts run for a period of time to produce the mp3, and you
>> want a sound outside of that time range. your scripts will say no.
>> i just woke up from a nap, so am probably not being clear.
>> if you've got a 20 second piece, and your scripts say run for 10
>> seconds, those last 10 seconds are going to go away never to be
>> heard.
>
> Yeah, and playing around with this it'll require a bit of engineering to
> allow saving to mp3 files but not anything else.  Well I think I'll have
> to come up with a different approach then.

I think the trick would be to have an always-running shred in the
background, like:

while (1) {
  1::day => now;
}

Then you could continously stream the output, and people could spork
other stuf on the same VM and it would get mixed in.
Probably it wouldn't be that hard to compile a version of ChucK
without any access to the file system.

It might be nice to have some level of process control.  Like, list
the running shreds and be able to kill them... just in case someone
leaves something running and logs out.

(Oh! It might be nice to actually track which user spawned which shred
and kill them when he logs out.. that would take more work though.)

I've thought of this idea myself, I think it would be fun to have a
server running and be able to improvise with other people.

One problem is that if someone does something stupid like while(1){};,
then it will block everyone else's fun.  Some kind of processing cap
per shred should be imposed.

Steve