[chuck-users] segmentation fault / OSC

[Stephen Sinclair]

On Mon, Mar 30, 2009 at 1:09 PM, Stephen Sinclair <radarsat1 at gmail.com> wrote:
> 2009/3/30 Bozelos Dimitris <dbozelos at yahoo.gr>:
>> Hi Kassen,
>>
>> thanks a lot and sorry for the late reply I had trouble last days with the
>> latest fedora updates and wouldn't ChucK that much!
>>
>> FROM: Kassen
>>
>> Hey, Dimitris!
>>
>>>  For some reason I constantly get a "segmentation fault" fatal error
>>> sometimes just after some seconds I run my shreds. What does this mean?
>>
>> Typically it means you tried to address something that doesn't exist/ isn't
>> instantiated. It can also mean there is some bug in ChucK that affects you.
>>
>> Well, I found out that an accumulator that I had was causing the trouble. I
>> was receiving a variable through osc and doing (inside an infinite
>> time-loop) something like
>>
>> while( event.nextMsg() )
>> {
>>     event.getFloat() +=> a;
>> }
>>
>> I don't really know why it was crushing, it shouldn't. when I removed this
>> part everything was ok.
>>
>>> Once or twice I had an "OSC packet ...: buffer (or stack) overflow" error.
>>> Is there a buffer or a limit on the messages you send / receive?
>>
>> I don't know :¬)
>> I'm certain there must be some limit somewhere but I'm not sure what or
>> where it is.
>>
>> What probably happened here is that I was being sent the messages faster
>> than receiving them, so if I had an osc message coming every 100 ms and I
>> had
>>
>> while( true )
>> {
>>     while( event.nextMsg() ) { ... }
>>     1000::ms => now;
>> }
>>
>> the messages might have been accumulating so there was the buffer overflow.
>> Although it shouldn't be, I think.
>>
>> But I actually have a question here about the OSC events: is there any smart
>> way to have some code executed on an event independently of the time of the
>> infinite time-loop? To be more clear, let's say I have an BiQuad filter and
>> I want to control its frequency over the network through OSC. So,
>>
>> while( true )
>> {
>>     while( event.nextMsg() )
>>     {
>>         event.getFloat() => f.pfreq;
>>     }
>>
>>     // do other stuff
>>
>>     1::second => now;
>> }
>>
>> This have the consequence, if I'm not mistaken, that every 1 second chuck
>> will check for new messages and if messages are sent every 300 ms and for
>> some reason we need the loop to run every one second the frequency is
>> actually updated once a second with the last of the 3 received values
>> instead of 3 times a second.
>>
>> The only way around I can think now is to declare the filter in a public
>> class as a static object and have a separate shred that runs with a faster
>> time-loop and update the filter this way. But this might lead to
>> unreasonable many shreds like one for gain, one for frequency etc. Moreover
>> this will mean that I will be able to have only one BiQuad filter working
>> this way. So I see this solution highly problematic. Any ideas?
>
> Yo,
>
> You can wait on the event itself, so that your loop will wake up every
> time a message comes in.
>
> while( true )
> {
>    while( event.nextMsg() )
>    {
>        event.getFloat() => f.pfreq;
>    }
>    1::second => now;
> }
>
> If you need to "do other stuff", I suggest doing this event loop in a
> shred by sporking it.

Sorry, I intended to change the code after copying it:

fun void msg_freq() {
  while( true )
  {
     event => now;
     while( event.nextMsg() )
     {
         event.getFloat() => f.pfreq;
     }
  }
}

spork ~ msg_freq();