hi,
this may be related to a thread last week about the nature lists ?
as a experienced max-user i'm having problems to understand the
nature of PD atoms. there seems to be the possibility that an atom is
neither a symbol, nor a number nor a list ? like in this patch some
inputs leave [route] through the rightmost outlet:
#N canvas 316 159 576 396 10; #X msg 30 55 3.14159; #X obj 67 149 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 117 149 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 66 123 route float list symbol; #X obj 169 149 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 221 149 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 122 55 alpha; #X msg 215 55 alpha beta; #X text 213 35 NOT a list??; #X text 97 35 NOT a symbol??; #X text 41 198 Philosophical question : if an atom is not a symbol , nor a number , nor a list , what kind of primitive atom class is it instead?; #X msg 310 56 symbol alpha; #X msg 412 57 symbol alpha beta; #X msg 354 127 list alpha; #X msg 430 90 list alpha beta; #X text 351 161 it's routed as a "symbol"!; #X text 66 164 f; #X text 117 166 l; #X text 169 166 s; #X text 221 168 other; #X text 349 146 this is completely weird ,; #X msg 132 304 list alpha beta; #X obj 255 365 print A; #X obj 321 365 print B; #X msg 255 305 list alpha; #X msg 338 304 alpha beta; #X obj 256 341 zl slice 1; #X text 339 284 allowed ...; #X connect 0 0 3 0; #X connect 3 0 1 0; #X connect 3 1 2 0; #X connect 3 2 4 0; #X connect 3 3 5 0; #X connect 6 0 3 0; #X connect 7 0 3 0; #X connect 11 0 3 0; #X connect 12 0 3 0; #X connect 13 0 3 0; #X connect 14 0 3 0; #X connect 21 0 26 0; #X connect 24 0 26 0; #X connect 25 0 26 0; #X connect 26 0 22 0; #X connect 26 1 23 0;
what i find particularly confusing is that [list alpha( comes out of
the symbol outlet ...
then the nature of lists. here i compare the same functionality in pd
and max. first max:
max v2; #N vpatcher 361 44 787 395; #P window setfont "Sans Serif" 9.; #P comment 89 223 29 196617 here; #P button 70 222 15 0; #P button 29 222 15 0; #P newex 29 192 51 196617 route list; #P comment 292 159 58 196617 "test test"; #P button 227 221 15 0; #P button 186 221 15 0; #P newex 186 191 51 196617 route list; #P newex 226 156 59 196617 print SLICE; #P newex 186 129 50 196617 zl slice 0; #P newex 67 136 59 196617 print PACK; #P newex 67 98 45 196617 pack s s; #P button 39 54 15 0; #P message 102 54 26 196617 test; #P message 67 54 26 196617 test; #P comment 69 158 58 196617 "test test"; #P comment 244 222 29 196617 here; #P comment 68 35 54 196617 both work; #P fasten 6 0 14 0 72 122 34 122; #P connect 14 0 15 0; #P connect 3 0 6 0; #P fasten 5 0 6 0 44 83 72 83; #P connect 6 0 7 0; #P connect 14 1 16 0; #P connect 4 0 6 1; #P fasten 6 0 8 0 72 122 191 122; #P fasten 8 1 10 0 231 150 191 150; #P connect 10 0 11 0; #P connect 8 1 9 0; #P connect 10 1 12 0; #P pop;
... then the same in pd:
#N canvas 253 241 513 444 10; #X obj 82 133 pack s s; #X msg 175 57 test; #X msg 83 57 test; #X text 83 39 this works; #X text 175 38 this complains; #X msg 175 103 symbol test; #X text 176 86 this works; #X obj 49 101 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 147 161 zl slice 0; #X obj 83 194 print PACK; #X text 59 214 "list test test"; #X text 210 212 "test test" (so "list" is "lost"?); #X obj 7 281 route list; #X obj 8 309 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 77 311 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 24 340 print ROUTE; #X obj 157 261 route list; #X obj 158 289 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 222 290 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X text 21 361 "list" removed again; #X obj 213 193 print SLICE; #X text 242 289 here; #X connect 0 0 8 0; #X connect 0 0 9 0; #X connect 0 0 12 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 5 0 0 1; #X connect 7 0 0 0; #X connect 8 1 16 0; #X connect 8 1 20 0; #X connect 12 0 13 0; #X connect 12 0 15 0; #X connect 12 1 14 0; #X connect 16 0 17 0; #X connect 16 1 18 0;
there seems to be no logic whether one has can use a message "as
such" and when one has to prepend the "symbol" selector. also there
seems to be no logic whether an object outputs a list "as such" or
with a prepended "list" selector ; like [pack] accepts a symbol
without "symbol" in the left inlet, but not in the right inlet ; it
will output a list prepended by "list" ; if i put this list into
[zl], the list-prefix is stripped.
also, what kind of atom is this [alpha beta gamma( if not a list?
thanks for help. best, -sciss-
Hallo, Sciss hat gesagt: // Sciss wrote:
this may be related to a thread last week about the nature lists ?
as a experienced max-user i'm having problems to understand the
nature of PD atoms. there seems to be the possibility that an atom is
neither a symbol, nor a number nor a list ? like in this patch some
inputs leave [route] through the rightmost outlet:
Check http://puredata.info/dev/PdDefinitions and http://puredata.info/dev/PdMessages and http://puredata.info/dev/HansDataTypeDefinitions
Being the author of http://puredata.info/dev/PdMessages I would just repeat myself here with text from there.
there seems to be no logic whether one has can use a message "as
such" and when one has to prepend the "symbol" selector. also there
seems to be no logic whether an object outputs a list "as such" or
with a prepended "list" selector ; like [pack] accepts a symbol
without "symbol" in the left inlet, but not in the right inlet ; it
will output a list prepended by "list" ; if i put this list into
[zl], the list-prefix is stripped.
I consider this a bug of [zl]. With newer Pd's you should use [list] instead for basic operations on lists. [list] *always* outputs a list-message with list-selector for messages with more than one element, except [list trim] which trims the selector.
also, what kind of atom is this [alpha beta gamma( if not a list?
It's something Miller calls a "meta-message". The most common example is the "set"-meta-message.
Frank Barknecht _ ______footils.org_ __goto10.org__
also,
[open ..... ..... (
[; sentdata $1 (
[read /.../../aaaaa.wav table-xyz(
etc...
i agree that these things are not objects and not lists, so "meta message" sounds perfect to describe them.
Hallo, hard off hat gesagt: // hard off wrote:
also,
[open ..... ..... (
[; sentdata $1 (
[read /.../../aaaaa.wav table-xyz(
etc...
i agree that these things are not objects and not lists, so "meta message" sounds perfect to describe them.
Btw: I often use a little abstraction called "prepent.pd" with pd-0.39, which will generate meta messages with a certain selector. Inside it just consists of a mix of "prepend" and "trim" => "prepent":
prepent.pd:
[inlet] [inlet] | | [list prepend $1] | [list trim] | [oulet]
I use this for example in front of netsend:
[prepent send] | [netsend]
Then I don't need to worry about the length of messages to send.
One advantage of all this is, that while working on the message *before* it gets to the "prepent", it always is a proper list-message with a list-selector, because I start the whole message-working chain with a [list] object that adds the list-selector. So I don't need to worry about encountering a meta-message in between.
I'd go as far to say that even when generating meta-messages it should be best practice to start with a list-message and convert it to a meta messages as late as possible. Unfortunatly this only really works with pd-0.39 and/or the proper [list] object. [zl] or [prepend] - while mighty - aren't as consistent when it comes to list- and meta-messages.
Rant end. ;)
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
i agree that these things are not objects and not lists, so "meta message" sounds perfect to describe them.
i agree too, that these things are neither objects nor lists, however to my ears "message" sounds even more perfect than "meta message" or "message not of the bang-, float-, symbol- and list-type"
Btw: I often use a little abstraction called "prepent.pd" with pd-0.39, which will generate meta messages with a certain selector. Inside it just consists of a mix of "prepend" and "trim" => "prepent":
prepent.pd:
[inlet] [inlet] | | [list prepend $1] | [list trim] | [oulet]
I use this for example in front of netsend:
[prepent send] | [netsend]
indeed this is a very useful thing. however, i (personally) use 2 objects instead of 1 (not that much of a gain...)
mf.asdr. IOhannes
On Apr 20, 2006, at 10:44 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, hard off hat gesagt: // hard off wrote:
i agree that these things are not objects and not lists, so "meta message" sounds perfect to describe them.
i agree too, that these things are neither objects nor lists,
however to my ears "message" sounds even more perfect than "meta message" or "message not of the bang-, float-, symbol- and list-type"
Except that we need to distinguish between symbolic atoms and
symbolic messages, since they are not the same thing, as the pack
example illustrates.
I think that "data messages" and "control messages" are a
possibility... meta messages just sounds to vague to me.
.hc
Btw: I often use a little abstraction called "prepent.pd" with
pd-0.39, which will generate meta messages with a certain selector. Inside it just consists of a mix of "prepend" and "trim" => "prepent":prepent.pd:
[inlet] [inlet] | | [list prepend $1] | [list trim] | [oulet]
I use this for example in front of netsend:
[prepent send] | [netsend]
indeed this is a very useful thing. however, i (personally) use 2 objects instead of 1 (not that much of a gain...)
mf.asdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"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 Thu, 20 Apr 2006, Hans-Christoph Steiner wrote:
I think that "data messages" and "control messages" are a possibility... meta messages just sounds to vague to me.
I first thought "great idea", they sounded like excellent names, but then I thought, I usually say "data" to mean both "messages" and other things, and I usually say "control" to talk about execution order and where's the currently active object(s) and such. As in "control flow" vs "data flow". Pd's patches are first and foremost data flow diagrams, but they imply control flow in it. A patch is a hierarchical version of the classic "control flow diagrams" but where the arrow means a function call instead of a GOTO. The original "control flow diagrams" have largely fell out of fashion but they've come back under a new name and new notation, namely, "Finite State Machine".
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Frank Barknecht wrote: ...
there seems to be no logic whether one has can use a message "as
such" and when one has to prepend the "symbol" selector. also there
seems to be no logic whether an object outputs a list "as such" or
with a prepended "list" selector ; like [pack] accepts a symbol
without "symbol" in the left inlet, but not in the right inlet ; it
will output a list prepended by "list" ; if i put this list into
[zl], the list-prefix is stripped.I consider this a bug of [zl]. With newer Pd's you should use [list]
a feature not a bug! Pd message system was designed for signal processing control, not for symbolic processing of any sort.
zl is just a version of the ``list ops'' Max library by James McCartney. Thus, in a sense, it was obsoleted first by pyrite, then by sc...
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
Frank Barknecht wrote: ...
will output a list prepended by "list" ; if i put this list into
[zl], the list-prefix is stripped.I consider this a bug of [zl]. With newer Pd's you should use [list]
a feature not a bug! Pd message system was designed for signal processing control, not for symbolic processing of any sort.
Well, "bug" may be a bit harsh of me, but I really don't see why [zl] doesn't just keep the "list" selector? I find the behaviour of [list] much more consistent compared to [zl]. [zl] is happily throwing away an important selector (see attached patch), which is a behaviour I would rather have control over myself with e.g. [list trim].
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote: ...
Well, "bug" may be a bit harsh of me, but I really don't see why [zl] doesn't just keep the "list" selector? I find the behaviour of [list] much more consistent compared to [zl]. [zl] is happily throwing away an important selector (see attached patch), which is a behaviour I would rather have control over myself with e.g. [list trim].
the only difference is that [list] always quotes its output unlike [zl], which always sends ready-to-evaluate messages. Otherwise, both work just on vectors of atoms, and you can't tell from their output, whether input was quoted or not.
You might argue that a [list] inserted on output costs more than a [list trim], although I doubt Max users are really forced to insert [prepend list] that often.
Krzysztof