[Fluxus] OSC interestingness

[Dave Griffiths]

On Thu, 2009-01-15 at 18:39 +0000, evan.raskob [lists] wrote:
> Hi all,
> 
> I was just going straight through the fluxus manual when to got to  
> OSC.  I have a Max app that blasts OSC data describing pitch, volume,  
> etc of sound coming into the computer, and I noticed an odd flicker  
> in fluxus when I worked with the data.  What seems to be happening is  
> that when there is no osc data, fluxus returns 0 in (osc 0) and when  
> there is data, it doesn't toss data out - it keeps backlogging and  
> gets out of sync with the Max app.  That's a bit odd - I can  
> understand why it would back up when too many messages are there  
> (although it should really discard them after a very short interval  
> so it stays in phase), but I would have thought that the the (when  
> (osc-msg "/xxx") ...) bit would prevent my program from getting osc  
> data that hasn't been set.  I hope this makes sense - I think  
> somewhere there is a bit where the current osc msg is set to 0 when  
> it is retrieved in a script, whereas I would rather it stay at the  
> same value until another osc message is received and overwrites the  
> previous value.  I can take a look at the actual C++ code tomorrow,  
> just thought I'd send this email tonight and see what people thought.

What you have to do is repeatedly call (osc-msg) until it runs out of
messages - and do this every frame, eg - if you are only interested in
one message per frame, just get the latest one:

(define (osc-last-msg path arg value)       
        (if (osc-msg path)   
            (osc-last-msg path arg (osc arg))       
            value))

The reason you have to do this yourself (it used to do it internally) is
that sometimes you need to parse every single osc message from a source
- eg with a gamepad I found doing the above meant I missed the
occasional message, which is obviously a problem if it's a key press.

There is currently a maximum of 256 messages stored for each path - it
could clear the queue for each message every frame, but it's a bit safer
this way I think.

I'll update the docs on this point...

cheers,

dave


> 
> Cheers
> Evan
> 
> 
>