What is the position regarding [gate]?
Andy Maskell
7月 19 2024 | 10:52 午前
As somebody who is obsessed with patches looking neat and tidy, I have often come across a problem where [gate] does not appear to have the desired effect.
I have also seen a number of posts in the forum where the user is asking for help in debugging their patch. I often note that there is actually nothing wrong with their code other than the fact that the position of a [gate] object relative to the objects that feed the [gate] inputs can be highly significant.
It's almost as though [gate] doesn't follow the usual right->left processing priority as expected, because it is normally necessary to set the [gate] output on the left before data is passed through on the right.
As a demonstration, try out these three simple examples:
They essentially all do the same thing but the results are different. The aim is to create a simple list with an integer followed by a value that determines which output of the [gate] to send the list.
The lefthand example is lined up neatly as many users tend to do. However, clicking on the 1 or 2 at the top constantly sends the message through the wrong side of the gate first but clicking it again appears to get it right.
The middle example is exactly the same code but with the [gate] positioned further to the left. Now the message always goes to the correct output every time.
The third example, which is lined up exactly the same as the first but now has a [trigger l l] to force the order in which the messages are processed, the messages again always go in the correct direction.
There are a lot of people who have suggested that the [gate] object be redesigned such that the data goes into the left input and the selector message into the right. If this was done, it would eliminate this unexpected behaviour. However, the clever people have justified the design because of how the underlying code works in the object. I know of some people that have created their own sub-patcher snippets that deliberately swap the inputs over but it means that you have to create different snippets for every size of [gate] that you need to use.
I'm wondering if a new object, for example called [gatex], could be added where the inputs are reversed such that users would be able to follow their desire to keep things neat and tidy without being confused by how [gate] is actually processing it's inputs?
Roman Thilenius
7月 19 2024 | 5:15 午後
this is what [110.gate] and his friends do since ever, because i also cannot stand the "reversed" inputs of this kind of objects either. (i think that "base model" "gate" is the very first "wrap" type of abstraction i ever made)
but that does not fully solve the "issue" people can have with [gate] and the way it works.
after 20 years of using both gate - and my own gate with reversed inlets - it still happens to me that i mix things up and connect the cables wrong at either of them!
also i think one should take into account that [gate] does not really break with the paradigm we have in mind.
1.) it is so old, that when it was born this inlets paradigm we know today did not exist yet, so it probably had some eligibility to design it after the boolean logic of a ceiling light switch or electronic component or whereever this unbearable disorder comes from.
2.) there are other objects where you at least in some cases would use them with a hot inlet right of a cold inlet, for example you might use [pak] and use the first inlet with a "set" and then trigger it only from another one.
(your mileage might vary, but i need that kind of thing more often than actually requiring all 17 pak inlets to be hot.)
"but it means that you have to create different snippets for every size of [gate] that you need to use."
that is right, but you could make a few with 16, 32, 48, 64 and you wont really lose anything.
and often you want to have a few other things changed or added as well, isnt it?
