Re: [chuck-users] segmentation fault / OSC

I have a faint memory that I have run into problems when not reading all parameters that are included in an event, or mismatching the actual event with the parameter list in the OscRecv constructor, or something. Say that whatever sends the OSC event that you are receiving in your code, Dimitris, adds two float parameters. You only read one, so the other remains somewhere. I can't reproduce this now locally, so I may just be rambling. A thought anyway. /Stefan On Mon, Mar 30, 2009 at 7:12 PM, Stephen Sinclair wrote:

...

2009/3/30 Bozelos Dimitris :

...

Hi Kassen,

thanks a lot and sorry for the late reply I had trouble last days with

...

...

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

...

...

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

...

...

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

On Mon, Mar 30, 2009 at 1:09 PM, Stephen Sinclair wrote: the trouble. I this 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(); _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!