Hi Alexandre,

You can also look at this thread on the forum.pdpatchrepo.info: https://forum.pdpatchrepo.info/topic/10466/matrices-and-reallocating-memory. And to this code : https://github.com/pierreguillot/pd.dummies/blob/master/src/leeloo_tilde.c

2018-02-22 18:41 GMT+01:00 Miller Puckette msp@ucsd.edu:

Check that the input addresses are different from the output ones - usually in a case like that Pd will re-use the memory from the inputs for the outputs, so your object needs to be able to operate in-place.

(hint: allocate a bunch of temporary signals on teh stack using alloca(), and put the outputs in them irst; then when you're through using the intputs for anything, you can copy the temporary outputs to the real ones.)

cheers Miller

On Thu, Feb 22, 2018 at 02:38:24PM -0300, Alexandre Torres Porres wrote:

...

Hi folks, I need help on an external. I wanna perform a task on an array

of

...

signal inputs. It's a multichannel object, and I define the number of channels with an argument.

Here's just the core of it, as an object named "mtx~", where I map the input to the output. And this is what happens.

[image: Imagem inline 1]

So you see I get a weird mirrored output, instead of something like "1 2

3

...

4 5 6".

The perform method in the code is just

static t_int *mtx_perform(t_int *w){

t_mtx *x = (t_mtx *)(w[1]);

int nblock = (int)(w[2]);

t_float **in_vectors = x->x_in_vectors;

t_float **out_vectors = x->x_out_vectors;

t_int i;

for(i = 0; i < x->x_ch; i++){

    t_float *in = in_vectors[i];

    t_float *out = out_vectors[i];

    t_int n = nblock;

    while(n--)

        *out++ = *in++;

}

return (w + 3);

}

What am I doing wrong? How should this go? See attached the help test example and code.

Thanks

...

#include "m_pd.h"

typedef struct _mtx{ t_object x_obj; t_int x_ch; t_float **x_in_vectors; t_float **x_out_vectors; }t_mtx;

static t_class *mtx_class;

static t_int *mtx_perform(t_int *w){ t_mtx *x = (t_mtx *)(w[1]); int nblock = (int)(w[2]); t_float **in_vectors = x->x_in_vectors; t_float **out_vectors = x->x_out_vectors; t_int i; for(i = 0; i < x->x_ch; i++){ t_float *in = in_vectors[i]; t_float *out = out_vectors[i]; t_int n = nblock; while(n--) *out++ = *in++; } return (w + 3); }

static void mtx_dsp(t_mtx *x, t_signal **sp){ t_int i, nblock = sp[0]->s_n; t_signal **sigp = sp; t_float **vecp = x->x_in_vectors; for(i = 0; i < x->x_ch; i++) *vecp++ = (*sigp++)->s_vec; // input vectors vecp = x->x_out_vectors; for(i = 0; i < x->x_ch; i++) *vecp++ = (*sigp++)->s_vec; // output vectors dsp_add(mtx_perform, 2, x, nblock); }

static void *mtx_free(t_mtx *x){ freebytes(x->x_in_vectors, x->x_ch * sizeof(*x->x_in_vectors)); freebytes(x->x_out_vectors, x->x_ch * sizeof(*x->x_out_vectors)); return(void *)x; }

static void *mtx_new(t_floatarg f){ t_mtx *x = (t_mtx *)pd_new(mtx_class); x->x_ch = (int)f < 1 ? 1 : (int)f > 64 ? 64 : (int)f; x->x_in_vectors = getbytes(x->x_ch * sizeof(*x->x_in_vectors)); x->x_out_vectors = getbytes(x->x_ch * sizeof(*x->x_out_vectors)); t_int i; for(i = 0; i < x->x_ch; i++) inlet_new(&x->x_obj, &x->x_obj.ob_pd, &s_signal, &s_signal); for(i = 0; i < x->x_ch; i++) outlet_new(&x->x_obj, gensym("signal")); return(x); }

void mtx_tilde_setup(void){ mtx_class = class_new(gensym("mtx~"), (t_newmethod)mtx_new,

(t_method)mtx_free,

...

                       sizeof(t_mtx), CLASS_NOINLET, A_DEFFLOAT, 0);
class_addmethod(mtx_class, (t_method)mtx_dsp, gensym("dsp"), A_CANT,

0);

...

}

...

---

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

Pierre, That is really helpful! So, do we not know the vector size until the *_dsp method then? There is EXTERN int sys_getblksize(void); in m_pd.h, it would probably be useful if we added comments indicating the usage of that if it isn't giving us the block size that we should expect in _perform Another thing I wasn't sure about is if you need to explicitly free symbols after you gensym if they're being used for variables etc [like to get a "value"]. would be nice to add into the header docs. Maybe these questions are answered "how to make an external" doc but I didn't see it. It could be useful to create an updated doc.

On Fri, Feb 23, 2018 at 8:02 AM, Alexandre Torres Porres porres@gmail.com wrote:

2018-02-23 10:59 GMT-03:00 Pierre Guillot guillotpierre6@gmail.com:

...

(...) And to this code : https://github.com/pierregui llot/pd.dummies/blob/master/src/leeloo_tilde.c

Wow, that's *exactly* what I needed :) it couldn't be easier than that for me, haha, thanks!

---

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

IOhannes, I'll try to get on that this weekend!

On Fri, Feb 23, 2018 at 8:40 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:

On 02/23/2018 05:26 PM, Alex wrote:

...

Pierre, That is really helpful! So, do we not know the vector size until the

*_dsp

...

method then? There is EXTERN int sys_getblksize(void); in m_pd.h, it

would

...

probably be useful if we added comments indicating the usage of that if

it

:-) +1

...

isn't giving us the block size that we should expect in _perform

well, sys_getblksize() will have a hard time with [block~ 1024], no?

...

Another thing I wasn't sure about is if you need to explicitly free

symbols

...

after you gensym if they're being used for variables etc [like to get a "value"]. would be nice to add into the header docs. Maybe these questions are answered "how to make an external" doc but I didn't see it. It could be useful to create an updated doc.

i accept pull requests

https://github.com/pure-data/externals-howto/

gfmdsar IOhannes

---

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

On 02/25/2018 09:54 AM, Alexandre Torres Porres wrote:

2018-02-23 13:02 GMT-03:00 Alexandre Torres Porres porres@gmail.com:

Well, it got hard again. I actually needed an extra main signal inlet, so, when I added it, I managed to make it work and build and stuff... but now, if I change the number of channels (that is, if I recreate the object with a different argument), Pd can freeze or blow up... so I screwed it somehow. Here's the code: https://github.com/porres/pd-else/blob/master/classes/mtx~.c - I don't know if it's something to do with the "free" method, or something inside the "dsp" method, that's all I can think but I've also already done all I could take a wild guess on.

you probably should learn how to use a debugger (other than pd-list or stackoverflow; don't get me wrong - both are valuable resources when it comes to debugging non-trivial things, but there are tools out there that allow you to automate the hunt for more trivial things).

#1 printf debugging. your code crashes? add printf() statements (or "post()" for that matter). to monitor which lines are reached (and which not, and to print the values (esp. of pointers) to see whether they are not what you expect. since a crash of Pd will take down the Pd-console, it's usually not a good idea to put any crash-debugging printout there. instead, start Pd from the cmdline with the "-stderr" flag.

#2 valgrind your code crashes? more often than not this is due to memory corruption. valgrind makes it easy to see where you have access violations. it's also super-easy to use, just add "valgrind" before the actual command when starting from the cmdline.

#3 gdb your code crashes? or does something bonkers? gdb to the rescue! gdb can be a tricky beast, and there is much to learn, but even if you only use the "backtrace" feature, you get at least an idea which line causes the crash (which can help tremendously). two things to keep in mind: a) you must compile the code to be debugged with "-g", so the debugging symbols don't get stripped away. for whatever reasons, the pd-lib-builder Makefile doesn't set this by default (most likely size- or speed-constraints; there was some discussion, i don't remember the details), unless you build with "make alldebug" b) you should run Pd with "-nrt" inside the debugger, unless you want a stream of "watchdog: signaling Pd" message to garble all your output.

fgamdsr IOhannes

PS: is there any specific reason to post on both pd-dev and pd-list?

Hi, As Miller explained previously, Pd reuse the inputs and outputs vectors for optimization purposes so an input vector can correspond to an output vector. When you write into an output vector, you can also write into an input vector then when you read it after, you have false values. To prevent that, in your example, you need to write the inputs' samples into a temporary vector before writing anything in an output vector (to ensure that it doesn't overwrite an input). You should have a look to the pull request that I created on your repo for multigate~.

PS: The problem with mtx is in the perform method. The main loop goes beyond the vector size, you should simply remove it and move the scope of the "gate" vector.

Cheers, Pierre

2018-02-26 6:11 GMT+01:00 Alexandre Torres Porres porres@gmail.com:

2018-02-25 6:45 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:

...

you probably should learn how to use a debugger

True! Enough fooling around... I should really learn how to use one now that I keep getting serious about this. But they're not so that easy to get started with for someone like me. I remember I wasn't very lucky with it a while back and just thought I'd let it go for then. But I see your point and it made me realize I gotta do something about it, thanks.

#1 printf debugging.

...

your code crashes? add printf() statements (or "post()" for that matter).

Yeah, that's all I really know how to do so far, it didn't help me much here.

But anyway, I also have a not debugging issue, which would be how to fix this code to have its outlets flipped/reversed, see => https://github.com/porres/pd-else/issues/161

This object is pretty stable, doesn't crash at all, but has this issue. I've been checking many externals and other examples, such as cyclone/matrix~, the example one from Pierre, and also now yours [matrix_*~] - and code above is actually modeled and derived after [cyclone/gate~], so I guess enough checking other externals, cause still no luck for me...

So the question to this list is if I can do something to get the output in the right order, from "1 to 6", instead of "6 to 1". If not a simple trick and edit to the current code, I see a way around would maybe be to have a temporary array and rearrange things over. But I also tried all I could think of (again also checking other externals) and nothing worked... so I was hoping maybe I could get a hand on that at least.

Thanks

---

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

Iohannes just merged an update to the external howto doc with this info.

On February 26, 2018 5:30:20 AM PST, Pierre Guillot guillotpierre6@gmail.com wrote:

And sys_getblksize() always returns the global vector size (64). Within an external you need to know the vector size of the signals you receive (using sp[0]->s_n) because if the patch has a block object the vector size can be different from the global vector size.

2018-02-26 14:24 GMT+01:00 Pierre Guillot guillotpierre6@gmail.com:

...

Hi, As Miller explained previously, Pd reuse the inputs and outputs

vectors

...

for optimization purposes so an input vector can correspond to an

output

...

vector. When you write into an output vector, you can also write into

an

...

input vector then when you read it after, you have false values. To

prevent

...

that, in your example, you need to write the inputs' samples into a temporary vector before writing anything in an output vector (to

ensure

...

that it doesn't overwrite an input). You should have a look to the

pull

...

request that I created on your repo for multigate~.

PS: The problem with mtx is in the perform method. The main loop goes beyond the vector size, you should simply remove it and move the

scope of

...

the "gate" vector.

Cheers, Pierre

2018-02-26 6:11 GMT+01:00 Alexandre Torres Porres porres@gmail.com:

...

2018-02-25 6:45 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:

...

you probably should learn how to use a debugger

True! Enough fooling around... I should really learn how to use one

now

...

...

that I keep getting serious about this. But they're not so that easy

to get

...

...

started with for someone like me. I remember I wasn't very lucky

with it a

...

...

while back and just thought I'd let it go for then. But I see your

point

...

...

and it made me realize I gotta do something about it, thanks.

#1 printf debugging.

...

your code crashes? add printf() statements (or "post()" for that matter).

Yeah, that's all I really know how to do so far, it didn't help me

much

...

...

here.

But anyway, I also have a not debugging issue, which would be how to

fix

...

...

this code to have its outlets flipped/reversed, see => https://github.com/porres/pd-else/issues/161

This object is pretty stable, doesn't crash at all, but has this

issue.

...

...

I've been checking many externals and other examples, such as cyclone/matrix~, the example one from Pierre, and also now yours [matrix_*~] - and code above is actually modeled and derived after [cyclone/gate~], so I guess enough checking other externals, cause

still no

...

...

luck for me...

So the question to this list is if I can do something to get the

output

...

...

in the right order, from "1 to 6", instead of "6 to 1". If not a

simple

...

...

trick and edit to the current code, I see a way around would maybe

be to

...

...

have a temporary array and rearrange things over. But I also tried

all I

...

...

could think of (again also checking other externals) and nothing worked... so I was hoping maybe I could get a hand on that at least.

Thanks

---

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

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_pdreflecti... https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf

and this GitHub repo https://github.com/iem-projects/pd-iemguts 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

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 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 nick@ccrma.stanford.edu 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 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 <nick@ccrma.Stanford.EDU mailto:nick@ccrma.Stanford.EDU> 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_pdreflecti... https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf

and this GitHub repo https://github.com/iem-projects/pd-iemguts 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 mailto: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

On 20 Aug 2019, at 18:09, Nick Porcaro nick@ccrma.stanford.edu 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 <jamie@jamiebullock.com mailto:jamie@jamiebullock.com> 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 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 <nick@ccrma.stanford.edu mailto:nick@ccrma.stanford.edu> 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 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 <nick@ccrma.Stanford.EDU mailto:nick@ccrma.Stanford.EDU> 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_pdreflecti... https://lac.linuxaudio.org/2009/cdm/Saturday/18_Zmoelnig/zmoelnig_pdreflection.pdf

and this GitHub repo https://github.com/iem-projects/pd-iemguts 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 mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev

---

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

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

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 msp@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 [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

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 nick@ccrma.stanford.edu 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_pdreflecti...

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

On 02/25/2018 09:54 AM, Alexandre Torres Porres wrote:

By the way, the end goal is not to have this silly multi channel gate object, but more of an automatic fade in/out for multi-channel files.

btw, the iemmatrix object has a [mtx_*~] object (aka [matrix~]) which does linear interpolation of many signals. your code probably would share most (if not all) of that object's functionality, so you might as well look at it.

while being there, please note that iemmatrix has used the "mtx" prefix for it's symbols for ages.

to avoid nameclashes, please declare all the symbols as *static*, unless you explicitely need to export them (which is really only the "setup" function).