<div dir="ltr">Just for background, here's the reason why it caused so much difficulty:<br><br>I'm working on a really big complex project with hundreds of abstractions.  Lots of parameters feeding into each other with state saving, automations, gui interaction...etc<br>In one synth channel, we have a [sel $1] object to update parameters according to the channel they correspond to. <br>That channel abstraction was written several years ago, and never had an issue. <br><br>About a year ago, we modified one of those channels to have 9 voices.  The voices get a $2 argument from 1-9.  In the original channels without the 9 voices, the creation argument is left off and therefore just stays as 0. <br><br>So last week i was doing a cleanup to merge the single voice channels with the 9 voice channel, and sending a channel message or a packed channel / voice message.   Started to get weird behaviour, somewhat akin to execution order issues.  Some values were being sent correctly the first few times, and then only coming out wrong later on.  I religiously use triggers everywhere, even when they are not essential, but i went over the whole section again and checked the order.  All seemed fine.  <br><br>Never even thought for a moment that the old [sel $1] object would change its selection value when presented with packed floats. <br><br>The reason it was so hard to detect, is that the first outlet of [sel] outputs a bang, and not a value.  So if the bang is not output, instead of getting a wrong value that is easy to track down, it just quietly sends the value through its right outlet (which in this case was not connected).<br><br>Turns out that by sending the channel / voice messages to the 9 voice channel, and then merging that with the single voice channels, that all the single voice channels were also receiving packed channel / voice messages to the [sel] object, and thus changing its selection value.  It wasn't until i literally put a print on either side of the [sel] object that i noticed something was super weird. <br><br>***<br><br>Can understand that it's just following protocol of other objects that take a list and distribute it to cold inlets, but the difference here is that those other objects will still output SOMETHING through their left outlet, so at least you get an idea that something is wrong.  With [sel] it just stops sending the bang, and if you don't have anything connected to the right outlet, you'd not notice that unless you are directly monitoring that bang. <br><br>The only other object that i can think of which would behave that same way is [moses], but even with that, you're inputting floats and outputting floats, so much more likely to track down the cause if you accidentally set the cold inlet of that one. <br><br>Anyway, i'm on no crusade.  I've learnt my lesson with this one, and spent a few days tracking down that one bug, so won't make that mistake again.  There does seem to be a big reluctance here to change the behaviour though, so whatever,,,,<br><br><br><br></div>