Hans-Christoph Steiner wrote:
Whatever prepend I'm using now (?) does support the "set" message.
FYI: the build system uses the [prepend] from cyclone.
just because i am interested and i don't want to think right now.
how do you prepend something to a "set" message with [cyclone/prepend]?
e.g. i want to construct [foo set bar( out of [foo( and [set bar(
fla.mni.g IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
just because i am interested and i don't want to think right now.
how do you prepend something to a "set" message with [cyclone/prepend]?
e.g. i want to construct [foo set bar( out of [foo( and [set bar(
You do this, by converting [set bar( to [list set bar( somehow. Unfortunatly that's not trivial at all for lists of unknow length - which in turn is, what you use [prepend] for instead of [x $1 $2(
Technically I actually would prefer IEMlib prepend to be the standard [prepend] because of this problem, but Cyclone is more Max compatible.
Btw: Both Cyclone and Zexy have [avg~]
Ciao
Frank Barknecht _ ______footils.org__
On Nov 10, 2004, at 3:38 AM, Frank Barknecht wrote
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
just because i am interested and i don't want to think right now.
how do you prepend something to a "set" message with
[cyclone/prepend]?e.g. i want to construct [foo set bar( out of [foo( and [set bar(
You do this, by converting [set bar( to [list set bar( somehow. Unfortunatly that's not trivial at all for lists of unknow length - which in turn is, what you use [prepend] for instead of [x $1 $2(
Technically I actually would prefer IEMlib prepend to be the standard [prepend] because of this problem, but Cyclone is more Max compatible.
Btw: Both Cyclone and Zexy have [avg~]
There will always be problems with any approach. There was a
relatively lengthy discussion on this very topic before this decision
was made. I recommend reading that thread and addressing the issues
that were discussed that lead the Cyclone [prepend] to be chosen. I
believe it was a compatibility issue. I didn't make this decision, I
just acted on it.
.hc
¡El pueblo unido jamás será vencido!
Hi, Hans-Christoph Steiner wrote:
On Nov 10, 2004, at 3:38 AM, Frank Barknecht wrote
Technically I actually would prefer IEMlib prepend to be the standard [prepend] because of this problem, but Cyclone is more Max compatible.
Btw: Both Cyclone and Zexy have [avg~]
There will always be problems with any approach. There was a
relatively lengthy discussion on this very topic before this decision
was made. I recommend reading that thread and addressing the issues
that were discussed that lead the Cyclone [prepend] to be chosen. I
believe it was a compatibility issue. I didn't make this decision, I
just acted on it.
Me, too, in RRADical. ;)
However, Johannes' question is valid: With Cyclone/Max-prepend it is practically impossible to prepend to lists starting with "set".
That's where I see the need for iem_prepend, but the big question actually is, what approach should be used for the list handling *internals* for Pd, that were discussed in Graz. They also need an object that does prepending to lists. Choosing Max/Cyclone-prepend for this is a bad solution, because of Johannes' problem. Because of nameclashes, the name "prepend" also cannot be used while satisfying both the technical (prepend to "set") as well as the practical issues (nameclashes, backwards compatibility).
Maybe we should use a whole new kind of names for the future Pd list functions, for example taken from the C++-STL conventions like "push_back", "push_front", "insert" and "erase" instead of the Lisp'ish "append" and "prepend"? A tempting idea.
Ciao
Frank
Aha, so, if we keep "prepend" and "scale" max-compatible, we just need better names for the "correctly designed" versions, no?
For prepend, at least, we could borrow an idea from Krzysztof and make a new "msg" object:
msg prepend msg append msg car msg cdr msg any
.. this is assuming nobody has yet written a "msg" object, of course!
cheers Miller
On Wed, Nov 10, 2004 at 05:29:26PM +0100, Frank Barknecht wrote:
Hi, Hans-Christoph Steiner wrote:
On Nov 10, 2004, at 3:38 AM, Frank Barknecht wrote
Technically I actually would prefer IEMlib prepend to be the standard [prepend] because of this problem, but Cyclone is more Max compatible.
Btw: Both Cyclone and Zexy have [avg~]
There will always be problems with any approach. There was a
relatively lengthy discussion on this very topic before this decision
was made. I recommend reading that thread and addressing the issues
that were discussed that lead the Cyclone [prepend] to be chosen. I
believe it was a compatibility issue. I didn't make this decision, I
just acted on it.Me, too, in RRADical. ;)
However, Johannes' question is valid: With Cyclone/Max-prepend it is practically impossible to prepend to lists starting with "set".
That's where I see the need for iem_prepend, but the big question actually is, what approach should be used for the list handling *internals* for Pd, that were discussed in Graz. They also need an object that does prepending to lists. Choosing Max/Cyclone-prepend for this is a bad solution, because of Johannes' problem. Because of nameclashes, the name "prepend" also cannot be used while satisfying both the technical (prepend to "set") as well as the practical issues (nameclashes, backwards compatibility).
Maybe we should use a whole new kind of names for the future Pd list functions, for example taken from the C++-STL conventions like "push_back", "push_front", "insert" and "erase" instead of the Lisp'ish "append" and "prepend"? A tempting idea.
Ciao
Frank
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi,
Miller Puckette wrote:
Aha, so, if we keep "prepend" and "scale" max-compatible, we just need better names for the "correctly designed" versions, no?
Yes, this is exactly, what I wanted to say. It basically boils down to the old question: How Max-compatible do we want or have to be? I would say, as "prepend" and similar objects are practically used in *every* Max patch of a certain complexity, we should avoid being incompatible to those prevalent objects.
For prepend, at least, we could borrow an idea from Krzysztof and make a new "msg" object:
msg prepend msg append msg car msg cdr msg any
.. this is assuming nobody has yet written a "msg" object, of course!
Do I hear a namespace whispering? ;) Actually this is a nice solution in the list handling case, as we then would have just one object for all list operations. I think, I like this. (I don't know, if there already is a "msg".)
Ciao
Frank Barknecht
On Wed, 10 Nov 2004, Frank Barknecht wrote:
Miller Puckette wrote:
Aha, so, if we keep "prepend" and "scale" max-compatible, we just need better names for the "correctly designed" versions, no?
Yes, this is exactly, what I wanted to say. It basically boils down to the old question: How Max-compatible do we want or have to be? I would say, as "prepend" and similar objects are practically used in *every* Max patch of a certain complexity, we should avoid being incompatible to those prevalent objects.
I'd say that if after discussing about an object class for a while we figure out that the MAX behaviour is annoying then I'd say we drop compatibility. Bonus points if there is actually a way to search-and-replace those things systematically, automateable using an hypothetical (or real) script.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Hallo, Matju hat gesagt: // Matju wrote:
I'd say that if after discussing about an object class for a while we figure out that the MAX behaviour is annoying then I'd say we drop compatibility. Bonus points if there is actually a way to search-and-replace those things systematically, automateable using an hypothetical (or real) script.
yes, there are these cases and those cases. However, the limitation of [prepend] is not annoying enough to break compatibility, IMO. ALso you have to take into account how common and prevalent a Max-object is. Breaking less used objects like, say, "bondo" is not that much of a problem, as breaking "prepend" would be.
Ciao
Frank Barknecht _ ______footils.org__
hi all,
Frank Barknecht wrote: ...
yes, there are these cases and those cases. However, the limitation of [prepend] is not annoying enough to break compatibility, IMO. ALso you
in case of prepend, I think, there is a compromise possible. An object would get the second inlet, but only when instantiated, max-incompatibly, without arguments. The 'set' method would still modify the argument, but only if a) creation arguments were provided, and b) the global max-compatibility flag was set. Otherwise, the 'set' method would call the 'anything' method.
I do not think, it is a good idea to have a [prepend this] in a patch, which actually prepends 'that' (after being set to 'that'). Such objects should read just [prepend].
I wonder, how many maxers use the 'set' feature of prepend? Or if they tend to use zl join, perhaps?
Interestingly, sending a single word 'set' to a prepend crashes Max on the next message to the object... I am talking about, 4.3.2, the last version I was determined enough to find money for...
Which is why my advocatus diaboli role is on halt...
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
I do not think, it is a good idea to have a [prepend this] in a patch, which actually prepends 'that' (after being set to 'that'). Such objects should read just [prepend].
At least where I use prepend for as a settable prepend, I only provide a dummy arg to get rid of the incompatibility warning, so this sounds good.
Ciao
Frank Barknecht _ ______footils.org__
This sounds like a perfect comprimise! I can't think of any serious disadvantages to this.
.hc
On Nov 12, 2004, at 11:30 AM, Krzysztof Czaja wrote:
hi all,
Frank Barknecht wrote: ...
yes, there are these cases and those cases. However, the limitation of [prepend] is not annoying enough to break compatibility, IMO. ALso you
in case of prepend, I think, there is a compromise possible. An object would get the second inlet, but only when instantiated, max-incompatibly, without arguments. The 'set' method would still modify the argument, but only if a) creation arguments were provided, and b) the global max-compatibility flag was set. Otherwise, the 'set' method would call the 'anything' method.
I do not think, it is a good idea to have a [prepend this] in a patch, which actually prepends 'that' (after being set to 'that'). Such objects should read just [prepend].
I wonder, how many maxers use the 'set' feature of prepend? Or if they tend to use zl join, perhaps?
Interestingly, sending a single word 'set' to a prepend crashes Max on the next message to the object... I am talking about, 4.3.2, the last version I was determined enough to find money for...
Which is why my advocatus diaboli role is on halt...
Krzysztof
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
http://at.or.at/hans/
hi miller, hi list ...
i came across this posting when searching my archive after benchmarking the pd message system ...
For prepend, at least, we could borrow an idea from Krzysztof and make a new "msg" object:
msg prepend msg append msg car msg cdr msg any
i'd request another msg mode (maybe called msg msg or something similar), that sends a fixed message on a bang. means |msg msg test| == |test(
i suppose this will be a speedup for messaging ... in my benchmarks the combination of |symbol test| and |unsymbol| was a lot faster that |test(
possibly the message_class code could be modified to improve the basic message handling, but i'm not really familiar with that part of pd and from what i saw, this it will require not only a few changes ...
cheers ... tim
I'm guessing |msg prepend test| would send a |test( message when banged (but have to think carefully about the design of a good "prepend" functionality and look at the existing ones to figure out what to do there...)
If "prepend" doesn't do it, "msg" might be worth putting in.
I wonder, now, if the message box could be sped up by precompiling the contents somehow. That would be fun for another day...
cheers Miller
On Thu, Dec 30, 2004 at 04:40:43PM +0100, Tim Blechmann wrote:
hi miller, hi list ...
i came across this posting when searching my archive after benchmarking the pd message system ...
For prepend, at least, we could borrow an idea from Krzysztof and make a new "msg" object:
msg prepend msg append msg car msg cdr msg any
i'd request another msg mode (maybe called msg msg or something similar), that sends a fixed message on a bang. means |msg msg test| == |test(
i suppose this will be a speedup for messaging ... in my benchmarks the combination of |symbol test| and |unsymbol| was a lot faster that |test(
possibly the message_class code could be modified to improve the basic message handling, but i'm not really familiar with that part of pd and from what i saw, this it will require not only a few changes ...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
I'm guessing |msg prepend test| would send a |test( message when banged(but have to think carefully about the design of a good "prepend" functionality and look at the existing ones to figure out what to do there...)
iem_prepend does that ... cyclones' prepend prepends the argument to "bang" (giving "test bang") ... still one would have to convert the triggering message to a bang ... something that will add some overhead ...
I wonder, now, if the message box could be sped up by precompiling the contents somehow. That would be fun for another day...
i thought about something like that, but i think the whole msg object will have to be written ... it would be the cleanest solution, though...
cheers ... tim
hi Tim,
in Pd, the proper handling seems to be:
'bang' -> [prepend test this]: 'test this' 'list' -> [prepend test this]: 'test this' 'symbol bang' -> [prepend test this]: 'test this bang' 'symbol list' -> [prepend test this]: 'test this list'
Max does it differently:
'bang' -> [prepend test this]: 'test this bang' 'list' -> [prepend test this]: a nop, because Max tends to ignore empty lists, not systematically, though: 'bang' -> [sprintf list] -> [prepend test this]: 'test this'
Cyclone's prepend imitates the Max handling of bang and empty list messages (will change this to the Pd way as the default, leaving Max-like behaviour in 'maxmode').
Max symbol handling cannot be imitated, but that is another story...
Krzysztof
Tim Blechmann wrote: ...
iem_prepend does that ... cyclones' prepend prepends the argument to "bang" (giving "test bang") ...
On Mon, 3 Jan 2005, Krzysztof Czaja wrote:
in Pd, the proper handling seems to be: 'bang' -> [prepend test this]: 'test this' 'list' -> [prepend test this]: 'test this' 'symbol bang' -> [prepend test this]: 'test this bang' 'symbol list' -> [prepend test this]: 'test this list'
Ok, since all this [prepend] ties in with how the whole of the Pd messagesystem is supposed to work, I have a question: if I do something like:
[bang( -> [t a a] -> [prepend test this] and [bang( -> [t a a] -> [route list] -> [prepend test this]
which one should be produced?
(a) first 'test this', second no-op (b) first 'test this bang', second no-op (c) both 'test this list 0' (d) first 'test this list 0', second no-op
Personally I'd expect either (b), or _maybe_ (a), and actually, replacing [t a a] with my own [fork] object (which does 99% the same), i get (b). However, trying the first case with [t a a], I think i get (c), until I try the second case and the reality is (d) (this behaviour of [route] is even documented as a _feature_ in route-help.pd)
Conclusion: in Pd,
"anything" really means "anything but bang".
a bang casted to the "anything" type becomes a list of single 0
3a. a list containing a single number is not a list...
3b. ... except for exceptions, which aren't that exceptional, and easy to come up with, even accidentally, in particular when coding an external.
How should I perceive Pd so that the above sounds normal, sane, and wellbehaved ?
PS: (*please* don't say "you know, pd is not a programming language...")
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote:
On Mon, 3 Jan 2005, Krzysztof Czaja wrote:
which one should be produced?
(b) first 'test this bang', second no-op
hmm, i disagree with that. [bang( is bang and not a symbol "bang"! bang is an atomic event not containing data (not even a timestamp) how do you encapsulate such a time-based event within a data-set (like "test this bang") ?? this does not make sense to me at all
next time, people will come and ask how to attach numbers to an event [bang 3.14( ??
programming in time-domain is an important concept of patcher-like languages.
PS: (*please* don't say "you know, pd is not a programming language...")
but it is turing complete, so who cares...
mfg.as.dr IOhannes
On Tue, 4 Jan 2005, Johannes M Zmoelnig wrote:
Mathieu Bouchard wrote:
On Mon, 3 Jan 2005, Krzysztof Czaja wrote:
which one should be produced?
(b) first 'test this bang', second no-op
hmm, i disagree with that. [bang( is bang and not a symbol "bang"!
Alrighty, here's a second issue I hid in the carpet so as to not distract from my first issue, but that I have to uncover to answer you here:
Since every possible symbol can be used in any message, save for a few reserved keywords, what would be a logical way of distinguishing those from symbol messages, which have "symbol" as their selector and whatever symbol as their $1 ?
In GridFlow,
[foo( -> [messageprepend zzz] gives 'zzz foo' [symbol foo( -> [messageprepend zzz] gives 'zzz symbol foo' [foo\ -> [messageprepend zzz] gives 'zzz symbol foo'
(where [\ is a symbolbox)
Where I designed [messageprepend], among other things, having in mind a mental model of Pd that is concise, consistent, and founded on the preconceptions I have learned while trying several shovelfuls of different programming languages. (which is why I sort of bang my head on the wall with issues like this one and the one in the previous mail: I don't understand those behaviours; they make no sense to me, and I expect to be able to make sense of them given how much time i spend on semantics!)
In the previous mail, the second and third entry would have given the first result. Now, until here, I have assumed that [prepend] should be "injective", that is, it is possible to know which inputs were put in just by looking at the output. If we drop that requirement, then [foo( and [symbol foo( could give the same result for convenience, but it would be inconsistent with the fact that, in general, to write in a messagebox a symbol compatible with a symbolbox, you actually have to write "symbol" in front of it, else it is rejected as "no method for ...".
bang is an atomic event not containing data (not even a timestamp) how do you encapsulate such a time-based event within a data-set (like "test this bang") ?? this does not make sense to me at all
could you please elaborate on this?
PS: (*please* don't say "you know, pd is not a programming language...")
but it is turing complete, so who cares...
Well, there are many turing-complete languages for which no-one expects a quality experience when programming them. Examples are:
- Turing Machine
- Lambda Calculus
- Game of Life
- COBOL
It turns out that even though the intent of the original creator of a given programming language is often largely ignored by its users, that doesn't mean it's always the case. For example, the first three examples were designed specifically to prove a point about really unwieldy languages still being "universal computers". Because of their features (or incredible absence thereof) it's normal that no-one expects anything from them.
However, in the case of PureData, after the intent of the author (or the marketing line) has been rejected/ignored, people *are* willing to ascribe new intents and meanings to PureData. The model of the language "talks to them": they *do* expect to find quality time with PureData, or at least a system that is 90% like PureData: and this is where the feature requests pour in, like
- Pd should do pixel video (solved in 1998)
- Pd should allow ~-objects to do batchjobs nonrealtime (not yet)
- Pd should have true strings (cross fingers for this year)
- etc
as well as bug reports, which may sound like my last two mails.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Mathieu Bouchard wrote: ...
Ok, since all this [prepend] ties in with how the whole of the Pd messagesystem is supposed to work, I have a question: if I do something like:
[bang( -> [t a a] -> [prepend test this] and [bang( -> [t a a] -> [route list] -> [prepend test this]
which one should be produced?
(a) first 'test this', second no-op (b) first 'test this bang', second no-op (c) both 'test this list 0' (d) first 'test this list 0', second no-op
Personally I'd expect either (b), or _maybe_ (a), and actually, replacing [t a a] with my own [fork] object (which does 99% the same), i get (b). However, trying the first case with [t a a], I think i get (c), until I try the second case and the reality is (d) (this behaviour of [route] is even documented as a _feature_ in route-help.pd)
cyclone's prepend does (e) first 'test this 0', but read on:
Conclusion: in Pd,
"anything" really means "anything but bang".
a bang casted to the "anything" type becomes a list of single 0
still marked in my archive is this:
Miller Puckette wrote:
This seems wrong. Also, I think "trigger list" should be putting out a bang (empty list) instead of a "0". But I should go find out what Max does for these...!
cheers Miller
On Mon, Sep 09, 2002 at 05:42:03AM +0200, Maurizio Umberto Puxeddu wrote:
Hi.
Sending a bang to a "trigger anything" object I get 0.
Krzysztof
On Tue, 4 Jan 2005, Krzysztof Czaja wrote:
still marked in my archive is this: Miller Puckette wrote:
This seems wrong. Also, I think "trigger list" should be putting out a bang (empty list) instead of a "0". But I should go find out what Max does for these...! On Mon, Sep 09, 2002 at 05:42:03AM +0200, Maurizio Umberto Puxeddu wrote:
Hi. Sending a bang to a "trigger anything" object I get 0.
Yes, and I also have reported that as a bug back in 2002 or 2003.
This is also why I used [fork] (an external I cloned from jMax) to do my work, because it avoids the above behaviour, and preserves single-element lists in "anything". Nowadays I mostly use [t a a] to make my patches more familiar to PureData users, but frankly, I think [fork] is right and [t a a] is wrong, and I still use [fork] when I want to make sure my messages aren't altered.
Besides, GridFlow still distinguishes between a single-element list (casts to one-dimensional grid) and a plain float (casts to zero-dimensional grid), and I'll change that behaviour only if really forced to, because when I have to choose between
- between integration of GridFlow into Pd
- internal consistency of GridFlow
I prefer the latter.
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Thu, 30 Dec 2004, Miller Puckette wrote:
I'm guessing |msg prepend test| would send a |test( message when banged (but have to think carefully about the design of a good "prepend" functionality and look at the existing ones to figure out what to do there...)
Well, while it's good to look at other existing [prepend]s, the behaviour of an official [prepend] should depend on what is consistent with pd; I mean consistent as in "what obeys to as few special rules as possible". So it would be good to come up with explanations about why it makes sense to have [prepend] behave a certain way.
I have written a [messageprepend] class (bundled with GF). When prepending a single element to a message, that element becomes the selector, and the former selector becomes $1, and so on.
This means that a bang becomes "test bang", and a 42 becomes "test float 42", and "1 2 3" becomes "test list 1 2 3". In the latter two cases, this involves the fact that a messagebox inserts a default selector where applicable.
In the Ruby-for-Pd external (aka gridflow.pd-*) I have a few automatic conversions going on, so that if you do send_out(0) then it's like doing send_out(0,:bang) (the colon is the symbol prefix in Ruby).
However, conversions are _never_ made the other way around: while nothingness may be considered a bang, a bang is then never considered like nothingness. The same applies to send_out(0,42) which is equivalent to send_out(0,:float,42), but once the first form is seen as the second one, there's no going back to the first one.
The reason can be distilled to one simple sentence:
A message always has a selector (of type Symbol).
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Tim Blechmann wrote: ...
i'd request another msg mode (maybe called msg msg or something similar), that sends a fixed message on a bang. means |msg msg test| == |test(
that is [zl reg test], an incompatible extension of the c74's zl
Krzysztof
i'd request another msg mode (maybe called msg msg or something similar), that sends a fixed message on a bang. means |msg msg test| == |test(
that is [zl reg test], an incompatible extension of the c74's zl
ah ... good to know ...
cheers ... tim
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Krzysztof Czaja -
Mathieu Bouchard -
Matju
-
Miller Puckette -
Tim Blechmann