Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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
Re: [PD] [qlist] and locality
-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 -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] Soundfiler not behaving as expected
Hi All, in Pd 0.45.4 vanilla I'm getting the following behavior from soundfiler, using the help file: 1. Hit 2nd message down to read full bell sound into array2 - works fine. 2. Hit 4th message down to write an AIFF file to /tmp - resulting sound file is unreadable, apparently due to an invalid header. 3. HIt 5th message down to write a WAVE file to /tmp - works fine. Below is a report from diagnostic utility sndfile-info. 2013 iMac, OS X 10.9.2. Version : libsndfile-1.0.25 Error : Not able to open input file foo1.aif. File : foo1.aif Length : 311942 FORM : 311932 (should be 311934) AIFF COMM : 18 Sample Rate : 44100 Frames : 155944 Channels: 1 Sample Size : 16 Encoding: NONE Unknown chunk marker 4568C0 at position 38. Resyncing. Unknown chunk marker 4568 at position 39. Resyncing. *** Unknown chunk marker 445 at position 44. Exiting parser. Invalid SF_PRIVATE field : dataoffset == -1. -Eric ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Soundfiler not behaving as expected
I suggest you use player~ by Eric Lyon for stable playback :-) I cannot speak to the bad header though Sent from my iPhone On Apr 3, 2014, at 10:03 AM, Eric Lyon audiodid...@gmail.commailto:audiodid...@gmail.com wrote: Hi All, in Pd 0.45.4 vanilla I'm getting the following behavior from soundfiler, using the help file: 1. Hit 2nd message down to read full bell sound into array2 - works fine. 2. Hit 4th message down to write an AIFF file to /tmp - resulting sound file is unreadable, apparently due to an invalid header. 3. HIt 5th message down to write a WAVE file to /tmp - works fine. Below is a report from diagnostic utility sndfile-info. 2013 iMac, OS X 10.9.2. Version : libsndfile-1.0.25 Error : Not able to open input file foo1.aif. File : foo1.aif Length : 311942 FORM : 311932 (should be 311934) AIFF COMM : 18 Sample Rate : 44100 Frames : 155944 Channels: 1 Sample Size : 16 Encoding: NONE Unknown chunk marker 4568C0 at position 38. Resyncing. Unknown chunk marker 4568 at position 39. Resyncing. *** Unknown chunk marker 445 at position 44. Exiting parser. Invalid SF_PRIVATE field : dataoffset == -1. -Eric ___ Pd-list@iem.atmailto: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
Re: [PD] [qlist] and locality
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
Re: [PD] [qlist] and locality
* 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 jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 por...@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 reduz...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Edit / Text Editor - what's the use?
Hi there, I see there's a new [text] object in Pd 0.45 that defines, opens and edits text. This raises some doubts about the Text Editor option in the Edit Menu. I never knew what it was for, and I'm still clueless. How do you use it? Is there any example around I missed? cheers ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 por...@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 jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 jancs...@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 por...@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 jancs...@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
Re: [PD] [qlist] and locality
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
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 reduz...@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
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 jancs...@yahoo.com mailto:jancs...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 reduz...@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
Re: [PD] [qlist] and locality
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
Re: [PD] [qlist] and locality
not confusing, thanks 2014-04-03 19:54 GMT-03:00 Roman Haefeli reduz...@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 reduz...@gmail.com: On Don, 2014-04-03
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 m...@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
Re: [PD] [qlist] and locality
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 m...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] UDOO Quad and Generic Guitar to USB link issues
Hello PD-list, I am currently working on my semester project which is a guitar multi-effect pedal using the UDOO Quad and PD. I got everything up and running on the Linaro Ubutu 12.04 LTS build provided by UDOO and I am having strange results with PD. The soundcard I am using works normally when I am using Audacity. It plays wav files and can record the guitar signal correctly but when it comes to PD, a basic osc object or a table read through ALSA produces a strange digital noise, completely ruining the audio signal. I have also tested this setup with a M-Audio Fast Track Pro USB card and the playback worked without issues, although I could not get the input signal through the adc object for an unknown reason. Has anyone tried a similar setup for guitar usage? Thanks! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Soundfiler not behaving as expected
I can confirm this happens for me for both soundfiler and writesf~ (Mac 10.6.8 and PD 0.45-4). Even after applying a new AIFF header in soundhack, the files are just noise. Honestly, I've only ever used WAV files with Pd before testing this just now! PS - Eric, I bought your Max/Pd external book for reference - excellent work! On Thu, Apr 3, 2014 at 10:01 AM, Eric Lyon audiodid...@gmail.com wrote: Hi All, in Pd 0.45.4 vanilla I'm getting the following behavior from soundfiler, using the help file: 1. Hit 2nd message down to read full bell sound into array2 - works fine. 2. Hit 4th message down to write an AIFF file to /tmp - resulting sound file is unreadable, apparently due to an invalid header. 3. HIt 5th message down to write a WAVE file to /tmp - works fine. Below is a report from diagnostic utility sndfile-info. 2013 iMac, OS X 10.9.2. Version : libsndfile-1.0.25 Error : Not able to open input file foo1.aif. File : foo1.aif Length : 311942 FORM : 311932 (should be 311934) AIFF COMM : 18 Sample Rate : 44100 Frames : 155944 Channels: 1 Sample Size : 16 Encoding: NONE Unknown chunk marker 4568C0 at position 38. Resyncing. Unknown chunk marker 4568 at position 39. Resyncing. *** Unknown chunk marker 445 at position 44. Exiting parser. Invalid SF_PRIVATE field : dataoffset == -1. -Eric ___ 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
Re: [PD] [qlist] and locality
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 m...@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 m...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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 m...@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 m...@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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list