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

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.

BH

On Sun, Apr 14, 2019, 4:27 PM IOhannes m zmölnig zmoelnig@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

I see the facebook discussion, it's actually a request for this:

https://github.com/pure-data/pure-data/issues/354

Em dom, 14 de abr de 2019 às 20:33, Alexandre Torres Porres < porres@gmail.com> escreveu:

Em dom, 14 de abr de 2019 às 19:14, William Huston < williamahuston@gmail.com> escreveu:

...

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

I've done that lots of times

...

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)

not a good point as both objects are supposed to be quite different, and each object has its own design or "syntax"

...

b) sending a list to [t f f f]. Distributing the list to each float seems rather useful

this task is performed by [unpack f f f] already.

I don't really understand your use case, can you give us more details?

cheers

Em dom, 14 de abr de 2019 às 21:07, William Huston williamahuston@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

Someone brought it to our attention on FB, and it seemed like a legitimate wart.

Thanks for remind me that unpack really does guarantee R to L fanout order.

You're right Alex. It's not really my issue. I have no real motivation. I should have left it alone.

I think my root concern at this point is how trigger is overloaded.

if it only dealt with bangs, that makes much more sense.

If you are replicating a float on all outlets, that seems to me an entirely different object! That's got nothing to do with a triggee. That's a float clone, or a symbol or list replicator.

When you add all those datatypes into one object, which you call trigger, and allow even mixing datatypes (!!) as arguments to a single object (!), well, IMO that produces some possibly very ugly code which does some really odd things.

This is my new request, and this is "mine" now ;)

Let's decouple that overloaded trigger into more rational objects

bang-only trigger float replicator/sequencer List replicator/sequencer symbol replicator / sequencer. deprecate existing trigger.

Because I think

*[t b f l s 55] *

is VERY MESSED UP, and *it's never going to so anything reasonable*, I can't imagine any useful purpose for that, allowing it will only confuse people, and make the language irregular and harder to learn,

and thus it should be prohibited by syntax or at least deprecated.

IMHO ;) BH

On Sun, Apr 14, 2019, 11:57 PM Alexandre Torres Porres porres@gmail.com wrote:

Em dom, 14 de abr de 2019 às 21:44, Alexandre Torres Porres < porres@gmail.com> escreveu:

...

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

cheers

Anyway, I just went ahead and made a PR for it. I just got the code from Purr Data and swapped with vanilla's, nothing else! I obviously tested and itt works just fine. I also updated the help file, of course (by the way, Purr Data's help file doesn't mention this feature).

I see how this could be convenient in some use cases, but I don't have that much of a personal motivation to request this. I guess my main motivation to do this PR is that:

A) people often request for it (maybe they are influenced by Max or Purr Data, who knows, doesn't matter).

B) I think it's really bad that Purr Data is not compatible to Pd, but I understand this is not Pd's fault.

Well, if this doesn't get accepted, I guess I maybe could make an external like it in my library.

cheers