[PD] Fwd: [coll] bug

[Roman Haefeli]

On Mon, 2017-01-30 at 21:10 +0100, IOhannes m zmölnig wrote:
> On 01/30/2017 08:42 PM, Roman Haefeli wrote:
> > 
> > On Mon, 2017-01-30 at 15:20 -0200, Alexandre Torres Porres wrote:
> >  
> > > 
> > > > 
> > > > Doing Uzi with 100k generated entries into coll object in Max
> > > > and I
> > > > get guaranteed crashes from these on both 6 and 7.
> > > > 
> > > well, I tested opening a file with 300k entries in Max 7 and got
> > > no
> > > audio crash/choke... it loaded the file fine, taking a bit under
> > > 500ms and the audio wasn't interrupted. I also had a block size
> > > of 1
> > > and audio I/O of 32 samples, highest CPU consuming setting
> > > possible,
> > > it was around 13%
> > Sounds like Max' [coll] is threaded, otherwise taking 500ms for a
> > task
> > without interrupting audio at this low latency setting would be a
> > contradiction. 
> > 
> well, it could do piecewise processing: just read a few lines per DSP
> tick.
> if systemcalls are involved, it's hard to predict the behaviour
> though.
> (e.g. rather than giving a single dropout, it could as well create
> multiple dropouts).

Right. Either way - and probably more important - it seems when using
[coll] in Max, determinacy is lost, which was the main point people
argued about.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170130/6bc3563d/attachment-0001.sig>