[PD] bang vs empty list

[Ivica Bukvic]

On Mar 1, 2013 12:14 PM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:
>
> >________________________________
> > From: Ivica Bukvic <ico at vt.edu>
> >To: Jonathan Wilkes <jancsika at yahoo.com>
> >Cc: pd-list <pd-list at iem.at>
> >Sent: Friday, March 1, 2013 12:03 PM
> >Subject: Re: [PD] bang vs empty list
> >
> >
> >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.
>
> I don't understand.  When did you change [select] to accept bang
messages?  Or are you saying
> that you were receiving the message "list" and it went unreported?

Yes they were being registered as list that before IOhannes' patch and now
are being reported as errors. so I opted for the select patch I proposed
above.

>
>
> > 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.
>
> There are probably very few cases where one would actually need to
differentiate between "bang" and "symbol bang" using [select], but it seems
like bad design to let two distinct messages trigger the same
> behavior in an object whose sole purpose is to differentiate messages
from each other.

At the same time I think having to cover bang to symbol bang just to have
it selectable by select does not seem very intuitive to me. How would you
even do that in the first place if there's more than just a bang coming
into that inlet, e.g. a bang and float values? You couldn't use [symbol]
before it as that would trash float values.

>
> Anyway, you could fix your patches simply by inserting [route bang]
before your [select].

That is what I did, but that does not address the issue above.

>
> -Jonathan
>
>
> >On Mar 1, 2013 11:47 AM, "Jonathan Wilkes" <jancsika at yahoo.com> wrote:
> >
> >>________________________________
> >>> From: Ivica Bukvic <ico at vt.edu>
> >>>To: Jonathan Wilkes <jancsika at yahoo.com>
> >>>Cc: pd-list <pd-list at 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" <ico at 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" <jancsika at yahoo.com> wrote:
> >>>>
> >>>>----- Original Message -----
> >>>>>
> >>>>>> From: Ivica Ico Bukvic <ico at vt.edu>
> >>>>>> To: pd-list at 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 at iem.at mailing list
> >>>>>> UNSUBSCRIBE and account-management ->
> >>>>>> http://lists.puredata.info/listinfo/pd-list
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130301/2b8392ac/attachment-0001.htm>