- 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