hi all first of all thanks for the answers Kassen wrote:

here i am again with a couple of questions : A : is it possible to quit Chuck from Chuck? I need to quit chuck when a certain osc message arrives, and i was wondering if there is a command to do this.

How about using the comand (forgot it's name) to call something from the OS and use it to call "chuck --kill"?

B: can i store references to functions in variables? similar to the python: def myfunc(): dowhatever myvar = myfunc myvar()

I don't think so, since they aren't objects they can't be asigned (to my knowledge). As a work around you could write a function that would have the new name and just pass on the variables to the older one? I don't realy understand the purpose from your example though.

I explain below my problem and why i wanted to assign a function to a variable i am trying to understand how to structure a complex OSC communication with several incoming message types. Because i am new to ChucK i am still trying to understand the chuckian way of doing things, and my paradigm at the moment is python which is the language i use all the time. I am using something like this to deal with the OSC at the moment but which few more message types ///////////////////////////////////////////// // two type of incoming messages in this example -> /pitch and /quit 1 => float pitch; OscRecv recv; 9000 => recv.port; recv.listen(); recv.event("/pitch, f") @=> OscEvent pitch_osc; recv.event("/quit, i") @=> OscEvent quit_osc; spork ~ oscshred(pitch_osc, "pitch"); spork ~ oscshred(quit_osc, "quit"); fun void oscshred(OscEvent e, string s){ while(true){ e => now; while(e.nextMsg() != 0){ if (s=="quit"){ <<<"quiting chuck here">>>; } if (s=="pitch"){ e.getFloat() => pitch; // put incoming value into var <<<"pitch", pitch>>>; } } } } //main loop while ( true ){ 0.2::second => now; } ///////////////////////////////////////////////// So for each message i spork a shred with the event and a string as id, then i check for the string id when a message arrives and trigger some action. It looks stupid to me to have to check for the string value in all of them. Another issue that sounds weird as well is that I need to have few more messages (around 40). The only difference between all those shreds is the action the need to perform so i wanted to declare a variable for each and pass it as a reference when sporking the shread. Something like fun quit(){Machine.crash();} spork ~ oscshred(quit_osc, quit); //passing ref to function fun void oscshred(OscEvent e, func f){ while(true){ e => now; while(e.nextMsg() != 0){ f(); //triggering function, different for each } } But this is impossible then. Couple of more questions, this time about OSC. is it possible to receive arrays? is it possible to check for the beginning of the address and redirect the rest? (like in PD with the OSCroute object, it checks for first part of address, in /sampler6/pitch would check for /sampler6 and if this matches then it sends the rest somewhere else. Sorry if the questions are stupid i am just trying to get my head around Chuck. thanks enrike

Hope that was of some help, Kas.

------------------------------------------------------------------------

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Spencer Salazar wrote:

On Nov 8, 2006, at 10:39 AM, altern wrote:

...

The only difference between all those shreds is the action the need to perform so i wanted to declare a variable for each and pass it as a reference when sporking the shread.

[...]

But this is impossible then.

Au contraire! As Ge mentioned, you can achieve the same result using polymorphic inheritance. Practically, this would mean defining an abstract base class like this:

class OscAction { fun void action() { } }

and then, for each actual action, define a corresponding subclass that "overloads" the action function:

class QuitAction extends OscAction { fun void action() { Machine.crash(); } }

class DoSomethingElseAction extends OscAction { fun void action() { /* do something else */ } }

Define oscshred like this: fun void oscshred( OscEvent e, OscAction a )

call spork ~ oscshred( quit_osc, new QuitAction );

to start up the quit listener and then call a.action() to actually execute the action when you receive the appropriate OSC message.

hope this helps/makes sense.

sure! now i understand. thanks!

I just needed this, setting variable off to 1 exits the main loop. I am still confused with ChucK ;) so i guess i did not asked the question in the right way. 0=>int off; while(true){ if(off){break;} 0.2::second => now; } Kassen wrote:

Hi, list,

I'd like to come back to quitting ChucK from within ChucK for a second because I was thinking about it before going to sleep.

If for a moment we asume we realy want to do it from withingChucK and so ignore asking the OS and we don't like crashing then the only thing left is killing all shreds by ID. This would be fine except that you can't get the highest shred id.

I thought of a little trick that might be of some use or entertainment value. What could be done is writing a seperate file that uppon entering the VM would ask the VM for it's own shred ID (which would be the highest one at that point), then kill every shred up to that number without advancing time.

It would be quite important to do this as a machine.add of a seperate file and not as a sporked function because part of the problem is that if we would kill the parent in that case that would also be the end of our "killer". It would also be important to have the shred that would add this file yield right after doing so to avoid other processes adding more files in the meantime; anything that's not a child shred and has a id over the killer shred's would survive.

Advantages; will kill everything in the VM without calls to the OS or crashes, doesn't require all code to be prepared for this. Disadvantage; will leave a empty VM in case it was told to "--loop".

Note from personal experience; if you make a way to kill the whole system in a setup that also uses MIDI it's best to first end all MIDI notes....

Might be of use to someone, some time, so I thought I'd share.

Kas.

------------------------------------------------------------------------

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

:) but your way doesnt block the loop! how come? 0 => float off; while (true){ if(off){break;} } locks the loop i am not sure why, but 0=>int off; while(!off){ 0.2::second => now; } does not lock it. Or thats what it seems to me... any reason for this? thanks! enrike joerg piringer wrote:

altern wrote:

...

I just needed this, setting variable off to 1 exits the main loop. I am still confused with ChucK ;) so i guess i did not asked the question in the right way.

0=>int off; while(true){ if(off){break;} 0.2::second => now; }

you could even write:

0=>int off;

while(!off) { 0.2::second => now; }

best joerg

:( but it bloks the main loop ... altern wrote:

I just needed this, setting variable off to 1 exits the main loop. I am still confused with ChucK ;) so i guess i did not asked the question in the right way.

0=>int off; while(true){ if(off){break;} 0.2::second => now; }

Kassen wrote:

...

Hi, list,

I'd like to come back to quitting ChucK from within ChucK for a second because I was thinking about it before going to sleep.

If for a moment we asume we realy want to do it from withingChucK and so ignore asking the OS and we don't like crashing then the only thing left is killing all shreds by ID. This would be fine except that you can't get the highest shred id.

I thought of a little trick that might be of some use or entertainment value. What could be done is writing a seperate file that uppon entering the VM would ask the VM for it's own shred ID (which would be the highest one at that point), then kill every shred up to that number without advancing time.

It would be quite important to do this as a machine.add of a seperate file and not as a sporked function because part of the problem is that if we would kill the parent in that case that would also be the end of our "killer". It would also be important to have the shred that would add this file yield right after doing so to avoid other processes adding more files in the meantime; anything that's not a child shred and has a id over the killer shred's would survive.

Advantages; will kill everything in the VM without calls to the OS or crashes, doesn't require all code to be prepared for this. Disadvantage; will leave a empty VM in case it was told to "--loop".

Note from personal experience; if you make a way to kill the whole system in a setup that also uses MIDI it's best to first end all MIDI notes....

Might be of use to someone, some time, so I thought I'd share.

Kas.

------------------------------------------------------------------------

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users