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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
