[chuck-users] ChucK and Processing

[Arthur Clemens]

> - It should be possible to start and stop the ChucK VM in Processing,
> but no stop handlers are called at closing the app, leaving the VM in
> the air. I understand this is an issue with Java applets.
>
> Yes, this is a bit mysterious to me. The way to go about this would  
> be staring ChucK using either "chuck --loop" or by feeding it a  
> file like this; "ChucK myfile.ck " using a file that will keep  
> running. The ChucK VM should exit after you give the system a  
> command to "chuck --kill" or after the last shred has been removed  
> from it (if it's not set to --loop). If it doesn't properly exit  
> after either then that would probably be a bug. I don't see how  
> applets would affect this as this would be something between the OS  
> and ChucK, ChucK shouldn't be affected by what sort of thing send  
> those system calls. Strange.


No, this is just because of the way applets are quit in Java. If  
'chuck --kill' is sent the processed are killed normally, so ChucK  
behaves predictable


> - I would have liked to use 1 FilePlayer class that is loaded only
> once into the VM, but I have not found a way to do this. Either:
>     1) call 'chuck fileplayer.ck' before demo files are called causes
> errors on running the demo files that FilePlayer is unknown
>     2) for every demo file call 'chuck fileplayer.ck
> chuckdemo.ck:all:sorts:of:params' causes an error that FilePlayer is
> already in the global VM space and this will stop the demo file from
> running
>
> I looked at your code for a bit and noticed you wrote a public  
> class in one file, then redefined the class in another...

The public class not used in the demo, but I kept the file because  
that is the way I would ideally solve it.

What I do in Processing is:
1) start chuck with 'chuck --loop' (because Processing will not quit  
the process I start it from the command line)
2) add the fileplayer class with 'chuck -add fileplayer.ck'
3) for each of the sound files, add it with 'chuck -add  
chuckdemo.ck:with:a:lot:of:params'

This is the order the commands are sent to ChucK. But what I get back  
is:
$ chuck --loop
[chuckdemo.ck]:line(43): undefined type 'FilePlayer'...
[chuckdemo.ck]:line(43): ... in declaration ...
[chuckdemo.ck]:line(43): undefined type 'FilePlayer'...
[chuckdemo.ck]:line(43): ... in declaration ...
[chuckdemo.ck]:line(43): undefined type 'FilePlayer'...
[chuckdemo.ck]:line(43): ... in declaration ...
[chuckdemo.ck]:line(43): undefined type 'FilePlayer'...
[chuckdemo.ck]:line(43): ... in declaration ...
[chuck](VM): sporking incoming shred: 1 (fileplayer.ck)...

So even if 'fileplayer.ck' is called earlier, it is added last to the  
VM. First the chuckdemo.ck files are run and they do not know any  
FilePlayer class at that time.
Note that the order varies at each run. Sometimes the FilePlayer  
class is added second or third, sometimes first.

I don't know if this is because of the way Java calls the processes,  
or if class initialization in ChucK happens after file processing.

So I would be fine if I could call for each file: 'chuck -add  
fileplayer.ck chuckdemo.ck:with:a:lot:of:params', but after the first  
file ChucK is bailing out:
	[fileplayer.ck]:line(1): class/type 'FilePlayer' is already defined  
in namespace 'global'
why can't it just ignore this?

Arthur


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070903/ae69d539/attachment-0001.htm