[chuck-users] osc listener shred woes
mike clemow
gelfmuse at gmail.com
Mon Apr 28 19:45:11 EDT 2008
Stefan,
> Sorry if I came across as a big arrogant earlier
You didn't come across as arrogant at all! I really appreciate your
feedback. I hadn't thought about using classes to encapsulate this
process. I think it's difficult to tell with only one or two OSC
messages which method scales better, although I imagine this is what
classes (as limited as they are in Chuck) are good for (i.e. making
scaling up less hairy).
I think that the me.yield() issue may also apply to your
implementation as well--Kassen, any thoughts?
Meanwhile, I now have multiple working options where before I had
none. So, thanks again!
cheers,
mike
On Mon, Apr 28, 2008 at 4:19 PM, Stefan Blixt <stefan.blixt at gmail.com> wrote:
> 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!
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>
--
http://semiotech.org
More information about the chuck-users
mailing list