[PD] Bug Report/Feature Request: trigger should work like pack

William Huston williamahuston at gmail.com
Mon Apr 15 00:11:48 CEST 2019

Well if it breaks things, then that is a problem.

However, I think that sending a list to
[t l l l], and replicating the list to each output would have very few
applications. I would like to see a patch where someone is using this

Anyway, that is not my use case.

My use case is

a) literals in [t] not working the same between [pack] with similar looking
syntax (as illustrated), and

b) sending a list to [t f f f]. Distributing the list to each float seems
rather useful, and changing the behavior as I suggested would be harmless,
except in the odd case where someone has a patch, sending trigger a list,
yet EXPECTS all values in the list to be dropped except the first element,
which is distributed to each float.

The only ambigutity I can in accepting my change would be the case of using
BOTH lists and floats (or literals) in a single [t].  I honestly cannot
imagine a programmer doing this.

But then just model existing behavior.

Requested change:

If trigger's arguments contains *any* lists, then model existing behavior.

If trigger's arguments contains only floats (or string literals) and no
lists, then

a) if the input is a single value, model existing behavior.

b) if the input is a list, then distribute to floats and literals similar
to pack.


On Sun, Apr 14, 2019, 4:27 PM IOhannes m zmölnig <zmoelnig at iem.at> wrote:

> On 4/14/19 10:05 PM, William Huston wrote:
> >
> >    - 2: Allow [trigger] to accept a list. If there is one element, then
> >    distribute to all "f" | "floats" as the present behavior. If there are
> >    multiple elements, then distribute similar to pack.
> >
> that doesn't make sense to me, as [trigger] already accepts lists fine:
> [t l l l].
> however, this has totally different sematics than [pack].
> it would break zillions of patches.
> did i miss something?
> gmdsr
> IOhannes
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190414/d4d65953/attachment.html>

More information about the Pd-list mailing list