[chuck-users] osc listener shred woes

[mike clemow]

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