[PD] bang vs empty list

[Ivica Bukvic]

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" <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/29550a50/attachment.htm>