Hi list,
I’m having some performance problems - clicks/dropouts when I feed my patch too much note concurrency by way of midi input into some [clone]d karplus strong abstractions among other things - but only when I’m concurrently sending midi out.
I’m finding that the audio settings menu hangs PD depending on what buffer size I choose. I’m only able to choose 64 or 128.
Typically I would increase buffer size to compensate - but the only other buffer setting that doesn’t hang pd is 128 and it actually gives me even more dropouts. I’ve tried playing around with block~ but couldn’t really get that helping either.
'defeat real-time scheduling' seems to help things somewhat. and running -rt didn’t seem to do anything either way.
-nogui also didn’t help
I’m using a fairly unimpressive 2-core mac mini.. and I do have about 1/2 of my DSP running in a pd~ instance
so maybe I just need to run this on a more powerful machine.
I’m sending a fair amount of midi data via ctlout to some micro controllers. Basically the more note-ins my patch receives - the more ctlout data it sends. Removing that part of the patch makes the dsp blocking clicks go away - but it seems like the midi out shouldn’t be interfering with audio so much. Is there a way to make PD prioritize the audio over the midi output? It would be great if I could wrap the midi output stuff in a lower priority abstraction somehow… I don’t think pd~ helps me there because there isn’t actually any DSP in the midi output abstraction - just control data...
OSX 10.11.1 (el capitan)
Pd 0.47.1
Motu 24AO (though it was experiencing audio blocking and also lock ups on the audio settings panel w/ the internal interface as well)
Any tips?
-Jesse
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list