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] where is the search priority set?

[Roman Haefeli]

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
> > should be different, first with "standard paths" (which includes
> > 'extra')
> > then the user added paths.
> 
> I think you are right that the core "extra" externals should have
> priority. 

I was trained by operating systems and programming languages that order
is usually from local to global. I don't quite see why /extra
should have priority. Is it considered more local than what I have in
my home folder or part of my project?

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

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

[Lucas Cordiviola]

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"


---

To compile the 64bit pdfontloader.dll I did add these packages to MinGW with:

pacman -S mingw64/mingw-w64-x86_64-tcl

pacman -S mingw64/mingw-w64-x86_64-tk

then I did "make" in pdfontloder dir. and rename the dll to pdfontloader64.dll.

--


-- 
Mensaje telepatico asistido por maquinas.

<>
___
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

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

[Nick Porcaro]

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