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

[Alexandre Torres Porres]

Em dom, 14 de abr de 2019 às 21:07, William Huston <williamahuston at gmail.com>
escreveu:

> unpack does not guarantee sequence
>

actually, it does, as virtually all objects in Pd, from right to left
(trigger is no exception).

So you're able to do what you want if you stack [pack] and [unpack]
together!


> I saw the post on FB about why [t 10 66 -100 3000] doesn't work as
> expected.
>

It wasn't expected to work at all in Vanilla, the help file shows how you
shouldn't use floats at all as arguments. It might be an expectation if
you're using that feature in Purr Data, but then, I think the expectation
flaw is that Purr Data has different behaviour for Vanilla objects that
break compatibility.

That seems like a reasonable expectation based on how [pack 10 66 -100
> 3000] works
>
Also giving a list to [t f f f f] seems like it should work like [pack f f
> f f].
>

It should definitely not as the trigger object has nothing to do with pack
or any other object. Pd objects work within their own design paradigms.
Having a simple look at trigger's help file shows you that a list to   [t f
f f f] will convert the list to a float and trigger it. And the facebook
post doesn't even request for this feature, it was something to do with how
trigger works in Max and in Purr Data, not a request that it should behave
like [pack].


> I am just saying that such irregularities and special cases in a language
> given similar syntax (as with English!) make it more difficult to learn,
> use, and master.
>

I don't see it as a "syntax" matter. Every object has a set of arguments
and flags. Some take floats, some take symbols, etc... it's all based on
what the task of the object is. If you do not seem to understand the
purpose and function of [trigger], then it might be confusing. As Iohannes
pointed out, [trigger] has a very clear method for handling lists and it
should not be changed because of any other object in Pd.

By the way, [pack] does not have a list method, it behaves much like every
object in Pd that has no list method and many inlets, it just splits the
message into the inlets. Trigger only has one inlet, it's a completely
different case without any syntactical conflict.

I think given present behavior, [t 35] should throw an error to the
> console.
>

or a mention in the help file that floats will just work as "float".


> But I would prefer the change requested.
>

which one, this? https://github.com/pure-data/pure-data/issues/354

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190414/9885f7bf/attachment.html>