hi, I just found out, that [select] only throughputs floats and symbols, but not lists.
[1 2 3 4 5( | [sel bla]
will only output "1" on the right outlet, but not a the whole list. that is quite a limitation. but... ok. marius.
Hmm, I suppose it should pass thru every thing unmodified on the
right outlet. Can anyone think of any problems or disadvantages of
[select] just outputting the unmatched input intact on the right outlet?
.hc
On Nov 29, 2007, at 3:12 AM, marius schebella wrote:
hi, I just found out, that [select] only throughputs floats and
symbols, but not lists.[1 2 3 4 5( | [sel bla]
will only output "1" on the right outlet, but not a the whole list.
that is quite a limitation. but... ok. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Thu, 2007-11-29 at 10:46 -0500, Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the
right outlet. Can anyone think of any problems or disadvantages of
[select] just outputting the unmatched input intact on the right outlet?
yeah, please don't change its behaviour only in pd-extended, so that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Nov 29, 2007, at 12:36 PM, Roman Haefeli wrote:
On Thu, 2007-11-29 at 10:46 -0500, Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the right outlet. Can anyone think of any problems or disadvantages of [select] just outputting the unmatched input intact on the right
outlet?yeah, please don't change its behaviour only in pd-extended, so that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.
Anything I change I submit to the patch tracker, so it's up to Miller
then.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Thu, 2007-11-29 at 12:56 -0500, Hans-Christoph Steiner wrote:
On Nov 29, 2007, at 12:36 PM, Roman Haefeli wrote:
On Thu, 2007-11-29 at 10:46 -0500, Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the right outlet. Can anyone think of any problems or disadvantages of [select] just outputting the unmatched input intact on the right
outlet?yeah, please don't change its behaviour only in pd-extended, so that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.
Anything I change I submit to the patch tracker, so it's up to Miller
then.
oh, good to know ;-)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Thu, 2007-11-29 at 12:56 -0500, Hans-Christoph Steiner wrote:
On Nov 29, 2007, at 12:36 PM, Roman Haefeli wrote:
yeah, please don't change its behaviour only in pd-extended, so that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.
Anything I change I submit to the patch tracker, so it's up to Miller
then.oh, good to know ;-)
Though as long as Miller doesn't accept the patch, you have incompatibilities on the language level.
Ciao
Frank Barknecht _ ______footils.org__
On Thu, Nov 29, 2007 at 10:27:07PM +0100, Frank Barknecht wrote:
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Thu, 2007-11-29 at 12:56 -0500, Hans-Christoph Steiner wrote:
On Nov 29, 2007, at 12:36 PM, Roman Haefeli wrote:
yeah, please don't change its behaviour only in pd-extended, so that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.
Anything I change I submit to the patch tracker, so it's up to Miller
then.oh, good to know ;-)
Though as long as Miller doesn't accept the patch, you have incompatibilities on the language level.
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it clear to people who download pd-extended that it is incompatible with Pd, an older version, and that it is bundled with many externals which aren't in Pd by default?
Note that I really appreciate all the work you are doing to make people's lives easier, and don't want to put a dent in your efforts. I just think if we're not careful with breaking compatability people are going to get very confused very quickly.
Best,
Chris.
On Nov 30, 2007, at 12:51 AM, Chris McCormick wrote:
On Thu, Nov 29, 2007 at 10:27:07PM +0100, Frank Barknecht wrote:
Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Thu, 2007-11-29 at 12:56 -0500, Hans-Christoph Steiner wrote:
On Nov 29, 2007, at 12:36 PM, Roman Haefeli wrote:
yeah, please don't change its behaviour only in pd-extended, so
that patches created in pd-extended can cause errors in pd-vanilla. if changed, it needs to be changed in both.Anything I change I submit to the patch tracker, so it's up to
Miller then.oh, good to know ;-)
Though as long as Miller doesn't accept the patch, you have incompatibilities on the language level.
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it
clear to people who download pd-extended that it is incompatible with Pd, an older version, and that it is bundled with many externals which aren't in Pd by default?Note that I really appreciate all the work you are doing to make
people's lives easier, and don't want to put a dent in your efforts. I just
think if we're not careful with breaking compatability people are going
to get very confused very quickly.
Correct me if I am wrong, but using Pd-extended vs Pd-vanilla of the
same version is no more incompatible than using Pd-vanilla 0.40 vs.
0.39. If you use [declare] in a patch in pd-vanilla 0.40, then it
won't work in pd-vanilla 0.39. If you use [atan2] in Pd-vanilla 0.37
then it won't be compatible with pd-vanilla 0.38, and vice-versa.
Pd-extended 0.39 is basically like half way between pd-vanilla 0.39
and 0.40 since it includes patches that get included in 0.40, but
doesn't include miller's 0.40 changes.
This is the reason why I made the [hcs/version] object, you can issue
a warning if someone is using your patch with a version not tested or
known to be incompatible. It's not in Pd-vanilla, I never submitted
it to the patch tracker since I wasn't sure of the best interface for
it, like maybe it should be a message like [;pd version(, then you
listen on [receive pd]-[route version] for the response.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Fri, Nov 30, 2007 at 02:06:52PM -0500, Hans-Christoph Steiner wrote:
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it
clear to people who download pd-extended that it is incompatible with Pd, an older version, and that it is bundled with many externals which aren't in Pd by default?Note that I really appreciate all the work you are doing to make
people's lives easier, and don't want to put a dent in your efforts. I just
think if we're not careful with breaking compatability people are going
to get very confused very quickly.Correct me if I am wrong, but using Pd-extended vs Pd-vanilla of the
same version is no more incompatible than using Pd-vanilla 0.40 vs.
0.39. If you use [declare] in a patch in pd-vanilla 0.40, then it
won't work in pd-vanilla 0.39. If you use [atan2] in Pd-vanilla 0.37
then it won't be compatible with pd-vanilla 0.38, and vice-versa.
If you change the behaviour of something as fundemental as [select] in pd-extended and it doesn't get changed in Pd, then the patches and libraries I write under Pd won't work properly in pd-extended.
You are correct though, if I recall correctly the specific problem I had with someone using pd-extended was when I tried to show them something that only works in 0.40. I had to get them to download the latest in order to get my abstraction to work. Which is fine - I guess you can't be expected to track the latest Pd exactly.
Pd-extended 0.39 is basically like half way between pd-vanilla 0.39
and 0.40 since it includes patches that get included in 0.40, but
doesn't include miller's 0.40 changes.
Got it.
This is the reason why I made the [hcs/version] object, you can issue
a warning if someone is using your patch with a version not tested or
known to be incompatible. It's not in Pd-vanilla, I never submitted
it to the patch tracker since I wasn't sure of the best interface for
it, like maybe it should be a message like [;pd version(, then you
listen on [receive pd]-[route version] for the response.
Might be a good idea if it acheives widespread use.
Best,
Chris.
On Dec 1, 2007, at 9:17 PM, Chris McCormick wrote:
On Fri, Nov 30, 2007 at 02:06:52PM -0500, Hans-Christoph Steiner
wrote:Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it clear to people who download pd-extended that it is incompatible with
Pd, an older version, and that it is bundled with many externals which
aren't in Pd by default?Note that I really appreciate all the work you are doing to make people's lives easier, and don't want to put a dent in your efforts. I just think if we're not careful with breaking compatability people are going to get very confused very quickly.
Correct me if I am wrong, but using Pd-extended vs Pd-vanilla of the same version is no more incompatible than using Pd-vanilla 0.40 vs. 0.39. If you use [declare] in a patch in pd-vanilla 0.40, then it won't work in pd-vanilla 0.39. If you use [atan2] in Pd-vanilla 0.37 then it won't be compatible with pd-vanilla 0.38, and vice-versa.
If you change the behaviour of something as fundemental as [select] in pd-extended and it doesn't get changed in Pd, then the patches and libraries I write under Pd won't work properly in pd-extended.
That is well understood. I have no plans to change [select] in an
incompatible way. Frank clearly illustrated why the change discussed
would break things.
.hc
You are correct though, if I recall correctly the specific problem I had with someone using pd-extended was when I tried to show them something that only works in 0.40. I had to get them to download the latest in order to get my abstraction to work. Which is fine - I guess you can't be expected to track the latest Pd exactly.
Pd-extended 0.39 is basically like half way between pd-vanilla 0.39 and 0.40 since it includes patches that get included in 0.40, but doesn't include miller's 0.40 changes.
Got it.
This is the reason why I made the [hcs/version] object, you can issue a warning if someone is using your patch with a version not tested or known to be incompatible. It's not in Pd-vanilla, I never submitted it to the patch tracker since I wasn't sure of the best interface for it, like maybe it should be a message like [;pd version(, then you listen on [receive pd]-[route version] for the response.
Might be a good idea if it acheives widespread use.
Best,
Chris.
Access to computers should be unlimited and total. - the hacker ethic
On Sun, Dec 02, 2007 at 07:32:31PM -0500, Hans-Christoph Steiner wrote:
On Dec 1, 2007, at 9:17 PM, Chris McCormick wrote:
If you change the behaviour of something as fundemental as [select] in pd-extended and it doesn't get changed in Pd, then the patches and libraries I write under Pd won't work properly in pd-extended.
That is well understood. I have no plans to change [select] in an
incompatible way. Frank clearly illustrated why the change discussed
would break things.
Alright, I will stop freaking out then. :)
Best,
Chris.
On Dec 2, 2007, at 8:26 PM, Chris McCormick wrote:
On Sun, Dec 02, 2007 at 07:32:31PM -0500, Hans-Christoph Steiner
wrote:On Dec 1, 2007, at 9:17 PM, Chris McCormick wrote:
If you change the behaviour of something as fundemental as [select] in pd-extended and it doesn't get changed in Pd, then the patches
and libraries I write under Pd won't work properly in pd-extended.That is well understood. I have no plans to change [select] in an incompatible way. Frank clearly illustrated why the change discussed would break things.
Alright, I will stop freaking out then. :)
No cause for alarm, I am still (mostly) rational ;). I have been
thinking of making a library of objects for things like select,
route, trigger, etc. that would all be very consistent in their
behavior, and easier to understand in their type handling. So far,
it's just a vague idea, but discussions like these are very helpful
to spur that thinking.
.hc
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
On Fri, 30 Nov 2007, Chris McCormick wrote:
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it clear to people who download pd-extended that it is incompatible with Pd,
Yes, why is Pd still incompatible with Pd-extended?
it is bundled with many externals which aren't in Pd by default?
I thought that this is why people download pd-extended in the first place? How can they not know?
Note that I really appreciate all the work you are doing to make people's lives easier, and don't want to put a dent in your efforts. I just think if we're not careful with breaking compatability people are going to get very confused very quickly.
Any added feature, any added external is broken compatibility when it comes to new patches using new features that you try to run in a previous version. It's not even possible to be careful about it without standing still. What do you want?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, Nov 30, 2007 at 03:02:21PM -0500, Mathieu Bouchard wrote:
On Fri, 30 Nov 2007, Chris McCormick wrote:
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it clear to people who download pd-extended that it is incompatible with Pd,
Yes, why is Pd still incompatible with Pd-extended?
Miller is more conservative about making changes to Pd source than Hans is.
it is bundled with many externals which aren't in Pd by default?
I thought that this is why people download pd-extended in the first place? How can they not know?
It's easy for them to not know. Not every artist or user in the world understands the nuances of Pd source code polititcs. My one data point is my friend who had no idea that there was any other Pd than pd-extended.
Note that I really appreciate all the work you are doing to make people's lives easier, and don't want to put a dent in your efforts. I just think if we're not careful with breaking compatability people are going to get very confused very quickly.
Any added feature, any added external is broken compatibility when it comes to new patches using new features that you try to run in a previous version. It's not even possible to be careful about it without standing still. What do you want?
What I want is to be able to work with other Pd users safe in the knowledge that I can recommend pd-extended to them and that my patches and abstractions will work on Pd as well as pd-extended.
Maybe that's a completely unrealistic dream and we must accept that my patches written for Pd will not always work for them (or will look different etc.). In that case I'd like it to be made clear to users downloading pd-extended exactly what the differences are between that and Pd so they know what they are getting into.
Best,
Chris.
On Dec 1, 2007, at 9:26 PM, Chris McCormick wrote:
On Fri, Nov 30, 2007 at 03:02:21PM -0500, Mathieu Bouchard wrote:
On Fri, 30 Nov 2007, Chris McCormick wrote:
Which has bitten me on the ass at least once when making music with someone who uses pd-extended. Hans, I wonder if you could make it
clear to people who download pd-extended that it is incompatible with Pd,Yes, why is Pd still incompatible with Pd-extended?
Miller is more conservative about making changes to Pd source than
Hans is.
AFAIK, Pd and Pd-extended incompatible. Plus submit a bug if it is.
There will be incompatibilites across versions, just like pd-vanilla
0.40 to pd-vanilla 0.39.
.hc
it is bundled with many externals which aren't in Pd by default?
I thought that this is why people download pd-extended in the
first place? How can they not know?It's easy for them to not know. Not every artist or user in the world understands the nuances of Pd source code polititcs. My one data point is my friend who had no idea that there was any other Pd than pd-extended.
Note that I really appreciate all the work you are doing to make people's lives easier, and don't want to put a dent in your
efforts. I just think if we're not careful with breaking compatability
people are going to get very confused very quickly.Any added feature, any added external is broken compatibility when it comes to new patches using new features that you try to run in a
previous version. It's not even possible to be careful about it without
standing still. What do you want?What I want is to be able to work with other Pd users safe in the knowledge that I can recommend pd-extended to them and that my patches and abstractions will work on Pd as well as pd-extended.
Maybe that's a completely unrealistic dream and we must accept that my patches written for Pd will not always work for them (or will look different etc.). In that case I'd like it to be made clear to users downloading pd-extended exactly what the differences are between that and Pd so they know what they are getting into.
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
I think [select] always worked that way since the beginning of Pd. it is also the case in max. I don't know if it is a good idea to change the behaviour, since it is easy to find a work around and might brake patches. but personally, of course I would like to see the change, at least it needs to be documented. it probably was documented in the original helpfile, but it is not documented in the pddp help patch. is there a workflow for changes in helppatches. how do I submit changes. and a wish related to that topic: please keep/make helpfiles read/writeable! marius.
Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the right outlet. Can anyone think of any problems or disadvantages of [select] just outputting the unmatched input intact on the right outlet?
.hc
On Nov 29, 2007, at 3:12 AM, marius schebella wrote:
hi, I just found out, that [select] only throughputs floats and symbols, but not lists.
[1 2 3 4 5( | [sel bla]
will only output "1" on the right outlet, but not a the whole list. that is quite a limitation. but... ok. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
On Nov 29, 2007, at 12:46 PM, marius schebella wrote:
I think [select] always worked that way since the beginning of Pd.
it is also the case in max. I don't know if it is a good idea to
change the behaviour, since it is easy to find a work around and
might brake patches.
If someone is relying on [select] to trim lists, that would be either
unintentional, or some odd programming, IMHO. I think it's worth
it. There have been more severe changes in the past, like atan
switching inlets, there could be a warning like "warning passing data
thru unchanged, this is new behavior in 0.41".
but personally, of course I would like to see the change, at least
it needs to be documented. it probably was documented in the
original helpfile, but it is not documented in the pddp help patch.
Please add it to PDDP help patch and submit it to the tracker. Then
I can check it in.
is there a workflow for changes in helppatches. how do I submit
changes. and a wish related to that topic: please keep/make helpfiles read/ writeable!
chmod -R +w /Applications/Pd-extended.app/Contents/Resources/doc/
.hc
marius.
Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the
right outlet. Can anyone think of any problems or disadvantages
of [select] just outputting the unmatched input intact on the
right outlet? .hc On Nov 29, 2007, at 3:12 AM, marius schebella wrote:hi, I just found out, that [select] only throughputs floats and
symbols, but not lists.[1 2 3 4 5( | [sel bla]
will only output "1" on the right outlet, but not a the whole
list. that is quite a limitation. but... ok. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
------- 'You people have such restrictive dress for women,’ she
said, hobbling away in three inch heels and panty hose to finish
out another pink-collar temp pool day. - “Hijab Scene #2", by
Mohja Kahf
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
What is [select] supposed to do with a list? Just select based on the first element? I think it should reject lists altogether and suggest the use of [route].
Martin
On Nov 29, 2007 8:45 PM, Martin Peach martin.peach@sympatico.ca wrote:
What is [select] supposed to do with a list? Just select based on the first element? I think it should reject lists altogether and suggest the use of [route].
I agree with Martin. [route] is meant for lists, [select] is meant for floats or symbols. I suppose lists don't work with [select] for the same reason [route] doesn't have a right inlet, considering what Frank pointed out. If you connect all but the right outlet of [route] to [b], you have a [select] that handles lists and has no right inlet.
-Chuckk
Yeah, this works, if you want to need a ton of clicks for each instantiation (or make abstractions with various outlet lengths, still "ugh").
Instead, wouldn't this (or something similar) do the job?
[list split 1]
|
|
| [output list data]
|
[select a b c]
Of course, if you want to detect the list and then pass only non-list data, I'm not sure what to do...is there an object like [islist] or something that will tell you if the incoming message is a list?
~Kyle
On Nov 30, 2007 1:17 AM, Chuckk Hubbard badmuthahubbard@gmail.com wrote:
On Nov 29, 2007 8:45 PM, Martin Peach martin.peach@sympatico.ca wrote:
What is [select] supposed to do with a list? Just select based on the first element? I think it should reject lists altogether and suggest the use of [route].
I agree with Martin. [route] is meant for lists, [select] is meant for floats or symbols. I suppose lists don't work with [select] for the same reason [route] doesn't have a right inlet, considering what Frank pointed out. If you connect all but the right outlet of [route] to [b], you have a [select] that handles lists and has no right inlet.
-Chuckk
-- http://www.badmuthahubbard.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 30 Nov 2007, Chuckk Hubbard wrote:
I agree with Martin. [route] is meant for lists,
There's something really weird about [route] (as it is in 0.40): It will only route selectors if I don't give any float arguments, but will only route a list's $1 if I give any float arguments. Can anyone confirm and explain this? The help file claims one should not mix floats and symbols, but [route] does not reject it, and then clearly does something useful that can't be done any other easy way.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, 30 Nov 2007, Mathieu Bouchard wrote:
On Fri, 30 Nov 2007, Chuckk Hubbard wrote:
I agree with Martin. [route] is meant for lists,
There's something really weird about [route] (as it is in 0.40): It will only route selectors if I don't give any float arguments, but will only route a list's $1 if I give any float arguments. Can anyone confirm and explain this? The help file claims one should not mix floats and symbols, but [route] does not reject it, and then clearly does something useful that can't be done any other easy way.
... if one has a [demux], Kyle's [list split] and [select], and then a list storage and a [t b l], then one can do like this undocumented behaviour of [route], but I wouldn't call it so easy.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Fri, 30 Nov 2007, Mathieu Bouchard wrote:
On Fri, 30 Nov 2007, Mathieu Bouchard wrote:
There's something really weird about [route] (as it is in 0.40): It will only route selectors if I don't give any float arguments, but will only route a list's $1 if I give any float arguments. Can anyone confirm and explain this? The help file claims one should not mix floats and symbols, but [route] does not reject it, and then clearly does something useful that can't be done any other easy way.
... if one has a [demux], Kyle's [list split] and [select], and then a list storage and a [t b l], then one can do like this undocumented behaviour of [route], but I wouldn't call it so easy.
Duh. Bad day. Do like what Claude says. Still, the question of the mystery feature of [route] remains open.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 30, 2007, at 3:10 PM, Mathieu Bouchard wrote:
On Fri, 30 Nov 2007, Chuckk Hubbard wrote:
I agree with Martin. [route] is meant for lists,
There's something really weird about [route] (as it is in 0.40): It
will only route selectors if I don't give any float arguments, but
will only route a list's $1 if I give any float arguments. Can
anyone confirm and explain this? The help file claims one should
not mix floats and symbols, but [route] does not reject it, and
then clearly does something useful that can't be done any other
easy way.
Could you post a patch that demonstrates this? It would make it
clearer. Plus it would be good to add it to the collection of
patches that illustrate things like this:
http://pure-data.cvs.sourceforge.net/pure-data/doc/additional/ messageoddness/
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
Could you post a patch that demonstrates this? It would make it
clearer.
fmgas.dr IOhannes
#N canvas 0 0 450 300 10; #X obj 239 162 route 1 bla; #X msg 235 117 list bla hu; #X obj 231 200 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 266 204 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 314 203 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 0 0 2 0; #X connect 0 1 3 0; #X connect 0 2 4 0; #X connect 1 0 0 0;
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Could you post a patch that demonstrates this? It would make it
clearer.fmgas.dr IOhannes
#N canvas 0 0 450 300 10; #X obj 239 162 route 1 bla; #X msg 235 117 list bla hu;
If you add a message "bla hu" as well, the issue becomes even clearer, as that will be sent to the "miss" outlet of [route 1 bla]. However as mixing floats and symbols in route's arguments is explicitly forbidden according to the help-patch, it's a moot issue to discuss for now.
Ciao
Frank Barknecht _ ______footils.org__
On Dec 1, 2007, at 4:49 AM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Could you post a patch that demonstrates this? It would make it clearer.
fmgas.dr IOhannes
#N canvas 0 0 450 300 10; #X obj 239 162 route 1 bla; #X msg 235 117 list bla hu;
If you add a message "bla hu" as well, the issue becomes even clearer, as that will be sent to the "miss" outlet of [route 1 bla]. However as mixing floats and symbols in route's arguments is explicitly forbidden according to the help-patch, it's a moot issue to discuss for now.
If mixing floats and symbols is forbidden, then it really should be
forbidden. For example, the object shouldn't create if there are
mixed float and symbol arguments. Currently, it works sometimes,
plus there are no warnings or errors issued.
.hc
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
On Sat, 1 Dec 2007, Frank Barknecht wrote:
If you add a message "bla hu" as well, the issue becomes even clearer, as that will be sent to the "miss" outlet of [route 1 bla]. However as mixing floats and symbols in route's arguments is explicitly forbidden according to the help-patch, it's a moot issue to discuss for now.
Your Pd experience should tell you that any feature exposed will be tried and documented by the community, and become a de facto standard.
For example, [pack] and [unpack] are not there to do type-checking, but somehow it has become a backward-compatibility issue. Following the documentation, there's nothing saying that you can rely on [pack] and [unpack] to filter out and report messages that do not fit the type declarations, but that's still how some people use it, and they'd rather have this de facto compatibility than strict by-the-book compatibility.
(And does the documentation of [pack] explicitly forbids, or does it explicitly states exceptions to what is officially documented?)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 1 Dec 2007, Frank Barknecht wrote:
If you add a message "bla hu" as well, the issue becomes even clearer, as that will be sent to the "miss" outlet of [route 1 bla]. However as mixing floats and symbols in route's arguments is explicitly forbidden according to the help-patch, it's a moot issue to discuss for now.
Your Pd experience should tell you that any feature exposed will be tried and documented by the community, and become a de facto standard.
I'm not saying that [select] must not be made to accept both floats and symbols. Actually I think it would be good if it did.
But so far, the result when mixing floats and symbols in [select] is officially undefined. And that's even documented, contrary to many other things in Pd. People may still try to see what happens when they mix floats and symbols, but people try to get execution order right without [trigger] or to divide by zero in their patches as well.
Ciao
Frank Barknecht _ ______footils.org__
On Sat, 1 Dec 2007, Frank Barknecht wrote:
I'm not saying that [select] must not be made to accept both floats and symbols. Actually I think it would be good if it did. But so far, the result when mixing floats and symbols in [select] is officially undefined.
We were talking about [route].
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 1 Dec 2007, Frank Barknecht wrote:
I'm not saying that [select] must not be made to accept both floats and symbols. Actually I think it would be good if it did. But so far, the result when mixing floats and symbols in [select] is officially undefined.
We were talking about [route].
Ah, sorry, I was a bit confused by the Subject (changed). But anyway, as route's help file also forbids mixing, I think my general point remains: One cannot expect something which is not defined to work in a defined way until it's defined.
Ciao
Frank Barknecht _ ______footils.org__
On Nov 30, 2007 10:10 PM, Mathieu Bouchard matju@artengine.ca wrote:
On Fri, 30 Nov 2007, Chuckk Hubbard wrote:
I agree with Martin. [route] is meant for lists,
There's something really weird about [route] (as it is in 0.40): It will only route selectors if I don't give any float arguments, but will only route a list's $1 if I give any float arguments. Can anyone confirm and explain this? The help file claims one should not mix floats and symbols, but [route] does not reject it, and then clearly does something useful that can't be done any other easy way.
Could that have something to do with how the list selector is assumed with multiple floats, but must be explicit if $1 is a symbol?
-Chuckk
On Sat, 1 Dec 2007, Chuckk Hubbard wrote:
On Nov 30, 2007 10:10 PM, Mathieu Bouchard matju@artengine.ca wrote:
There's something really weird about [route] (as it is in 0.40): It will only route selectors if I don't give any float arguments, but will only route a list's $1 if I give any float arguments. Can anyone confirm and explain this? The help file claims one should not mix floats and symbols, but [route] does not reject it, and then clearly does something useful that can't be done any other easy way.
Could that have something to do with how the list selector is assumed with multiple floats, but must be explicit if $1 is a symbol?
Oh yes, the distinction of behaviour is really only determined by the type of the $1 of the box, and nothing else. Thanks for the precision.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the
right outlet. Can anyone think of any problems or disadvantages of
[select] just outputting the unmatched input intact on the right outlet?
Yes, I can!
[select] like many objects distributes incoming messages over its inlets, so passing lists unchanged to the right outlet may let all hell break loose with old patches.
Example:
[5 5( | | [select] | | | [print MISS] | [print HIT]
will *always* print HIT because the second "5" in the list will first set the value, that [select] selects, the left "5" then will trigger a hit. A message "1 2" however will always pass the 1 to the MISS outlet, after the 2 in the list has set the select-target.
Ciao
Frank Barknecht _ ______footils.org__
got it. but it does not explain, the following: [select 1 2 3] has only one input. so no need to distribute anything. then send the message [4 4 4 4( no bang on the first outlet, but on the last one, but why is still only the first element on the list passed? just want to point out, that select just does not work for messages. marius.
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, I suppose it should pass thru every thing unmodified on the
right outlet. Can anyone think of any problems or disadvantages of
[select] just outputting the unmatched input intact on the right outlet?Yes, I can!
[select] like many objects distributes incoming messages over its inlets, so passing lists unchanged to the right outlet may let all hell break loose with old patches.
Example:
[5 5( | | [select] | | | [print MISS] | [print HIT]
will *always* print HIT because the second "5" in the list will first set the value, that [select] selects, the left "5" then will trigger a hit. A message "1 2" however will always pass the 1 to the MISS outlet, after the 2 in the list has set the select-target.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
got it. but it does not explain, the following: [select 1 2 3] has only one input. so no need to distribute anything. then send the message [4 4 4 4( no bang on the first outlet, but on the last one, but why is still only the first element on the list passed?
The list is still distributed, but only over one inlet now, so the rest is ignored. I think, it would be even more confusing if a select with 2 or more arguments would behave differently from a select with less args.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
got it. but it does not explain, the following: [select 1 2 3] has only one input. so no need to distribute anything.
The list is still distributed, but only over one inlet now
Why doesn't [select 1 2 3 4] have 5 inlets and 5 outlets?
Wouldn't break old patches, but could be useful in some circumstances.
Claude
Claude Heiland-Allen wrote:
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
got it. but it does not explain, the following: [select 1 2 3] has only one input. so no need to distribute anything.
The list is still distributed, but only over one inlet now
Why doesn't [select 1 2 3 4] have 5 inlets and 5 outlets?
Wouldn't break old patches, but could be useful in some circumstances.
Maybe it would make more sense if [select] accepted messages like [set 5 4 3 2( on its single inlet and rejected lists. [select]'s current method for list handling is just pd's default behaviour when an object has no list method of its own.
Martin
Martin Peach wrote:
Claude Heiland-Allen wrote:
Why doesn't [select 1 2 3 4] have 5 inlets and 5 outlets?
Wouldn't break old patches, but could be useful in some circumstances.
Maybe it would make more sense if [select] accepted messages like [set 5 4 3 2( on its single inlet and rejected lists. [select]'s current method for list handling is just pd's default behaviour when an object has no list method of its own.
I disagree: multiple inlets allow different parts to be set independently, and pd's default behaviour is common among many objects, which makes it easier to learn once.
Claude
On Nov 30, 2007, at 12:09 PM, Claude Heiland-Allen wrote:
Martin Peach wrote:
Claude Heiland-Allen wrote:
Why doesn't [select 1 2 3 4] have 5 inlets and 5 outlets?
Wouldn't break old patches, but could be useful in some
circumstances.Maybe it would make more sense if [select] accepted messages like
[set 5 4 3 2( on its single inlet and rejected lists. [select]'s current
method for list handling is just pd's default behaviour when an object has no
list method of its own.I disagree: multiple inlets allow different parts to be set independently, and pd's default behaviour is common among many
objects, which makes it easier to learn once.
From what I've seen, this shortcut that applies lists across inlets
is directly responsible for the structures that cause a lot of the
list/non-list confusion, and strange situations like this. It's
entrenched, so I don't think it will be removed from or changed in pd-
vanilla.
But I was just thinking about it, I think it would make more sense if
there was a standard selector to trigger this behavior, something like:
[inlets 1 5(
Then we could have [select] do the more natural thing and pass stuff
out the right outlet unchanged.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
On Thu, 2007-11-29 at 03:12 -0500, marius schebella wrote:
hi, I just found out, that [select] only throughputs floats and symbols, but not lists.
[1 2 3 4 5( | [sel bla]
will only output "1" on the right outlet, but not a the whole list. that is quite a limitation. but... ok. marius.
hm. i'd rather say, that the error messages it outputs are inconsistent. the help-file says, that it accepts numbers and symbols. i'd expect it to output an error, whenever a non-symbol or non-number message is received. however, what it does, is quite 'funny', if not to say 'frivolous':
sending messages and corresponding error messages:
[select three] 'list one 2' error: inlet: no method for 'float' 'list one two' no error 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
[select 3] 'list one 2' no error 'list one two' error: inlet: no method for 'symbol' 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
we see, that a [select <symbol>] outputs an error, if the second element of a list is a floar, and vice versa, a [select <float] gives an error, if the second element of the incoming list is a symbol. i think, there is no explanation, that would make this behaviour to seem logical.
use [route] for message with n!=1 elements. i'd expect [select] to work with only n=1 element lists and everything at least looks to be consistent.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
hm. i'd rather say, that the error messages it outputs are inconsistent. the help-file says, that it accepts numbers and symbols. i'd expect it to output an error, whenever a non-symbol or non-number message is received. however, what it does, is quite 'funny', if not to say 'frivolous':
sending messages and corresponding error messages:
[select three] 'list one 2' error: inlet: no method for 'float' 'list one two' no error 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
[select 3] 'list one 2' no error 'list one two' error: inlet: no method for 'symbol' 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
[select] distributes lists over its inlets, so this behaviour looks correct. See my other mail.
Ciao
Frank Barknecht _ ______footils.org__
On Thu, 2007-11-29 at 22:37 +0100, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
hm. i'd rather say, that the error messages it outputs are inconsistent. the help-file says, that it accepts numbers and symbols. i'd expect it to output an error, whenever a non-symbol or non-number message is received. however, what it does, is quite 'funny', if not to say 'frivolous':
sending messages and corresponding error messages:
[select three] 'list one 2' error: inlet: no method for 'float' 'list one two' no error 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
[select 3] 'list one 2' no error 'list one two' error: inlet: no method for 'symbol' 'symbol one' no error '3' no error 'one' error: select: no method for 'one' 'bang' error: select: no method for 'bang
[select] distributes lists over its inlets, so this behaviour looks correct. See my other mail.
thanks for clarification. once again i just forgot about this distribution behaviour. makes perfectly sense to me now. everything is in order and consistent.... aaaaah... nicee.......... ;-)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Chris McCormick -
Chuckk Hubbard -
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Kyle Klipowicz -
marius schebella -
Martin Peach -
Mathieu Bouchard -
Roman Haefeli