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

Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.

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

That's what I suspected now.

<snip>

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.

This is very odd, I'm inclined to suspect Processing is sending the commands in the wrong order. What you could do is start ChucK using this;

chuck --loop fileplayer.ck

That should force it to be added at the right moment.

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?

Because (right now) you can't re-define existing public classes.

I don't quite understand why it won't add the second file after running the first has failed, there might be a good reason for that but I don't see it.

I'd sugest you try the sugestion of adding the public class to the VM at the time you start the VM, that should force the order to be the right way around, let's see where that gets us.

Yours,
Kas.