[2 3( | [sel 2]
outputs the 2 from the right outlet! Sending a 3 afterwards outputs a bang from the left outlet.
Pretty sure this is unwanted behaviour, due probably to pd objects' default behaviour of using a second float to set the cold inlet. In this case it is definitely unwanted, and can be the source of some very hard to track down bugs.
due probably to pd objects' default behaviour of using a second float to set the cold inlet.
that's correct. The first inlet of [select] expects a *single* float (or symbol). The help patch says: "compare floast and symbol".
Pretty sure this is unwanted behaviour
The behavior has been like this for ages and won't change. If you don't like it, use another object. You're probably looking for [relay] from zexy. You can easily make a vanilla version with [list split], [route] and [list prepend].
Christof
On 20.09.2020 13:13, Matt Davey wrote:
[2 3( | [sel 2]
outputs the 2 from the right outlet! Sending a 3 afterwards outputs a bang from the left outlet.
Pretty sure this is unwanted behaviour, due probably to pd objects' default behaviour of using a second float to set the cold inlet. In this case it is definitely unwanted, and can be the source of some very hard to track down bugs.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Is there any reason why it shouldn't change?
It's undocumented and weird behaviour that surely nobody relies on.
I cannot think of a single case in which anyone would want to send packed floats to a sel object in order to set its value.
Em dom., 20 de set. de 2020 às 09:40, Matt Davey hard.off@gmail.com escreveu:
Is there any reason why it shouldn't change?
It's undocumented and weird behaviour that surely nobody relies on.
actually it is as 'seb shader' referenced on github, see http://msp.ucsd.edu/Pd_documentation/x2.htm#s3.3
Unless they arrange otherwise by defining a "list" method, objects respond to the "list" message by distributing the arguments of the message to their inlets, except for the first argument which is passed as a "float" or "symbol" message to the object proper.
you can easily fix your patch by using unpack or something. But you may have a request that we add a list method to select where it only considers the 1st item of a list. If no one actually relies on this list behaviour you may have a point.
you can easily fix your patch by using unpack or something.
[t f] is probably the most efficient.
If no one actually relies on this list behaviour you may have a point.
like always, I'm pretty sure that I actually used this at least once.
but more importantly, I definitely do you use the list-to-inlets feature with objects like [+], [pack] and [line]; and I think that the behaviour should be consistent (as it currently is).
mfg.hft.fsl IOhannes
Here’s my proposal:
If a sel object is created with arguments, add a list method to truncate incoming lists to the first item.
If a sel object is created without any arguments, behaviour stays the way it currently is.
Would that work?
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 issue.
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 bang.
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,,,,
hello,
why don't you just use [route] ?
cheers
Le 21/09/2020 à 02:52, Matt Davey a écrit :
Here’s my proposal:
If a sel object is created with arguments, add a list method to truncate incoming lists to the first item.
If a sel object is created without any arguments, behaviour stays the way it currently is.
Would that work?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I am aware of the workarounds, and have put one in place to fix this now.
That's not the issue here. The issue is that accidentally sending a list to the select object invisibly changes its behaviour and can produce some hard to find bugs in big patches. There are lots of other objects where this could happen, but [sel] is somewhat unique in that it won't output incorrect values to its main outlet but rather just stops sending bangs and sends to its second outlet.
On Mon, 2020-09-21 at 17:16 +0800, Matt Davey wrote:
I am aware of the workarounds, and have put one in place to fix this now.
That's not the issue here. The issue is that accidentally sending a list to the select object invisibly changes its behaviour and can produce some hard to find bugs in big patches.
I don't quite see why you are singling out [select]. To my knowledge, all control objects distribute incoming lists across there inlets. There is nothing special in [select] here. Also, it's pretty common in Pd that you can override creation arguments without the visual representation not reflect it. Personally, I find this discussion moot.
There are lots of other objects where this could happen, but [sel] is somewhat unique in that it won't output incorrect values to its main outlet but rather just stops sending bangs and sends to its second outlet.
Especially with [select], it's hard to check its internal state. Maybe a possibility for introspection is lacking here? A new 'introspect' method, that would print the current state to the console?
Roman
Especially with [select], it's hard to check its internal state. Maybe a possibility for introspection is lacking here?
[select] doesn't have any more internal state than, say, [+]. It is not special in any way.
A new 'introspect' method, that would print the current state to the console?
Please no :-)
On 22.09.2020 09:37, Roman Haefeli wrote:
On Mon, 2020-09-21 at 17:16 +0800, Matt Davey wrote:
I am aware of the workarounds, and have put one in place to fix this now.
That's not the issue here. The issue is that accidentally sending a list to the select object invisibly changes its behaviour and can produce some hard to find bugs in big patches.
I don't quite see why you are singling out [select]. To my knowledge, all control objects distribute incoming lists across there inlets. There is nothing special in [select] here. Also, it's pretty common in Pd that you can override creation arguments without the visual representation not reflect it. Personally, I find this discussion moot.
There are lots of other objects where this could happen, but [sel] is somewhat unique in that it won't output incorrect values to its main outlet but rather just stops sending bangs and sends to its second outlet.
Especially with [select], it's hard to check its internal state. Maybe a possibility for introspection is lacking here? A new 'introspect' method, that would print the current state to the console?
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2020-09-22 at 11:19 +0200, Christof Ressi wrote:
Especially with [select], it's hard to check its internal state. Maybe a possibility for introspection is lacking here?
[select] doesn't have any more internal state than, say, [+]. It is not special in any way.
Right.
A new 'introspect' method, that would print the current state to the console?
Please no :-)
Yeah, let's forget about it, I wouldn't want it either.. was thinking loud.
Roman
I don't quite see why you are singling out [select]
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).
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.
I did have a good think about possible uses for the current behaviour, and i can think of one.
[pack f f] | [sel ]
is quicker than
[pack f f] | [== ] | [t b]
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.
thanks everyone for the discussion. happy to consider this one closed now.
On 22.09.20 15:46, Matt Davey wrote:
I did have a good think about possible uses for the current behaviour, and i can think of one.
[pack f f] | [sel ]
is quicker than
[pack f f] | [== ] | [t b]
personally i would definitely use the second case
but then, the behaviour would obviously be very different. just send [0 1( to both patches and see what happens.
gamsdr IOhannes
lol, forgot the very object we are talking about.
[pack f f] | [== ] | [sel 1] | [t b]
add a list method to truncate incoming lists to the first item. ... Would that work?
Unfortunately no, because [select] already has a (default) list method. Also I don't see why the behavior should depend on the presence of creation arguments...
In Pd we can *extend* behavior, but we can never *change* existing behavior, unless it is clearly a bug - which is not the case here!
The issue is that accidentally sending a list to the select object invisibly changes its behaviour
Well, the same happens if you accidentally send a list to [+], [-], [del], [metro], [line], etc.
What we *could* improve is the help patch, i.e. make it clear that list messages are distributed across inlets. But then we would actually have to do this for all the other objects...
As others have already pointed out: unless the help patch explicitly mentions a list method, the object has a default list method, which distributes items across inlets. When in doubt, use [t f] to prevent list messages.
Christof
On 21.09.2020 02:52, Matt Davey wrote:
Here’s my proposal:
If a sel object is created with arguments, add a list method to truncate incoming lists to the first item.
If a sel object is created without any arguments, behaviour stays the way it currently is.
Would that work?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 20/09/2020 12:13, Matt Davey wrote:
[2 3( | [sel 2]
outputs the 2 from the right outlet! Sending a 3 afterwards outputs a bang from the left outlet.
Dear Matt
I don’t find this behaviour problematic, but if you want to guard against accidentally "reprogramming" the select by sending a list, you can add a second — repeated — argument to the select (the second inlet goes away and the second outlet is redundant):
[2 3( | [sel 2 2]
… or you can place a float before the select:
[2 3( | [f] | [sel 2]
Right?
Best
matthew brandi