[PD] packed floats to select object changes the select value

Matt Davey hard.off at gmail.com
Mon Sep 21 04:43:58 CEST 2020

Just for background, here's the reason why it caused so much difficulty:

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
In one synth channel, we have a [sel $1] object to update parameters
according to the channel they correspond to.
That channel abstraction was written several years ago, and never had an

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.

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.

Never even thought for a moment that the old [sel $1] object would change
its selection value when presented with packed floats.

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).

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.


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

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.

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,,,,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200921/f2e39bd7/attachment-0001.html>

More information about the Pd-list mailing list