questions on osc, events and multi-shredding
Hi List, Do I understand this correctly that I have to create an OscEvent for every single OSC method I want to listen for? The docs say I can use any valid OSC address pattern, but this does not seem to work. I have attached a (stupid) program that demonstrates the problem. So I need a separate shred for each OSC method? Which brings me to another thing I was wondering about lately: A shred can not wait for more than one event (including time passage) at the same time. So in many situtations, I will have no choice but to either do polling on a set of conditions, or create a separate shred for each event I am interested in. But this could be quite a large (theoretically infinit) number of shreds. Until now, I decided to use polling, but I was wondering if there was some kind of "proven pattern" that could be employed in such situations. What is the overhead of a shred anyway? Would it be a problem to create a *lot* of them? Like - let's say - a couple of thousands? From some primitive experiments, it seems that the creation involves some noticeable overhead, but I already had thousands of them running (well, mostly idle) without any problem. Are there any upper bounds? Otoh, is it a good idea to do polling in very short intervals, like the duration of one frame? Sorry, lots of questions. :-) Best Regards, --lu fun int sender(){ OscSend xmit; xmit.setHost("localhost",6449); while(true){ now + 1000::ms => now; xmit.startMsg("/test/bla", "i s"); 42 => xmit.addInt; "knarz" => xmit.addString; } } spork ~ sender(); OscRecv orec; 6449 => orec.port; orec.listen(); orec.event("/test/*, i s") @=> OscEvent e; while(true){ e => now; e.nextMsg(); <<<"event recieved!">>>; }
Hi Lu, just answering on regards to the code. Other questions might be addressed better by developers. There is 1 offending line, namely orec.event("/test/*, i s") @=> OscEvent e . This means your receiver is waiting for events of the form /test/*, which are never received for you are sending events / test/bla Trying to fix lu's code I realised that the following yields the same results: 1. xmit.startMsg("/test/bla", "i, s"); and xmit.startMsg("/test/ bla, i, s"); 2. orec.event("/test/bla", "i,s") @=> OscEvent e; and orec.event("/ test/bla, i,s") @=> OscEvent e; Should it be this way? eduard You may try this code, string words[]; ["foo", "bar", "foo2", "bar2"] @=> words; words.cap() => int size; size--; fun int sender(){ OscSend xmit; xmit.setHost("localhost",6449); 0 => int i; while(true){ now + 1000::ms => now; xmit.startMsg("/test/bla", "i, s"); i => xmit.addInt; //sending different ints to check it's receiving correct msgs words[i++ & size] => xmit.addString; // sending different strings } } spork ~ sender(); OscRecv orec; 6449 => orec.port; orec.listen(); orec.event("/test/bla, i,s") @=> OscEvent e; while(true){ e => now; e.nextMsg(); e.getInt() => int i1; e.getString() => string s1; <<<"event recieved!", i1, s1>>>; } On Mar 27, 2007, at 1:59 AM, Lukas Degener wrote:
Hi List,
Do I understand this correctly that I have to create an OscEvent for every single OSC method I want to listen for?
The docs say I can use any valid OSC address pattern, but this does not seem to work. I have attached a (stupid) program that demonstrates the problem. So I need a separate shred for each OSC method?
Which brings me to another thing I was wondering about lately: A shred can not wait for more than one event (including time passage) at the same time. So in many situtations, I will have no choice but to either do polling on a set of conditions, or create a separate shred for each event I am interested in. But this could be quite a large (theoretically infinit) number of shreds. Until now, I decided to use polling, but I was wondering if there was some kind of "proven pattern" that could be employed in such situations.
What is the overhead of a shred anyway? Would it be a problem to create a *lot* of them? Like - let's say - a couple of thousands? From some primitive experiments, it seems that the creation involves some noticeable overhead, but I already had thousands of them running (well, mostly idle) without any problem. Are there any upper bounds?
Otoh, is it a good idea to do polling in very short intervals, like the duration of one frame?
Sorry, lots of questions. :-)
Best Regards, --lu
fun int sender(){ OscSend xmit; xmit.setHost("localhost",6449); while(true){ now + 1000::ms => now; xmit.startMsg("/test/bla", "i s"); 42 => xmit.addInt; "knarz" => xmit.addString; }
} spork ~ sender();
OscRecv orec; 6449 => orec.port; orec.listen(); orec.event("/test/*, i s") @=> OscEvent e; while(true){ e => now; e.nextMsg(); <<<"event recieved!">>>; }
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi Eduard, thanks a lot for your input! eduard aylon schrieb:
There is 1 offending line, namely orec.event("/test/*, i s") @=> OscEvent e . This means your receiver is waiting for events of the form /test/*, which are never received for you are sending events / test/bla
I know. I also tried listening for a concrete address, and it works without any problem. It's just that the documentation makes it sound as if there was a way to listen at more than one address. http://chuck.cs.princeton.edu/doc/language/event.html states that "Each instance of OscRecv can create OscEvent objects using its event() method to listen for packets at any valid OSC Address pattern." but it seems the event() method actually expects concrete message addresses, not patterns. I am building an application where there are potentially a lot of parameters controlled via OSC. It would be interesting how other ChucKers deal with this kind of situation. Best regards, --lu
I am building an application where there are potentially a lot of parameters controlled via OSC. It would be interesting how other ChucKers deal with this kind of situation.
I started building a class to deal with this problem once. Of course, the *real* solution is to allow waiting on multiple events, but for now I'm using shreds. This was partly a response to the issues I brought up in this thread on the OSC list: http://www.create.ucsb.edu/pipermail/osc_dev/2007-February/001183.html Anyways, I thought it would be way more convenient to be able to just declare a class as being OscFloat and then use its value as needed, instead of having to set up an OscEvent for each parameter of my synth. Also, I wanted float values to also response to int messages. So here, I'm waiting on OscEvents in multiple shreds, but when OSC messages are received, the shreds wake up a shared Event using broadcast. This makes it work much nicer with Pd, which has a tendency to send either float or int messages, depending on the value. I understand that this issue is under consideration. The chuck language specification currently has no way to wait on multiple events, partly because events are waited on using the "chuck" operator (=>), which can only have one left-hand and one right-hand parameter. One way might be to support some sort of Pythonic "list" structure, like this: [event1, event2, event3] => now; Steve
I found an old thread on this mailing list which deals with a similar problem: https://lists.cs.princeton.edu/pipermail/chuck-users/2005-October/000100.htm... Afaics, all those problems can be solved once it is possible to wait for more than one event. I already saw it on some Todo-list somewhere, so, hm.... when is the next release comming? ;-) Cheers, --lu
to use only 1 shred you can send your messages to a base-adress, and pack
the
sub-adresses into an argument. not nice, but works.. this way you still can
not use adress patterns.
but share 1 shred for many message receivers (with the same signature of
course..)
short example:
// the receiver:
OscRecv rec;
6449 => rec.port;
rec.listen();
rec.event("/BaseAdress,si") @=> OscEvent BaseEvent;
while ( true )
{
BaseEvent => now;
while( BaseEvent.nextMsg() != 0 )
{
BaseEvent.getString() => string adress;
BaseEvent.getInt() => int value;
if(adress == "SubAdress1")
{
<<<"reveived on SubAdress1:", value>>>;
}
else if(adress == "SubAdress2/SubSub")
{
<<<"reveived on SubAdress2/SubSub:", value>>>;
}
}
}
// the sender:
while( true )
{
sender.startMsg( "/BaseAdress", "si" );
sender.addString("SubAdress1");
sender.addInt(1);
2::second => now;
sender.startMsg( "/BaseAdress", "si" );
sender.addString("SubAdress2/SubSub");
sender.addInt(2);
2::second => now;
}
2007/3/27, Lukas Degener
I found an old thread on this mailing list which deals with a similar problem:
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-October/000100.htm...
Afaics, all those problems can be solved once it is possible to wait for more than one event. I already saw it on some Todo-list somewhere, so, hm.... when is the next release comming? ;-)
Cheers, --lu _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- tazumi
participants (4)
-
eduard aylon -
Lukas Degener -
Stephen Sinclair -
tazumi