Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-03-31 23:54, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
yes (at least: yes, i expect that to make problems; you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either).
however, it's fairly trivial to build a [qlist] from [textfile], [delay] and [s] where you can do whatever magic you'd like to do to the receive symbols.
fgmasdr IOhannes
you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either
Bummer. anyway, this brings me to a different topic then. Why is there this lack of expansion in messages?
I think I've raised this issue sometime ago. Sorry I don't remember what the problem was, but I'd like to ask again if it's really really hard to expand the functionality in messages, or if this could happen sometime soon in Pd.
I believe there won't be any compatibility issues by expanding this functionality. Old patches will still work and newer patches could be simpler, right?
cheers
2014-04-01 4:31 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-03-31 23:54, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
yes (at least: yes, i expect that to make problems; you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either).
however, it's fairly trivial to build a [qlist] from [textfile], [delay] and [s] where you can do whatever magic you'd like to do to the receive symbols.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTOms0AAoJELZQGcR/ejb4cjEP/jh/AyPAtefrXya26f7ph00z yFo7DI1o2dVgkXr8GOZa0/6XL0K0DWzeQFxd5P+a0TnSoNQ1+2JV92UGJjCX74Ub lWVwS6hXLgVHlUxmLZVQiq5yuIrWb3vqol1Ji70fmzt2hxn8VgSJ/DxxyMcVs28z hDSppMXTOg3ebUMq8YNOmYp0yWqAxLlW/qAPkywWMqxCUbxHYiTTfaMcyc3jcwbZ wP8oLTSWk2AdflS7zDCbrM1V+sB7yBiTm39pJK9jfjTH2ttjEbcUOo0VyD68lf+9 VGtvdt3fSzu3F2RljzppaC/n6Z32iCu5Kc/VulGM9Dya8K4cB6/icnxcjcNUtNlw 2anJWEQ/RpCxRA/J3NJRDo1Ml63r45ze0OESZboV1hEUUcU6vmXwFMWsCoxsNbkk RdQ8pTp5hayCLtJIwT93KLpZcpgNh6I2f1L84N8qOUQaaBhuqziSDH7BW3ngsNFw yTWpSmTJ65l7eusRsXDstNV8LLaANY4cvGsvwlKmi+Gu7ySRMn66tjkFSzWhb5c+ rxhocOpa+MiDOF5dAzE7ER6K1Guk/Uq52N276rniyegHOwtcPLYh1pND9WzMLRU2 RRFbM+XxWT4TbZ2VWbH9HYBP6v/iBdvOi18WhGLLJYRZH0xze/O+qtTIw5TDWgag mbBItM5lwmBpcXzi3IWi =/TRx -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2014-04-01 at 17:20 -0300, Alexandre Torres Porres wrote:
you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either
Bummer. anyway, this brings me to a different topic then. Why is there this lack of expansion in messages?
Message boxes _do_ expand dollar arguments.
I think I've raised this issue sometime ago. Sorry I don't remember what the problem was, but I'd like to ask again if it's really really hard to expand the functionality in messages, or if this could happen sometime soon in Pd.
The difference is that dollar arguments in message boxes expand to the incoming message while dollar arguments in object boxes expand to the arguments given to the parent. $0 in object boxes is actually an argument given implicitly by Pd to the parent (every instance of a Pd file gets a separate one).
I believe there won't be any compatibility issues by expanding this functionality. Old patches will still work and newer patches could be simpler, right?
You're asking for inconsistency: You propose to have a mixture of dollar arguments in message boxes, namely you want $0 to expand to an argument of the parent and all other dollar arguments expand according to the incoming message.
While I also don't see how your proposal would break compatibility, I think what I said above is the reasoning why things are how they are. While I don't have a strong opinion on the subject matter, I suspect it is not going to be changed soon (it was brought up a few times already, iirc).
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-02 09:08, Roman Haefeli wrote:
You're asking for inconsistency:
++
fmsda IOhannes
On 04/02/2014 03:08 AM, Roman Haefeli wrote:
On Tue, 2014-04-01 at 17:20 -0300, Alexandre Torres Porres wrote:
you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either
Bummer. anyway, this brings me to a different topic then. Why is there this lack of expansion in messages?
Message boxes _do_ expand dollar arguments.
I think I've raised this issue sometime ago. Sorry I don't remember what the problem was, but I'd like to ask again if it's really really hard to expand the functionality in messages, or if this could happen sometime soon in Pd.
The difference is that dollar arguments in message boxes expand to the incoming message while dollar arguments in object boxes expand to the arguments given to the parent. $0 in object boxes is actually an argument given implicitly by Pd to the parent (every instance of a Pd file gets a separate one).
I believe there won't be any compatibility issues by expanding this functionality. Old patches will still work and newer patches could be simpler, right?
You're asking for inconsistency: You propose to have a mixture of dollar arguments in message boxes, namely you want $0 to expand to an argument of the parent and all other dollar arguments expand according to the incoming message.
I think what the OP wants is some minimally-workable notion of scope wrt receive-symbols. Because $0 doesn't deliver this, the next best thing is an inconsistent $0 that gets closer to minimally-workable scope. It says something that so many people are willing to overlook the inconsistency to get behavior that doesn't cause them to pull their hair out.
While I also don't see how your proposal would break compatibility, I think what I said above is the reasoning why things are how they are.
Tim Blechmann already addressed scope and implemented a solution in Nova. There are certainly developers in the Pd community who could port that idea, or maybe even something better. But free software devs have limited time, and they're smart, so they know if a now prominent Supercollider dev can't get such a needed improvement into Pd then they probably have 1000 better ways to spend their time.
-Jonathan
While I don't have a strong opinion on the subject matter, I suspect it is not going to be changed soon (it was brought up a few times already, iirc).
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, 2014-03-31 at 18:54 -0300, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
You can:
[nbx
|
[t b f]
|
[pack $0 f]
|
[add 500 $1-bla $2]
|
[qlist]
[r $0-bla] | [print]
The thing is you have to expand $0 before you're putting the messages into qlist. BTW: You also cannot internally expand to the arguments ($1, $2, etc.) of the abstraction that contains the qlist. You'd have to use the same 'trick'.
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-02 08:57, Roman Haefeli wrote:
On Mon, 2014-03-31 at 18:54 -0300, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
You can:
[pack $0 f] | [add 500 $1-bla $2]
ah yes. i assumed (most probably correctly), that alex wanted to store the qlist to a file and read it back in a different session of Pd. and/or store a qlist with one instance of an abstraction, and recall it from another instance.
fgmasdr IOhannes
See also the 'text' object in 0.45 that does $ expansion :)
M
On Wed, Apr 02, 2014 at 09:45:56AM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-02 08:57, Roman Haefeli wrote:
On Mon, 2014-03-31 at 18:54 -0300, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
You can:
[pack $0 f] | [add 500 $1-bla $2]
ah yes. i assumed (most probably correctly), that alex wanted to store the qlist to a file and read it back in a different session of Pd. and/or store a qlist with one instance of an abstraction, and recall it from another instance.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTO8AvAAoJELZQGcR/ejb4ZLkQAIpZWuGsQZTyAz+DPXRW3Gyz UjhQzMXl3lRSOUuulxA/wTqjFnWsNgQxQH2v2PO+mxWgZL7I9D0JQW24sFrpzNdO zzyaH+i2F6ZQZPris+R71SarfMu8ovIuV4fX1m/2pUDxremPdjRnErwtiRlBu6DE qqxYOi/UYh1/ECSLIW01azr1d01d/C3bSkdYtnrOZGQJYz6VjpBpt8sFLyyPdMqO xbaYTRIezRx+LGXpgs2lEKO5c7DQJli0y4+a3DThO0arKf2BWL+VJ7DqNtJmnaj1 XgFMsm1wkXkDE3vlFqsnjMJnY2zWg8o247oUwnOK2R0ZFHHF7D/eYsKjOKgB8RCc CMoZu3cqq+CCZsl1QCfneoKN8DVRkxLSC3AoK0mpRlDSNK6CKBW7PpH2sc99My7R exnfXJxYKthREXt2GVrB5uD1wewMczg7rxAPo3wHNReYxItNd1TmjDb2d07/TmPg MN/OYp/UWF/LG45C3rENfLkPa8VT48P+I+cX2K8urlheC/2/jXaMZZb+slFjuTlp TvDnIGG9JzsUSQeWj71ILfvAXXHSrNH/9YmbdKuhhFSUe3qePUen8elgV7NOuoec KJcRGMViwqvtRpNVRjjirT9C4u/zV7x6xoPSdc4TINTtHFVheHTJF37xeWFkZZfX bQkA59PavXIbgvQmDPzM =XIxv -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
See also the 'text' object in 0.45 that does $ expansion :)
on it ;)
Now, so it seems, at least [qlist] could be upgarded any time to do the expansion, right? That wouldn't hurt, would it?
Cheers
2014-04-02 10:26 GMT-03:00 Miller Puckette msp@ucsd.edu:
See also the 'text' object in 0.45 that does $ expansion :)
M
On Wed, Apr 02, 2014 at 09:45:56AM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-02 08:57, Roman Haefeli wrote:
On Mon, 2014-03-31 at 18:54 -0300, Alexandre Torres Porres wrote:
Hi there, I can't get messages from [qlist] to an object with "$0". Is this really a problem?
You can:
[pack $0 f] | [add 500 $1-bla $2]
ah yes. i assumed (most probably correctly), that alex wanted to store the qlist to a file and read it back in a different session of Pd. and/or store a qlist with one instance of an abstraction, and recall it from another instance.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTO8AvAAoJELZQGcR/ejb4ZLkQAIpZWuGsQZTyAz+DPXRW3Gyz UjhQzMXl3lRSOUuulxA/wTqjFnWsNgQxQH2v2PO+mxWgZL7I9D0JQW24sFrpzNdO zzyaH+i2F6ZQZPris+R71SarfMu8ovIuV4fX1m/2pUDxremPdjRnErwtiRlBu6DE qqxYOi/UYh1/ECSLIW01azr1d01d/C3bSkdYtnrOZGQJYz6VjpBpt8sFLyyPdMqO xbaYTRIezRx+LGXpgs2lEKO5c7DQJli0y4+a3DThO0arKf2BWL+VJ7DqNtJmnaj1 XgFMsm1wkXkDE3vlFqsnjMJnY2zWg8o247oUwnOK2R0ZFHHF7D/eYsKjOKgB8RCc CMoZu3cqq+CCZsl1QCfneoKN8DVRkxLSC3AoK0mpRlDSNK6CKBW7PpH2sc99My7R exnfXJxYKthREXt2GVrB5uD1wewMczg7rxAPo3wHNReYxItNd1TmjDb2d07/TmPg MN/OYp/UWF/LG45C3rENfLkPa8VT48P+I+cX2K8urlheC/2/jXaMZZb+slFjuTlp TvDnIGG9JzsUSQeWj71ILfvAXXHSrNH/9YmbdKuhhFSUe3qePUen8elgV7NOuoec KJcRGMViwqvtRpNVRjjirT9C4u/zV7x6xoPSdc4TINTtHFVheHTJF37xeWFkZZfX bQkA59PavXIbgvQmDPzM =XIxv -----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
On 04/02/2014 05:43 PM, Alexandre Torres Porres wrote:
See also the 'text' object in 0.45 that does $ expansion :)
on it ;)
Now, so it seems, at least [qlist] could be upgarded any time to do the expansion, right? That wouldn't hurt, would it?
or you could build your own [qlist] based on [text]...no need to change the old and rusty code of the original [qlist].
dsar IOhannes
or you could build your own [qlist] based on [text]... no need to change the old and rusty code of the original [qlist].
I get the workaround, but [qlist] is built for sequencing and simpler for that (like, it can easily set the tempo), and I still think it wouldn't hurt to make it more flexible. It'd be totally backwards compatible.
Although I assume I don't think I get the hassle it'd be to do that. I'm still struggling to see what could be so tricky to make "$0" possible to work in messages, sorry :P
cheers
2014-04-02 13:50 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 04/02/2014 05:43 PM, Alexandre Torres Porres wrote:
See also the 'text' object in 0.45 that does $ expansion :)
on it ;)
Now, so it seems, at least [qlist] could be upgarded any time to do the expansion, right? That wouldn't hurt, would it?
or you could build your own [qlist] based on [text]...no need to change the old and rusty code of the original [qlist].
dsar IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
2014-04-02 19:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
or you could build your own [qlist] based on [text]... no need to change the old and rusty code of the original [qlist].
I get the workaround, but [qlist] is built for sequencing and simpler for that (like, it can easily set the tempo), and I still think it wouldn't hurt to make it more flexible. It'd be totally backwards compatible.
Although I assume I don't think I get the hassle it'd be to do that. I'm still struggling to see what could be so tricky to make "$0" possible to work in messages, sorry :P
cheers
2014-04-02 13:50 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 04/02/2014 05:43 PM, Alexandre Torres Porres wrote:
See also the 'text' object in 0.45 that does $ expansion :)
on it ;)
Now, so it seems, at least [qlist] could be upgarded any time to do the expansion, right? That wouldn't hurt, would it?
or you could build your own [qlist] based on [text]...no need to change the old and rusty code of the original [qlist].
dsar IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So, tried other things, and I see it won't be able to deal with messages including "$0" like [qlist]. So the reason must be not related to [qlist] or [textfile], but the way Pd handles (or doesn't handle) $0 in messages.
The only workaround is to forcely insert $0 with [makefilename], but then all symbols have to be local.
cheers
2014-04-02 20:49 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
2014-04-02 19:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
or you could build your own [qlist] based on [text]...
no need to change the old and rusty code of the original [qlist].
I get the workaround, but [qlist] is built for sequencing and simpler for that (like, it can easily set the tempo), and I still think it wouldn't hurt to make it more flexible. It'd be totally backwards compatible.
Although I assume I don't think I get the hassle it'd be to do that. I'm still struggling to see what could be so tricky to make "$0" possible to work in messages, sorry :P
cheers
2014-04-02 13:50 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 04/02/2014 05:43 PM, Alexandre Torres Porres wrote:
See also the 'text' object in 0.45 that does $ expansion :)
on it ;)
Now, so it seems, at least [qlist] could be upgarded any time to do the expansion, right? That wouldn't hurt, would it?
or you could build your own [qlist] based on [text]...no need to change the old and rusty code of the original [qlist].
dsar IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2014-04-02 at 22:05 -0300, Alexandre Torres Porres wrote:
So, tried other things, and I see it won't be able to deal with messages including "$0" like [qlist]. So the reason must be not related to [qlist] or [textfile], but the way Pd handles (or doesn't handle) $0 in messages.
Yes.
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-03 03:05, Alexandre Torres Porres wrote:
So, tried other things, and I see it won't be able to deal with messages including "$0" like [qlist]. So the reason must be not related to [qlist] or [textfile], but the way Pd handles (or doesn't handle) $0 in messages.
yes.
The only workaround is to forcely insert $0 with [makefilename],
yes.
but then all symbols have to be local.
no. you can build logic in Pd that will add $0 to *some* symbols. e.g. use [route] to extract those special senders you want to prepend with "$0".
note that i'm not saying that this could not be done more conveniently on the Pd side. i'm only saying that you can build things yourself that do (more or less) what you want to do. and it's not that hard to create your own little set of helpers that do what you want (though probably not what I want)
btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of "[qlist] and locality" - very simple and forces you to think about your object interfaces.
fgmasdr IOhannes
On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-03 03:05, Alexandre Torres Porres wrote:
[...]
btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of "[qlist] and locality" - very simple and forces you to think about your object interfaces.
I would also recommend only using global receive-symbols when you have to use them. That way:
- your patches are more readable
- no need to feed $0 to message boxes
- when you run into nameclashes, you know your project has outgrown Pd
and it's time to choose another language
-Jonathan
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
- when you run into nameclashes, you know your project
has outgrown Pd and it's time to choose another language
what's a nameclash? (maybe I haven't outgrown Pd yet)
2014-04-03 13:00 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-03 03:05, Alexandre Torres Porres wrote:
[...]
btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of "[qlist] and locality" - very simple and forces you to think about your object interfaces.
I would also recommend only using global receive-symbols when you have to use them. That way:
- your patches are more readable
- no need to feed $0 to message boxes
- when you run into nameclashes, you know your project has outgrown Pd and
it's time to choose another language
-Jonathan
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -----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
For example, if you have two help patches open and each has an array inside it named "array1". One of the help patches will work, and the other won't. That's because "Put" menu arrays assume you only have one array by that name. Pd will use the first one it finds (probably the first one you create) and the duplicate will be ignored.
In the case of arrays you'll get a warning, because you're not supposed to use the same name twice. But with the send/receive classes (as well as many other objects that use pd_bind) you can have many s/r pairs sharing the same name.
So suppose you have [s loop] and [r loop] in a subpatch, and [s loop] and [r loop] in an unrelated subpatch.
Are those s/r pairs supposed to communicate with each other? Or... Did the author forget he/she already used the name "loop" for the first s/r pair and doesn't actually want the other s/r pair to communicate with the first?
If the answer to the second question is yes, then that's an example of a nameclash. Pd doesn't give you a way to tell the difference. Most programming languages have clear and sensible ways to avoid this. There's even a Pd external to do it-- I think it's called [sendlocal] and [receivelocal]-- but its author erroneously thought that $0 deprecates those objects.
Pd gurus on the list can give you seemingly simple workarounds for these problems with scope and nameclashes, but as you the programmer accumulate them it gets more and more unwieldy. Worse, it makes it difficult to read patches, as you must spend time decoding someone else's idiosyncratic use of [makefilename] or whatever they are doing to get Pd to do what is concise, consistent and robust in nearly every other modern programming language.
Finally-- and again-- these problems cannot be improved in Pd without breaking some backwards compatibility. Just take the related issue of namespaces with external libraries-- it's hard enough to design and test something robust like Python's namespacing. Now imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible, and that means as long as people imagine Pd Vanilla as the "core" Pd $0 hackery is the only way to simulate scoping.
-Jonathan On Thursday, April 3, 2014 12:35 PM, Alexandre Torres Porres porres@gmail.com wrote:
- when you run into nameclashes, you know your project
has outgrown Pd and it's time to choose another language
what's a nameclash? (maybe I haven't outgrown Pd yet)
2014-04-03 13:00 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2014-04-03 03:05, Alexandre Torres Porres wrote:
[...]
btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of "[qlist] and locality" - very simple and forces you to think about your object interfaces.
I would also recommend only using global receive-symbols when you have to use them. That way:
- your patches are more readable
- no need to feed $0 to message boxes
- when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language
-Jonathan
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -----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
thanks for explaining it all
imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?
As I don't see I'll be able to grasp the details for now, I'll just take your word for it :)
cheers
2014-04-03 15:52 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
For example, if you have two help patches open and each has an array inside it named "array1". One of the help patches will work, and the other won't. That's because "Put" menu arrays assume you only have one array by that name. Pd will use the first one it finds (probably the first one you create) and the duplicate will be ignored.
In the case of arrays you'll get a warning, because you're not supposed to use the same name twice. But with the send/receive classes (as well as many other objects that use pd_bind) you can have many s/r pairs sharing the same name.
So suppose you have [s loop] and [r loop] in a subpatch, and [s loop] and [r loop] in an unrelated subpatch.
Are those s/r pairs supposed to communicate with each other? Or... Did the author forget he/she already used the name "loop" for the first s/r pair and doesn't actually want the other s/r pair to communicate with the first?
If the answer to the second question is yes, then that's an example of a nameclash. Pd doesn't give you a way to tell the difference. Most programming languages have clear and sensible ways to avoid this. There's even a Pd external to do it-- I think it's called [sendlocal] and [receivelocal]-- but its author erroneously thought that $0 deprecates those objects.
Pd gurus on the list can give you seemingly simple workarounds for these problems with scope and nameclashes, but as you the programmer accumulate them it gets more and more unwieldy. Worse, it makes it difficult to read patches, as you must spend time decoding someone else's idiosyncratic use of [makefilename] or whatever they are doing to get Pd to do what is concise, consistent and robust in nearly every other modern programming language.
Finally-- and again-- these problems cannot be improved in Pd without breaking some backwards compatibility. Just take the related issue of namespaces with external libraries-- it's hard enough to design and test something robust like Python's namespacing. Now imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible, and that means as long as people imagine Pd Vanilla as the "core" Pd $0 hackery is the only way to simulate scoping.
-Jonathan On Thursday, April 3, 2014 12:35 PM, Alexandre Torres Porres < porres@gmail.com> wrote:
- when you run into nameclashes, you know your project
has outgrown Pd and it's time to choose another language
what's a nameclash? (maybe I haven't outgrown Pd yet)
2014-04-03 13:00 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-04-03 03:05, Alexandre Torres Porres wrote:
[...]
btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of "[qlist] and locality" - very simple and forces you to think about your object interfaces.
I would also recommend only using global receive-symbols when you have to use them. That way:
- your patches are more readable
- no need to feed $0 to message boxes
- when you run into nameclashes, you know your project has outgrown Pd and
it's time to choose another language
-Jonathan
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -----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
On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote:
thanks for explaining it all
imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?
Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages.
While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect.
Roman
Wow, you keep beating that horse after its dead for quite a while by now
I don't think this debate is going lead anywhere
please, cope with my lack of knowledge in computer science/languages jargons. All I'm doing is asking to learn more about it and get what you guys mean. I'm not debating, since I'm even stating I couldn't do it when I say I probably won't be able to grasp all the details and will just take the word for it...
So relax, you keep misjudging before reading more carefully. I'm not looking for a debate, and I'm also saying I'm cool with Pd's workaround myself, so there's no personal frustration. As I said, I'm not even thinking about me as my concerns come from luring people into using Pd, while I'm already sold for it.
Anyway, having said that, I'd appreciate if anyone could help me understand Pd's structure and developing issues.
For instance, I don't think I understand what "inconsistencies" mean in this context.
cheers
2014-04-03 17:03 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote:
thanks for explaining it all
imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?
Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages.
While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote:
Wow, you keep beating that horse after its dead for quite a while by now
I don't think this debate is going lead anywhere
please, cope with my lack of knowledge in computer science/languages jargons.
I'm sorry. I sure will (though I don't feel I have in any way less of a lack of knowledge). Actually, I don't have any computer science background myself.
All I'm doing is asking to learn more about it and get what you guys mean. I'm not debating, since I'm even stating I couldn't do it when I say I probably won't be able to grasp all the details and will just take the word for it...
So relax, you keep misjudging before reading more carefully. I'm not looking for a debate, and I'm also saying I'm cool with Pd's workaround myself, so there's no personal frustration. As I said, I'm not even thinking about me as my concerns come from luring people into using Pd, while I'm already sold for it.
Anyway, having said that, I'd appreciate if anyone could help me understand Pd's structure and developing issues.
I think I can't answer that.
For instance, I don't think I understand what "inconsistencies" mean in this context.
I try to explain some more. The confusion probably comes from the fact, that a similar looking syntax is used for two relatively different things in Pd. A $1 in an object box is substituted by the first argument I give to the parent abstraction. If I create [myabs 0.3] and myabs contains an [f $1], the value of $1 actually is '0.3'. If I have a message box [bla $1( in the same abstraction [myabs], we actually don't know yet what the value of this $1 is. Only when we send message to [bla $1( we know what the value of $1.
[1.7( | [bla $1(
When I click the [1.7( message box, we know that the $1 in [bla $1( is going to be substituted by 1.7. So far, so good.
We now have encountered two different $1s in the same abstraction. Once it got substituted by 0.3 and once by 1.7, although both are written $1. Confusing, isn't it?
I know that is nothing new to you at all as you most likely have used dollar variables in both ways already. What I am trying to say is that a $1 in a message box [bla $1( is a different animal from a $1 in an object box [f $1]. Pd could have been designed to make this distinction more explicit. It could have used # variables for message boxes and $ variables for object boxes. Then we would be able to do both with message boxes, namely expanding to a parent's argument AND expanding to an element of the incoming message, depending on whether we use the # or the $ syntax.
[1.7( | [bla #1(
In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we click the [1.7( message box (as does $1 in the real Pd). Clicking on [1.7( would output 'bla 1.7'.
[1.7( | [bla $1(
In our hypothetical Pd, $1 would hold the value of the first argument given to the parent abstraction [myabs 0.3], in our example '0.3'. Clicking the [1.7( message box would output a message 'bla 0.3'. However, there is no such thing in the real Pd (yet).
In the real Pd, the $1 in the message box works totally differently from the $1 in the object box. The canvas local-ID unique to each instance of a .pd file (abstraction or patch) can be considered as an argument to that abstraction or patch. Thus it can easily be accessed by $0 in object boxes.
When you propose that $0s in message boxes are substituted by the canvas-local ID, then you want the function of the dollar variables to be different depending on what number follows the dollar sign. You want $0 to access an argument given to the parent, but $1 to be substituted by the first element of the incoming message. That is where the inconsistency happens: Why should the function be different based on the value I put after the dollar sign?
In our hypothetical Pd, this would be a non-issue. You wouldn't expect a #0 in message box to get substituted by the canvas-local ID. You would use $0 for that. In the real Pd, we unfortunately don't have direct access to the arguments of the parent from message boxes. When you ask "Why can't a $0 in a message box be substituted by the canvas-local ID", then you also should ask "Why isn't a $1 in message box substituted by the first argument given to the parent?" The answer is that this is the way Pd is designed.
I'd prefer our hypothetical Pd, if it would exist. However, switching from today's Pd to our hypothetical Pd would surely break compatibility, which makes its introduction a bit less likely. Finally, I don't see any other concise solution than our hypothetical Pd for the $0-in-message-boxes problem.
I hope I didn't cause even more confusion.
Roman
2014-04-03 17:03 GMT-03:00 Roman Haefeli reduzent@gmail.com: On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote: > thanks for explaining it all > > > > imagine trying to design something like that > > which is also backwards compatible with the > > crude namespacing tools that already exist in Pd. > > It's not possible > > > ok, here's where I'm a bit confuse. You're not saying it'd be > impossible to make messages inherit the $0 value, are you?
Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages. While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
not confusing, thanks
2014-04-03 19:54 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote:
Wow, you keep beating that horse after its dead for quite a while by now
I don't think this debate is going lead anywhere
please, cope with my lack of knowledge in computer science/languages jargons.
I'm sorry. I sure will (though I don't feel I have in any way less of a lack of knowledge). Actually, I don't have any computer science background myself.
All I'm doing is asking to learn more about it and get what you guys mean. I'm not debating, since I'm even stating I couldn't do it when I say I probably won't be able to grasp all the details and will just take the word for it...
So relax, you keep misjudging before reading more carefully. I'm not looking for a debate, and I'm also saying I'm cool with Pd's workaround myself, so there's no personal frustration. As I said, I'm not even thinking about me as my concerns come from luring people into using Pd, while I'm already sold for it.
Anyway, having said that, I'd appreciate if anyone could help me understand Pd's structure and developing issues.
I think I can't answer that.
For instance, I don't think I understand what "inconsistencies" mean in this context.
I try to explain some more. The confusion probably comes from the fact, that a similar looking syntax is used for two relatively different things in Pd. A $1 in an object box is substituted by the first argument I give to the parent abstraction. If I create [myabs 0.3] and myabs contains an [f $1], the value of $1 actually is '0.3'. If I have a message box [bla $1( in the same abstraction [myabs], we actually don't know yet what the value of this $1 is. Only when we send message to [bla $1( we know what the value of $1.
[1.7( | [bla $1(
When I click the [1.7( message box, we know that the $1 in [bla $1( is going to be substituted by 1.7. So far, so good.
We now have encountered two different $1s in the same abstraction. Once it got substituted by 0.3 and once by 1.7, although both are written $1. Confusing, isn't it?
I know that is nothing new to you at all as you most likely have used dollar variables in both ways already. What I am trying to say is that a $1 in a message box [bla $1( is a different animal from a $1 in an object box [f $1]. Pd could have been designed to make this distinction more explicit. It could have used # variables for message boxes and $ variables for object boxes. Then we would be able to do both with message boxes, namely expanding to a parent's argument AND expanding to an element of the incoming message, depending on whether we use the # or the $ syntax.
[1.7( | [bla #1(
In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we click the [1.7( message box (as does $1 in the real Pd). Clicking on [1.7( would output 'bla 1.7'.
[1.7( | [bla $1(
In our hypothetical Pd, $1 would hold the value of the first argument given to the parent abstraction [myabs 0.3], in our example '0.3'. Clicking the [1.7( message box would output a message 'bla 0.3'. However, there is no such thing in the real Pd (yet).
In the real Pd, the $1 in the message box works totally differently from the $1 in the object box. The canvas local-ID unique to each instance of a .pd file (abstraction or patch) can be considered as an argument to that abstraction or patch. Thus it can easily be accessed by $0 in object boxes.
When you propose that $0s in message boxes are substituted by the canvas-local ID, then you want the function of the dollar variables to be different depending on what number follows the dollar sign. You want $0 to access an argument given to the parent, but $1 to be substituted by the first element of the incoming message. That is where the inconsistency happens: Why should the function be different based on the value I put after the dollar sign?
In our hypothetical Pd, this would be a non-issue. You wouldn't expect a #0 in message box to get substituted by the canvas-local ID. You would use $0 for that. In the real Pd, we unfortunately don't have direct access to the arguments of the parent from message boxes. When you ask "Why can't a $0 in a message box be substituted by the canvas-local ID", then you also should ask "Why isn't a $1 in message box substituted by the first argument given to the parent?" The answer is that this is the way Pd is designed.
I'd prefer our hypothetical Pd, if it would exist. However, switching from today's Pd to our hypothetical Pd would surely break compatibility, which makes its introduction a bit less likely. Finally, I don't see any other concise solution than our hypothetical Pd for the $0-in-message-boxes problem.
I hope I didn't cause even more confusion.
Roman
2014-04-03 17:03 GMT-03:00 Roman Haefeli reduzent@gmail.com: On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote: > thanks for explaining it all > > > > imagine trying to design something like that > > which is also backwards compatible with the > > crude namespacing tools that already exist in Pd. > > It's not possible > > > ok, here's where I'm a bit confuse. You're not saying it'd be > impossible to make messages inherit the $0 value, are you?
Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages. While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect. Roman _______________________________________________ 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
On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote:
thanks for explaining it all
imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?
I don't know how difficult such a change is. I assume something in Pd's parser would need to be changed. I can't remember if the code responsible for parsing a msg box message even knows where the message got sent from-- seems ike it doesn't since I can't "find last error" on msg-box parsing errors (like an out-of-range dollarsign variable).
What I'm saying is that even with a canvas $0 inside message boxes Pd's scope system is still way too clunky. You still don't get straightforward subpatch-locality, nor nested-abstraction locality. I think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and [preset_node] get the latter (though I don't think it does global scope). Both work perfectly fine with no $0 at all. The pedagogical benefit is enormous-- new users can get the scope they want without having to learn or think about what a dollarsign variable is, or how string concatenation works. In the case of [preset_hub], just creating the object sets the scope boundary almost certainly to what the user wants it to be. I like that.
-Jonathan
Hi Jonathan, I like it too, and the pedagogical concern is what gets me the most. I find new users to be reluctant to the clunkiness.
Had never heard of the Nova system, is it available somewhere? Seems it's not built on the core of Pd anyway, right?
thanks
2014-04-03 19:03 GMT-03:00 Jonathan Wilkes jancsika@yahoo.com:
On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote:
thanks for explaining it all
imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible
ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?
I don't know how difficult such a change is. I assume something in Pd's parser would need to be changed. I can't remember if the code responsible for parsing a msg box message even knows where the message got sent from-- seems ike it doesn't since I can't "find last error" on msg-box parsing errors (like an out-of-range dollarsign variable).
What I'm saying is that even with a canvas $0 inside message boxes Pd's scope system is still way too clunky. You still don't get straightforward subpatch-locality, nor nested-abstraction locality. I think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and [preset_node] get the latter (though I don't think it does global scope). Both work perfectly fine with no $0 at all. The pedagogical benefit is enormous-- new users can get the scope they want without having to learn or think about what a dollarsign variable is, or how string concatenation works. In the case of [preset_hub], just creating the object sets the scope boundary almost certainly to what the user wants it to be. I like that.
-Jonathan
On 04/03/2014 06:33 PM, Alexandre Torres Porres wrote:
Hi Jonathan, I like it too, and the pedagogical concern is what gets me the most. I find new users to be reluctant to the clunkiness.
Had never heard of the Nova system, is it available somewhere? Seems it's not built on the core of Pd anyway, right?
No, it was abandoned. I believe Tim develops something for Supercollider called "Supernova" which allows users to take advantage of parallelism when doing DSP.
[preset_hub] is in Pd-l2ork.
-Jonathan
thanks
2014-04-03 19:03 GMT-03:00 Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com>:
On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote:thanks for explaining it all > imagine trying to design something like that > which is also backwards compatible with the > crude namespacing tools that already exist in Pd. > It's not possible ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you?I don't know how difficult such a change is. I assume something in Pd's parser would need to be changed. I can't remember if the code responsible for parsing a msg box message even knows where the message got sent from-- seems ike it doesn't since I can't "find last error" on msg-box parsing errors (like an out-of-range dollarsign variable). What I'm saying is that even with a canvas $0 inside message boxes Pd's scope system is still way too clunky. You still don't get straightforward subpatch-locality, nor nested-abstraction locality. I think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and [preset_node] get the latter (though I don't think it does global scope). Both work perfectly fine with no $0 at all. The pedagogical benefit is enormous-- new users can get the scope they want without having to learn or think about what a dollarsign variable is, or how string concatenation works. In the case of [preset_hub], just creating the object sets the scope boundary almost certainly to what the user wants it to be. I like that. -Jonathan
On Don, 2014-04-03 at 12:00 -0400, Jonathan Wilkes wrote:
- when you run into nameclashes, you know your project has outgrown Pd
and it's time to choose another language
That is a pretty bold statement. I never ever run into name clashes, no matter how big the project was/is.
The no-name-clash dogma:
Do not use global s/r-symbols (simple)
Use global s/r-symbols for singletons (i.e. one server, many clients)
Use global s/r-symbols in cases where the protocol is multinode-aware. (No matter how many instances of an abstraction using a global s/r- symbol are created, they will always be able to communicate with each other in the same way)
Roman
On 04/03/2014 04:14 PM, Roman Haefeli wrote:
On Don, 2014-04-03 at 12:00 -0400, Jonathan Wilkes wrote:
- when you run into nameclashes, you know your project has outgrown Pd
and it's time to choose another language
That is a pretty bold statement.
It's meant as a shortcut to avoid wasting time.
I never ever run into name clashes, no matter how big the project was/is.
The no-name-clash dogma:
- Do not use global s/r-symbols (simple)
Except you have two points below which contradict this!
But I suppose you meant to write that one shouldn't use global s/r-symbols except for the two special cases below. Even so, what you ignore is the entire learning curve that accompanies the dogma. The new user is presented with the perverse starting point that the simple, common case of global symbols should be used almost never and the cryptic, dollarsign-zero symbol names should be used almost always.
Because the user must rely on cryptic dollarsign symbols for locality, patching is more error-prone, and patches are harder to read. Every message box is accompanied by the user's choice of extra patch cruft to feed $0 into it. Maybe it's [f $0], [list prepend $0], an abstraction, or something else. That yet one more little detail to check when things go wrong, and it's there because the user is forced to type something extra to get patch locality, which is most often what the user needs.
So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages.
-Jonathan
Use global s/r-symbols for singletons (i.e. one server, many clients)
Use global s/r-symbols in cases where the protocol is multinode-aware. (No matter how many instances of an abstraction using a global s/r- symbol are created, they will always be able to communicate with each other in the same way)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2014-04-03 at 17:33 -0400, Jonathan Wilkes wrote:
So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages.
Clunky or not, Pd is the language I feel the most expressive with. YMMV.
Roman
On 04/03/2014 05:42 PM, Roman Haefeli wrote:
On Don, 2014-04-03 at 17:33 -0400, Jonathan Wilkes wrote:
So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages.
Clunky or not, Pd is the language I feel the most expressive with. YMMV.
Sorry, I'm not using the best terminology here. I'm talking about the practical expressivity of the language.
For just one example-- let's say you wanted to make a polyphonic patch
with 30 oscillators, and send them messages to set initial frequency and
amplitude. Let's use "Old-school Pd" which doesn't have abstractions.
You make a subpatch, get it the way you want it, copy it, then paste it
29 times. Now when you need to make changes to the subpatch, you need
to delete the other 29, copy the one you changed and paste it 29 times.
That sucks.
Now let's look at "New-school Pd" which has abstractions. In this case you get your abstraction the way you want it, instantiate it on a canvas, copy it, and paste it 29 times. Now when you want to make a change to the abstraction, you click "Save" and Pd automatically pushes your changes to all instances of your abstraction. You don't have to copy/paste everything again. That's very simple, but it's one of the ways abstractions can make Pd more expressive.
So you can express yourself by programming in either version of the language. But the "New-school" version makes it easier to do that. That may be clearer with the example of abstractions-- which you no doubt use all the time-- than with examples of scope that don't rely on $0. But that's why I refer to other modern languages which don't suffer from that roadblock.
-Jonathan
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Don, 2014-04-03 at 18:41 -0400, Jonathan Wilkes wrote:
On 04/03/2014 05:42 PM, Roman Haefeli wrote:
On Don, 2014-04-03 at 17:33 -0400, Jonathan Wilkes wrote:
So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages.
Clunky or not, Pd is the language I feel the most expressive with. YMMV.
Sorry, I'm not using the best terminology here. I'm talking about the practical expressivity of the language.
For just one example-- let's say you wanted to make a polyphonic patch with 30 oscillators, and send them messages to set initial frequency and amplitude. Let's use "Old-school Pd" which doesn't have abstractions.
You make a subpatch, get it the way you want it, copy it, then paste it 29 times. Now when you need to make changes to the subpatch, you need to delete the other 29, copy the one you changed and paste it 29 times.
That sucks.Now let's look at "New-school Pd" which has abstractions. In this case you get your abstraction the way you want it, instantiate it on a canvas, copy it, and paste it 29 times. Now when you want to make a change to the abstraction, you click "Save" and Pd automatically pushes your changes to all instances of your abstraction. You don't have to copy/paste everything again. That's very simple, but it's one of the ways abstractions can make Pd more expressive.
So you can express yourself by programming in either version of the language. But the "New-school" version makes it easier to do that. That may be clearer with the example of abstractions-- which you no doubt use all the time-- than with examples of scope that don't rely on $0. But that's why I refer to other modern languages which don't suffer from that roadblock.
Thanks for your remarks. You probably caught me in the act of feeling comfortable in an actually not so comfortable situation. It's true that people get accustomed to the environment they grow up in. I've never challenged myself into thinking how things could be different as I found ways to cover my needs with the clunky locality of $0.
Not yet fully seeing the impact, you convinced me that a more 'true' locality would probably make some things easier.
And that is certainly not everything where Pd is clunky. I still find myself using dynamic patching for problems I don't know how to solve otherwise and that is not even an officially supported feature with a definitely clunky interface.
Roman
On 04/03/2014 07:13 PM, Roman Haefeli wrote:
[...]
Thanks for your remarks. You probably caught me in the act of feeling comfortable in an actually not so comfortable situation. It's true that people get accustomed to the environment they grow up in. I've never challenged myself into thinking how things could be different as I found ways to cover my needs with the clunky locality of $0.
Not yet fully seeing the impact, you convinced me that a more 'true' locality would probably make some things easier.
And that is certainly not everything where Pd is clunky. I still find myself using dynamic patching for problems I don't know how to solve otherwise and that is not even an officially supported feature with a definitely clunky interface.
Do you have any examples of such problems? I'd be curious to see...
-Jonathan
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
Miller proposed to use the new [text] class introduced in 0.45
Oh I see, didn't know about it. It really seems like it's the option for more flexibility than [qlist] can handle. Will try it out. cheers
2014-04-03 3:38 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oops, I'll be dammed, but [text] doesn't seem to handle "$0" in the same way.
Although it looks like a super [qlist], giving [text] a "$0" for an address symbol, such as "$0-test1", turns it into "0-test1"... so no deal for it.
I'm assuming it's not supposed to be something regarding an object design. As with [qlist] and [textfile], the issue is related to the way Pd doesn't handle $0 in messages. So unless it eventually does, I guess that the only thing left to do is to find some workarounds as discussed here.
"note that i'm not saying that this could not be done more conveniently on the Pd side. i'm only saying that you can build things yourself that do (more or less) what you want to do. and it's not that hard to create your own little set of helpers that do what you want (though probably not what I want)"
I get that, and I'm actually cool with the philosophy. The reason I insist is aimed to Pd's functionality as a whole, and I only mention one thing or another after giving it a good deal of thought and really believing it'd be a better user experience for other people. Specially beginners.
Actually, lots of this issues come up for me when I'm preparing patches for classes. And I'm also writing extensive documentation for Pd. So when I hit this issues I think of the students and all the people I want to lure into Pd, selling it as a very simple and fucntional environment.
Bur for example, now I'm teaching how to do sequencing, and I'd like to say that it just works if anyone needs [qlist] to send local messages. It's bad to not mention some limitations or to mention them and spend a lot of time on some clumsy workarounds to avoid them.
And for having taught Pd a lot, the $0 thing in messages is always something that stands out for some working around. It's fine by me, I'm just thinking of newcomers having to grasp these details, when I wonder if it all could just be solved internally on the way Pd is programmed to deal with messages.
I assume I have no idea of the hassles involved, but I have the idea that there must be a few options to solve this. It can't be impossible.
Well, one way or another, this is just a humble opinion. It's my two cents on the subject. I don't see any problem emerging from the capability of messages inheriting $0, and it'd be totally backwards compatible to older patches. Moeover, [qlist] and [text] could send messages to local receives.
cheers
2014-04-03 13:45 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
Miller proposed to use the new [text] class introduced in 0.45
Oh I see, didn't know about it. It really seems like it's the option for more flexibility than [qlist] can handle. Will try it out. cheers
2014-04-03 3:38 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I almost meant that :) you still have to send [text sequence] the values of the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there.
cheers M
On Thu, Apr 03, 2014 at 08:38:16AM +0200, Roman Haefeli wrote:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"I almost meant that :) you still have to send [text sequence] the values of the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there."
hmmm, are you pointing to a solution where I can send "$0" to textfile and it would generate the number and do the trick? Gotta check this thing better.
cheers
2014-04-03 20:10 GMT-03:00 Miller Puckette msp@ucsd.edu:
I almost meant that :) you still have to send [text sequence] the values of the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there.
cheers M
On Thu, Apr 03, 2014 at 08:38:16AM +0200, Roman Haefeli wrote:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
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
Yeah - for instance use a [pack] object to get a list of $ substtution values into [text sequence] - then one of the arguments to [pcak] can be $0.
cheers M On Thu, Apr 03, 2014 at 08:44:02PM -0300, Alexandre Torres Porres wrote:
"I almost meant that :) you still have to send [text sequence] the values of the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there."
hmmm, are you pointing to a solution where I can send "$0" to textfile and it would generate the number and do the trick? Gotta check this thing better.
cheers
2014-04-03 20:10 GMT-03:00 Miller Puckette msp@ucsd.edu:
I almost meant that :) you still have to send [text sequence] the values of the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there.
cheers M
On Thu, Apr 03, 2014 at 08:38:16AM +0200, Roman Haefeli wrote:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think I got it, will try as soon as a I can. I have to properly study this new object first anyway.
If I got it, that looks like a workaround I thought about before, still thinking of [qlist], like storing all the sequence in the patch and then send it to [qlist], where I could get the patch $0 value and send it to it. Someting like that, right?
I thought it was a bit of a hassle, then I reached the list. Maybe with [text] it could be easier.
cheers
2014-04-03 20:59 GMT-03:00 Miller Puckette msp@ucsd.edu:
Yeah - for instance use a [pack] object to get a list of $ substtution values into [text sequence] - then one of the arguments to [pcak] can be $0.
cheers M On Thu, Apr 03, 2014 at 08:44:02PM -0300, Alexandre Torres Porres wrote:
"I almost meant that :) you still have to send [text sequence] the
values of
the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there."
hmmm, are you pointing to a solution where I can send "$0" to textfile
and
it would generate the number and do the trick? Gotta check this thing better.
cheers
2014-04-03 20:10 GMT-03:00 Miller Puckette msp@ucsd.edu:
I almost meant that :) you still have to send [text sequence] the
values of
the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there.
cheers M
On Thu, Apr 03, 2014 at 08:38:16AM +0200, Roman Haefeli wrote:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file,
you
can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not
the
old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand
correctly -
to take literal $0 strings that get expanded only at reading time.
(Is
that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
HEY, I SEE HOW [text] WORKS NOW
Awesome, you can easily send arguments to it.
Perfect
2014-04-03 20:59 GMT-03:00 Miller Puckette msp@ucsd.edu:
Yeah - for instance use a [pack] object to get a list of $ substtution values into [text sequence] - then one of the arguments to [pcak] can be $0.
cheers M On Thu, Apr 03, 2014 at 08:44:02PM -0300, Alexandre Torres Porres wrote:
"I almost meant that :) you still have to send [text sequence] the
values of
the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there."
hmmm, are you pointing to a solution where I can send "$0" to textfile
and
it would generate the number and do the trick? Gotta check this thing better.
cheers
2014-04-03 20:10 GMT-03:00 Miller Puckette msp@ucsd.edu:
I almost meant that :) you still have to send [text sequence] the
values of
the $ variables you want to use (starting with $1). But the ability to instance-ize sequences is there.
cheers M
On Thu, Apr 03, 2014 at 08:38:16AM +0200, Roman Haefeli wrote:
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote:
By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file,
you
can't use it to work as an address for [send].
Miller proposed to use the new [text] class introduced in 0.45, not
the
old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand
correctly -
to take literal $0 strings that get expanded only at reading time.
(Is
that what you meant, Miller?)
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
wrap your qlist, if you need more than one of the same 'device' $0 or similar logic is unavoidable. track numbers are your friends as well as device numbers whenever storage of temporal information about them together is the task. leave the unique identifier up to the process that spawns the identified. I have gone off the deepend and installed wine, now the matchzine is drunk with Reason and Live, hahahaah If you need the $0 as the text representation instead of the expanded numeral representation search here for [PD] literal $0 from message to gui send and gui receive and
http://puredata.hurleur.com/sujet-6417-dollar-signs-objects-messages
On Wed, 2014-04-02 at 19:00 -0300, Alexandre Torres Porres wrote:
Although I assume I don't think I get the hassle it'd be to do that. I'm still struggling to see what could be so tricky to make "$0" possible to work in messages, sorry :P
The reason is most likely not the difficulty to implement it, but as I said: probably nobody wants to introduce inconsistencies.
Roman
-
Alexandre Torres Porres -
Billy Stiltner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jonathan Wilkes -
Miller Puckette -
Roman Haefeli