I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor $bugfix" to rcv-name
[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute values" to rcv-name
leaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for about.pd in the other thread--
if Pd has a "get" method then about.pd doesn't need to rely on externals (well, aside from
pddplink for the links).
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
-Jonathan
hi jonathan
maybe PID, if possible, would be great....
yours sincerely der.brandt
Zitat von "Jonathan Wilkes" jancsika@yahoo.com:
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor $bugfix"
to rcv-name[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute
values" to rcv-nameleaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for
about.pd in the other thread--if Pd has a "get" method then about.pd doesn't need to rely on
externals (well, aside frompddplink for the links).
Are there Pd attributes other than version and dsp status that would
be nice to make "gettable"?-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Le 2011-11-17 à 08:43:00, brandt@subnet.at a écrit :
maybe PID, if possible, would be great....
There's [gf/getpid].
http://gridflow.ca/help/gf/getpid-help.html
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
oh...thank you
yours sincerely :-) der.brandt
Zitat von "Mathieu Bouchard" matju@artengine.ca:
Le 2011-11-17 à 08:43:00, brandt@subnet.at a écrit :
maybe PID, if possible, would be great....
There's [gf/getpid].
http://gridflow.ca/help/gf/getpid-help.html
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 02:43, Jonathan Wilkes wrote:
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor $bugfix" to rcv-name
[...]
wouldn't it be easier to use a syntax like [get <rcvname> <attribute>( ? rather than [get <attribute> <rcvname>(
i think sending the rcvname first will make the syntax more easily extendible. e.g. it would allow for [tryset <rcvname> <attribute> <values...>( and the like.
madf IOhannes
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 3:33 AM Subject: Re: [PD] "get" method for Pd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 02:43, Jonathan Wilkes wrote:
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor
$bugfix" to rcv-name [...]
wouldn't it be easier to use a syntax like [get <rcvname> <attribute>( ? rather than [get <attribute> <rcvname>(
i think sending the rcvname first will make the syntax more easily extendible. e.g. it would allow for [tryset <rcvname> <attribute> <values...>( and the like.
I really want to avoid that syntax because while it may be the most flexible for the current Pd implementation (e.g., one without a list atom) it's clearest to have "get" followed directly by the thing being "gotten".
Maybe I can sidestep the issue by suggesting just to send the result back to the "pd" symbol by forwarding it using an added "state" method that does nothing:
[loadbang] | [; pd get dsp(
[r pd] | [route state] | [route dsp] | [set $1( | [0(
Added benefit is that you can also state a message to pd using the "state" method, and all pd receivers will be notified.
-Jonathan
madf IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ExsQACgkQkX2Xpv6ydvRm7gCcCY+tuCG95nwLHoOw7nm46zdl gEEAoI57wflBh6egv1Vh5WlQ3PVC3VGV =wHPp -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
Very useful! I could think of these, to start with:
[; pd get tcl-version rcv-name( sends "tcl-version $" to rcv-name
[; pd get float-precision rcv-name( sends "float-precision $" to rcv-name (expressed as 8*sizeof(t_float))
[; pd get pd-path rcv-name( sends "pd-path path/to/pd" to rcv-name
Katja
On Thu, 2011-11-17 at 13:14 +0100, katja wrote:
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
Very useful! I could think of these, to start with:
[; pd get tcl-version rcv-name( sends "tcl-version $" to rcv-name
[; pd get float-precision rcv-name( sends "float-precision $" to rcv-name (expressed as 8*sizeof(t_float))
[; pd get pd-path rcv-name( sends "pd-path path/to/pd" to rcv-name
To complement the last one (in the syntax proposed by IOhannes):
[; pd get rcv-name start-path(
Roman
How about
[; pd get self rcv-name(
Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear.
On Thu, 17 Nov 2011 13:14:58 +0100 katja katjavetter@gmail.com wrote:
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
Very useful! I could think of these, to start with:
[; pd get tcl-version rcv-name( sends "tcl-version $" to rcv-name
[; pd get float-precision rcv-name( sends "float-precision $" to rcv-name (expressed as 8*sizeof(t_float))
[; pd get pd-path rcv-name( sends "pd-path path/to/pd" to rcv-name
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Andy Farnell padawan12@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] "get" method for Pd
How about
[; pd get self rcv-name(
Not sure I understand this one-- what comes out of [r rcv-name] here?
-Jonathan
Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear.
On Thu, 17 Nov 2011 13:14:58 +0100 katja katjavetter@gmail.com wrote:
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com
wrote:
Are there Pd attributes other than version and dsp status that would
be nice to make "gettable"?
Very useful! I could think of these, to start with:
[; pd get tcl-version rcv-name( sends "tcl-version $" to
rcv-name
[; pd get float-precision rcv-name( sends "float-precision $" to rcv-name (expressed as 8*sizeof(t_float))
[; pd get pd-path rcv-name( sends "pd-path path/to/pd" to
rcv-name
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Andy Farnell padawan12@obiwannabe.co.uk
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Nov 17, 2011 at 05:21:29AM -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Andy Farnell padawan12@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] "get" method for Pd
How about
[; pd get self rcv-name(
Not sure I understand this one-- what comes out of [r rcv-name] here?
-Jonathan
Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear.
I think what Andy means here is the actual text of the patch itself as you would find by looking at the .pd file in a text editor.
e.g. #N canvas 218 94 842 634 10; #X obj 63 84 t a a; #X obj 63 241 spigot; #X obj 102 149 bang; #X obj 102 168 1; #X obj 223 149 route bang; #X obj 183 150 bang; ...
Making 'self' a settable property would open up all kinds of lovely madness!
Cheers,
Chris.
----- Original Message -----
From: Chris McCormick chris@mccormick.cx To: Jonathan Wilkes jancsika@yahoo.com Cc: Andy Farnell padawan12@obiwannabe.co.uk; "pd-list@iem.at" pd-list@iem.at Sent: Thursday, November 17, 2011 8:38 PM Subject: Re: [PD] "get" method for Pd
On Thu, Nov 17, 2011 at 05:21:29AM -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Andy Farnell padawan12@obiwannabe.co.uk To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:12 AM Subject: Re: [PD] "get" method for Pd
How about
[; pd get self rcv-name(
Not sure I understand this one-- what comes out of [r rcv-name] here?
-Jonathan
Dumps itself. Once I wanted to get Pd patches to print themselves, can't remember how it was solved now, but the above would have been quite clear.
I think what Andy means here is the actual text of the patch itself as you would find by looking at the .pd file in a text editor.
e.g. #N canvas 218 94 842 634 10; #X obj 63 84 t a a; #X obj 63 241 spigot; #X obj 102 149 bang; #X obj 102 168 1; #X obj 223 149 route bang; #X obj 183 150 bang; ...
Making 'self' a settable property would open up all kinds of lovely madness!
You can already do this if you know the file name of the patch. With my canvas get method, a patch can retrieve its own filename. In either case you can also save the a revised patch using [textfile].
-Jonathan
Cheers,
Chris.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 13:14, katja wrote:
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
Very useful! I could think of these, to start with:
[; pd get tcl-version rcv-name( sends "tcl-version $" to rcv-name
which tcl-version is reported for "pd -nogui"?
or rather, how are non-existing attributes reported? simply by not sending anything to the <rcvname>?
fgmasdr IOhannes
Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit :
which tcl-version is reported for "pd -nogui"? or rather, how are non-existing attributes reported?
symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-17 à 15:10:00, Mathieu Bouchard a écrit :
Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit :
which tcl-version is reported for "pd -nogui"? or rather, how are non-existing attributes reported?
symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation.
or, of course, any anything message, e.g. you could use :
[route unavailable] or [route unknown]
to pick up the thing that plays an error-message-like role (though as a normal message).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hm, how about this:
[info symbol]
where symbol is "pd" for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui,
or no args for "this canvas"
the only inlet takes: "get attribute" to output an "attribute value(s)" message "get" to get a sequence of all "attribute value(s)" messages
"symbol receive-symbol" to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas
It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :)
-Jonathan
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Thursday, November 17, 2011 3:11 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-17 à 15:10:00, Mathieu Bouchard a écrit :
Le 2011-11-17 à 15:15:00, IOhannes m zmoelnig a écrit :
which tcl-version is reported for "pd -nogui"? or rather, how are non-existing attributes reported?
symbol none symbol unknown float -1 float 0 etc. whatever float or symbol best fits the situation.
or, of course, any anything message, e.g. you could use :
[route unavailable] or [route unknown]
to pick up the thing that plays an error-message-like role (though as a normal message).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Nov 17, 2011 at 12:45:57PM -0800, Jonathan Wilkes wrote:
Hm, how about this:
[info symbol]
where symbol is "pd" for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui,
or no args for "this canvas"
the only inlet takes: "get attribute" to output an "attribute value(s)" message "get" to get a sequence of all "attribute value(s)" messages
"symbol receive-symbol" to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas
It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :)
I think DesireData had a facility for receiving error messages back into the patch. While we are thinking about this type of thing, what about [info errors] or [info console] which outputs everything that goes to console or all errors generated by Pd?
Cheers,
Chris.
On Nov 17, 2011, at 8:43 PM, Chris McCormick wrote:
On Thu, Nov 17, 2011 at 12:45:57PM -0800, Jonathan Wilkes wrote:
Hm, how about this:
[info symbol]
where symbol is "pd" for pd, an array name, subpatch or abstraction name, the receive symbol of an iemgui,
or no args for "this canvas"
the only inlet takes: "get attribute" to output an "attribute value(s)" message "get" to get a sequence of all "attribute value(s)" messages
"symbol receive-symbol" to set a new receive symbol pointer to set it to query a scalarpointer-to-head-of-list to query a particular canvas
It might be too complex with that many disparate classes, but it sure would simplify the process of getting pure data :)
I think DesireData had a facility for receiving error messages back into the patch. While we are thinking about this type of thing, what about [info errors] or [info console] which outputs everything that goes to console or all errors generated by Pd?
This should really just be a standalone object, something like [stdout] and [stderr] with an outlet.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Le 2011-11-18 à 09:43:00, Chris McCormick a écrit :
I think DesireData had a facility for receiving error messages back into the patch.
It had only something to trap all console-messages («posts») during the time it takes to handle a pd-message. You send a message through it, and the console-messages are trapped until the message «returns» (end of message-handling, not counting any [delay]ed things).
http://artengine.ca/desiredata/gallery/unpost.gif
It can be nested : you can have an [unpost] in the main patch and have it send stuff to an abstraction that also uses [unpost], for example, and posts will be sent to only one [unpost], the latest one still active.
I also thought there would be something specifically for errors, but kept it for the future.
I had plans for a different error-messaging system because [unpost]-like solutions need parsing error messages. I thought of future error messages being regular pd messages so that you can use [route] to pick up error categories by selector. That would have been much closer to try/catch or begin/rescue in other languages (while not actually implementing the part that makes it hard to implement).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
Colet Patrice
----- Mail original -----
De: "Jonathan Wilkes" jancsika@yahoo.com À: "pd-list" pd-list@iem.at Envoyé: Jeudi 17 Novembre 2011 02:43:08 Objet: [PD] "get" method for Pd
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor $bugfix" to rcv-name
[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute values" to rcv-name
leaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for about.pd in the other thread--
if Pd has a "get" method then about.pd doesn't need to rely on externals (well, aside from
pddplink for the links).
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2011-11-17 at 14:53 +0100, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
How would pd know which canvas you mean?
Wouldn't it make more sense to ask the canvas itself instead of pd? pd-<canvasname> is already listening for stuff...
Roman
I think that belongs in the canvas get method:
[; pd-mpatch.pd get etc.(
-Jonathan
----- Original Message -----
From: Patrice Colet colet.patrice@free.fr To: Jonathan Wilkes jancsika@yahoo.com; pd-list pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 8:53 AM Subject: Re: [PD] "get" method for Pd
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
Colet Patrice
----- Mail original -----
De: "Jonathan Wilkes" jancsika@yahoo.com À: "pd-list" pd-list@iem.at Envoyé: Jeudi 17 Novembre 2011 02:43:08 Objet: [PD] "get" method for Pd
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor
$bugfix" to
rcv-name
[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute values" to rcv-name
leaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for about.pd in the other thread--
if Pd has a "get" method then about.pd doesn't need to rely
on
externals (well, aside from
pddplink for the links).
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:07, Jonathan Wilkes wrote:
I think that belongs in the canvas get method:
[; pd-mpatch.pd get etc.(
what would that return if you have multiple instances of the mpatch abstraction?
fgmadr IOhannes
On Thu, 2011-11-17 at 15:12 +0100, IOhannes m zmoelnig wrote:
On 2011-11-17 15:07, Jonathan Wilkes wrote:
I think that belongs in the canvas get method:
[; pd-mpatch.pd get etc.(
what would that return if you have multiple instances of the mpatch abstraction?
I think the most "natural" behavior would be that all instances would respond in an un-orderer manner. If you want to request many instances separately, you'd have to use something like [namecanvas].
Roman
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 9:12 AM Subject: Re: [PD] "get" method for Pd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:07, Jonathan Wilkes wrote:
I think that belongs in the canvas get method:
[; pd-mpatch.pd get etc.(
what would that return if you have multiple instances of the mpatch abstraction?
Try it:
http://sourceforge.net/tracker/index.php?func=detail&aid=3308027&gro...
It returns a result for each instance of the abstraction-- thus the user has the ability to query the set of all abstraction instances, as well as individual results for a particular canvas (the latter either using your [sendcanvas] or my [send2canvas] wrapper around "get parent" in the demo).
There are some things I need to revise in that patch, but it should give a good starting point.
-Jonathan
fgmadr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFloACgkQkX2Xpv6ydvSEIgCg3BLPyZ5GRgOOhowZSFL9fmwA nF4AnAxpNcUgl/NcUc6YVdpLHMWPLree =2aOa -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
fgamsdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just "info". It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I like "info" too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just "info". It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:01 PM Subject: Re: [PD] "get" method for Pd
I like "info" too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
Miller said "object", so I'm assuming he meant [info] (though I don't think anyone else agreed that it would be the right approach).
Benefit:
- [info] would have a help patch, so it would be easier to document, plus avoid
the confusion of the pd receive symbol with the [pd] canvas
Benefit of [; pd info(
- easier to code, plus it fits nicely with the extend implicit set methods katja
mentioned -- [; pd dsp 1( etc. (i.e., using the currently existing methods to set attributes)
Maybe others have benefit/drawback ideas?
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
I agree these should be separated.
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else
but I
agree this should be an object, maybe 'get-info" or even just
"info".
It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get
<rcvname> ..." is
better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to "receive" it (I'm not even sure that's possible without making a self-editing patch).
But there are other situation which seem to beg for the "receive" solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has.
although it's migraine-inducing, the neatest solution would be to allow "info" style objects to have a right-hand outlet that you connect to, say, the "textfile" object like so:
[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote:
I like "info" too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just "info". It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
That's a great point, just an [info] object makes a lot of sense.
[dsp( | [info] | [route dsp] | [1(
Then there could also be [pd-gui], but unfortunately not [pd]. But about the [textfile] example, it seems to be that the second outlet could be used for general meta information. This is used in lots of other objects and it works quite nicely (see [hid], [comport], etc.) I suppose that would break backwards compatibilty tho...
.hc
On Nov 17, 2011, at 1:42 PM, Miller Puckette wrote:
This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to "receive" it (I'm not even sure that's possible without making a self-editing patch).
But there are other situation which seem to beg for the "receive" solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has.
although it's migraine-inducing, the neatest solution would be to allow "info" style objects to have a right-hand outlet that you connect to, say, the "textfile" object like so:
[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote:
I like "info" too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just "info". It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
Access to computers should be unlimited and total. - the hacker ethic
Say you'd have a [global] object, with a getter and / or setter for things like dsp, samplerate, version etc. Obviously, some things are gettable but not settable, like version or path/to/pd, and some things are not even gettable in certain circumstances, like IOhannes pointed out. The object would then give an error message which you can catch. For local info you'd have another object, for example [this] for the window, (like MaxMsp has [thispatcher]).
Katja
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 17, 2011 3:33 PM Subject: Re: [PD] "get" method for Pd
Say you'd have a [global] object, with a getter and / or setter for things like dsp, samplerate, version etc.Obviously, some things are gettable but not settable, like version or path/to/pd, and some things are not even gettable in certain circumstances, like IOhannes pointed out. The object would then give an error message which you can catch. For local info you'd have another object, for example [this] for the window, (like MaxMsp has [thispatcher]).
I think [thispatcher] would be analogous to [sendcanvas], or, a pointer to the head of a glist, which you can get with [pointer] and use its "send-window" method to send messages to it. My canvas "get" method patch makes it possible to get a pointer to the parent of a canvas, so you can essentially write your own "sendcanvas" abstraction.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Nov 17, 2011 at 9:51 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I think [thispatcher] would be analogous to [sendcanvas], or, a pointer to the head of a glist, which you can get with [pointer] and use its "send-window" method to send messages to it. My canvas "get" method patch makes it possible to get a pointer to the parent of a canvas, so you can essentially write your own "sendcanvas" abstraction.
True there's many externals for info purposes, but your patch makes it work via a modification of pd core code. I tried your patch file and demo. What a cool demo it is! This makes my day. (And I've not even seen half of it, because pd crashes at the 'edit demo-abstraction', that's maybe because I patched pd version test5.) Good thing you bumped this topic.
Katja
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all.
Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user.
-Jonathan
So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to "receive" it (I'm not even sure that's possible without making a self-editing patch).
But there are other situation which seem to beg for the "receive" solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has.
although it's migraine-inducing, the neatest solution would be to allow "info" style objects to have a right-hand outlet that you connect to, say, the "textfile" object like so:
[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote:
I like "info" too, maybe [pd info(. I like Jonathan's
ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own
'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something
else but I
agree this should be an object, maybe 'get-info" or even just
"info".
It could get and/or set info about the canvas it's in as well as
about
other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get
<rcvname> ..." is
better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this
is
not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for sorting/splitting/etc.-- stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all.
Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to desired data about a pd instance, canvas instance, array, scalar-- i.e., things that don't have an inlet to hook into-- then we can build an abstraction around that to provide a unified interface for the user.
It sounds to me that this is unifying too many things. I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas.
As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages.
One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done.
.hc
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so far
resisted
the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for
sorting/splitting/etc.--
stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the
ugliness
necessary to get decent list processing to happen in Pd, than to not have the list classes at all.
Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to
desired data
about a pd instance, canvas instance, array, scalar-- i.e., things that
don't have
an inlet to hook into-- then we can build an abstraction around that to
provide a
unified interface for the user.
It sounds to me that this is unifying too many things.
It will never be the case in Pd that something-- anything-- is too unified.
I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas.
As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages.
Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used.
One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done.
Is there a way to standardize a "get" method? I mean, if some externals took float messages, and others took "float NUMBER PRECISION" messages, and yet another took "float32 NUMBER", I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery.
-Jonathan
.hc
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. -Admiral Gene LeRocque
On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so far
resisted
the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes do a terrible job of processing lists. The resulting pd code for
sorting/splitting/etc.--
stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example). Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the
ugliness
necessary to get decent list processing to happen in Pd, than to not have the list classes at all.
Similarly, object chains with a big blank space between a [send] and its corresponding [receive] aren't great, but if they can provide access to
desired data
about a pd instance, canvas instance, array, scalar-- i.e., things that
don't have
an inlet to hook into-- then we can build an abstraction around that to
provide a
unified interface for the user.
It sounds to me that this is unifying too many things.
It will never be the case in Pd that something-- anything-- is too unified.
The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually.
I think all this stuff should be gettable using the same style and technique (i.e. messages, inlets, outlets, etc) but not necessarily in the same object. The mediasettings lib provides a way to get and set the audio/midi settings, the iemguts library provides a means for getting and setting info about the patch and canvas.
As long as all this libs and objects use the same idioms for interaction, then I think this is a much preferrable route than having a single centralized [info] object with hundreds of messages.
Yeah, it's overkill to wrap _everything_ into one object, but for the things that I listed which don't have an inlet, a unified object would be nice. Maybe choosing context by the inbound message type like I described would be problematic-- so maybe an approach similar to the list classes where the arg sets the class to be used.
One example of such an idiom is having a data outlet and a status outlet, like comport, hid, etc. Another example is the [textfile] way that you can go thru a list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done.
Is there a way to standardize a "get" method? I mean, if some externals took float messages, and others took "float NUMBER PRECISION" messages, and yet another took "float32 NUMBER", I wouldn't use Pd. So when you imply that the solution is all these disparate libraries that pretty much do what people need, and all in their own disparate ways, I'm leery.
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 9:17 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at"
pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at
Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so
far
resisted
the idea of using send/receive as a back channel for getting
return
values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes
do a terrible job of processing lists. The resulting pd code for
sorting/splitting/etc.--
stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the
innards of
[listabs/list-drip] for example). Yet it's better to have the
core
list classes plus a library of abstractions-- listabs-- that hides
the
ugliness
necessary to get decent list processing to happen in Pd, than to
not have
the list classes at all.
Similarly, object chains with a big blank space between a [send]
and its
corresponding [receive] aren't great, but if they can provide
access to
desired data
about a pd instance, canvas instance, array, scalar-- i.e., things
that
don't have
an inlet to hook into-- then we can build an abstraction around
that to
provide a
unified interface for the user.
It sounds to me that this is unifying too many things.
It will never be the case in Pd that something-- anything-- is too unified.
The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually.
Oh, you mean all mashed together in a big nondescript list? Here again it's too bad that lists don't nest in Pd-- that way you could just get one list of many key/values.
I think all this stuff should be gettable using the same style and technique (i.e. messages,
inlets,
outlets, etc) but not necessarily in the same object. The
mediasettings lib
provides a way to get and set the audio/midi settings, the iemguts
library
provides a means for getting and setting info about the patch and
canvas.
As long as all this libs and objects use the same idioms for
interaction, then I
think this is a much preferrable route than having a single centralized
[info]
object with hundreds of messages.
Yeah, it's overkill to wrap _everything_ into one object, but for the
things that I
listed which don't have an inlet, a unified object would be nice.
Maybe choosing
context by the inbound message type like I described would be problematic--
so maybe an approach similar to the list classes where the arg sets the
class
to be used.
One example of such an idiom is having a data outlet and a status
outlet, like
comport, hid, etc. Another example is the [textfile] way that you can
go thru a
list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done.
Is there a way to standardize a "get" method? I mean, if some
externals took
float messages, and others took "float NUMBER PRECISION"
messages, and
yet another took "float32 NUMBER", I wouldn't use Pd. So
when you imply that
the solution is all these disparate libraries that pretty much do what
people
need, and all in their own disparate ways, I'm leery.
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
But all the messages would follow the same syntax. Take [info] in tcl-- it doesn't have a particularly large help file.
-Jonathan
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
On Nov 17, 2011, at 9:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at" pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 9:17 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 6:26 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Miller Puckette msp@ucsd.edu; "pd-list@iem.at"
pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at
Sent: Thursday, November 17, 2011 5:50 PM Subject: Re: [PD] "get" method for Pd
On Nov 17, 2011, at 5:40 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: pd-list@iem.at; IOhannes m zmoelnig zmoelnig@iem.at Sent: Thursday, November 17, 2011 1:42 PM Subject: Re: [PD] "get" method for Pd
T his leads to an interesting larger design issue. I've so
far
resisted
the idea of using send/receive as a back channel for getting
return
values because of the unreadablity of the resulting patch.
I was thinking: from that same vantage point, the core list classes
do a terrible job of processing lists. The resulting pd code for
sorting/splitting/etc.--
stuff that is elementary in many other programming languages-- either ends up being simplistic and inefficient, or efficient but extremely weird and difficult to read (just have a look at the
innards of
[listabs/list-drip] for example). Yet it's better to have the
core
list classes plus a library of abstractions-- listabs-- that hides
the
ugliness
necessary to get decent list processing to happen in Pd, than to
not have
the list classes at all.
Similarly, object chains with a big blank space between a [send]
and its
corresponding [receive] aren't great, but if they can provide
access to
desired data
about a pd instance, canvas instance, array, scalar-- i.e., things
that
don't have
an inlet to hook into-- then we can build an abstraction around
that to
provide a
unified interface for the user.
It sounds to me that this is unifying too many things.
It will never be the case in Pd that something-- anything-- is too unified.
The audio dialog message and the midi dialog message are too unified. Things like sample rate, channels, etc. should be settable individually.
Oh, you mean all mashed together in a big nondescript list? Here again it's too bad that lists don't nest in Pd-- that way you could just get one list of many key/values.
No matter what the format of the list itself, having to set all of the possibilities at once makes it very hard to work with.
I think all this stuff should be gettable using the same style and technique (i.e. messages,
inlets,
outlets, etc) but not necessarily in the same object. The
mediasettings lib
provides a way to get and set the audio/midi settings, the iemguts
library
provides a means for getting and setting info about the patch and
canvas.
As long as all this libs and objects use the same idioms for
interaction, then I
think this is a much preferrable route than having a single centralized
[info]
object with hundreds of messages.
Yeah, it's overkill to wrap _everything_ into one object, but for the
things that I
listed which don't have an inlet, a unified object would be nice.
Maybe choosing
context by the inbound message type like I described would be problematic--
so maybe an approach similar to the list classes where the arg sets the
class
to be used.
One example of such an idiom is having a data outlet and a status
outlet, like
comport, hid, etc. Another example is the [textfile] way that you can
go thru a
list of things: load it, bang it get the next element, catch bang from right-outlet when the list is done.
Is there a way to standardize a "get" method? I mean, if some
externals took
float messages, and others took "float NUMBER PRECISION"
messages, and
yet another took "float32 NUMBER", I wouldn't use Pd. So
when you imply that
the solution is all these disparate libraries that pretty much do what
people
need, and all in their own disparate ways, I'm leery.
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
But all the messages would follow the same syntax. Take [info] in tcl-- it doesn't have a particularly large help file.
You think that ~2300 words is not particularly large for a help file? That's now long Tcl's info help is. I don't think any Pd help patch has anywhere close to 2300 words.
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Le 2011-11-17 à 22:24:00, Hans-Christoph Steiner a écrit :
You think that ~2300 words is not particularly large for a help file? That's now long Tcl's info help is. I don't think any Pd help patch has anywhere close to 2300 words.
wc -w "#convolve-help.pd" says 3086, but counting only the contents of the comments, it's 1596. To be fair, however, you have to count the code examples, and doc elements that aren't plain comments, so it's probably closer to 2000.
http://gridflow.ca/help/%23convolve-help.html
But that's because it contains a whole tutorial, too. Otherwise, the design of the thing is quite simple.
I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 560000 words and doesn't even come with a Ctrl+f feature.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 4:31 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-17 à 22:24:00, Hans-Christoph Steiner a écrit :
You think that ~2300 words is not particularly large for a help file?
That's now long Tcl's info help is. I don't think any Pd help patch has anywhere close to 2300 words.
wc -w "#convolve-help.pd" says 3086, but counting only the contents of the comments, it's 1596. To be fair, however, you have to count the code examples, and doc elements that aren't plain comments, so it's probably closer to 2000.
http://gridflow.ca/help/%23convolve-help.html
But that's because it contains a whole tutorial, too. Otherwise, the design of the thing is quite simple.
I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 560000 words and doesn't even come with a Ctrl+f feature.
Did you make a bug report?
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-18 à 13:43:00, Jonathan Wilkes a écrit :
From: Mathieu Bouchard matju@artengine.ca
I don't think that 2300 words (or 3600 words for more recent docs) is that large. A hardcopy of a successful book such as Tolstoï's War and Peace has 560000 words and doesn't even come with a Ctrl+f feature.
Did you make a bug report?
No, because the book actually works. No-one complains about it.
Well, except Charlie Brown.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit :
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;)
try again.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
I'm with Hans -- e.g., 'list' where there's a whole slew of functionalities masquerading as a single class (and sharing a help file), but in which you only need one object for each type of use, e.g., "list nth".
cheers M
On Fri, Nov 18, 2011 at 01:23:12PM -0500, Mathieu Bouchard wrote:
Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit :
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;)
try again.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-18 19:43, Miller Puckette wrote:
I'm with Hans -- e.g., 'list' where there's a whole slew of functionalities masquerading as a single class (and sharing a help file), but in which you only need one object for each type of use, e.g., "list nth".
while i'm all for "one objectclass per functionality", and for establishing a single idiom (at least, per "objectclass family") - and thus think i'm with hans also, i still don't see any point in "masquerading as a single class".
what makes the name [list foo] any better than [listfoo]?
objects with "proper" names - that don't involve "mummmers" - can still share the same help-patch (if needed).
mfgasdr IOhannes
Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit :
while i'm all for "one objectclass per functionality", and for establishing a single idiom (at least, per "objectclass family") - and thus think i'm with hans also, i still don't see any point in "masquerading as a single class". what makes the name [list foo] any better than [listfoo]?
It's a form of namespacing.
Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas.
objects with "proper" names - that don't involve "mummmers" - can still share the same help-patch (if needed).
(What are you talking about ?)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-list@iem.at Sent: Monday, November 21, 2011 3:02 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit :
while i'm all for "one objectclass per functionality", and
for
establishing a single idiom (at least, per "objectclass family")
- and
thus think i'm with hans also, i still don't see any point in "masquerading as a single class". what makes the name [list foo] any better than [listfoo]?
Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers.
Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch.
It's a form of namespacing.
Hyphens work, too, but two words against each other are less readable.
-Jonathan
Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas.
objects with "proper" names - that don't involve
"mummmers" - can still
share the same help-patch (if needed).
(What are you talking about ?)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-21 à 12:35:00, Jonathan Wilkes a écrit :
Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers.
Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch.
http://upload.wikimedia.org/wikipedia/commons/f/fe/Codex_Sinaiticus_Paralipo...
http://en.wikipedia.org/wiki/Scriptio_continua
Hyphens work, too, but two words against each other are less readable.
I really meant to compare «namespacing» with whichever form of single-symbol name compares more favourably, which is often not the one without a delimiter.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-21 21:35, Jonathan Wilkes wrote:
what makes the name [list foo] any better than [listfoo]?
Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers.
Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch.
i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world.
for unknown reasons, it seems that [text file] seems to work for lots of people.
It's a form of namespacing.
and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator.
i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens.
Hyphens work, too, but two words against each other are less readable.
i'm fine with hyphen, underscore, CamelCase. i just don't like space.
fgmasdr IOhannes
Le 2011-11-21 à 22:09:00, IOhannes m zmoelnig a écrit :
and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator.
It's good if you want to implement the new functionality as one big class while pretending that it's many small classes to people who want that ;)
i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens.
Tcl has two different namespace mechanisms, the ::-separated one, called «namespaces» actually were introduced after the space-separated one, which is called «ensembles» nowadays. Space is also a token-separator in Tcl, and this makes the function name be the first argument of the call to the ensemble that is posing as a function. That's just like in Pd. I think Tcl has had that for about 20 years.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: IOhannes m zmoelnig zmoelnig@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; "pd-list@iem.at" pd-list@iem.at Sent: Monday, November 21, 2011 4:09 PM Subject: Re: [PD] "get" method for Pd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-21 21:35, Jonathan Wilkes wrote:
what makes the name [list foo] any better than [listfoo]?
Yeahreallythey'rebothequallyclearespeciallyformusicianswhoaren'tprogrammers.
Justlikereadingamusicscore--whitespacedoesn'taffectreadabilitythatmuch.
i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world.
English speakers don't live in the real world?
-Jonathan
for unknown reasons, it seems that [text file] seems to work for lots of people.
It's a form of namespacing.
and i argue that it's a bad idea to introduce whitespace as namespace delimiter in a language that already uses whitespace as token/atom separator.
i cannot remember any other complang, that uses whitespace as namespace delimiter, most likely because virtually all languages already use whitespace to separate tokens.
Hyphens work, too, but two words against each other are less readable.
i'm fine with hyphen, underscore, CamelCase. i just don't like space.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7Kve8ACgkQkX2Xpv6ydvRP6ACgq0ROp6mYOhJV4ufpU+2UwVG+ DLgAn3wRvqLMLqY0MbAv9AOKUa9Hydmr =COwq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-21 23:05, Jonathan Wilkes wrote:
i don't know. my native language allows construction of compound words, and while this seems ridiculous to many english speakers, it's not that it makes a lot of problems in real world.
English speakers don't live in the real world?
english speakers usually don't encounter these "compound words" since they (the words) are not used in their (the people's) everyday life. thus i assumed that these compound words do not impose any problems for those people (unless they are communicating with germans that keep glueing words together)
german speakers have to deal with these words on a day by day basis, and for them it usually does not make a lot of problems in their real world.
fmgar IOhannes
Le 2011-11-21 à 23:33:00, IOhannes m zmoelnig a écrit :
On 2011-11-21 23:05, Jonathan Wilkes wrote:
English speakers don't live in the real world?
english speakers usually don't encounter these "compound words" since they (the words) are not used in their (the people's) everyday life.
« communication » comes from « communicate », which comes from « common ».
Well, actually, it's more like it came from latin « commūnicātiōnem », which came from « commūnicāre », which came from « commūnis », but my point is about suffix aggregation.
For « compound » and « component », however, it comes from com- (together) and -ponere (to put).
This is actually copy-paste from several wiktionary pages (I don't know any latin !).
thus i assumed that these compound words do not impose any problems for those people (unless they are communicating with germans that keep glueing words together)
assumed = ad+sūmō+ed ; impose = in+ponere ; problem = pro+ballo (before several mutations) ; unless = un+less ; glueing = glue+ing ; together = to+gether (with various old spellings) ;
german speakers have to deal with these words on a day by day basis, and for them it usually does not make a lot of problems in their real world.
usual+ly
-----BEGIN PGP SIGNATURE-----
sign+ature
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Monday, November 21, 2011 3:02 PM, "Mathieu Bouchard" matju@artengine.ca wrote:
Le 2011-11-21 à 12:58:00, IOhannes m zmoelnig a écrit :
while i'm all for "one objectclass per functionality", and for establishing a single idiom (at least, per "objectclass family") - and thus think i'm with hans also, i still don't see any point in "masquerading as a single class". what makes the name [list foo] any better than [listfoo]?
It's a form of namespacing.
Ask Hans what makes the name ::pdtk_canvas::pdtk_canvas_popup any better than just pdtk_canvas_popup... I don't get it either, and on top of that, I don't get the point of the the repetitive repetition of of pdtk_canvas pdtk_canvas.
pdtk_canvas is the new namespace, and pdtk_canvas_popup is the legacy name. Remember, part of the mandate of the pd-gui rewrite was not changing the C code. Therefore not everything could be renamed.
.hc
objects with "proper" names - that don't involve "mummmers" - can still share the same help-patch (if needed).
(What are you talking about ?)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 18, 2011, at 1:23 PM, Mathieu Bouchard wrote:
Le 2011-11-17 à 21:17:00, Hans-Christoph Steiner a écrit :
The last sentence is the key there. They should not all do these things in their own disparate ways. If the objects stick to common, well-established idioms, then all these objects will be easy use. Just imagine the help patch of an [info] object with so many messages vs the help patch for each object and its specific task.
Yes, it's much more convenient to open 20 tiny help patches to have an overview, then have to open 1 big help patch that contains all of the info in one place... ;)
try again.
I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this.
.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
Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit :
I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this.
Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces.
try again.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 18, 2011, at 2:06 PM, Mathieu Bouchard wrote:
Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit :
I guess you haven't seen the all_about_ patches, you can have one of those for the unified overview. Then have each object's help patch link to this.
Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces.
Why on earth would you do that? That would be a worthless exercise. The point is to have overview content, quick reference content, and learning content. These are all separate things.
.hc
kill your television
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 2:06 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-18 à 14:00:00, Hans-Christoph Steiner a écrit :
I guess you haven't seen the all_about_ patches, you can have one of
those for the unified overview. Then have each object's help patch link to this.
Bingo ! Now you need to write every piece of documentation twice : once in each separate help file, and copy-paste into the big overview that you need only because you cut things into tiny pieces.
try again.
Please use telepathy to let me know the places where I have the same material in the object help and pasted it to all_about_*. I will then try to remove it from the object help and just make a reference to the all_about_* with pddp/pddplink so that the info is only in one place.
However I should warn you that I will travel to the past to make the revisions in a cruel attempt to make it look like you didn't actually read any of the all_about_* patches in the first place.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-18 à 11:37:00, Jonathan Wilkes a écrit :
Please use telepathy to let me know the places where I have the same material in the object help and pasted it to all_about_*.
I'm not even talking about the existing ones.
However I should warn you that I will travel to the past to make the revisions in a cruel attempt to make it look like you didn't actually read any of the all_about_* patches in the first place.
I didn't even have to travel back to the past to make you look like you didn't read my mail.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-17 à 14:40:00, Jonathan Wilkes a écrit :
efficient but extremely weird and difficult to read (just have a look at the innards of [listabs/list-drip] for example).
BTW, the one nowadays in listabs is the simplest of the fast [list-drip] implementations. The faster ones are more complex, but they're all based on the one bundled in listabs.
None of them are nearly as fast as [foreach] though. The gap widened in GridFlow 9.13 and 9.14, when the C++-wrapper used by GridFlow became much more efficient. A plain C version of [foreach] might still be a tiny bit faster, but I don't know.
Yet it's better to have the core list classes plus a library of abstractions-- listabs-- that hides the ugliness necessary to get decent list processing to happen in Pd, than to not have the list classes at all.
It's always better to be in big trouble than in any trouble bigger than it.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi all, i can't read in detail the whole thread, but just a remark:
I think what you have in mind is close to the idea of patcher
attributes in Max, where you'd have a [pattrhub] object in the
abstraction and you can either ask it for built-in object attributes
or [pattr] patcher variables.
I implemented a similar idea already some years ago with the [absattr]
object, which was extensively used in the vibrez project. It connect
to the concept of flext-style attributes. It's here:
https://svn.grrrr.org/ext/trunk/absattr
gr~~~
Am 17.11.2011 um 19:42 schrieb Miller Puckette:
This leads to an interesting larger design issue. I've so far
resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The
other way, assuming you want locality, would be to confect a unique symbol
name and then somehow to "receive" it (I'm not even sure that's possible
without making a self-editing patch).But there are other situation which seem to beg for the "receive"
solution. For example you have a complicated object like textfile and you just
want to query it as to how many lines it has.although it's migraine-inducing, the neatest solution would be to
allow "info" style objects to have a right-hand outlet that you connect
to, say, the "textfile" object like so:[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower textfile
object). I think Krzystof Chaya did something like this in his wonderful "xeq"
object (first Pd convention, Graz.)cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner
wrote:I like "info" too, maybe [pd info(. I like Jonathan's ordering
because it also makes it easy to have a default receive symbol, so :[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd- gui' receive listener, so you direct GUI-related stuff to [send pd- gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just
"info". It could get and/or set info about the canvas it's in as well as
about other canvases (by name) and Pd globally.cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote:
Hello, would this method provide patch window size and position?
[; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get
<rcvname> ..." is better than "get <verb> <rcvname>"but of course jonathan and roman are right when they say that
this is not something you would ask "pd" about.fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker
ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
.hc
On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote:
Hi all, i can't read in detail the whole thread, but just a remark:
I think what you have in mind is close to the idea of patcher attributes in Max, where you'd have a [pattrhub] object in the abstraction and you can either ask it for built-in object attributes or [pattr] patcher variables.
I implemented a similar idea already some years ago with the [absattr] object, which was extensively used in the vibrez project. It connect to the concept of flext-style attributes. It's here: https://svn.grrrr.org/ext/trunk/absattr
gr~~~ <Bild 2.png>
Am 17.11.2011 um 19:42 schrieb Miller Puckette:
This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to "receive" it (I'm not even sure that's possible without making a self-editing patch).
But there are other situation which seem to beg for the "receive" solution. For example you have a complicated object like textfile and you just want to query it as to how many lines it has.
although it's migraine-inducing, the neatest solution would be to allow "info" style objects to have a right-hand outlet that you connect to, say, the "textfile" object like so:
[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower textfile object). I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote:
I like "info" too, maybe [pd info(. I like Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for something else but I agree this should be an object, maybe 'get-info" or even just "info". It could get and/or set info about the canvas it's in as well as about other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote:
On 2011-11-17 14:53, Patrice Colet wrote: > Hello, > would this method provide patch window size and position?
> [; pd get size pd-mpatch.pd rcv_name( > [; pd get pos pd-mpatch.pd rcv_name(
now we are getting close to why i think using "get <rcvname> ..." is better than "get <verb> <rcvname>"
but of course jonathan and roman are right when they say that this is not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Thomas Grill gr@grrrr.org Cc: pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 10:16 AM Subject: Re: [PD] "get" method for Pd
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all.
What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s).
For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever message. One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
- clear syntax that can be extended to other areas of pd. I like the "get $something" syntax
because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.)
- for canvases, the user must be able to make a distinction between "this local canvas" and
"all canvases that have this receive symbol". (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with "pd-".) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants.
My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable. If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c.
-Jonathan
.hc
On Nov 18, 2011, at 5:17 AM, Thomas Grill wrote:
Hi all, i can't read in detail the whole thread, but just a remark:
I think what you have in mind is close to the idea of patcher attributes in
Max, where you'd have a [pattrhub] object in the abstraction and you can either ask it for built-in object attributes or [pattr] patcher variables.
I implemented a similar idea already some years ago with the [absattr]
object, which was extensively used in the vibrez project. It connect to the concept of flext-style attributes. It's here:
https://svn.grrrr.org/ext/trunk/absattr
gr~~~ <Bild 2.png>
Am 17.11.2011 um 19:42 schrieb Miller Puckette:
This leads to an interesting larger design issue. I've so far
resisted
the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch. So, for instance, samplerate~ just puts the sample rate on its outlet. The
other
way, assuming you want locality, would be to confect a unique symbol
name
and then somehow to "receive" it (I'm not even sure
that's possible without
making a self-editing patch).
But there are other situation which seem to beg for the
"receive" solution.
For example you have a complicated object like textfile and you just
want to
query it as to how many lines it has.
although it's migraine-inducing, the neatest solution would be to
allow
"info" style objects to have a right-hand outlet that you
connect to, say,
the "textfile" object like so:
[get linecount( | | [textfile -reference] | | | [textfile] V [15<
(where "15" would be the number of lines in the lower
textfile object). I
think Krzystof Chaya did something like this in his wonderful
"xeq" object
(first Pd convention, Graz.)
cheers Miller
On Thu, Nov 17, 2011 at 01:01:50PM -0500, Hans-Christoph Steiner wrote:
I like "info" too, maybe [pd info(. I like
Jonathan's ordering because it also makes it easy to have a default receive symbol, so :
[;pd info(
would dump all the info to:
[receive pd] | [route info]
Then you could also specify specific things to request:
[; pd info dsp(
would dump:
[receive pd] | [route info] | [route dsp]
As for GUI-related things, I think 'pd-gui' should have its
own 'pd-gui' receive listener, so you direct GUI-related stuff to [send pd-gui].
.hc
On Nov 17, 2011, at 12:13 PM, Miller Puckette wrote:
Unfortunately I already used the name "get" for
something else but I
agree this should be an object, maybe 'get-info" or
even just "info".
It could get and/or set info about the canvas it's in as
well as about
other canvases (by name) and Pd globally.
cheers Miller
On Thu, Nov 17, 2011 at 03:12:08PM +0100, IOhannes m zmoelnig
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-17 15:09, IOhannes m zmoelnig wrote: > On 2011-11-17 14:53, Patrice Colet wrote: >> Hello, >> would this method provide patch window size and
position?
> >> [; pd get size pd-mpatch.pd rcv_name( >> [; pd get pos pd-mpatch.pd rcv_name( > > now we are getting close to why i think using "get
<rcvname> ..." is
> better than "get <verb>
<rcvname>"
but of course jonathan and roman are right when they say
that this is
not something you would ask "pd" about.
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla -
iEYEARECAAYFAk7FFjgACgkQkX2Xpv6ydvRjGACeKhVGEDtrXIhGi3tZlmLBpVYx
nkwAn1JsM8C6tVj95ZTHCAAhbz0d7A1z =XrRZ -----END PGP SIGNATURE-----
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
Access to computers should be unlimited and total. - the hacker
ethic
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used [absattr] for the @key value syntax when it was sitting in a previous version of pd extended but that's all.
What I'm really after are some simple, core features that allow the user to access simple, core data about the pd instance and canvas instance(s).
For the pd instance the most obvious starting point is the version-- the simplest way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this approach for readability reasons, so if there's a better approach I'd be interested in hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever message. One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best approach. Why don't you like it? I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
- clear syntax that can be extended to other areas of pd. I like the "get $something" syntax
because one could also use it for getting data from the inlet of an object and outputting it to a subsidiary outlet. (Other selectors could be used-- that's just my example.)
Having individual objects means the most minimal and Pd-ish syntax:
[bang( | [nogui] | [1(
- for canvases, the user must be able to make a distinction between "this local canvas" and
"all canvases that have this receive symbol". (This is why [namecanvas] isn't obsoleted by sending to an abstraction's filename prefixed with "pd-".) The only ways I've seen to do this are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with the send-window method of [pointer]. Using either to query/receive canvas attributes will be wireless, which evidently isn't what Miller wants.
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send.
My idea is to have the pd community build abstractions around whatever way these features get implemented. Even if one method of getting the core functionality isn't the most readable, it can be wrapped in an abstraction that has an inlet and an outlet to make it more readable.
If changes to the core functionality need to be made at a later date then the innards of the abstraction can be modified to fit those revisions without the abstraction's interface being affected. This way you open up development of these interfaces to the entire Pd userbase, rather than just people who can code in c.
I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib.
.hc
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] "get" method for Pd
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
This is more like iemguts: properties of abstractions. Jonathan's
proposal
includes that, but also global things. IMHO, iemguts is the most
Pd-ish because
its a library of simple objects rather than a single absattr
mega-object with
attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used [absattr]
for the @key value
syntax when it was sitting in a previous version of pd extended but
that's all.
What I'm really after are some simple, core features that allow the
user to
access simple, core data about the pd instance and canvas instance(s).
For the pd instance the most obvious starting point is the version-- the
simplest
way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this
approach
for readability reasons, so if there's a better approach I'd be
interested in
hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever message.
One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best approach. Why don't you like it?
Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain.
I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between "list" and "bang" to trigger different behavior, and the level for [sendcanvas] isn't settable.
-Jonathan
- clear syntax that can be extended to other areas of pd. I like the
"get $something" syntax
because one could also use it for getting data from the inlet of an object
and outputting it
to a subsidiary outlet. (Other selectors could be used-- that's just
my example.)
Having individual objects means the most minimal and Pd-ish syntax:
[bang( | [nogui] | [1(
- for canvases, the user must be able to make a distinction between
"this local canvas" and
"all canvases that have this receive symbol". (This is why
[namecanvas] isn't obsoleted by
sending to an abstraction's filename prefixed with "pd-".)
The only ways I've seen to do this
are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with
the send-window
method of [pointer]. Using either to query/receive canvas attributes will
be wireless, which
evidently isn't what Miller wants.
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send.
My idea is to have the pd community build abstractions around whatever way
these features
get implemented. Even if one method of getting the core functionality
isn't the most readable,
it can be wrapped in an abstraction that has an inlet and an outlet to make
it more readable.
If changes to the core functionality need to be made at a later date then
the innards of the
abstraction can be modified to fit those revisions without the
abstraction's interface being
affected. This way you open up development of these interfaces to the
entire Pd userbase,
rather than just people who can code in c.
I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas (posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib.
.hc
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] "get" method for Pd
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
This is more like iemguts: properties of abstractions. Jonathan's
proposal
includes that, but also global things. IMHO, iemguts is the most
Pd-ish because
its a library of simple objects rather than a single absattr
mega-object with
attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used [absattr]
for the @key value
syntax when it was sitting in a previous version of pd extended but
that's all.
What I'm really after are some simple, core features that allow the
user to
access simple, core data about the pd instance and canvas instance(s).
For the pd instance the most obvious starting point is the version-- the
simplest
way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this
approach
for readability reasons, so if there's a better approach I'd be
interested in
hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever message.
One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best approach. Why don't you like it?
Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.] connected to however many message boxes, it's a lot of patching work to do something very simple. So if I had a patch that needed many of your objects above, it's a pain.
I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches.
I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
I'm not wild about the interface of some of the iemguts objects-- one of them differentiates between "list" and "bang" to trigger different behavior, and the level for [sendcanvas] isn't settable.
Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang? That can make sense depending on the context.
.hc
-Jonathan
- clear syntax that can be extended to other areas of pd. I like the
"get $something" syntax
because one could also use it for getting data from the inlet of an object
and outputting it
to a subsidiary outlet. (Other selectors could be used-- that's just
my example.)
Having individual objects means the most minimal and Pd-ish syntax:
[bang( | [nogui] | [1(
- for canvases, the user must be able to make a distinction between
"this local canvas" and
"all canvases that have this receive symbol". (This is why
[namecanvas] isn't obsoleted by
sending to an abstraction's filename prefixed with "pd-".)
The only ways I've seen to do this
are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using gpointers with
the send-window
method of [pointer]. Using either to query/receive canvas attributes will
be wireless, which
evidently isn't what Miller wants.
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send.
My idea is to have the pd community build abstractions around whatever way
these features
get implemented. Even if one method of getting the core functionality
isn't the most readable,
it can be wrapped in an abstraction that has an inlet and an outlet to make
it more readable.
If changes to the core functionality need to be made at a later date then
the innards of the
abstraction can be modified to fit those revisions without the
abstraction's interface being
affected. This way you open up development of these interfaces to the
entire Pd userbase,
rather than just people who can code in c.
I think we all agree on the end goal here. It sounds there are two things here: iemguts-like functionality for interacting with the patch's t_canvas
(posonparent, parent, coords, etc.) and getting info from the global (nogui, version, rtflag, etc.). For things about interacting with the t_canvas that are missing from iemguts, I think they should be added to iemguts. Then for global things, we can start a new lib..hc
"Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder." - Chris McCormick
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
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 3:34 PM Subject: Re: [PD] "get" method for Pd
On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at"
pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at
Sent: Friday, November 18, 2011 1:33 PM Subject: Re: [PD] "get" method for Pd
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
This is more like iemguts: properties of abstractions.
Jonathan's
proposal
includes that, but also global things. IMHO, iemguts is the
most
Pd-ish because
its a library of simple objects rather than a single absattr
mega-object with
attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used
[absattr]
for the @key value
syntax when it was sitting in a previous version of pd extended but
that's all.
What I'm really after are some simple, core features that allow
the
user to
access simple, core data about the pd instance and canvas
instance(s).
For the pd instance the most obvious starting point is the
version-- the
simplest
way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this
approach
for readability reasons, so if there's a better approach
I'd be
interested in
hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever
message.
One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best
approach. Why
don't you like it?
Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.]
connected
to however many message boxes, it's a lot of patching work to do
something
very simple. So if I had a patch that needed many of your objects above, it's a pain.
I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches.
I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
I'm not wild about the interface of some of the iemguts objects-- one
of them
differentiates between "list" and "bang" to trigger
different behavior, and
the level for [sendcanvas] isn't settable.
Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang?
canvasargs I think.
That can make sense depending on the context.
Name another object in the history of Pd that (purposefully) does that.
-Jonathan
.hc
-Jonathan
- clear syntax that can be extended to other areas of pd. I like
the
"get $something" syntax
because one could also use it for getting data from the inlet of an
object
and outputting it
to a subsidiary outlet. (Other selectors could be used--
that's just
my example.)
Having individual objects means the most minimal and Pd-ish syntax:
[bang( | [nogui] | [1(
- for canvases, the user must be able to make a distinction between
"this local canvas" and
"all canvases that have this receive symbol". (This is
why
[namecanvas] isn't obsoleted by
sending to an abstraction's filename prefixed with
"pd-".)
The only ways I've seen to do this
are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using
gpointers with
the send-window
method of [pointer]. Using either to query/receive canvas
attributes will
be wireless, which
evidently isn't what Miller wants.
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas]
with an
inlet for the receive and an outlet for the send.
My idea is to have the pd community build abstractions around
whatever way
these features
get implemented. Even if one method of getting the core
functionality
isn't the most readable,
it can be wrapped in an abstraction that has an inlet and an outlet
to make
it more readable.
If changes to the core functionality need to be made at a later
date then
the innards of the
abstraction can be modified to fit those revisions without the
abstraction's interface being
affected. This way you open up development of these interfaces to
the
entire Pd userbase,
rather than just people who can code in c.
I think we all agree on the end goal here. It sounds there are two
things here:
iemguts-like functionality for interacting with the patch's
t_canvas
(posonparent, parent, coords, etc.) and getting info from the global
(nogui,
version, rtflag, etc.). For things about interacting with the t_canvas
that are
missing from iemguts, I think they should be added to iemguts. Then
for global
things, we can start a new lib.
.hc
"Making boring techno music is really easy with modern tools, but
with live
coding, boring techno is much harder." - Chris McCormick
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 Nov 18, 2011, at 3:44 PM, Jonathan Wilkes wrote:
On Nov 18, 2011, at 2:58 PM, Jonathan Wilkes wrote:
On Nov 18, 2011, at 11:53 AM, Jonathan Wilkes wrote:
This is more like iemguts: properties of abstractions.
Jonathan's
proposal
includes that, but also global things. IMHO, iemguts is the
most
Pd-ish because
its a library of simple objects rather than a single absattr
mega-object with
attributes (Max/MSP style) or messages via send/receive.
The max [pattrhub] object isn't what I'm after. I used
[absattr]
for the @key value
syntax when it was sitting in a previous version of pd extended but
that's all.
What I'm really after are some simple, core features that allow
the
user to
access simple, core data about the pd instance and canvas
instance(s).
For the pd instance the most obvious starting point is the
version-- the
simplest
way is what I proposed about sending a query to the pd and getting a response with a [receive pd]. Miller wants to avoid this
approach
for readability reasons, so if there's a better approach
I'd be
interested in
hearing it. At the least it should have these features:
- ability to return all data with a single bang/get/whatever
message.
One-object-per-datum
like [version], [rtflag], [nogui], etc. isn't optimal.
I think having individual objects that are bangable is the best
approach. Why
don't you like it?
Because if you want to get n data about pd (or from a canvas) you have to have n objects. One of my biggest pains in Pd comes when I need to map keys to, say, midi numbers-- if you use [route 32 12 56 32 etc.]
connected
to however many message boxes, it's a lot of patching work to do
something
very simple. So if I had a patch that needed many of your objects above, it's a pain.
I don't see how typing the message boxes for the send/receive approach is really much less typing and patching than the single object approach. And it does make the patch a lot more readable. As for your [route] example, that doesn't quite seem related. You can also do programmatic matching using [select], and other approaches.
I'm just about done with a [canvasvisible] object for iemguts to illustrate this idea.
I'm not wild about the interface of some of the iemguts objects-- one
of them
differentiates between "list" and "bang" to trigger
different behavior, and
the level for [sendcanvas] isn't settable.
Yes the depth should be settable, that should be possible to add, not a lot of work. Which differentiates between list and bang?
canvasargs I think.
That can make sense depending on the context.
Name another object in the history of Pd that (purposefully) does that.
I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result.
.hc
-Jonathan
.hc
-Jonathan
- clear syntax that can be extended to other areas of pd. I like
the
"get $something" syntax
because one could also use it for getting data from the inlet of an
object
and outputting it
to a subsidiary outlet. (Other selectors could be used--
that's just
my example.)
Having individual objects means the most minimal and Pd-ish syntax:
[bang( | [nogui] | [1(
- for canvases, the user must be able to make a distinction between
"this local canvas" and
"all canvases that have this receive symbol". (This is
why
[namecanvas] isn't obsoleted by
sending to an abstraction's filename prefixed with
"pd-".)
The only ways I've seen to do this
are [iemguts/sendcanvas] / [iemguts/receivecanvas] and using
gpointers with
the send-window
method of [pointer]. Using either to query/receive canvas
attributes will
be wireless, which
evidently isn't what Miller wants.
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas]
with an
inlet for the receive and an outlet for the send.
My idea is to have the pd community build abstractions around
whatever way
these features
get implemented. Even if one method of getting the core
functionality
isn't the most readable,
it can be wrapped in an abstraction that has an inlet and an outlet
to make
it more readable.
If changes to the core functionality need to be made at a later
date then
the innards of the
abstraction can be modified to fit those revisions without the
abstraction's interface being
affected. This way you open up development of these interfaces to
the
entire Pd userbase,
rather than just people who can code in c.
I think we all agree on the end goal here. It sounds there are two
things here:
iemguts-like functionality for interacting with the patch's
t_canvas
(posonparent, parent, coords, etc.) and getting info from the global
(nogui,
version, rtflag, etc.). For things about interacting with the t_canvas
that are
missing from iemguts, I think they should be added to iemguts. Then
for global
things, we can start a new lib.
.hc
"Making boring techno music is really easy with modern tools, but
with live
coding, boring techno is much harder." - Chris McCormick
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
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Le 2011-11-18 à 16:02:00, Hans-Christoph Steiner a écrit :
I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result.
Read it as « a bang or an empty list ».
The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 18, 2011, at 4:55 PM, Mathieu Bouchard wrote:
Le 2011-11-18 à 16:02:00, Hans-Christoph Steiner a écrit :
I don't really see what you mean in canvasargs. [+] behaves differently when given a bang or a list. Bang outputs the current result again, and a list of two numbers sets two new values to add and outputs the result.
Read it as « a bang or an empty list ».
The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't.
Hmm, I think it really the opposite, an empty list is cast as a bang. That's how its generally implemented anyway.
.hc
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Le 2011-11-18 à 16:57:00, Hans-Christoph Steiner a écrit :
On Nov 18, 2011, at 4:55 PM, Mathieu Bouchard wrote:
Read it as « a bang or an empty list ». The bang is cast to an empty-list in a context where a list-method is defined but a bang-method isn't.
Hmm, I think it really the opposite, an empty list is cast as a bang. That's how its generally implemented anyway.
pd_defaultbang() casts bang to list when there is no bang-method.
pd_defaultlist() casts list to bang wheh there is no list-method and the list has 0 arguments (otherwise it casts to something else or tries to auto-unpack)
So, it's really both, but at least I didn't claim that there was only one converter.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-18 à 12:44:00, Jonathan Wilkes a écrit :
Name another object in the history of Pd that (purposefully) does that.
http://gridflow.ca/help/gf/selector-help.html
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; Thomas Grill gr@grrrr.org; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 4:06 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-18 à 12:44:00, Jonathan Wilkes a écrit :
Name another object in the history of Pd that (purposefully) does that.
Dammit! I overplayed my hand.
Ok, so you have an object to report the actual selector getting passed around in Pd, which obviously differentiates between between "list" and "bang".
So-- name two!*
- doesn't include any externals like selector that suffer from pd-dev reverb, which is the
phenomena of missing features in the core being reflected in multiple externals by different authors which all do essentially the same thing.
-Jonathan
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-18 à 13:42:00, Jonathan Wilkes a écrit :
So-- name two!*
Any grid-processing inlet does distinguish between float and list, though the object they're on might not always use the difference. But that's not the same as making a difference between bang and list, which is more rare. Let me think some more.
...
Actually, in the help of [gf/selector], it says « unlike [route] ». Well, GridFlow has two [route]-like classes that don't behave like [route] :
http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html
So I just named two more. They're acknowledging the concept of [route] while working around certain problems that either needs a lot of repetitive solving or that just can't be worked around without externals. That way you have short AND clean ways of using [route].
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; Thomas Grill gr@grrrr.org; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 4:53 PM Subject: Re: [PD] "get" method for Pd
Le 2011-11-18 à 13:42:00, Jonathan Wilkes a écrit :
So-- name two!*
Any grid-processing inlet does distinguish between float and list, though the object they're on might not always use the difference. But that's not the same as making a difference between bang and list, which is more rare. Let me think some more.
...
Actually, in the help of [gf/selector], it says « unlike [route] ». Well, GridFlow has two [route]-like classes that don't behave like [route] :
http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html
So I just named two more.
What are the contexts where you have used either of these to differentiate between a bang and an empty list?
-Jonathan
They're acknowledging the concept of [route] while working around certain problems that either needs a lot of repetitive solving or that just can't be worked around without externals. That way you have short AND clean ways of using [route].
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-11-18 à 14:22:00, Jonathan Wilkes a écrit :
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca http://gridflow.ca/help/route2-help.html http://gridflow.ca/help/route3-help.html So I just named two more.
What are the contexts where you have used either of these to differentiate between a bang and an empty list?
Oh. I haven't. The workarounds I'm talking about are actually about [route] potentially producing anythings when you either wanted the message as-is or just with the selector replaced by «list» ; and the problem in which «list 42» is undistinguishable from «list list 42», or something like that.
The fact that it doesn't try to fudge the selector, was because anything-methods don't do this automatically and I wasn't concerned with that problem.
BTW, GridFlow used to distinguish between bang and list in a lot more places, but that was a design mistake (and/or a lingering jMaxism ?) which got fixed as recently as 9.11.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-18 21:44, Jonathan Wilkes wrote:
work. Which differentiates between list and bang?
canvasargs I think.
has that ever created a problem for you, or is your complaint purely academic?
would it help you, if there was a [set( message that would do the same thing as the current [list(?
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-18 21:34, Hans-Christoph Steiner wrote:
Yes the depth should be settable, that should be possible to add, not a lot of work.
it probably should be settable.
however, i never encountered a real need for that, that's why it's not there.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-18 19:33, Hans-Christoph Steiner wrote:
You could combine [sendcanvas] and [receivecanvas] into [thiscanvas] with an inlet for the receive and an outlet for the send.
you could even do this as an abstraction.
fgmasdr IOhannes
So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts.
https://github.com/pd-projects/info
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 7:19 PM Subject: Re: [PD] "get" method for Pd
So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts.
How do they get from iemguts to core pd?
https://github.com/pd-projects/info
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Nov 18, 2011, at 9:58 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Thomas Grill gr@grrrr.org; "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu; IOhannes m zmoelnig zmoelnig@iem.at Sent: Friday, November 18, 2011 7:19 PM Subject: Re: [PD] "get" method for Pd
So here is two quick sketches of ideas for objects related to this: [coords] and [canvasvisible]. coords you can already get from iemguts, and I'm planning on submitting [canvasvisible] for inclusion in iemguts.
How do they get from iemguts to core pd?
I don't see a need to do that, so that's a question for someone else to answer.
.hc
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Le 2011-11-18 à 10:16:00, Hans-Christoph Steiner a écrit :
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
Is the goal to make pd easier to use for complex problems, or is the goal to create lots of tiny classes for the sake of ideology ?
I don't mind small classes and I do have problems with certain huge classes being huge (in Max) and bundling lots of things that they could outsource, but [absattr-sub] doesn't look like one.
Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 18, 2011, at 1:01 PM, Mathieu Bouchard wrote:
Le 2011-11-18 à 10:16:00, Hans-Christoph Steiner a écrit :
This is more like iemguts: properties of abstractions. Jonathan's proposal includes that, but also global things. IMHO, iemguts is the most Pd-ish because its a library of simple objects rather than a single absattr mega-object with attributes (Max/MSP style) or messages via send/receive.
Is the goal to make pd easier to use for complex problems, or is the goal to create lots of tiny classes for the sake of ideology ?
I don't mind small classes and I do have problems with certain huge classes being huge (in Max) and bundling lots of things that they could outsource, but [absattr-sub] doesn't look like one.
Obviously, there are objects that are too simple just as there are objects that are too complex. One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc..
So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list. Its easy when its divided in the right way. Take canvas visibility. If this is its own [canvasvisible] object, then [bang( means get the value and [float 1( means set the value. Then on the output we receive a float representing the visibility.
Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax.
I am fine with expr since I can also use [*] [+] [-] [/], etc.
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Le 2011-11-18 à 14:20:00, Hans-Christoph Steiner a écrit :
Obviously, there are objects that are too simple just as there are objects that are too complex.
ok.
One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc..
What's not a built-in atom type in there ? [textfile], [comport] and [hid] only use built-in atom types. If you mean messages that are not anythings, then you have to know that bangs and lists are not atoms, they're messages (but list elements are atoms, selectors are symbols, etc).
But I don't know why you consider this to be valuable, nor why you didn't talk about it in the last ten years or so, nor why nobody else ever did.
So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list.
You made up the previous principle so that you could promote a design that wouldn't otherwise have an advantage of its own.
Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax.
I am fine with expr since I can also use [*] [+] [-] [/], etc.
That is not an answer to my question.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Nov 18, 2011, at 3:50 PM, Mathieu Bouchard wrote:
Le 2011-11-18 à 14:20:00, Hans-Christoph Steiner a écrit :
Obviously, there are objects that are too simple just as there are objects that are too complex.
ok.
One thing that I think is a valuable goal is making objects that do their thing only using the core atom types as input: bang, float, symbol, list (rather than [get blah( etc.) That's not always possible, like with [textfile], [comport], [hid], etc..
What's not a built-in atom type in there ? [textfile], [comport] and [hid] only use built-in atom types. If you mean messages that are not anythings, then you have to know that bangs and lists are not atoms, they're messages (but list elements are atoms, selectors are symbols, etc).
But I don't know why you consider this to be valuable, nor why you didn't talk about it in the last ten years or so, nor why nobody else ever did.
I don't really see a point in continuing this conversation when you consider whatever I write is all just whitewashing to further my secret agenda. I really have no secret agenda, and I'm just trying to communicate.
So we can take these concepts, like canvas properties and say: how can I do everything around canvas properties using only bang, float, symbol, list.
You made up the previous principle so that you could promote a design that wouldn't otherwise have an advantage of its own.
Why on earth would I do that?
.hc
Do you also think that [expr] should be avoided, for the sake of making simple objects ? [expr] is a complex thing with complex syntax.
I am fine with expr since I can also use [*] [+] [-] [/], etc.
That is not an answer to my question.
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
Le 2011-11-17 à 10:42:00, Miller Puckette a écrit :
This leads to an interesting larger design issue. I've so far resisted the idea of using send/receive as a back channel for getting return values because of the unreadablity of the resulting patch.
It doesn't have to be written as such in the patch. A send/receive pair can be bundled together as one object. It would solve a more general problem of making things more readable in pd which would reach beyond just [samplerate~] or queries to canvases.
A few convenient shortcuts are sometimes all it takes to make a big difference in readability. Trying to stick to a minimal set of basic constructs forces the user to do more work than what would be necessary.
The other way, assuming you want locality, would be to confect a unique symbol name and then somehow to "receive" it (I'm not even sure that's possible without making a self-editing patch).
Pd has a cool and very important feature named « abstractions », and using $0, you can create a unique receiver name without even having to think about it. No need for dynamic naming.
But if you want dynamic naming, there's [receives] with an s, which allows a single object to receive from many names at once and distinguish them while having always 2 outlets. You can use it with 1-element lists if you want. See this patch (screenshot) :
http://gridflow.ca/help/receives-help.html
BTW, [receives] was actually meant to manage large number of GUI objects matching attributes, method names, and a get-method, without making patches unreadable.
although it's migraine-inducing, the neatest solution would be to allow "info" style objects to have a right-hand outlet that you connect to, say, the "textfile" object like so:
You don't give any explanation of why you think it's migraine-inducing. I don't think that it's obvious why [get( and right-outlet could be more migraine-inducing than the average pd construct.
I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
I don't remember Czaja's talk in particular, but the idea must have been in the air back then. Flext 0.4 (nov 2002) introduced Jitter-style attributes in Pd, and I added my own kind of attributes in GridFlow in 2005 by introducing parsing of the comma in objectboxes so that attributes setters always counted as ordinary messages.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-18 18:49, Mathieu Bouchard wrote:
But if you want dynamic naming, there's [receives] with an s, which
there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name)
truct.
I think Krzystof Chaya did something like this in his wonderful "xeq" object (first Pd convention, Graz.)
I don't remember Czaja's talk in particular, but the idea must have been in the air back then. Flext 0.4 (nov 2002) introduced Jitter-style attributes in Pd, and I added my own kind of attributes in GridFlow in 2005 by introducing parsing of the comma in objectboxes so that attributes setters always counted as ordinary messages.
iirc, the xeq approach was more like having multiple objects connected via a "filehandle" like thing; so you could have an object that just opens the file, and another objects that would seek within that file.
fgmasdr IOhannes
Le 2011-11-21 à 09:56:00, IOhannes m zmoelnig a écrit :
On 2011-11-18 18:49, Mathieu Bouchard wrote:
But if you want dynamic naming, there's [receives] with an s, which
there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name)
Actually, it doesn't do the same.
But it's harder to do, because [multireceive] doesn't have a help file at all, whereas [receives] has http://gridflow.ca/help/receives-help.html
For the problem we were talking about, [multireceive] fits the problem more directly.
However, [receives] is more geared towards local receivers, with automatic joining of a prefix (such as «$0-») from receive-symbols.
The job that I do using [receives] (managing a lot of iemguis) would have taken many more objects if I had been trying to use [multireceive] instead.
With [receives], pd feels a lot more like it supports local-symbols.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-21 20:56, Mathieu Bouchard wrote:
Le 2011-11-21 à 09:56:00, IOhannes m zmoelnig a écrit :
On 2011-11-18 18:49, Mathieu Bouchard wrote:
But if you want dynamic naming, there's [receives] with an s, which
there's also zexy's [multireceive] which does probably the same (though i agree that [receives] is a very nice name)
Actually, it doesn't do the same.
But it's harder to do, because [multireceive] doesn't have a help file
true. thanks for going through the trouble to understand it.
at all, whereas [receives] has http://gridflow.ca/help/receives-help.html
after having a look, i see that [receives] is not such a good name as i initially thought.
gmsd IOhannes
Le 2011-11-21 à 21:12:00, IOhannes m zmoelnig a écrit :
On 2011-11-21 20:56, Mathieu Bouchard wrote:
at all, whereas [receives] has http://gridflow.ca/help/receives-help.html
after having a look, i see that [receives] is not such a good name as i initially thought.
Hahaha !
And don't care about explaining yourself, of course !
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-21 22:04, Mathieu Bouchard wrote:
Le 2011-11-21 à 21:12:00, IOhannes m zmoelnig a écrit :
On 2011-11-21 20:56, Mathieu Bouchard wrote:
at all, whereas [receives] has http://gridflow.ca/help/receives-help.html
after having a look, i see that [receives] is not such a good name as i initially thought.
Hahaha !
And don't care about explaining yourself, of course !
it wasn't meant to be offensive (in case you read it like that).
i think that [receives] is a great name for a "multiple receives" object.
however, i think that the "prefix" functionality of [receives] (which is very present, being the 1st argument) is a bit confusing in this context. for me, the name [receives] would be great, if you could use it without having to the prefix (and no, i don't think that using [loadbang]->[foo bar(" is a proper replacement, nor [recevies, foo bar])
fmgadsr IOhannes
Le 2011-11-21 à 22:15:00, IOhannes m zmoelnig a écrit :
however, i think that the "prefix" functionality of [receives] (which is very present, being the 1st argument) is a bit confusing in this context. for me, the name [receives] would be great, if you could use it without having to the prefix (and no, i don't think that using [loadbang]->[foo bar(" is a proper replacement, nor [recevies, foo bar])
the working syntax is [receives, list foo bar], because it takes a list-message, not a anything.
I'll let you explain what is a « proper replacement ».
Oh yeah, another thing that I hadn't noticed at first. Actually, I had assumed that [multireceive] was doing something interesting. What I said about using it in place of [receives] is actually wrong : in my abstractions, I just can't use [multireceive] at all for managing gui objects, because it doesn't have an outlet for telling me which thing just got modified !
Actually, I have no idea why [multireceive] exists the way it is. I can hardly think of a use for it, when it doesn't allow to distinguish between receive-symbols.
Look at the example at the top-left of receives-help.html : you can't do that with a (single) [multireceive] !
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I made a patch awhile back that added a "get" method to pd
And considering the "set" method, which is now implicit like in [; pd dsp 1(, it would be nice to have:
[; pd samplerate <samplerate>(
Katja
Le 2011-11-17 à 15:16:00, katja a écrit :
On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I made a patch awhile back that added a "get" method to pd
And considering the "set" method, which is now implicit like in [; pd dsp 1(, it would be nice to have:
[; pd samplerate <samplerate>(
In the model I use for attributes (in GridFlow), the name of the attribute is always the same as the name of the set-method, and for getting, there is a single get-method that takes the attribute name in $1, defaulting to all. IIRC, everybody does it like that in Pd, and perhaps in MAX too, but I don't really remember.
I mean I think that we all agree on this.
(DS [set] is an exception to this model, in some way... but DS don't have inlets nor receivers accessible from pd, anyway, so, they wouldn't be able to fit the model)
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Would the device names and numbers from the Audio and MIDI settings be considered "gettable Pd attributes"? If so, that would be awesome.
.mmb
On Wed, Nov 16, 2011 at 8:43 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor $bugfix" to rcv-name
[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute values" to rcv-name
leaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for about.pd in the other thread--
if Pd has a "get" method then about.pd doesn't need to rely on externals (well, aside from
pddplink for the links).
Are there Pd attributes other than version and dsp status that would be nice to make "gettable"?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Mike Moser-Booth mmoserbooth@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-list pd-list@iem.at Sent: Thursday, November 17, 2011 4:34 PM Subject: Re: [PD] "get" method for Pd
Would the device names and numbers from the Audio and MIDI settings be considered "gettable Pd attributes"?
They certainly are. However-- like canvas coords-- what's the best format to get them in? If you separate them out into individual "attribute value" messages they may be much easier to read and figure out, but a single "attribute value(s)" message is easier to unpack/change/repack. Then again, a single "attribute value(s)" message with lots of cryptic numeric values is difficult to read-- just think about all the questions to the list about what all the args for an iemgui mean, or donecanvasdialog, etc...
-Jonathan
If so, that would be awesome.
.mmb
On Wed, Nov 16, 2011 at 8:43 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I made a patch awhile back that added a "get" method to pd:
[; pd get version rcv-name( sends "version $major $minor
$bugfix" to rcv-name
[; pd get dsp rcv-name( sends "dsp $status" to rcv-name
[; pd get * rcv-name( sends a sequence of all query-able "attribute
values" to rcv-name
leaving off rcv-name will send the output to the Pd console
[; pd get( is synonymous with [; pd get *(
I remembered the patch when trying to generate crash logs for about.pd in
the other thread--
if Pd has a "get" method then about.pd doesn't need to rely
on externals (well, aside from
pddplink for the links).
Are there Pd attributes other than version and dsp status that would be
nice to make "gettable"?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- Mike Moser-Booth mmoserbooth@gmail.com
-
Andy Farnell -
brandt＠subnet.at -
Chris McCormick -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
katja -
Mathieu Bouchard -
Mike Moser-Booth -
Miller Puckette -
Patrice Colet -
Roman Haefeli -
Thomas Grill