porting trigger from Purr Data

[porres]

using the code and features of Purr Data into Pd.

closes #354

and also closes #583

[umlaeute]

could you expand a bit on what those features backported from Purr Data actually are? (it's much easier to read a short description here, than to download/install/run Purr Data and check the help-patch)

[porres]

Actually (and funny enough) Purr Data's help file doesn't mention these features :)

But I've updated the help file of trigger for this PR including the changes. And it's nothing but what's been pointed in both #354 and #583

Namely it:

1. also converts anythings.

2. Offers constant values.

Regarding "2", non constant values are the usual arguments: anything, list, bang, float, symbol, pointer or the first letter of each. Anything else, like a float or a different symbol, is treated as a constant value. So if something like [t f b 30 stop] receives a "5" float message, the output, from right to left, is: "symbol stop", "30", "bang", "5".

[Spacechild1]

I can see the value of 2. as a shortcut for connecting bangs to individual message boxes and I think it's ok for floats, but I consider mixing symbols and reserved identifiers a bit problematic.
just look at [1 2 3( -> [t a b c d e f]

[porres]

just look at [1 2 3( -> [t a b c d e f]

I don't know what you mean, but I see that this doesn't work in Purr Data, as it actually cannot load one character symbols.

[porres]

I think you did not mean that the code of Purr Data was wrong or bad... but I've fixed it anyway...

now [t a b c d e f] will output the symbols 'c', 'd' and 'e' alright...

of course and as stated, 'a', 'b' and 'f' are special cases and will not be output as symbols, cause it would even break patches

[porres]

well, ok, I get you think it's not perfect to mix symbols, because some are special cases. I can see that, though I personally don't mind. I also realize @umlaeute isn't very happy either with the idea.

It's not like I'm dying for this feature anyway, the motivation was coming from a personal concern that purr data and vanilla could be more compatible, but this seems to be a lost battle anyway, and I don't really care that much.

On the other hand, I've seen people from time to time request for this feature, specially for floats, of course, so maybe it's worth it.

Hence, if what gets into Pd is the float feature alone, I'd be cool with that ;) and I could adapt the code to only allow for constant Floats if that's the case! Maybe I'll do a separate PR for that case.

Oh, I hope there's no opposition to allowing anythings to be converted to other message types, that's an annoyance I never understood and I hope we get rid of it.

Cheers

[rnkn]

I would love to see this merged. Anything that makes Pd more intuitive is a good thing.

[porres]

how do you feel about symbols?

[rnkn]

how do you feel about symbols?

I have no opinion.

[porres]

so, there's a new PR #600 we can have instead, with just constant floats! If floats is all we want, then this one can be closed

[fdch]

I realize I am late on this discussion, but still, my 2 cents:

I can't see why one would need this other than loading patches from Purr Data with that specific use of [trigger]. And I guess it will take time to get used to using [trigger] in that way. But, if some find this intuitive behavior I cannot argue with that. So, I really have no arguments against this feature and I would be curious to try it.

Perhaps if [trigger] has constant floats or lists, it would make sense that [unpack] had something similar

[porres]

I can't see why one would need this other than loading patches from Purr Data with that specific use of [trigger]

I don't get it, If someone is using trigger in Purr Data like that, then it has a use case.

I can better se the usefulness of having constant floats, a symbol would be more rarely used, like if you need to sequence a "stop" or a "reset" message or whatever an object requires.

Perhaps if [trigger] has constant floats or lists

it'd have just floats

it would make sense that [unpack] had something similar

why? and how so?

[rnkn]

"I wouldn't use this so no one should" strikes again!

[fdch]

As I said: I am not against this, please read carefully. I am only skeptical about it being actually useful.

About [unpack]:
I thought of initializing arguments instead of them being "type declarations." This would apply to [pack], and work like [list]'s arguments, or an abstraction's args, for that matter. It would make sense to me since it is a similar treatment of arguments by initializing them instead of only declaring their types.

[fdch]

Also, perhaps a "set" method might be needed to update the values if you need to.

[rnkn]

@fdch: Alexandre has already explained it's usefulness, and it is default behaviour in Max. Read above.

[porres]

i'm closing this one and I'm working on a new PR instead #694