[chuck-users] osc listener shred woes
mike clemow
gelfmuse at gmail.com
Mon Apr 28 16:18:17 EDT 2008
Hey folks,
So, using a combination of suggestions, I have arrived at a much
simpler version of the code that seems to work great. I haven't
scaled it up to grab all 14 OSC message types, but I think that I'm in
a much better place to do so at this point. I might have too many
me.yield() calls now, actually, but it works tons better.
thanks again!
mike
---
8000 => int oscport;
// the messages for the osc objects
"/leftraw, i" => string leftraw;
"/leftavg, i" => string leftavg;
spork ~ oscListener( oscport, leftraw );
me.yield();
spork ~ oscListener( oscport, leftavg );
me.yield();
SinOsc raw => dac;
SinOsc avg => dac;
// a generic osc listener shred
fun void oscListener( int port, string osctype ) {
// create our OSC receiver
OscRecv recv;
port => recv.port;
recv.listen();
int val;
string type;
// create an address in the receiver, store in new variable
recv.event( osctype ) @=> OscEvent oe;
while( true ) {
// wait for osc event to arrive
oe => now;
while( oe.nextMsg() ) {
oe.getInt() => val;
osctype => type;
if( type == leftraw ) {
val => raw.freq;
}
else if( type == leftavg ) {
val => avg.freq;
}
me.yield();
}
}
}
while( true ) {
1::second => now;
}
On Mon, Apr 28, 2008 at 2:43 PM, mike clemow <gelfmuse at gmail.com> wrote:
> Wow, okay... Trying to make sense of this...
>
>
> > Actually, come to think of it, Mike, why have the Bang object at all? Why
> > not just move the code (the if statements) from the main loop into the
> > oscListener loops/shreds, and replace the broadcast with actual
> > functionality instead? Maybe there is some more advanced stuff that you
> > haven't included that prevents this?
>
> No, the only thing that I left out were the spork lines for the other
> 12 OSC listeners I need. :)
>
> I guess the answer to your question is that I never thought of doing
> that because I'm still trying to wrap my head around Chuck's notions
> of scope. What you're indirectly telling me is that it's possible to
> access my SinOsc objects (and indeed my whole patch) from the other
> shreds, which I imagined would not be possible because of scope
> limitations. However, considering how classes work, I'm clearly not
> fully grasping reality here. I thought that the only way I could
> share data between shreds was an event.
>
> Kassen, I completely forgot about me.yield(), which makes me feel
> pretty dumb. But I guess concurrency is not as simple as Chuck leads
> me to believe!
>
> Dan, thanks for pointing out the bug. Honestly, I seem to remember
> running into issues where if I had one OSC message with a signature of
> "/test, i" and another with a signature of "/mike, i" and both were
> coming in on the same port, that Chuck couldn't tell the difference
> between them for some reason. I remember fixing this with multiple
> listeners on multiple ports. Perhaps I was doing something else
> wrong.
>
> I'm going to mess around with these excellent suggestions and get back
> to you all. (sadly, this is all due today. oh well.)
>
> Thanks!
> Mike
>
>
>
>
>
> On Mon, Apr 28, 2008 at 12:10 PM, Stefan Blixt <stefan.blixt at gmail.com> wrote:
> > Actually, come to think of it, Mike, why have the Bang object at all? Why
> > not just move the code (the if statements) from the main loop into the
> > oscListener loops/shreds, and replace the broadcast with actual
> > functionality instead? Maybe there is some more advanced stuff that you
> > haven't included that prevents this?
> >
> > /Stefan
> >
> >
> >
> > On Mon, Apr 28, 2008 at 6:00 PM, Stefan Blixt <stefan.blixt at gmail.com>
> > wrote:
> > > Yeah, but note that there are two shreds running this loop in parallell.
> > So if one event on each port arrive at the same time, chances are that the
> > first yield will hand over execution to the second shred, that in turn
> > overwrites b.value and b.message. I think you need at least two Bang
> > instances to be sure that this doesn't happen.
> > >
> > > /Stefan
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Apr 28, 2008 at 5:10 PM, Kassen <signal.automatique at gmail.com>
> > wrote:
> > >
> > > >
> > > >
> > > >
> > > > 2008/4/28 Stefan Blixt <stefan.blixt at gmail.com>:
> > > >
> > > >
> > > >
> > > > > I don't know about the segv signal, but it seems to me that there is
> > only one Bang instance that is shared by all iterations/shreds. This means
> > that if two events arrive at this loop:
> > > > >
> > > > >
> > > > > while( oe.nextMsg() ) {
> > > > > oe.getInt() => b.value;
> > > > > osctype => b.message;
> > > > > b.broadcast();
> > > > > }
> > > > >
> > > > > the second's values will overwrite those of the first (value and
> > message from the first event will be lost).
> > > >
> > > > I think that's right and I think the way around this would be
> > > >
> > > >
> > > > while( oe.nextMsg() ) {
> > > > oe.getInt() => b.value;
> > > > osctype => b.message;
> > > > b.broadcast();
> > > > //yield to receiving shreds,
> > > > //then continue processing the message cue
> > > > me.yield();
> > > > }
> > > >
> > > > This is the exact same principle I talked about earlier in this topic;
> > if you don't yield you don't give the waiting shreds a chance to run.
> > Advancing time here would probably not be a good idea.
> > > >
> > > > Yours,
> > > > Kas.
> > > >
> > > >
> > > > _______________________________________________
> > > > chuck-users mailing list
> > > > chuck-users at lists.cs.princeton.edu
> > > > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Release me, insect, or I will destroy the Cosmos!
> >
> >
> >
> > --
> > Release me, insect, or I will destroy the Cosmos!
> > _______________________________________________
> > chuck-users mailing list
> > chuck-users at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> >
> >
>
>
>
> --
> http://semiotech.org
>
--
http://semiotech.org
More information about the chuck-users
mailing list