Max/MSP Gate operator

A DAT and CHOP version of this would be great. It’s basically a Switch DAT in reverse. The Switch takes a bunch of inputs and choose which to pass based on index. This takes one input and chooses where it goes based on index.

cycling74.com/docs/max5/refpages … /gate.html

That would be really useful.
I don’t know of any operators that have variable numbers of outputs though.

+1

+1

What gets sent to the unselected channels?

I think this concept works in Max because it has and atomic events that trigger node cooks. TDs ops mostly cook every frame.

Maybe I’m misunderstanding.

Editing this because I didn’t notice the ‘routing’ behavior of the Max gate — (although Max distinguishes between gate and route they share that behavior)

I think the behavior should be equivalent to anything downstream, connected to an output that is ‘off’ from the gate, would see nothing upstream and thus couldn’t pull a cook out of the elements upstream of the gate unless it were patched through (or connected).

What does ‘Off’ mean though? Sending a value of ‘0’ or sending no channels, the latter which throws errors and the former ‘0’ is not the same as sending nothing. A parameter setting for "Default Off Value’?

Just spitballing here and I’d prob have to poke at the Max component a bit. I think rather than think of this as a gate it’s better to think of its function as a route. A par (or a value in its first inlet) determines which of its outputs (and the multi-output thing is the new part of the paradigm) receives the signal. The rest of the outputs send either nothing (as in the ops they’re connected to see nothing on their input), a default value, or hold the last value they got. Perhaps even the ‘route’ argument can be a list or range of values determining which of many outlets receives the input’s value.

The goal is to be able to redirect the output of one op to one of multiple destinations without the use of a bunch of switch ops or scripting a bunch of select ops. As Elburz said, the opposite of a switch.

It seems like some of the conceptual disconnect here comes from the fact that data is pushed through Max/Msp networks, but more often polled, or pulled through TD networks. Broadly speaking, operators that are ‘live’ (actively, participating in creating the composition) should not have their inputs spontaneously go dark as a matter of course.

I don’t want to be unilaterally against the idea, but the use case so far sounds like something that would be better engineered in a different way.

I’ve been using delete CHOPs to do this for channels. I just set to delete non-scoped and then delete by channel index. Of course this still requires multiple deletes if you want multiple “outs” but you could make a little component that creates more delete/out pairs as needed…

One RFE though for this might be to have a numeric parameter for selecting a single index via another channel instead of having to put an expression to look at the chop channel of your “controller chop” in the selnumbers parameter ( which is a string parameter right now to allow for ranges and such )

Attaching a simple tox to show what I’m talking about ( this doesn’t dynamically make new outputs or selection parameters, just set to 3 right now and no error correction if you select out of range).
gateSelector.tox (814 Bytes)

Delete would work but then surely a select followed by a rename would work for this as well and be less prone to erroring. Either way I’m still not quite sure how that’d work.

I think someone needs to draw this out.

There was a question on the Slack i believe about how to route a single audio channels between a bunch of outputs and there are obviously Python ways to do it, but then if you try to do something that simple with native ops, it get’s pretty hairy quickly. The example I had made for them used Fan CHOP and a bunch of selects and maths, which is fine, but it’s not elegant by any stretch and doesn’t scale very well.

I don’t think push/pull applies too much here. There are a number of operators that are “always cook” like Filter or Logic, so this could just be another one (although I don’t think it does need to be).

I don’t think it’s just me who is feeling the desire to both push TouchDesigner into less idiosyncratic ninja tricks AND develop elegant best practices to make for a stronger talent pool.

The reason why the push/pull metaphor is relevant here (possibly only to me) is that Touch will want to evaluate an OP chain if it’s connected to a live output, and if it gets to an OP that has had it’s input disabled because it is currently un-routed, this results in an error.

Hence Ben’s question about what ‘Off’ means.

Correct me if I’m wrong (haven’t touched Max in years), but i think that as part of it’s Push paradigm (instead of pull/poll) Max has endpoints with no new input data automatically hold the previous input value. This is great for managing things like dc-offset on audio channels for example.

Maybe that means that the best solution here is to make this new CHOP automatically hold the last value that was routed to an un-routed cable by default, with an option to set it to a user defined value (probably zero by default).

That’s a more elegant way of saying what I was trying to get out. It’s the behavior I think I’d expect.

I mean it could jsut be an option for what to have as the non-matched output, whether its 0, last value, or some other default value.

If I’m allowed to chime in* could I suggest using the lock flag?
Take a look at the attachment to see what I mean.

*I’m very new to this and I think this is my first post
lockgateSelector.toe (3.98 KB)