UnUnUnium

I'm coming from a long stint with SuperCollider and trying to find some way to implement SuperCollider's 'add actions'.

These functions add a synth voice to a specific point in a signal chain - for example '.addToTail' adds the synth voice to the end of the signal chain, and '.addToHead' adds to the beginning of the signal chain.

I am trying to do this in a poly~ with multiple patcher names (attached), so that the filter comes after the reverb in the signal chain, but it seems like it just mixes the signals together.

Any other way to achieve this? I want to be able to dynamically construct an effects chain, with envelopes and DSP muting in poly so that I can spawn one effect directly after the other without mixing them, kind of like guitar pedals connected in series.

filtersynth.maxpat

polyfx.maxpat

verbsynth.maxpat

I'm coming from a long stint with SuperCollider and trying to find some way to implement SuperCollider's 'add actions'.
These functions add ... 

supercollider-'add-actions'-in-max

How many effects are you trying to have in the chain (series) and how many chains are you wanting to run in parallel?

Sure, probably relevant! I'm hoping to run 4 chains of 8 different effects in series, to start.

The tricky thing is, I want to spawn them so that each time an effect is spawned from the poly, it can be placed anywhere in the signal chain.

i dont think there is a simple function like that (which somehow reminds my on the before/after html tag) but it should not be too complicated to build one yourself.

you would first design the graph or matrix and then build the logic to have your "insert a before b" function on the frontend, which changes, moves, or reconnects the subpatchers in question to create the new order you want.

before you start using thispatcher scripting you should look into bpatcher (which you could use to unload subpatchers and load others) and maybe also pcontrol.

4*8 cells is not too much to simply have an emtpy bpatcher with inlets and outlets to let audio pass, as "unused" or "non-existing" cell between the others.

I am wondering if you could solve this by having 8 poly objects setup in a series - possibly using MC to have control of individual voices/chains. Then you could have a dummy patch within poly that just passes audio through which then gets switched out with different effects as needed.

If you do it all with one poly you would need to route audio back into itself. This could probably be done by using named send~ and receive~ objects. It's a bit like building a routing matrix within poly.

Hello again,
I am wondering if you could solve this by having 8 poly objects setup in a series - possibly using MC to have control of individual voices/chains. Then you could have a dummy patch within poly that just passes audio through which then gets switched out with different effects as needed. 

Thank you for your suggestions here. It seems there are various options, and I'll need to explore both of these approaches to see what works best.

One thing to note is that it's important that it's efficient and fast - the plan is to sequence effects changes, sometimes rapidly. I guess having many poly~ objects should handle that.

It seems matrix~ will be a part of this operation in any case!

poly~, i.e. everythign is loaded and connected and then you only choose which paths are open, is the fastest.

one poly patcher would be the "though" one and only has I/O and on/off.

Yes, that makes sense - the through patcher to manage the 'dry' signal. I will attempt this soon!

, if I understand you correctly. And you can set a fade in/out time for where you put stuff in the signal chain. Although I don't recall their name, I believe that there's someone who borrowed the stuff from a Vizzie module I wrote called 

 and modified it to work with audio with some success (although it was a single path through the signal chain rather than a matrix of sources)....

I'd just use matrix~, if I understand you correctly. And you can set a fade in/out time for where you put stuff in the signal chain. Although I don't recall their name, I believe that there's someone who borrowed the stuff from a Vizzie module I wrote called PATCHROUTR and modified it to work with audio with some success (although it was a single path through the signal chain rather than a matrix of sources)....

model makes sense - actually it would simplify things if I just used one matrix and worked out all possible combinations and saved them as presets, then triggered the effect voices as needed.

I'd be interested to see the audio version, if anyone has it kicking about.

Yes, the PATCHROUTR model makes sense - actually it would simplify things if I just used one matrix and worked out all possible combinations and saved them as presets, then triggered the effect voices as needed.

Here's something I was playing around with recently. I am using mc objects to create a matrix (in this case 4x4) and each node is controllable with audio rate signals. In the example I made an LFO by using mc.cycle with 16 channels. It starts getting a bit CPU heavy if the matrix is larger.

The experiments I have done with audio rate matrix control using poly were more CPU efficient since individual poly voices can be turned off when not in use.

McMatrix_example.maxpat

The experiments I have done with audio rate matrix control using poly were more CPU efficient since individual poly voices can be turned off when not in use. 

Thank you Simone, this is an interesting approach and the 'splayed' panning sounds great to my ears. Also more easily understood than matrix~, which as some have mentioned is a bit confusing to look at when creating a dynamic effects network.

This is close to what I want - I'm still deciding on the specifics before I start patching. I'm also deciding whether or not I want to build it using mc in Max, or RNBO. Ideally it would all be signal rate, but I guess there's no way to involve poly~ without messages/scheduler, and I can't see a way to manage subpatch DSP turning off and on at signal rate.

1. effects are triggered by an envelope that mixes between the wet/dry signal

2. the triggering envelope manages the DSP of each effect, turning it off when the envelope is done

3. effects order reconfigurable dynamically

I'll post it if I make anything interesting.

This is close to what I want - I'm still deciding on the specifics  before I start patching. I'm also deciding whether or not I want to build it using mc in Max, or RNBO. Ideally it would all be signal rate, but I guess there's no way to involve poly~ without messages/scheduler, and I can't see a way to manage subpatch DSP turning off and on at signal rate.

The main requirements are:

1. effects are triggered by an envelope that mixes between the wet/dry signal
2. the triggering envelope manages the DSP of each effect, turning it off when the envelope is done
3. effects order reconfigurable dynamically

SuperCollider 'add actions' in Max