[PD] loadbang for externals

[Miller Puckette]

Hi Olaf and all,

Yes, DSP and "event" computations have the same priority, and the order
in which they are carried out is deterministic (so that DSP doesn't
interrupt event processing, for example.)  There's only one thread, although
nothing stops objects from sprouting their own threads.  (but don't call
outlet_...() except from the "main" thread!)

Ther's something else wrong with your setup if long computations cause audio
to die  or Pd to crash.  You should be able to call "sleep(5)" from an object
and have Pd bounce back after 5 seconds as if nothing were wrong except a
DIO error.  If this isn't working it's wrong and I'd like to know what audio
hardware&drivers you're getting this  with...  

Sorry, I'm not sure windows has a "sleep" function, substiture a for loop
counting to 1000000000 for example.)

cheers
Miller

On Fri, Feb 22, 2002 at 07:17:43PM +0100, Olaf Matthes wrote:
> 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