madbutter

I've been using Max for a number of years now and there is one thing that I do over and over that drives me crazy: I build elaborate patches using trigger objects throughout the patch, and then realize that I need to add an argument in the middle of a given trigger object, then spend a bunch of time redrawing the patch cords because the new outlet is always added on the end. Why can't the new outlet be drawn at the position of the new argument, preserving the correct placement of the existing patch cords, if they are there?

This seems like such a simple and desirable UI feature that I assume that there is a good reason for Max not to work that way (because this would mess up the way programmers use other objects and consistency is important? I personally can't think of a case where I would not want this feature...) or that there is some simple workflow technique that everyone else uses that I am unaware of!

Apologies if this has been discussed - couldn't find anything with some simple searches...

I've been using Max for a number of years now and there is one thing that I do over and over that drives me crazy: I build elaborate patches using trigger objects throughout the patch, and then realize that I need to add an argument in the middle of a given trigger object, then spend a bunch of time redrawing the patch cords because the new outlet is always added on the end. Why can't the new outlet be drawn at the position of the new argument, preserving the correct placement of the existing patch cords, if they are there?
This seems like such a simple and desirable UI feature that I assume that there is a good reason for Max not to work that way (because this would mess up the way programmers use other objects and consistency is important? I personally can't think of a case where I would not want this feature...) or that there is some simple workflow technique that everyone else uses that I am unaware of!
Apologies if this has been discussed - couldn't find anything with some simple searches...
-bob stratton


adding-args-to-trigger-preserving-existing-signal-routing

the object box cant know what conections you want to keep.

sure, you could say it should be default that when you add something at

position three, that there is a new outlet created at this position, but thats

simply not how outlets work - check out some other objects like [route] or

sure, you could say it should be default that when you add something at
position three, that there is a new outlet created at this position, but  thats
simply not how outlets work - check out some other objects like [route] or
[tapout~] and youll see the problem.


i just have to 10000% agree with the OP here. there MUST be a way to make this work. it is the single most annoying thing about max patching. to me, it would be worth the perceived illogicality of this feature for this one object if it CAN be implemented. in fact for the trigger object it IS logical to operate in this suggested different way. it has been annoying me since for ever (well, i started on Max 4.0.9 OS9). what i find myself doing is: a-- copy the complex trigger for visual reference, b-- carefully rename the existing trigger so that connections will not be lost, sometimes doing this one at a time so patch chords can be moved. c-- eventually add the new t item, d-- rearrange as necessary, e-- delete the visual reference. all a lot easier since max 5.1.0 of course but still... and before there are calls of 'a properly planned patch this should not happen', that is ridiculous - these things just happen as you add / modify something. would be my number one feature request. cannot believe this issue just brought out such a crazy response from me. apologies. it obviously does drive me mad. surely it drives everyone mad, not just me and Robert?!

Hi Roman. Not sure if I see your point about [route]. In my proposed scenario, if I had an an object [route 1 2] and the left two outlets where each connected to 12 objects, then I am saying that if you later added a third argument "3" you could add it before the 1 or after the 2 without having to redraw the 24 patch cords. Of course there is no difference in performance or behavior between a [route 3 1 2] object and a [route 1 2 3] so it is not a big deal to insist that you need - in this case - to add the new argument to the end to preserve the original 24 patchcords. But on the other hand my proposal would still seem logical, in this route example, from the Max user point of view, and I can't see why tracking where the new argument is added breaks any basic functionality of route. Of course, with trigger, where you add the argument is the whole point and it is massively frustrating to redraw the patchcords everytime I find I need to adjust the flow of the program.

I guess I do see some complications. You can, for instance, change more than one argument when you edit the object arguments - even, of course, cut and paste multiple arguments from one position to another. Tracking all this adding and deleting may be too much to ask. But to the extent that it could be done, it would save users - well me and pid at least ;) - lots of time and frustration.

Hi Roman. Not sure if I see your point about [route]. In my proposed scenario, if I had an an object [route 1 2] and the left two outlets where each connected to 12 objects, then I am saying that if you later added a third argument "3" you could add it before the 1 or after the 2 without having to redraw the 24 patch cords. Of course there is no difference in performance or behavior between a [route 3 1 2] object and a [route 1 2 3] so it is not a big deal to insist that you need - in this case - to add the new argument to the end to preserve the original 24 patchcords. But on the other hand my proposal would still seem logical, in this route example, from the Max user point of view, and I can't see why tracking where the new argument is added breaks any basic functionality of route. Of course, with trigger, where you add the argument is the whole point and it is massively frustrating to redraw the patchcords everytime I find I need to adjust the flow of the program.
I guess I do see some complications. You can, for instance, change more than one argument when you edit the object arguments - even, of course, cut and paste multiple arguments from one position to another. Tracking all this adding and deleting may be too much to ask. But to the extent that it could be done, it would save users - well me and pid at least ;) - lots of time and frustration.


exactly, what should happen inside the object if you change _and add several

or of you delete the 7th and the 8th but add a 12th ... automatic inserting of a

new outlet would fail, because the object does not recognize what you type until

we also agree on the difference between route and trigger. that is what was

suggesting: with [route] you dont come too often across this because the order

wont matter anyway - while in trigger the order is what it is all about.

in other words: this is normal, all objects suffer from this.

i know the trigger frustration desease very well, but my guess is that auto-recreation

and numbering of the outlets would mean that the developer of the object would have

to build the way trigger creates outlets totally different from other objects.

once i tried to always start with a t 0 0 0 0 0 0 and then use only every other 0 to to

type the stuff i need, but that sucks as much as reconnecting. :)

exactly, what should happen inside the object if you change _and add several
new arguments in a [t b b 1 0 b set].
or of you delete the 7th and the 8th but add a 12th ... automatic inserting of a
new outlet would fail, because the object does not recognize what you type until
you release the insert cursor.

we also agree on the difference between route and trigger. that is what was
suggesting: with [route] you dont come too often across this because the order
wont matter anyway - while in trigger the order is what it is all about.
in other words: this is normal, all objects suffer from this.

i know the trigger frustration desease very well, but my guess is that auto-recreation
and numbering of the outlets would mean that the developer of the object would have
to build the way trigger creates outlets totally different from other objects.

once i tried to always start with a t 0 0 0 0 0 0 and then use only every other 0 to to
type the stuff i need, but that sucks as much as reconnecting. :)

adding args to trigger, preserving existing signal routing