Gate inlets

Is there any historic folklore about why [gate] asks you to send it a message before you calculate the outlet that message should me routed to?

Obviously we can’t change it now, and I know there’s Lgate, or other solutions but seriously, I take great pride in almost never crossing scheduler rate patch cords and this is just about the only exception. It’s like a pebble in my shoe every time.

hah Emmanuel, that’s exactly what he is saying : given Max message scheduling is from right to left, you should have the inlet for opening the door at the right, calculated before the inlet by which you go out of the house ;)

twas the best of times, twas the worst of times, twas the age of wisdom, twas the age of foolishness… uh… when ‘gate’ and ‘switch’ were made, that is.
_____________________________________________________________

"almost never crossing scheduler rate patch cords and this is just about the only exception…"

never fear! i have the perfect solution!

<code>

– Pasted Max Patch, click to expand. –

Copy all of the following text. Then, in Max, select New From Clipboard.

Interesting, that never bothered me. I always thought that it was like this for consistency between switch and gate, but it appears to be a false assumption: Max 2.53 had a gate object (which only add one inlet), but no switch.

Emmanuel, Great image! But somehow it doesn’t seem correct to me. My (admittedly terrible) memory is that both gate and switch existed in Max 2.0 and maybe even before. Hmm. If you’re actually running that version of the program in an emulator, though, then I must be wrong.

As I understood things, right-to-left ordering is basically a convention that is convenient for serializing events that are conceptually in parallel. Like, for instance, connecting notein to noteout. Conceptually you (well, a lot of people) think of pitch, velocity, and channel arriving and being processed in parallel; in fact they are handled one after another, and the right-to-left convention, together with the convention left-inlet-triggers, take care of the disconnect between ideal and reality.

In the case of gate, you’re not (or, at least, I’m not) normally opening the gate "conceptually simultaneously" with the message going through. I suppose there are times when this is the case, but they’re sufficiently rare that the gate inlet order never bothered me. In fact, sometimes I’ve found it quite convenient (and I think it has reduced crossing of patch cords).

Peter this really surprises me because essentially what you’re saying is that you never compute the message for the left inlet in the same scheduler tick as the right one. I see almost no real use (besides just creatively patching stuff together without focusing on the outcome) in sending the messages simultaneously in right left order.

"you never compute the message for the left inlet in the same scheduler tick as the right one… I see almost no real use"

trigger into gate allows you to do this(?)

but i understand what Peter is saying. the function of gate is not necessarily designed to accomodate the idea that each message would be accompanied by an inlet-control message. and the gate and switch objects were probably created near the same time as the parallel UI objects: ggate and gswitch…(?) which would make gate and switch make more sense in context… at least to me(the idea seems to decouple inlet control from message passing, to allow for less complex setups, while trigger can still solve for the complex ones, too… leaving it more open-ended)…? nah… i’m just guessing…

i still think if it were the way audiomatt suggests it would make everything easier.

to give relative context, in gen~, the ‘mix’ and the ‘interp’ objects are also quirky: they both have ‘interpolation’ inlets(and 2 input inlets), but one’s interpolation inlet is on the left(with inputs on the right) and the other’s interpolation inlet is on the right(with inputs on the left)…
but since it’s all signals in gen~(and their interpolation is applied to 2 distinctly different contexts), changing them would make no difference… i guess i rambled there… it was to say that audiomatt’s way for gate and switch(in the scheduler context of max) would actually make a useable difference :D

the question is not how often you will like to send "7" into both inlets of a [gate 20] to route the number to the seventh output, the question is how often you need this compared to the other way round, first sending a message and then, consecutively, send the same number to the control inlet == never.

IF there is any possible use of running a number into both inlets of a gate, then it is running it first into the control inlet.

i wasn’t even thinking of anything like that, but that got me playing around and on a subtopic, i feel the way gate handles lists of 2 numbers in its left inlet is also strange(i’d think the $1 would change the control-inlet value first before sending the $2):

– Pasted Max Patch, click to expand. –

Copy all of the following text. Then, in Max, select New From Clipboard.

7 into both, i am using this in several abstractions. mainly because [route] doest forward numbers or the first element in a list.
it could be something different than itself which is triggered by the incoming data to send but something to the control inlet, the issue remains.
like i said, my main problem with gate is not on the technical side, it is just stupid that the first inlet isnt for the data. [110.gate], a gate with switched inlets, is one of the first things i ever made.