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

[Nick Porcaro]

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 (1, pdInBuffer.getData(), pdOutBuffer.getData());

Which has no reference to any patch, now does it? ;-)

So this is what you have to do:

foreach enabled patch in the fx chain: 
disable other patches 
tick this patch
   reenable other patches
end


- Nick



> On Sep 12, 2019, at 6:36 PM, Nick Porcaro  wrote:
> 
> 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 at a different level in my code.
> 
> Whew, that was close!
> 
> - Nick
> 
>> On Sep 12, 2019, at 6:09 AM, Nick Porcaro > > wrote:
>> 
>> 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 maybe it should be like this:
>> 
>> 
>> for (each buffer from the audio callback) {
>> for (a smaller buffer that’s the pd block size (eg 64)) {
>> // Do something here to disable the patches that are not active
>> // eg :
>> for (patches that are not this one) {
>> pd->sendFloat(“/patchName/enable",0);
>> }
>> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
>> }
>> }
>> 
>> The code above is a member function of a C++ class that encapsulates a patch.
>> I just realized as I was falling asleep for the night that this line is NOT 
>> specific
>> to any patch!
>> 
>> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
>> 
>> I’ll try something first thing tomorrow and I’ll let you all know what 
>> happens.
>> 
>> 
>> - Nick
>> 
>>> On Sep 12, 2019, at 4:56 AM, Nick Porcaro >> > wrote:
>>> 
>>> 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 call up a separate
 Pd instance for each of them, and use "adc~" and "dac~" objects to get
 audio in and out - that incurs zero latency (once you've buffered 64
 samples in the first place).
>>> 
>>> I tried this two ways:  
>>> 
>>> - Create separate Pd  instances for each patch wrapped in adc~ and dac~
>>> 
>>> - Use a single Pd  instance with multiple patches,  with each patch wrapped 
>>> in adc~ and dac~
>>> 
>>> Then I have a simple JUCE app (based on the sampler example) that drives
>>> these pd patches.
>>> 
>>> There is no problem with doing switch~ and such, but I am 
>>> getting distortion that seems like clipping in both cases (one pd instance 
>>> with many patches
>>> or multiple pd instances with one patch)
>>> 
>>> To be more clear these wrapper patches are like:
>>> 
>>> Patch 1: [adc~]   ->   [lop~ 200] -> [dac~]
>>> Patch 2: [adc~]   ->   [hip~ 200] -> [dac~]
>>> 
>>> These wrapper patches also have a loadbang to pd dsp 1;
>>> 
>>> Then the code that calls these patches does something like this calling 
>>> libpd:
>>> 
>>> for (each buffer from the audio callback) {
>>> for (a smaller buffer that’s the pd block size (eg 64)) {
>>> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
>>>   }
>>> }
>>> 
>>> I tried scaling the input and output to these  wrapper patches after the 
>>> adc~ and before the dac~
>>> and that does not solve the distortion/clipping problem either.
>>> 
>>> There are a couple of more things I can try:
>>> 
>>>- make the wrapper patches even simpler, just scaling instead of the 
>>> filters.
>>>- dump the samples to a file and maybe that will shed some light on the 
>>> problem.
>>>- making a much simpler example program that I can share will you all.
>>> 
>>> I have libpd and pd source directly compiled into my example
>>> 
>>> Any other ideas would be greatly appreciated!
>>> 
>>> 
 
 OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
 switched off, to control each sub-patch.  Send the switch~ objects bangs in
 whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
 be the simplemt way to pass signals between them.  In libpd you can do this
 zero-latency (just stuff your inpuits into arrays before sending all the

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

[Nick Porcaro]

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 at a different level in my code.

Whew, that was close!

- Nick

> On Sep 12, 2019, at 6:09 AM, Nick Porcaro  wrote:
> 
> 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 maybe it should be like this:
> 
> 
> for (each buffer from the audio callback) {
> for (a smaller buffer that’s the pd block size (eg 64)) {
> // Do something here to disable the patches that are not active
> // eg :
> for (patches that are not this one) {
> pd->sendFloat(“/patchName/enable",0);
> }
> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
> }
> }
> 
> The code above is a member function of a C++ class that encapsulates a patch.
> I just realized as I was falling asleep for the night that this line is NOT 
> specific
> to any patch!
> 
> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
> 
> I’ll try something first thing tomorrow and I’ll let you all know what 
> happens.
> 
> 
> - Nick
> 
>> On Sep 12, 2019, at 4:56 AM, Nick Porcaro > > wrote:
>> 
>> 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 call up a separate
>>> Pd instance for each of them, and use "adc~" and "dac~" objects to get
>>> audio in and out - that incurs zero latency (once you've buffered 64
>>> samples in the first place).
>> 
>> I tried this two ways:  
>> 
>> - Create separate Pd  instances for each patch wrapped in adc~ and dac~
>> 
>> - Use a single Pd  instance with multiple patches,  with each patch wrapped 
>> in adc~ and dac~
>> 
>> Then I have a simple JUCE app (based on the sampler example) that drives
>> these pd patches.
>> 
>> There is no problem with doing switch~ and such, but I am 
>> getting distortion that seems like clipping in both cases (one pd instance 
>> with many patches
>> or multiple pd instances with one patch)
>> 
>> To be more clear these wrapper patches are like:
>> 
>> Patch 1: [adc~]   ->   [lop~ 200] -> [dac~]
>> Patch 2: [adc~]   ->   [hip~ 200] -> [dac~]
>> 
>> These wrapper patches also have a loadbang to pd dsp 1;
>> 
>> Then the code that calls these patches does something like this calling 
>> libpd:
>> 
>> for (each buffer from the audio callback) {
>> for (a smaller buffer that’s the pd block size (eg 64)) {
>> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
>>   }
>> }
>> 
>> I tried scaling the input and output to these  wrapper patches after the 
>> adc~ and before the dac~
>> and that does not solve the distortion/clipping problem either.
>> 
>> There are a couple of more things I can try:
>> 
>>- make the wrapper patches even simpler, just scaling instead of the 
>> filters.
>>- dump the samples to a file and maybe that will shed some light on the 
>> problem.
>>- making a much simpler example program that I can share will you all.
>> 
>> I have libpd and pd source directly compiled into my example
>> 
>> Any other ideas would be greatly appreciated!
>> 
>> 
>>> 
>>> OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
>>> switched off, to control each sub-patch.  Send the switch~ objects bangs in
>>> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
>>> be the simplemt way to pass signals between them.  In libpd you can do this
>>> zero-latency (just stuff your inpuits into arrays before sending all the
>>> tick messages and copy the results out afterward).
>> 
>> This approach works well, but the problem is I can’t insert non-Pd signal 
>> processing
>> anywhere I’d like in the Pd patch so that’s why I went with the first 
>> approach.
>> 
>>> 
>>> Within the Pd app, you can do teh same thing but you incur one tick extra
>>> latency, because copying the autio into the tables has to happen on the
>>> previous tick form the one on which you get the outputs back.
>>> 
>>> If you like danger, you can write an external tilde object that, for its
>>> "dsp" action, sends a message to teh patch that can "tick" the switch~
>>> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
>>> because it could cause major confusion if general-purpose Pd messages
>>> got sent around 

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

[Nick Porcaro]

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 maybe it should be like this:


for (each buffer from the audio callback) {
for (a smaller buffer that’s the pd block size (eg 64)) {
// Do something here to disable the patches that are not active
// eg :
for (patches that are not this one) {
pd->sendFloat(“/patchName/enable",0);
}
pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
}
}

The code above is a member function of a C++ class that encapsulates a patch.
I just realized as I was falling asleep for the night that this line is NOT 
specific
to any patch!

pd->processFloat (oneTick, smallBufferIn, smallBufferOut);

I’ll try something first thing tomorrow and I’ll let you all know what happens.


- Nick

> On Sep 12, 2019, at 4:56 AM, Nick Porcaro  wrote:
> 
> 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 call up a separate
>> Pd instance for each of them, and use "adc~" and "dac~" objects to get
>> audio in and out - that incurs zero latency (once you've buffered 64
>> samples in the first place).
> 
> I tried this two ways:  
> 
> - Create separate Pd  instances for each patch wrapped in adc~ and dac~
> 
> - Use a single Pd  instance with multiple patches,  with each patch wrapped 
> in adc~ and dac~
> 
> Then I have a simple JUCE app (based on the sampler example) that drives
> these pd patches.
> 
> There is no problem with doing switch~ and such, but I am 
> getting distortion that seems like clipping in both cases (one pd instance 
> with many patches
> or multiple pd instances with one patch)
> 
> To be more clear these wrapper patches are like:
> 
> Patch 1: [adc~]   ->   [lop~ 200] -> [dac~]
> Patch 2: [adc~]   ->   [hip~ 200] -> [dac~]
> 
> These wrapper patches also have a loadbang to pd dsp 1;
> 
> Then the code that calls these patches does something like this calling libpd:
> 
> for (each buffer from the audio callback) {
> for (a smaller buffer that’s the pd block size (eg 64)) {
> pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
>   }
> }
> 
> I tried scaling the input and output to these  wrapper patches after the adc~ 
> and before the dac~
> and that does not solve the distortion/clipping problem either.
> 
> There are a couple of more things I can try:
> 
>- make the wrapper patches even simpler, just scaling instead of the 
> filters.
>- dump the samples to a file and maybe that will shed some light on the 
> problem.
>- making a much simpler example program that I can share will you all.
> 
> I have libpd and pd source directly compiled into my example
> 
> Any other ideas would be greatly appreciated!
> 
> 
>> 
>> OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
>> switched off, to control each sub-patch.  Send the switch~ objects bangs in
>> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
>> be the simplemt way to pass signals between them.  In libpd you can do this
>> zero-latency (just stuff your inpuits into arrays before sending all the
>> tick messages and copy the results out afterward).
> 
> This approach works well, but the problem is I can’t insert non-Pd signal 
> processing
> anywhere I’d like in the Pd patch so that’s why I went with the first 
> approach.
> 
>> 
>> Within the Pd app, you can do teh same thing but you incur one tick extra
>> latency, because copying the autio into the tables has to happen on the
>> previous tick form the one on which you get the outputs back.
>> 
>> If you like danger, you can write an external tilde object that, for its
>> "dsp" action, sends a message to teh patch that can "tick" the switch~
>> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
>> because it could cause major confusion if general-purpose Pd messages
>> got sent around in mid-tick.
>> 
>> cheers
>> Miller
>> 
>> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
>>> 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
 "channel1" as both inputs and outputs so you can rearrange them in
 any
 order.
 
 (Beware of allowing patches to _write_ andy of their output channels
 before
 reading all the input channels, if 

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

[Nick Porcaro]

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 call up a separate
> Pd instance for each of them, and use "adc~" and "dac~" objects to get
> audio in and out - that incurs zero latency (once you've buffered 64
> samples in the first place).

I tried this two ways:  

- Create separate Pd  instances for each patch wrapped in adc~ and dac~

- Use a single Pd  instance with multiple patches,  with each patch wrapped in 
adc~ and dac~

Then I have a simple JUCE app (based on the sampler example) that drives
these pd patches.

There is no problem with doing switch~ and such, but I am 
getting distortion that seems like clipping in both cases (one pd instance with 
many patches
or multiple pd instances with one patch)

To be more clear these wrapper patches are like:

Patch 1: [adc~]   ->   [lop~ 200] -> [dac~]
Patch 2: [adc~]   ->   [hip~ 200] -> [dac~]

These wrapper patches also have a loadbang to pd dsp 1;

Then the code that calls these patches does something like this calling libpd:

for (each buffer from the audio callback) {
for (a smaller buffer that’s the pd block size (eg 64)) {
pd->processFloat (oneTick, smallBufferIn, smallBufferOut);
  }
}

I tried scaling the input and output to these  wrapper patches after the adc~ 
and before the dac~
and that does not solve the distortion/clipping problem either.

There are a couple of more things I can try:

   - make the wrapper patches even simpler, just scaling instead of the filters.
   - dump the samples to a file and maybe that will shed some light on the 
problem.
   - making a much simpler example program that I can share will you all.

I have libpd and pd source directly compiled into my example

Any other ideas would be greatly appreciated!


> 
> OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
> switched off, to control each sub-patch.  Send the switch~ objects bangs in
> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
> be the simplemt way to pass signals between them.  In libpd you can do this
> zero-latency (just stuff your inpuits into arrays before sending all the
> tick messages and copy the results out afterward).

This approach works well, but the problem is I can’t insert non-Pd signal 
processing
anywhere I’d like in the Pd patch so that’s why I went with the first approach.

> 
> Within the Pd app, you can do teh same thing but you incur one tick extra
> latency, because copying the autio into the tables has to happen on the
> previous tick form the one on which you get the outputs back.
> 
> If you like danger, you can write an external tilde object that, for its
> "dsp" action, sends a message to teh patch that can "tick" the switch~
> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
> because it could cause major confusion if general-purpose Pd messages
> got sent around in mid-tick.
> 
> cheers
> Miller
> 
> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
>> 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
>>> "channel1" as both inputs and outputs so you can rearrange them in
>>> any
>>> order.
>>> 
>>> (Beware of allowing patches to _write_ andy of their output channels
>>> before
>>> reading all the input channels, if you're re-using the same channels
>>> as 
>>> inputs and outputs :)
>> 
>> Do I understand right: When loading them as separate patches, you can
>> dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]
>> (which you could with abstractions, too) _without_ adding latency?
>> 
>> And: When changing the symbol of [tabsend~] or [tabreceive~], is the
>> DSP graph re-calculated?
>> 
>> Roman
> 
> 
> 
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at 
>> https://lists.puredata.info/listinfo/pd-dev
> 
> 
> 
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at 
> https://lists.puredata.info/listinfo/pd-dev
> 
> 




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Nick Porcaro]

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 subpatches and 
allow
signals to conditionally pass through [~ *]  objects.

Instruments and effects can be in this matrix.  This is the way some analog 
synths work.
Turns out simple catch~ and throw~ were sufficent, I didn’t need tabread~ and 
tabwrite~

- Nick

> On Aug 21, 2019, at 6:26 PM, William Brent  wrote:
> 
> 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 you can 
> just tell [DRFX] the names of your inputs and effects and it creates a GUI 
> routing matrix to control effect processing order. You can also control 
> matrix switches via control send/receive names since it sounds like you won't 
> want a Pd GUI. It has messages for controlling fade in/out times so that you 
> can make transitions as desired, and there's also functionality for parameter 
> presets and exporting/loading routing and parameter presets from text files. 
> It's been very useful for my needs in multi-FX projects.
> 
> You can find it via deken or go to the repo here:
> https://github.com/wbrent/DRFX.git 
> The help patch and INSTRUCTIONS.pdf explain the basics if you want to check 
> it out and see if it's useful in your case.
> 
> William
> 
> 
> 
> On Tue, Aug 20, 2019 at 3:57 AM Nick Porcaro  > wrote:
> 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: 
> 
> [noise~]
> [lop~]
> [hip~]
> [dac~’
> 
> To this: 
> 
> [noise~]
> [hip~]
> [lop~]
> [dac~]
> 
> Of course this is a trivial example, but it’s not if you wanted to 
> arbitrarily reorder
> an effects chain with 30 objects in it.
> 
> I stumbled across this paper:
> 
> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
>  
> 
> 
> and this GitHub repo https://github.com/iem-projects/pd-iemguts 
> 
> 
> and it appears that iemguts might do what I need -
> 
> What do you all think?  
> 
> (I posted this to the patch~ section of the Pd forum as well, and there’s 
> some discussion going on).
> 
> - Nick
> 
> 
> 
> 
> 
> 
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at 
> https://lists.puredata.info/listinfo/pd-dev 
> 
> 
> 
> -- 
> William Brent
> www.williambrent.com 
> 
> “Great minds flock together”
> Conflations: conversational idiom for the 21st century
> 
> www.conflations.com 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[William Brent]

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 you can
just tell [DRFX] the names of your inputs and effects and it creates a GUI
routing matrix to control effect processing order. You can also control
matrix switches via control send/receive names since it sounds like you
won't want a Pd GUI. It has messages for controlling fade in/out times so
that you can make transitions as desired, and there's also functionality
for parameter presets and exporting/loading routing and parameter presets
from text files. It's been very useful for my needs in multi-FX projects.

You can find it via deken or go to the repo here:
https://github.com/wbrent/DRFX.git
The help patch and INSTRUCTIONS.pdf explain the basics if you want to check
it out and see if it's useful in your case.

William



On Tue, Aug 20, 2019 at 3:57 AM Nick Porcaro 
wrote:

> 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:
>
> [noise~]
> [lop~]
> [hip~]
> [dac~’
>
> To this:
>
> [noise~]
> [hip~]
> [lop~]
> [dac~]
>
> Of course this is a trivial example, but it’s not if you wanted to
> arbitrarily reorder
> an effects chain with 30 objects in it.
>
> I stumbled across this paper:
>
>
> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
>
> and this GitHub repo https://github.com/iem-projects/pd-iemguts
>
> and it appears that iemguts might do what I need -
>
> What do you all think?
>
> (I posted this to the patch~ section of the Pd forum as well, and there’s
> some discussion going on).
>
> - Nick
>
>
>
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>


-- 
William Brent
www.williambrent.com

“Great minds flock together”
Conflations: conversational idiom for the 21st century

www.conflations.com
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Jamie Bullock]

> 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 question of building the dependencies for iOS.

The benefits of using libIntegra over lower-level options are state saving and 
module introspection. You can automate the building of UI, for example by 
querying it for module attributes etc

Cheers,

Jamie

> 
>> 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: 
>> https://github.com/BirminghamConservatoire/integra-framework 
>> 
>> 
>> It was specifically designed as module management layer to sit between libPd 
>> (which it wraps) and an application, e.g. JUCE. An Integra “module” is 
>> basically a collection of Pd patches with some metadata wrapped in a ZIP 
>> file.
>> 
>> Happy to answer any questions.
>> 
>> Cheers,
>> 
>> Jamie
>> 
>> 
>>> On 20 Aug 2019, at 09:18, Nick Porcaro >> > wrote:
>>> 
>>> 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 then I reload the patch.  This works, but it’s a hack.  What’d 
>>> really be
>>> slick is if there was api in libpd for inspecting and editng a running 
>>> patch.
>>> 
>>> The goal is to minimize glitches on reloading the patch.  We do a similar 
>>> thing in 
>>> GeoShred http://www,moforte.com  in the effects 
>>> chain.  We use Faust for the signal processing
>>> in GeoShred.  There we essentially reorder a table of function pointers to 
>>> accomplish the reordering.
>>> 
>>> - Nick
>>> 
>>> 
 On Aug 20, 2019, at 3:47 AM, Nick Porcaro >>> > wrote:
 
 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: 
 
 [noise~]
 [lop~]
 [hip~]
 [dac~’
 
 To this: 
 
 [noise~]
 [hip~]
 [lop~]
 [dac~]
 
 Of course this is a trivial example, but it’s not if you wanted to 
 arbitrarily reorder
 an effects chain with 30 objects in it.
 
 I stumbled across this paper:
 
 https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
  
 
 
 and this GitHub repo https://github.com/iem-projects/pd-iemguts 
 
 
 and it appears that iemguts might do what I need -
 
 What do you all think?  
 
 (I posted this to the patch~ section of the Pd forum as well, and there’s 
 some discussion going on).
 
 - Nick
 
 
 
 
 
 
 
 ___
 Pd-dev mailing list
 Pd-dev@lists.iem.at 
 https://lists.puredata.info/listinfo/pd-dev 
 
>>> 
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at 
>>> https://lists.puredata.info/listinfo/pd-dev 
>>> 
>> 
> 

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Joseph Larralde]

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 processing power of the currently enabled subpatch.
Going into the details, if you want to cross-fade between patches x and 
y (instead of fading patch x out, then switch it off, then switch patch 
y on, then fade it in), you might get some cpu peaks if both patches 
consume a lot.
In many cases I don't need to cross-fade (sound continuity is not an 
issue), so this is a solution I've used in several systems.

Hope this is relevant to the discussion and might be of some help.

Joseph

Le 21/08/2019 à 07:10, Alex Norman a écrit :
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 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 and let you all know it goes-

- Nick


On Aug 20, 2019, at 7:26 PM, x nor mailto:x37v.a...@gmail.com>> wrote:

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~] |
|  [effect2~]
|   |
[mixer~  ]
|
[dac~]


generating abstraction by editing files as text is pretty simple,
patching each abstraction to a panner is probably pretty simple
with your text editor as well.

though, maybe you don't have enough processing power for it? 
but.. maybe you do?


On Tue, Aug 20, 2019 at 4:09 PM Miller Puckette mailto:m...@ucsd.edu>> 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 call
up a separate
Pd instance for each of them, and use "adc~" and "dac~"
objects to get
audio in and out - that incurs zero latency (once you've
buffered 64
samples in the first place).

OR, within one pd instance, in libpd or in Pd, you can use
switch~ objects,
switched off, to control each sub-patch.  Send the switch~
objects bangs in
whatever orders you wish.  In this scenario, tabsend~ and
tabreceive~ would
be the simplemt way to pass signals between them. In libpd
you can do this
zero-latency (just stuff your inpuits into arrays before
sending all the
tick messages and copy the results out afterward).

Within the Pd app, you can do teh same thing but you incur
one tick extra
latency, because copying the autio into the tables has to
happen on the
previous tick form the one on which you get the outputs back.

If you like danger, you can write an external tilde object
that, for its
"dsp" action, sends a message to teh patch that can "tick"
the switch~
objects right in the middle of Pd/s DSP tick. This is not
part of Pd
because it could cause major confusion if general-purpose Pd
messages
got sent around in mid-tick.

cheers
Miller

On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
> 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
> > "channel1" as both inputs and outputs so you can
rearrange them in
> > any
> > order.
> >
> > (Beware of allowing patches to _write_ andy of their
output channels
> > before
> > reading all the input channels, if you're re-using the
same channels
> > as
> > inputs and outputs :)
>
> Do I understand right: When loading them as separate
patches, you can
> dynamically re-order the signal flow by using

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

[Alex Norman]

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 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 and let you all know it goes-
>
>- Nick
>
>> On Aug 20, 2019, at 7:26 PM, x nor  wrote:
>> 
>> 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~] |
>> |  [effect2~]
>> |   |
>> [mixer~  ]
>> |
>> [dac~]
>> 
>> 
>> generating abstraction by editing files as text is pretty simple,
>patching each abstraction to a panner is probably pretty simple with
>your text editor as well.
>> 
>> though, maybe you don't have enough processing power for it?  but..
>maybe you do?
>> 
>> 
>> On Tue, Aug 20, 2019 at 4:09 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 call up a
>separate
>> Pd instance for each of them, and use "adc~" and "dac~" objects to
>get
>> audio in and out - that incurs zero latency (once you've buffered 64
>> samples in the first place).
>> 
>> OR, within one pd instance, in libpd or in Pd, you can use switch~
>objects,
>> switched off, to control each sub-patch.  Send the switch~ objects
>bangs in
>> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~
>would
>> be the simplemt way to pass signals between them.  In libpd you can
>do this
>> zero-latency (just stuff your inpuits into arrays before sending all
>the
>> tick messages and copy the results out afterward).
>> 
>> Within the Pd app, you can do teh same thing but you incur one tick
>extra
>> latency, because copying the autio into the tables has to happen on
>the
>> previous tick form the one on which you get the outputs back.
>> 
>> If you like danger, you can write an external tilde object that, for
>its
>> "dsp" action, sends a message to teh patch that can "tick" the
>switch~
>> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
>> because it could cause major confusion if general-purpose Pd messages
>> got sent around in mid-tick.
>> 
>> cheers
>> Miller
>> 
>> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
>> > 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
>> > > "channel1" as both inputs and outputs so you can rearrange them
>in
>> > > any
>> > > order.
>> > > 
>> > > (Beware of allowing patches to _write_ andy of their output
>channels
>> > > before
>> > > reading all the input channels, if you're re-using the same
>channels
>> > > as 
>> > > inputs and outputs :)
>> > 
>> > Do I understand right: When loading them as separate patches, you
>can
>> > dynamically re-order the signal flow by using
>[tabsend~]/[tabreceive~]
>> > (which you could with abstractions, too) _without_ adding latency?
>> > 
>> > And: When changing the symbol of [tabsend~] or [tabreceive~], is
>the
>> > DSP graph re-calculated?
>> > 
>> > Roman
>> 
>> 
>> 
>> > ___
>> > Pd-dev mailing list
>> > Pd-dev@lists.iem.at 
>> > https://lists.puredata.info/listinfo/pd-dev
>
>> 
>> 
>> 
>> 
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at 
>> https://lists.puredata.info/listinfo/pd-dev
>
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Nick Porcaro]

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 and 
let you all know it goes-

- Nick

> On Aug 20, 2019, at 7:26 PM, x nor  > wrote:
> 
> 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~] |
> |  [effect2~]
> |   |
> [mixer~  ]
> |
> [dac~]
> 
> 
> generating abstraction by editing files as text is pretty simple, patching 
> each abstraction to a panner is probably pretty simple with your text editor 
> as well.
> 
> though, maybe you don't have enough processing power for it?  but.. maybe you 
> do?
> 
> 
> On Tue, Aug 20, 2019 at 4:09 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 call up a separate
> Pd instance for each of them, and use "adc~" and "dac~" objects to get
> audio in and out - that incurs zero latency (once you've buffered 64
> samples in the first place).
> 
> OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
> switched off, to control each sub-patch.  Send the switch~ objects bangs in
> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
> be the simplemt way to pass signals between them.  In libpd you can do this
> zero-latency (just stuff your inpuits into arrays before sending all the
> tick messages and copy the results out afterward).
> 
> Within the Pd app, you can do teh same thing but you incur one tick extra
> latency, because copying the autio into the tables has to happen on the
> previous tick form the one on which you get the outputs back.
> 
> If you like danger, you can write an external tilde object that, for its
> "dsp" action, sends a message to teh patch that can "tick" the switch~
> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
> because it could cause major confusion if general-purpose Pd messages
> got sent around in mid-tick.
> 
> cheers
> Miller
> 
> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
> > 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
> > > "channel1" as both inputs and outputs so you can rearrange them in
> > > any
> > > order.
> > > 
> > > (Beware of allowing patches to _write_ andy of their output channels
> > > before
> > > reading all the input channels, if you're re-using the same channels
> > > as 
> > > inputs and outputs :)
> > 
> > Do I understand right: When loading them as separate patches, you can
> > dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]
> > (which you could with abstractions, too) _without_ adding latency?
> > 
> > And: When changing the symbol of [tabsend~] or [tabreceive~], is the
> > DSP graph re-calculated?
> > 
> > Roman
> 
> 
> 
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at 
> > https://lists.puredata.info/listinfo/pd-dev 
> > 
> 
> 
> 
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at 
> https://lists.puredata.info/listinfo/pd-dev 
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at 
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[x nor]

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~] |
|  [effect2~]
|   |
[mixer~  ]
|
[dac~]


generating abstraction by editing files as text is pretty simple, patching
each abstraction to a panner is probably pretty simple with your text
editor as well.

though, maybe you don't have enough processing power for it?  but.. maybe
you do?


On Tue, Aug 20, 2019 at 4:09 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 call up a separate
> Pd instance for each of them, and use "adc~" and "dac~" objects to get
> audio in and out - that incurs zero latency (once you've buffered 64
> samples in the first place).
>
> OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
> switched off, to control each sub-patch.  Send the switch~ objects bangs in
> whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
> be the simplemt way to pass signals between them.  In libpd you can do this
> zero-latency (just stuff your inpuits into arrays before sending all the
> tick messages and copy the results out afterward).
>
> Within the Pd app, you can do teh same thing but you incur one tick extra
> latency, because copying the autio into the tables has to happen on the
> previous tick form the one on which you get the outputs back.
>
> If you like danger, you can write an external tilde object that, for its
> "dsp" action, sends a message to teh patch that can "tick" the switch~
> objects right in the middle of Pd/s DSP tick.  This is not part of Pd
> because it could cause major confusion if general-purpose Pd messages
> got sent around in mid-tick.
>
> cheers
> Miller
>
> On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
> > 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
> > > "channel1" as both inputs and outputs so you can rearrange them in
> > > any
> > > order.
> > >
> > > (Beware of allowing patches to _write_ andy of their output channels
> > > before
> > > reading all the input channels, if you're re-using the same channels
> > > as
> > > inputs and outputs :)
> >
> > Do I understand right: When loading them as separate patches, you can
> > dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]
> > (which you could with abstractions, too) _without_ adding latency?
> >
> > And: When changing the symbol of [tabsend~] or [tabreceive~], is the
> > DSP graph re-calculated?
> >
> > Roman
>
>
>
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
>
>
>
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Miller Puckette]

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 out - that incurs zero latency (once you've buffered 64
samples in the first place).

OR, within one pd instance, in libpd or in Pd, you can use switch~ objects,
switched off, to control each sub-patch.  Send the switch~ objects bangs in
whatever orders you wish.  In this scenario, tabsend~ and tabreceive~ would
be the simplemt way to pass signals between them.  In libpd you can do this
zero-latency (just stuff your inpuits into arrays before sending all the
tick messages and copy the results out afterward).

Within the Pd app, you can do teh same thing but you incur one tick extra
latency, because copying the autio into the tables has to happen on the
previous tick form the one on which you get the outputs back.

If you like danger, you can write an external tilde object that, for its
"dsp" action, sends a message to teh patch that can "tick" the switch~
objects right in the middle of Pd/s DSP tick.  This is not part of Pd
because it could cause major confusion if general-purpose Pd messages
got sent around in mid-tick.

cheers
Miller

On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote:
> 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
> > "channel1" as both inputs and outputs so you can rearrange them in
> > any
> > order.
> > 
> > (Beware of allowing patches to _write_ andy of their output channels
> > before
> > reading all the input channels, if you're re-using the same channels
> > as 
> > inputs and outputs :)
> 
> Do I understand right: When loading them as separate patches, you can
> dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]
> (which you could with abstractions, too) _without_ adding latency?
> 
> And: When changing the symbol of [tabsend~] or [tabreceive~], is the
> DSP graph re-calculated?
> 
> Roman



> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Roman Haefeli]

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
> "channel1" as both inputs and outputs so you can rearrange them in
> any
> order.
> 
> (Beware of allowing patches to _write_ andy of their output channels
> before
> reading all the input channels, if you're re-using the same channels
> as 
> inputs and outputs :)

Do I understand right: When loading them as separate patches, you can
dynamically re-order the signal flow by using [tabsend~]/[tabreceive~]
(which you could with abstractions, too) _without_ adding latency?

And: When changing the symbol of [tabsend~] or [tabreceive~], is the
DSP graph re-calculated?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Miller Puckette]

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.

(Beware of allowing patches to _write_ andy of their output channels before
reading all the input channels, if you're re-using the same channels as 
inputs and outputs :)

Miller

On Tue, Aug 20, 2019 at 04:18:58AM -0400, Nick Porcaro wrote:
> 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 then I reload the patch.  This works, but it???s a hack.  What???d 
> really be
> slick is if there was api in libpd for inspecting and editng a running patch.
> 
> The goal is to minimize glitches on reloading the patch.  We do a similar 
> thing in 
> GeoShred http://www,moforte.com  in the effects 
> chain.  We use Faust for the signal processing
> in GeoShred.  There we essentially reorder a table of function pointers to 
> accomplish the reordering.
> 
> - Nick
> 
> 
> > On Aug 20, 2019, at 3:47 AM, Nick Porcaro  wrote:
> > 
> > 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: 
> > 
> > [noise~]
> > [lop~]
> > [hip~]
> > [dac~???
> > 
> > To this: 
> > 
> > [noise~]
> > [hip~]
> > [lop~]
> > [dac~]
> > 
> > Of course this is a trivial example, but it???s not if you wanted to 
> > arbitrarily reorder
> > an effects chain with 30 objects in it.
> > 
> > I stumbled across this paper:
> > 
> > https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
> >  
> > 
> > 
> > and this GitHub repo https://github.com/iem-projects/pd-iemguts 
> > 
> > 
> > and it appears that iemguts might do what I need -
> > 
> > What do you all think?  
> > 
> > (I posted this to the patch~ section of the Pd forum as well, and there???s 
> > some discussion going on).
> > 
> > - Nick
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Pd-dev mailing list
> > Pd-dev@lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
> 

> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev




___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Nick Porcaro]

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: 
> https://github.com/BirminghamConservatoire/integra-framework 
> 
> 
> It was specifically designed as module management layer to sit between libPd 
> (which it wraps) and an application, e.g. JUCE. An Integra “module” is 
> basically a collection of Pd patches with some metadata wrapped in a ZIP file.
> 
> Happy to answer any questions.
> 
> Cheers,
> 
> Jamie
> 
> 
>> On 20 Aug 2019, at 09:18, Nick Porcaro > > wrote:
>> 
>> 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 then I reload the patch.  This works, but it’s a hack.  What’d 
>> really be
>> slick is if there was api in libpd for inspecting and editng a running patch.
>> 
>> The goal is to minimize glitches on reloading the patch.  We do a similar 
>> thing in 
>> GeoShred http://www,moforte.com  in the effects 
>> chain.  We use Faust for the signal processing
>> in GeoShred.  There we essentially reorder a table of function pointers to 
>> accomplish the reordering.
>> 
>> - Nick
>> 
>> 
>>> On Aug 20, 2019, at 3:47 AM, Nick Porcaro >> > wrote:
>>> 
>>> 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: 
>>> 
>>> [noise~]
>>> [lop~]
>>> [hip~]
>>> [dac~’
>>> 
>>> To this: 
>>> 
>>> [noise~]
>>> [hip~]
>>> [lop~]
>>> [dac~]
>>> 
>>> Of course this is a trivial example, but it’s not if you wanted to 
>>> arbitrarily reorder
>>> an effects chain with 30 objects in it.
>>> 
>>> I stumbled across this paper:
>>> 
>>> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
>>>  
>>> 
>>> 
>>> and this GitHub repo https://github.com/iem-projects/pd-iemguts 
>>> 
>>> 
>>> and it appears that iemguts might do what I need -
>>> 
>>> What do you all think?  
>>> 
>>> (I posted this to the patch~ section of the Pd forum as well, and there’s 
>>> some discussion going on).
>>> 
>>> - Nick
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Pd-dev mailing list
>>> Pd-dev@lists.iem.at 
>>> https://lists.puredata.info/listinfo/pd-dev 
>>> 
>> 
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at 
>> https://lists.puredata.info/listinfo/pd-dev
> 

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Jamie Bullock]

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 management layer to sit between libPd 
(which it wraps) and an application, e.g. JUCE. An Integra “module” is 
basically a collection of Pd patches with some metadata wrapped in a ZIP file.

Happy to answer any questions.

Cheers,

Jamie


> On 20 Aug 2019, at 09:18, Nick Porcaro  wrote:
> 
> 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 then I reload the patch.  This works, but it’s a hack.  What’d 
> really be
> slick is if there was api in libpd for inspecting and editng a running patch.
> 
> The goal is to minimize glitches on reloading the patch.  We do a similar 
> thing in 
> GeoShred http://www,moforte.com  in the effects 
> chain.  We use Faust for the signal processing
> in GeoShred.  There we essentially reorder a table of function pointers to 
> accomplish the reordering.
> 
> - Nick
> 
> 
>> On Aug 20, 2019, at 3:47 AM, Nick Porcaro > > wrote:
>> 
>> 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: 
>> 
>> [noise~]
>> [lop~]
>> [hip~]
>> [dac~’
>> 
>> To this: 
>> 
>> [noise~]
>> [hip~]
>> [lop~]
>> [dac~]
>> 
>> Of course this is a trivial example, but it’s not if you wanted to 
>> arbitrarily reorder
>> an effects chain with 30 objects in it.
>> 
>> I stumbled across this paper:
>> 
>> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
>>  
>> 
>> 
>> and this GitHub repo https://github.com/iem-projects/pd-iemguts 
>> 
>> 
>> and it appears that iemguts might do what I need -
>> 
>> What do you all think?  
>> 
>> (I posted this to the patch~ section of the Pd forum as well, and there’s 
>> some discussion going on).
>> 
>> - Nick
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Pd-dev mailing list
>> Pd-dev@lists.iem.at 
>> https://lists.puredata.info/listinfo/pd-dev
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

[Nick Porcaro]

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 then I reload the patch.  This works, but it’s a hack.  What’d really 
be
slick is if there was api in libpd for inspecting and editng a running patch.

The goal is to minimize glitches on reloading the patch.  We do a similar thing 
in 
GeoShred http://www,moforte.com  in the effects chain. 
 We use Faust for the signal processing
in GeoShred.  There we essentially reorder a table of function pointers to 
accomplish the reordering.

- Nick


> On Aug 20, 2019, at 3:47 AM, Nick Porcaro  wrote:
> 
> 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: 
> 
> [noise~]
> [lop~]
> [hip~]
> [dac~’
> 
> To this: 
> 
> [noise~]
> [hip~]
> [lop~]
> [dac~]
> 
> Of course this is a trivial example, but it’s not if you wanted to 
> arbitrarily reorder
> an effects chain with 30 objects in it.
> 
> I stumbled across this paper:
> 
> https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf
>  
> 
> 
> and this GitHub repo https://github.com/iem-projects/pd-iemguts 
> 
> 
> and it appears that iemguts might do what I need -
> 
> What do you all think?  
> 
> (I posted this to the patch~ section of the Pd forum as well, and there’s 
> some discussion going on).
> 
> - Nick
> 
> 
> 
> 
> 
> 
> 
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev