Hi Miller, hi all,
I've a question concerning the 'timing' of pd. I once had difficulties to load several soundfiles into arrays using loadbang. Pd reported "audio I/O stuck..." and crashed. A workaround was to delay the loadbang by several ms each before loading the next soundfile. Now I have problems with my oggcast~/oggamp~ externals when connecting to the server via the net. Using a "connect" message sort of stops pd, i.e. audio out stops and goes on after the connection has been established. But sometimes pd crashes reporting the same "audio I/O stuck..." as last message... My question now is if this is due to the architecture of Pd and if there are any ways to avoid it. I allways thought only the perform routine to be time critical but now I begin to realise that everything has to fit inbetween two dsp calls. Is this right? If yes, is there no multithreading inside Pd (in the windows version) to have non-signal routines running in a second thread? (my externals use multithreading just for encoding / decoding and data transmission via TCP since this would halt the performe routine)
Olaf
Miller Puckette schrieb:
There is a problem in that Pd doesn't warn objects properly when they're getting freed... the free() routine gets called right before the object is destroyed adn you don't have a chance to open a save() dialog if you want to save internal state separately. I want to fix that for a future release.
cheers Miller