From: Miller Puckette <mpuckette@cloud.ucsd.edu>
Perhaps the ones that manage lists specially
should be flagged as not distributing lists among inlets.
that is indeed the case, [spigot] for instance passes lists and 'anythings'.
I opened an issue here
https://github.com/pure-data/pddp/issues/187 and MIller also replied and I quote and bring it back to this thread "
line and line~ (and I think vline~) also do non-standard list distribution - the ramp-time inlet resets to zero after each segment is started. That's why list-input behavior needs to be described explicitly. "Normal" objects like makenote don't reset inlets. BUT I guess it's still true that sending a list to line, etc., is still equivalent to distributing the values over the inlets, in the same way as for all the normal objects. The not-quite-standardness is in the way the middle inlet itself acts."
The special 'clearing' behaviour of inlets in the line family is well explained in the help file and I see it as totally equivalent to other cases where lists are spread over inlets.
Em qui., 14 de mar. de 2024 às 14:17, IOhannes m zmölnig <
zmoelnig@iem.at> escreveu:
i'm still very reluctant about adding the same and the same information
to every object that just exhibits standard behaviour, as this quickly
becomes noise. ("hey, did you know that you can connect this object to
[print]?")
I don't mean to add this to *all*, and in some cases would be rather silly, like [float]. And now I remembered of another object that "abuses" this behaviour in the help files, [stripnote], but not all too explicitly, Maybe there's one or another more...
I use this for math objects usually, for instance. And in fact, not by chance I guess, a math object was used to show this behaviour in (04.messages.pd). This can save someone from using [unpack] sometimes. I feel this is little known and people miss it or get confused.
I've also seen this occasionally "abused" in the help files of MAX; take [offer] for instance, and this is also true for [cyclone/offer]'s help file.
I also wanted to add an abstraction loaded under the [pd reference] subpatches that would be a 'guide' to better understand things as described in my reference subpacthes. My idea was to also reinforce this behaviour, because I consciously chose not to put into the references that 'list' input would eventually work. So I understand the idea of not reinforcing this all the time and for every case, but there are some examples in the help patch that can benefit from this and it wouldn't pollute too much, in fact, it's already happening.
cheers