<div dir="ltr">>I don't quite see why you are singling out [select]<br><br>It's the only object that has ever given me trouble in this way.  My guess is because almost all other objects that allow a list to modify their internal state will also output differently once that state has been modified.  If your [+ 1] object suddenly starts adding 100 to every input, it's pretty obvious what's gone wrong, and can be quickly fixed.  I think the reason why it's so sneaky with [sel] is that its main outlet only outputs a bang, and not a value.  There's never a "wrong" value being passed, unless you are connected to its last outlet (which usually you aren't).<br><br>Anyway, i can fully accept that this is not considered a bug, but rather a feature that keeps the [sel] object consistent with all others.  I'm not trying to stir up trouble, was just trying to point out the issue, cos it cost us a lot of time and effort to get to the bottom of a bug that was caused by that behaviour.  <br><br>I did have a good think about possible uses for the current behaviour, and i can think of one. <br><br>[pack f f]<br>|<br>[sel ]<br><br>is quicker than <br><br>[pack f f]<br>|<br>[== ]<br>|<br>[t b]<br><br>personally i would definitely use the second case, as it much more obviously shows the intent, but i guess the first way would also be legitimate. <br><br>thanks everyone for the discussion.  happy to consider this one closed now.  <br><br></div>