This makes perfect sense. However, I have at least a couple of patches where I have a select connected to a networked stream of messages one which includes bang. So after I have to appied IOhannes' patch, this effectively resulted in a regression where bang messages were not recognized by the select object, throwing a large number of errors. While one can argue that this is simply a poorly designed patch the other side of the coin is to say that this latest addition has caused a breakage in the existing patches as this problem was never reported by pd before and now is causing xruns. I also hear your call for consistency so I am open for going either way particularly because the example you gave did not use select. After all what follows from select is nothing more than a bang while symbol bang would be intercepted anyways. On Mar 1, 2013 11:47 AM, "Jonathan Wilkes" <jancs...@yahoo.com> wrote:
> >________________________________ > > From: Ivica Bukvic <i...@vt.edu> > >To: Jonathan Wilkes <jancs...@yahoo.com> > >Cc: pd-list <pd-list@iem.at> > >Sent: Friday, March 1, 2013 7:55 AM > >Subject: Re: [PD] bang vs empty list > > > > > >To add to this, I cannot think of a scenario where you would want to > differentiate between bang versus symbol bang. Please feel free to convince > me otherwise. > > Just one example: > > If you parse a Pd patch in Pd you'll want to handle everything as lists, > because > the moment you shave off the list selector you're in danger of outputting > bad > messages: > > "#X text 10 10 INLET_0 bang float symbol" > > | > [route #X] > | > [route text] > | > [route 10] > | > [route 10] > | > [route INLET_0] > | > [route bang] > | > [route float] <-- oops, "float" got silently discarded above > > > Of course that's just a didactic example, because in real life you > would iterate over the message one atom at a time, and if "bang" > and "float" had been switched above you'd even get an explicit error > about "Bad arguments" (since float needs to be followed by a > float atom and not the symbol atom "bang"). Therefore you have > to use list objects to ensure you don't lose data or run into a badly > formed mesage, and when you split lists you end up with "symbol bang" > which [select] handles perfectly well. > > > The point is that select inspects the payload of the message and not the > selector. Bang messages don't have a payload so you've now made a special > case where the selector is inspected only if the user types "bang" as an > arg. The > [route] object already chooses bases on selector so I don't see a reason > to change > the behavior for [select] in this way. > > > -Jonathan > > > >On Mar 1, 2013 7:50 AM, "Ivica Bukvic" <i...@vt.edu> wrote: > > > >Yes, but it also prevents profuse errors on the console regarding how > select does not understand things which may happen in complex patches under > certain circumstances, and which previously were not reported. > >>On Mar 1, 2013 3:29 AM, "Jonathan Wilkes" <jancs...@yahoo.com> wrote: > >> > >>----- Original Message ----- > >>> > >>>> From: Ivica Ico Bukvic <i...@vt.edu> > >>>> To: pd-list@iem.at > >>>> Cc: > >>>> Sent: Thursday, February 28, 2013 7:15 PM > >>>> Subject: Re: [PD] bang vs empty list > >>>> > >>>> BTW, the only regression with this is that [select] object complains > it does not > >>>> understand "bang." > >>> > >>>Pd's [select] only understands symbol and float messages. If you make > it > >>>accept bangs then you create an inconsistency where both > >>>"symbol bang" and "bang" are matched by [sel bang]. > >>> > >>>-Jonathan > >>> > >>>> I've patched it so that when it receives a bang > >>>> it redirects it to sel1_symbol and sel2_symbol with a gensym("bang"). > >>>> This also means that [sel b] would not work for bangs, but [sel bang] > will. I > >>>> think that makes sense since someone might want to select letter "b." > >>>> > >>>> _______________________________________________ > >>>> Pd-list@iem.at mailing list > >>>> UNSUBSCRIBE and account-management -> > >>>> http://lists.puredata.info/listinfo/pd-list > >>>> > >>> > > > > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list