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.
WHY?!?!?!?!
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.
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.
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, 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.