Controlling parameters sometimes from this source, sometimes from this other?

Hi there,
Some may know I’m coming and still using Max.
I’m trying to retrieve some feelings, habits and new concepts with TD.

I don’t know if some are interested in that, but here is how I manage my routing in Max.
I guess that I probably would have to change some paradigms with TD and this thread is also to talk about that and maybe hopefully share ideas around this.

I’ll describe here how I do that in Max (since my project ALPHA)
The paradigm I’d like to port to TD is : one parameter can be controlled by many sources.

Related to the figure below,
For each song (=context, arrows colored here),
I link a trigger to custom actions for altering visuals system parameters.

For instance, Song01 is related to green arrows. Song02 to orange ones.
When I fire a midi program change, the system switch from a context to another one.

For instance, here, when I switch from green to orange, Par 3 takes a new default value, static and
Par 4 is no more controlled by Trigger3 through action b, but now by Trigger 3 via Action c.

At each context switching , I need :

  • to fire initial conditions to all n visuals parameters (Par 1, Par 2 … Par n)
  • to connect triggers to Parameters (all not connected ones will remain in the initial condition state just fired up above)

This system allows me:

  • to create my visuals system while composing, progressively.
  • to be totally free while composing without thinking about that pitch has to be pitched up or down to match a specific pitch in the visuals system,
  • to decide about the link trigger / visuals’ parameter progressively, not deciding all at the beginning
  • to have specific actions for THIS trigger in THAT context. As I wouldn’t want to have THIS midi pitch does always trigger an envelope, or does always pop out a random number (the “always” would be the problem here)

Naturally, I’d like to do that or almost that in TD.

According to what I understood and experiment, I know we can dynamically export to this, or that.
In my Max patch, I use gate/switching. For song 1, I have ALL my midi flows going to that part of the patch. Inside that part (designed on purpose for song 1), I use my triggers on very custom way and send that further to parameters themselves. (reminding me that post, of course, which was a pre-project to this one)

I’m thinking about this solution: dynamic recall of initial conditions & dynamic routing through Python
Program change changes. A MIDIIn DAT get it and the associated callback check what it has to do for that program change number. Callbacks do ALL the job:

  • fire specific values to the n parameters
  • connect (export) specific nodes related to that context to each one of n visuals parameters.

Here is a view:

Sorry for the UglY schematics.

I’m posting this to know if it does make sense ?
Maybe it is a too much specific personal local self post.
But I always make progressions and increase potentials by sharing, discussing etc.
I just hope this post won’t be too big and useless and could trigger ideas to some people too.

I will try to implement this and post more later

Hi Julien.

I didn’t dive too deep into your diagrams, so I’m not sure I fully understand the intricacies of what you’re asking but I want to point you to a couple operators that I think will help.

First, the bindCHOP takes multiple inputs and when multiple input channels have the same name, it outputs the last received value. You can also bind parameters directly to bindCHOP channels as another input source, making the output extremely versatile. There are also callbacks so you can react differently to changes from different sources.

The other one is the various switch operators. In this case, I think the switchCHOP is most useful to you for switching between various inputs. You can set a complex bindCHOP network for each song and switch between them before final output to your parameters.