[chuck-users] osc listener shred woes

[Stefan Blixt]

Sorry if I came across as a big arrogant earlier - it's an interesting
problem. I got to thinking while walking home from work if you couldn't use
some polymorphic class setup. Here's a thing i tried:
----------------------------------

class OscListener {

fun void listenOnOsc(string msg, int port) {

OscRecv recv;

port => recv.port;

recv.listen();

recv.event(msg) @=> OscEvent oe;

while (true) {

oe => now;

while (oe.nextMsg()) {

receiveEvent(oe);

}

}

}

fun void receiveEvent(OscEvent oe) {

}

}


SinOsc raw => dac;

SinOsc avg => dac;


//---- Listen on OSC for raw

class ListenOnRaw extends OscListener {

fun void receiveEvent(OscEvent oe) {

<<< "Received raw event" >>>;

oe.getInt() => raw.freq;

}

}

ListenOnRaw listenOnRaw;

spork ~ listenOnRaw.listenOnOsc("/leftraw/press,i", 8000);


//---- Listen on OSC for avg

class ListenOnAvg extends OscListener {

fun void receiveEvent(OscEvent oe) {

<<< "Received avg event" >>>;

oe.getInt() => avg.freq;

}

}

ListenOnAvg listenOnAvg;

spork ~ listenOnAvg.listenOnOsc("/leftavg/press,i", 8001);


while (true) {

1::second => now;

}
----------------------------------
I tried out a modified version of this code - I only have one OSC-sending
device that sends three parameters - but I think it should work. However you
do this, I agree that it amounts up to a lot of code for each kind of OSC
message, but I guess it can't be avoided.

Hope you get everything in order for the installation!

/Stefan

On Mon, Apr 28, 2008 at 8: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
> _______________________________________________
> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080428/f1da7366/attachment.html>