<div dir="ltr"><div>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?<br><br></div><div>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.<br><br></div><div>-Alex<br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 1:51 PM, Jesse Mejia <span dir="ltr"><<a href="mailto:jmejia@anestheticaudio.com" target="_blank">jmejia@anestheticaudio.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi list,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
'defeat real-time scheduling' seems to help things somewhat. and running -rt didn’t seem to do anything either way.<br>
-nogui also didn’t help<br>
<br>
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<br>
so maybe I just need to run this on a more powerful machine.<br>
<br>
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...<br>
<br>
OSX 10.11.1 (el capitan)<br>
Pd 0.47.1<br>
Motu 24AO (though it was experiencing audio blocking and also lock ups on the audio settings panel w/ the internal interface as well)<br>
<br>
Any tips?<br>
<br>
-Jesse<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div><br></div></div>