Re: [PD] Bug Report/Feature Request: trigger should work like pack
I agree [t b f l s 55] is rather messed up, but the usual use case is something like [t b b f b] or [[t b l] or [t a b] or [t b s b] - you get it, mixing message types with bangs. I know I do this all the time and perhaps you do that too. Just because you can do crazy and unreasonable things, it doesn't mean the object was designed for that. And now we have a request to also include constant values, which can add even more arbitrary and unreasonable possibilities, like in your example with t b f l s *55*]... I think there's an use case to initialize a patch and not need to have [t b b b] and then connect the bang outputs to symbols and floats. So I can see how it can be convenient. Em seg, 15 de abr de 2019 às 01:33, William Huston escreveu: > 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. > Like I said, trigger is mostly used not as a bang only, but also mixing with other message types. So I don't see how it would get deprecated. I also don't see why creating several other objects since the trigger object already does that. I think your problems with trigger is that you haven't really gotten it yet, it's actually a simple and quite versatile object. But simplicity can lead to versatileness, but that doesn't have to be confused with being complex and weird. cheers > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] trigger request, convert anythings
I see now that Purr Data does this, and since I've put its code into a PR < https://github.com/pure-data/pure-data/pull/582? I realize it also deals with this feature request :) Em seg, 15 de abr de 2019 às 01:21, Alexandre Torres Porres < por...@gmail.com> escreveu: > Hi Pd list, I don't get why trigger can't convert anything to something > other than a bang. Is there a particular concern not to let it happen? > > I think it should be converted to a list just by adding the list selector, > and treated as a list so it could be converted to the other message types > (symbol, float) > > what do you say? > > cheers > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
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 wrote: > Em dom, 14 de abr de 2019 às 21:44, Alexandre Torres Porres < > por...@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 > > > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] trigger request, convert anythings
Hi Pd list, I don't get why trigger can't convert anything to something other than a bang. Is there a particular concern not to let it happen? I think it should be converted to a list just by adding the list selector, and treated as a list so it could be converted to the other message types (symbol, float) what do you say? cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
Em dom, 14 de abr de 2019 às 21:44, Alexandre Torres Porres < por...@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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
Em dom, 14 de abr de 2019 às 21:07, William Huston 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
unpack does not guarantee sequence, as does trigger. It's not really "my" use case. I saw the post on FB about why [t 10 66 -100 3000] doesn't work as expected. That seems like a reasonable expectation based on how [pack 10 66 -100 3000] works, and a useful feature. Also giving a list to [t f f f f] seems like it should work like [pack f f f f]. 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. Whereas a language like Perl, things just seem to work as you would expect them to, based on similar patterns. You can often guess at the syntax and things just work, as opposed to learning a bunch of special cases. I think given present behavior, [t 35] should throw an error to the console. But I would prefer the change requested. BH On Sun, Apr 14, 2019, 7:34 PM Alexandre Torres Porres wrote: > > > Em dom, 14 de abr de 2019 às 19:14, William Huston < > williamahus...@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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
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 < por...@gmail.com> escreveu: > > > Em dom, 14 de abr de 2019 às 19:14, William Huston < > williamahus...@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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
Em dom, 14 de abr de 2019 às 19:14, William Huston 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
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 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 > ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Bug Report/Feature Request: trigger should work like pack
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 signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
