[PD] buffer and performance woes on OSX

[Jesse Mejia]

Thanks! Moving the midi out to a separate patch - in a separate instance. (from a copy/pasted pd application) solved my problems. I’m sending OSC between the two patches and everything is smooth.

But I still wonder if there’s a way to do this from within one instance. Pd~ seems to only separate the dsp processes - but my problem was actually with midi output. It would be great if there’s a way to prioritize and/or specificy threading for abstractions.

-Jesse

> On Jun 21, 2016, at 2:37 PM, Alex <x37v.alex at gmail.com> wrote:
> 
> If the audio logic is exclusively dependent on the midi input and the midi output is also exclusively dependent on the midi input you could potentially separate the midi output into its own process and run it independently of the audio?
> 
> If they're instead both dependent on some processed version of the midi, but not on each-other, you could do the processing in one of the processes then still generate your audio/midi out independently.
> 
> -Alex
> 
> 
> On Tue, Jun 21, 2016 at 1:51 PM, Jesse Mejia <jmejia at anestheticaudio.com <mailto:jmejia at anestheticaudio.com>> wrote:
> 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160621/f073810c/attachment.html>