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

To be more clear the answer was basically this: My original thought was this (which of course every reasonable person would assume ;-)) foreach enabled patch in the fx chain: tick this patch end But this could not work because “tick this patch” is something like this: pd->processFloat

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

OK folks all is well now - the solution to the problem is as I expected. As Miller said, pdlib ticks all the patches in question so if you just want to feed samples from one patch to another you have to make sure all the other patches are switched off. I had deceived myself by disabling them

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

Miller, et. al: I think I see the problem, this code would appear to tick ALL the patches in the pd instance: for (each buffer from the audio callback) { for (a smaller buffer that’s the pd block size (eg 64)) { pd->processFloat (oneTick, smallBufferIn, smallBufferOut); } } So

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

Hi Miller- > On Aug 20, 2019, at 7:08 PM, Miller Puckette > wrote: > > 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

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

Thanks folks for your suggestions on this topic. I figured out a way to do it vanilla Pd with catch/throw/switch~. The key to figuring the problem out is to imagine a matrix where the x axis has outputs and the y axis has inputs. Each item in this matrix is a toggle switch that can turn on

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

Hi Nick, I made a vanilla abstraction called [DRFX] that builds a routing matrix for effects abstractions using dynamically created [send~]/[receive~] and [throw~]/[catch~] busses. You have to follow some basic naming conventions for the wireless audio busses of your inputs and effects, but then

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

> On 20 Aug 2019, at 18:09, Nick Porcaro wrote: > > Thanks Jamie - have you been able to get it to run on iOS? > iOS isn’t currently supported (only Windows and macOS). Other platforms are theoretically possible but there is no build system set up for them. In the case of iOS, it’s more a

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

An approach I've been using successfully is to put a [switch~] and some fade-in / fade-out mechanism (with appropriate delays to avoid audio artifacts) in all subpatches that need to be exclusively active. This way you can enable / disable them at will, and you will always only consume the

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] 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: >

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