[PD] bang vs empty list
Seems like for any object that doesn't have a bang method nor list method, an empty list silently gets discarded. compare [bang( | [sin] to [list( | [sin] or, more likely [bang( | [t a] | [sin] Same for [select] and many others. Is there a way to fix this? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
I wonder if we could as part of the setup call for each external somehow
infer default behaviors for each object e.g.:
something_bang() {
Error("this inlet does not support bang message\n");
}
etc.
Then if that particular object has another addmethod after it referencing
its own genuine bang (or whatever) method, such call would override the
original. I am just not sure if this is possible in the first place and
whether that could produce some misleading messages as well (e.g. I just
fixed cxc/ascseq crash when receiving a bang but this was solved without
having the bang function--this may be fixed by the aforesaid approach as
long as this is somehow possible as part of the setup function and without
having to manually alter every single external's setup function and assuming
that bang function will take precedence over the anything function).
Thoughts?
> -Original Message-
> From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
> Jonathan Wilkes
> Sent: Monday, February 25, 2013 8:18 PM
> To: pd-list
> Subject: [PD] bang vs empty list
>
> Seems like for any object that doesn't have a bang method nor list method,
> an empty list silently gets discarded.
>
> compare
>
> [bang(
> |
> [sin]
>
> to
>
> [list(
> |
> [sin]
>
> or, more likely
>
> [bang(
>
> |
> [t a]
> |
> [sin]
>
> Same for [select] and many others.
>
> Is there a way to fix this?
>
> -Jonathan
>
>
> ___
> 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
Re: [PD] bang vs empty list
Each class has methods that can be looked up by symbol. At some point
after the class has been created, you could check the class has no bang
method, and if so, add the default bang method. Only built-in classes are
loaded when pd starts up, so if you load a class later, it would not have
the default method.
If you wanted it done at setup time, you would have to modify the function
that calls the setup function (I don't know what it is or how it's
done--please tell me) so you would follow the setup function and add
default methods.
Chuck
On Wed, Feb 27, 2013 at 5:05 PM, Ivica Ico Bukvic wrote:
> I wonder if we could as part of the setup call for each external somehow
> infer default behaviors for each object e.g.:
>
> something_bang() {
> Error("this inlet does not support bang message\n");
> }
> etc.
>
> Then if that particular object has another addmethod after it referencing
> its own genuine bang (or whatever) method, such call would override the
> original. I am just not sure if this is possible in the first place and
> whether that could produce some misleading messages as well (e.g. I just
> fixed cxc/ascseq crash when receiving a bang but this was solved without
> having the bang function--this may be fixed by the aforesaid approach as
> long as this is somehow possible as part of the setup function and without
> having to manually alter every single external's setup function and
> assuming
> that bang function will take precedence over the anything function).
>
> Thoughts?
>
>
> > -Original Message-
> > From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf
> Of
> > Jonathan Wilkes
> > Sent: Monday, February 25, 2013 8:18 PM
> > To: pd-list
> > Subject: [PD] bang vs empty list
> >
> > Seems like for any object that doesn't have a bang method nor list
> method,
> > an empty list silently gets discarded.
> >
> > compare
> >
> > [bang(
> > |
> > [sin]
> >
> > to
> >
> > [list(
> > |
> > [sin]
> >
> > or, more likely
> >
> > [bang(
> >
> > |
> > [t a]
> > |
> > [sin]
> >
> > Same for [select] and many others.
> >
> > Is there a way to fix this?
> >
> > -Jonathan
> >
> >
> > ___
> > 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
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i guess i'm missing something, but...
On 2013-02-28 00:38, Charles Z Henry wrote:
> Each class has methods that can be looked up by symbol. At some
> point after the class has been created, you could check the class
> has no bang method, and if so, add the default bang method. Only
> built-in classes are loaded when pd starts up, so if you load a
> class later, it would not have the default method.
each object has a default method, namely the defaul catch-all ("aka
"anything") method, that will print "no method for ".
not having an explicit "bang" method, will defer the "bang" message to
this catch-all method.
>
> If you wanted it done at setup time, you would have to modify the
> function that calls the setup function (I don't know what it is or
> how it's done--please tell me) so you would follow the setup
> function and add default methods.
not sure whether i totally understand what you mean by "setup time"
(and "setup function") here.
the function that calls the setup function does not do anything
special (it just calls an entry point in a dll). especially, it does
notmake any assumptions what this setup function is going to perform
(though in most cases it will register some classes).
so, the only function that needed to be changed would be the generic
class-creator function class_new().
nevertheless i don't see what this would solve with respect to the
current behaviour.
i can imagine that the problems you are trying to solve are caused by
Pd's automatic conversions between different types (e.g. [list 12( and
[float 12().
if you removed all those conversions, you would immediately get your
"desired" behaviour.
and people would start complaining why the following gives an error
"[sin]: no method for 'list'".
[1 2 3(
|
[list split 1]
|
[sin]
this can of course be fixed by simply adding an explicit "list" method
to [sin], which does "the right thing".
but all the problems that arise because of the automatic message
conversion can already be solved by adding explicit methods for
messages you don't want to be autoconverted.
btw, i think something really nice to have would be per-object methods
(as oppposed to per-class methods). for this to work, the object would
need a copy of the class method table (rather than a reference).
fgamsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEvFakACgkQkX2Xpv6ydvS4vgCfa5l8LEuR8IhDQdqPtH/VE7qX
860An0vDf9w36U/I4qxD7si1pLX5CVT4
=9kvD
-END PGP SIGNATURE-
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-02-26 02:17, Jonathan Wilkes wrote:
> Seems like for any object that doesn't have a bang method nor list
> method, an empty list silently gets discarded.
[...]
>
> Is there a way to fix this?
>
sure :-)
the default list method will try to do something clever with the empty
list:
- - if there is a non-default bangmethod, it will call that (which is
not the case for [sin])
- - elif there is a non-default catchall method, it will call that
(which is not the case for [sin])
- - elif the object has inlets (which is the case for [sin]), it will
distribute the atoms over the inlets. since there are 0 atoms, no
inlet will receive any data.
- - else call the default catchall method.
so i think there are two things to fix:
1. Pd shouldn't try to fill an empty list to the objects inlets.
2. [t a] should not output an empty list if it receives a [bang(
attached are fixes for both problems (actually the 2nd patch makes [t
a] output the message as it came in, rather than converting it to a
list - so it also fixes the problem for numbers and symbols, not only
for bangs)
i rely on the community to test them thorougly :-)
there are still some weirdos though:
[float 42, list 666, list, foo(
|
[t s]
|
[print]
i wonder what the correct behaviour should actually be.
intuitively i would say that for non-symbols, [t s] should output the
selector as a symbol (if we don't want to introduce "%d" semantics
which i would rather not for performance reasons).
this would also make sense for anythings, where we currently get that
weird "only convert 's' to 'b' or 'a'" (it's weird insofar as it takes
some time to see what the 's' is referring to)
fgm,asdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEvIWQACgkQkX2Xpv6ydvROxQCcCySUREYwDdUEAQwkHpq/oSVX
TJUAoMxAjB4wZwUGy+QiOAoSwY2o7xLF
=56Tj
-END PGP SIGNATURE-
>From 049904da3f4019593e6565bb7b2723b5154f5e87 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig
Date: Thu, 28 Feb 2013 10:05:45 +0100
Subject: [PATCH 1/3] don't unpack empty lists to object's inlets
since the list is empty, this will effectively be a no-op
(and thus an empty list is silently discarded).
better call the pd_defaultanything() method.
---
src/m_class.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/m_class.c b/src/m_class.c
index bbc2fe7..3fb6d5c 100644
--- a/src/m_class.c
+++ b/src/m_class.c
@@ -132,7 +132,7 @@ static void pd_defaultlist(t_pd *x, t_symbol *s, int argc, t_atom *argv)
/* if the object is patchable (i.e., can have proper inlets)
send it on to obj_list which will unpack the list into the inlets */
-else if ((*x)->c_patchable)
+else if (argc>0 && (*x)->c_patchable)
obj_list((t_object *)x, s, argc, argv);
/* otherwise gove up and complain. */
else pd_defaultanything(x, &s_list, argc, argv);
--
1.7.10.4
>From 7bfdcc792d20cf173ab58e69260b148144dbd903 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig
Date: Thu, 28 Feb 2013 10:09:05 +0100
Subject: [PATCH 2/3] fixing trigger's "a" outlet
so it re-sends the actual message, rather than converting it to list.
---
src/x_connective.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/x_connective.c b/src/x_connective.c
index abd0931..0ac8cc6 100644
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol *s, int argc, t_atom *argv)
else if (u->u_type == TR_SYMBOL)
outlet_symbol(u->u_outlet,
(argc ? atom_getsymbol(argv) : &s_symbol));
+else if (u->u_type == TR_ANYTHING)
+outlet_anything(u->u_outlet, s, argc, argv);
else if (u->u_type == TR_POINTER)
{
if (!argc || argv->a_type != TR_POINTER)
@@ -1017,28 +1019,28 @@ static void trigger_anything(t_trigger *x, t_symbol *s, int argc, t_atom *argv)
static void trigger_bang(t_trigger *x)
{
-trigger_list(x, 0, 0, 0);
+trigger_list(x, &s_bang, 0, 0);
}
static void trigger_pointer(t_trigger *x, t_gpointer *gp)
{
t_atom at;
SETPOINTER(&at, gp);
-trigger_list(x, 0, 1, &at);
+trigger_list(x, &s_pointer, 1, &at);
}
static void trigger_float(t_trigger *x, t_float f)
{
t_atom at;
SETFLOAT(&at, f);
-trigger_list(x, 0, 1, &at);
+trigger_list(x, &s_float, 1, &at);
}
static void trigger_symbol(t_trigger *x, t_symbol *s)
{
t_atom at;
SETSYMBOL(&at, s);
-trigger_list(x, 0, 1, &at);
+trigger_list(x, &s_symbol, 1, &at);
}
static void trigger_free(t_trigger *x)
--
1.7.10.4
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
How about further expanding trigger to tolerate a->s by simply taking
the very first argument if the first argument is not type descriptor?
See attached.
e.g.
[foo<
|
[t s]
|
[print]
would output foo.
foo bar->outputs foo
bar foo->outputs bar
--- x_connective.c.orig 2013-02-28 13:31:10.011297224 -0500
+++ x_connective.c 2013-02-28 13:33:08.110292915 -0500
@@ -977,6 +977,9 @@
t_triggerout *x_vec;
} t_trigger;
+// forward declaration
+static void trigger_symbol(t_trigger *x, t_symbol *s);
+
static void *trigger_new(t_symbol *s, int argc, t_atom *argv)
{
t_trigger *x = (t_trigger *)pd_new(trigger_class);
@@ -1100,8 +1103,8 @@
else if (u->u_type == TR_STATIC_SYMBOL)
{
outlet_symbol(u->u_outlet, &u->u_sym);
- }
-else pd_error(x, "trigger: can only convert 'a' to 'b' or 'a'");
+ }
+ else trigger_symbol(x, s);
}
}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 02/28/2013 19:34, Ivica Ico Bukvic wrote:
> How about further expanding trigger to tolerate a->s by simply taking
> the very first argument if the first argument is not type descriptor?
that's what i was proposing, though i used terminology which i think is
more common, e.g. "selector" instead of "type descriptor" ("foo" is
really _not_ a type-descriptor, but instead is the CAR that selects
(sic!) a method of an object).
> See attached.
to which versionn of Pd should this be applied? doesn't seem to be
compatible with Pd master/git.
anyhow, yes, i agree that the implementation is fairly simple, i was
more concerned with the question what's the *right* thing to do.
fgmadrs
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
This is for pd-l2ork, but should be near identical to regular. Pd-l2ork's
trigger is also capable of static values like Max's, so this may be the
discrepancy in source.
On Feb 28, 2013 2:29 PM, "IOhannes m zmölnig" wrote:
> On 02/28/2013 19:34, Ivica Ico Bukvic wrote:
> > How about further expanding trigger to tolerate a->s by simply taking
> > the very first argument if the first argument is not type descriptor?
>
> that's what i was proposing, though i used terminology which i think is
> more common, e.g. "selector" instead of "type descriptor" ("foo" is
> really _not_ a type-descriptor, but instead is the CAR that selects
> (sic!) a method of an object).
>
> > See attached.
>
> to which versionn of Pd should this be applied? doesn't seem to be
> compatible with Pd master/git.
>
> anyhow, yes, i agree that the implementation is fairly simple, i was
> more concerned with the question what's the *right* thing to do.
>
> fgmadrs
> IOhannes
>
> ___
> 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
Re: [PD] bang vs empty list
BTW, the only regression with this is that [select] object complains it
does not understand "bang." 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
Re: [PD] bang vs empty list
- Original Message -
> From: Ivica Ico Bukvic
> 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
Re: [PD] bang vs empty list
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" wrote:
> - Original Message -
>
> > From: Ivica Ico Bukvic
> > 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
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.
On Mar 1, 2013 7:50 AM, "Ivica Bukvic" 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" wrote:
>
>> - Original Message -
>>
>> > From: Ivica Ico Bukvic
>> > 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
Re: [PD] bang vs empty list
>
> From: Ivica Bukvic
>To: Jonathan Wilkes
>Cc: pd-list
>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" 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" wrote:
>>
>>- Original Message -
>>>
>>>> From: Ivica Ico Bukvic
>>>> 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
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. 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" wrote:
> >
> > From: Ivica Bukvic
> >To: Jonathan Wilkes
> >Cc: pd-list
> >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" 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" wrote:
> >>
> >>- Original Message -
> >>>
> >>>> From: Ivica Ico Bukvic
> >>>> 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
Re: [PD] bang vs empty list
>
> From: Ivica Bukvic
>To: Jonathan Wilkes
>Cc: pd-list
>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?
> 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.
Anyway, you could fix your patches simply by inserting [route bang] before your
[select].
-Jonathan
>On Mar 1, 2013 11:47 AM, "Jonathan Wilkes" wrote:
>
>>____
>>> From: Ivica Bukvic
>>>To: Jonathan Wilkes
>>>Cc: pd-list
>>>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" 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" wrote:
>>>>
>>>>- Original Message -
>>>>>
>>>>>> From: Ivica Ico Bukvic
>>>>>> 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
Re: [PD] bang vs empty list
On Mar 1, 2013 12:14 PM, "Jonathan Wilkes" wrote: > > > > > From: Ivica Bukvic > >To: Jonathan Wilkes > >Cc: pd-list > >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" wrote: > > > >> > >>> From: Ivica Bukvic > >>>To: Jonathan Wilkes > >>>Cc: pd-list > >>>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&
Re: [PD] bang vs empty list
> > From: Ivica Bukvic >To: Jonathan Wilkes >Cc: pd-list >Sent: Friday, March 1, 2013 1:41 PM >Subject: Re: [PD] bang vs empty list > > > >On Mar 1, 2013 12:14 PM, "Jonathan Wilkes" wrote: >> >> > >> > From: Ivica Bukvic >> >To: Jonathan Wilkes >> >Cc: pd-list >> >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. Outputting the message from [textfile] (which has its own problems because it outputs anything instead of list), then something like [list-drip]. Splitting the message up in the list domain ensures that you won't lose data since everything is treated as a list. So if there is the word "bang" somewhere in the middle of the message it will come out of [list-drip] (or a home-brewed one using [list split]) as "list bang" which gets interpreted by [select] as a symbol message. That's the only way to parse a text file in Pd without running into errors (although you'll still lose data, for example, if consecutive whitespaces are needed, or special characters that Pd escapes, etc.). -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-01 18:03, Ivica Bukvic wrote: > 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. thanks for the test. however, i'm not entirely sure whether this is really a regression (or a poorly designed patch). my patch will make empty lists do something meaningful (that is: check whether the object can handle them) rather than simply ignore them, but that was the point of the patch. before my patch, [select] would emit a "no method for 'bang'" whenever it received a [bang(, and it would do nothing when it received a [list( (neither "accept" nor "reject" the message through it's designated outlets). now it will emit a "no method for 'list'" whenever it gets a [list(, and retain the original behaviour for all other messages. this is the intended behaviour. i tried to reproduce your test-case, but it seems to behave differently on pd-vanilla than on pd-l2ork. this is what i tried: [connect localhost ( [r data] | | | +-+ | [netsend] [netreceive ] | [select] doing a [;data send bang( will give me a "select: no method for 'bang'" both with and without my patch applied. doing a [;data send( will give me nothing both with and without my patch applied (since [netsend] will not send an empty message). could this be a regression in [dsis_netsend]/[dsis_netreceive] that has been exposed by my patch? maybe it would help if you posted a patch that exposes the problem. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE0WiMACgkQkX2Xpv6ydvRsxwCg8vxkb3JB4SKisMki5J5twdPD K98AoIEsBMLZ1KNrUvhDZfTuYaHEgu+M =Sr1k -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol *s, int
argc, t_atom *argv)
else if (u->u_type == TR_SYMBOL)
outlet_symbol(u->u_outlet,
(argc ? atom_getsymbol(argv) : &s_symbol));
+else if (u->u_type == TR_ANYTHING)
+outlet_anything(u->u_outlet, s, argc, argv);
else if (u->u_type == TR_POINTER)
{
if (!argc || argv->a_type != TR_POINTER)
This part causes pointers to not properly propagate through the trigger
objects. If you run scalar-help.pd file (part of pd-extended/pd-l2ork
documentation developed by Jonathan and others), clicking on scalars that
should animate generates an error. Removing this works fine for scalars but I
wonder if it then disables functionality of the patch you provided.
Any thoughts?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 03:12 PM, Ivica Ico Bukvic wrote:
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol
*s, int argc, t_atom *argv)
else if (u->u_type == TR_SYMBOL)
outlet_symbol(u->u_outlet,
(argc ? atom_getsymbol(argv) : &s_symbol));
+else if (u->u_type == TR_ANYTHING)
+outlet_anything(u->u_outlet, s, argc, argv);
else if (u->u_type == TR_POINTER)
{
if (!argc || argv->a_type != TR_POINTER)
This part causes pointers to not properly propagate through the
trigger objects. If you run scalar-help.pd file (part of
pd-extended/pd-l2ork documentation developed by Jonathan and others),
clicking on scalars that should animate generates an error. Removing
this works fine for scalars but I wonder if it then disables
functionality of the patch you provided.
Any thoughts?
As of right now, I cannot see any regressions by removing that part
since at the end it does output_list call anyhow. Can you test this/confirm?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 20:26, Ivica Ico Bukvic wrote:
> On 03/21/2013 03:12 PM, Ivica Ico Bukvic wrote:
>> IOhannes,
hi
>>
>> Your patch has one regression:
thanks for reporting
>>
>> --- a/src/x_connective.c
>> +++ b/src/x_connective.c
>> @@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol
>> *s, int argc, t_atom *argv)
>> else if (u->u_type == TR_SYMBOL)
>> outlet_symbol(u->u_outlet,
>> (argc ? atom_getsymbol(argv) : &s_symbol));
>> +else if (u->u_type == TR_ANYTHING)
>> +outlet_anything(u->u_outlet, s, argc, argv);
>> else if (u->u_type == TR_POINTER)
>> {
>> if (!argc || argv->a_type != TR_POINTER)
>>
>>
[...]
>> Any thoughts?
>>
yep.
outlet_list() is *not* the same as outlet_anything()
>>
>>
> As of right now, I cannot see any regressions by removing that part
> since at the end it does output_list call anyhow. Can you test
> this/confirm?
i cannot test right now, but i'm pretty sure that removing that very
line makes my entire patch obsolete and reverts to the old behaviour.
which errors do you get?
fgmadsr
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 20:47, IOhannes m zmölnig wrote: > > which errors do you get? "inlet: expected 'pointer' but got 'pointer'" how cool is that? fgmsrd IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 21:02, IOhannes m zmölnig wrote:
> "inlet: expected 'pointer' but got 'pointer'"
so having a short go into m_class.c, it seems indeed that the
c_pointermethod is called from within the list-method.
the attached patch should fix this, by using the "list" selector when
outputting pointers through [trigger].
this should be totally compatible to the original behaviour (regarding
pointers):
org: outlet_list(out, 0 , 1, ptratom);
new: outlet_anything(out, &s_list, 1, ptratom);
nevertheless it's probably good to hear some pointer expert's (e.g.
miller's) opinion about how this *should* be handled.
fgmasrd
IOhannes
>From 0830fff9c3c6533c3a68ded1f921acc66b4a9c24 Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig
Date: Thu, 21 Mar 2013 21:13:16 +0100
Subject: [PATCH 3/3] pointers are output as lists
a pointer message is really a "list " rather than
"pointer " (which i would have guessed due to the
existance of 's_pointer').
this can be confirmed by sending a pointer via [t a] to the
right inlet of [set] (which gives the error:
"inlet: expected 'pointer' but got 'pointer'"
checking back in m_class.c, it seems that the pointer-method
will only ever get called from within the pd_defaultlist.
---
src/x_connective.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/x_connective.c b/src/x_connective.c
index 0ac8cc6..08cb97c 100644
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -1026,7 +1026,7 @@ static void trigger_pointer(t_trigger *x, t_gpointer *gp)
{
t_atom at;
SETPOINTER(&at, gp);
-trigger_list(x, &s_pointer, 1, &at);
+trigger_list(x, &s_list, 1, &at);
}
static void trigger_float(t_trigger *x, t_float f)
--
1.7.10.4
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
