Re: [PD-dev] dynamic patching - is iemguts the way to go?

Yeah, maybe that is positive (reverb tails etc) but if not, you could put the control on the other end, send your signal into every effect in parallel and then mix in the one you want to hear selectively. Alex On August 20, 2019 7:06:10 PM PDT, Nick Porcaro wrote: >Hey x_nor, > >The problem

Re: [PD-dev] dynamic patching - is iemguts the way to go?

Hey x_nor, The problem with this approach is that you still have active signal processing going in each effect even if they are panned to zero (I assume) and you couldn’t change the running order of effect1 and effect2. Thanks for thinking on it though. I’m going to study Miller’s responses

Re: [PD-dev] dynamic patching - is iemguts the way to go?

another approach could be to generate all the permutations of your effects as abstractions and simply route audio to a permutation selectively like you would with a speaker with an N-channel panner. [adc~] | [pan control] | | [pan~ ] | | [effect1~]

Re: [PD-dev] dynamic patching - is iemguts the way to go?

actually I wrote that before I thought the whole thing out :) No, if you "tick" a pdlib instance you tick all the patches in it - so teh way to get different patches in different orders is to call up a separate Pd instance for each of them, and use "adc~" and "dac~" objects to get audio in and

Re: [PD-dev] dynamic patching - is iemguts the way to go?

On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote: > I think the way to do this in libpd is to open them all as separate > patches > within one instance of Pd (so that symbols are shared) and use > "tabsend" > and "tabreceive" to route signals to/from them, using shared names > like >

Re: [PD-dev] where is the search priority set?

On Sat, 2019-08-10 at 14:17 +0200, Dan Wilcox wrote: > > By working on Pd's manual, I can see the current priority is to > > look first > > in the directory containing the patch, then in the search paths. I > > still > > want to maintain that structure. I just think that the order of the > > paths

Re: [PD-dev] dynamic patching - is iemguts the way to go?

I think the way to do this in libpd is to open them all as separate patches within one instance of Pd (so that symbols are shared) and use "tabsend" and "tabreceive" to route signals to/from them, using shared names like "channel1" as both inputs and outputs so you can rearrange them in any order.

Re: [PD-dev] dynamic patching - is iemguts the way to go?

Thanks Jamie - have you been able to get it to run on iOS? > On Aug 20, 2019, at 4:57 AM, Jamie Bullock wrote: > > > This is possibly a bit more heavyweight solution than you’re looking for, but > you might want to look into the Integra Framework: >

[PD-dev] 0.50-0 released (windows 64bit release with "font" troubles)

Hi Miller, The 64bit release has font troubles. Two files are missing: bin/pdfontloader.dll (the 64bit one) font/DejaVuSansMono-Bold.ttf  (this one is the git repo and in is included in the 32bit release and is actually needed or we get an ugly render.) I attach "pdfontloader64.zip"

Re: [PD-dev] dynamic patching - is iemguts the way to go?

This is possibly a bit more heavyweight solution than you’re looking for, but you might want to look into the Integra Framework: https://github.com/BirminghamConservatoire/integra-framework It was specifically designed as module

Re: [PD-dev] dynamic patching - is iemguts the way to go?

My setup is a JUCE app that uses libpd. I load a patch that’s an effects chain, with each effect in it’s own abstraction that can be switch~’d to zero so it does not comsume processing when not in use. The solution I have now is to rename the abstractions to reflect a new processing order and

[PD-dev] dynamic patching - is iemguts the way to go?

Hey Folks, It’s been a while since I’ve done any hard core work with Pd but that time has come again, and I’m glad to be back on the scene! In the project I’m working on I need to be able to reconfigure the processing order of DSP objects in a given patch on the fly: For example, from this: