What is troubling you? You can't get out of your house unless you open the door first, well at least I can't ;-)

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 ;)

Exactly.

the historic folklore runs thus, herewith, heretofor, and forthwith:

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!

(jus jerkin yer chain :D)

Wonderful !! :D

ah if Max patchers where on a 3D spherical canvas it would be even tidier !

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.

Yeah, I'll have too double check that. It could just be this old version is missing the switch object. At least it was not in Max 1.9 ;-)

...but don't trust me. I'm old, and the past is beginning to blur. :) It's quite possible that Miller created a simple gate early on, and that David made the logical next steps thereafter.

queue and order issues is the last thing i am thinking of when i look at [gate] and its "wrong" inlet order.

[gate] is first of all a perfect example for "annoying-by-design", closely followed by [pow~] and [cos~].

-110

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).

But I guess mileage may vary. As it mostly does.

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.

-110

'7 into both inlets'?!

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):

if the inlets were the way audiomatt suggests, this would make more sense... meh... who am i to argue when there's so much other gen~eral progress :D

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.

@Matt: I most certainly did not say "never."

I did say YMMV, which it obviously does in your case. Still, that's no reason to try to put words in my mouth.