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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 > _______________________________________________ > [email protected] <mailto:[email protected]> mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > <https://lists.puredata.info/listinfo/pd-list> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
