Re: [PD] pduino rewrite
Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction
Re: [PD] pduino rewrite
The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. But as I had mentioned - I doubt that efficiency will play a role in just about any case for the arduino's digital pins. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Donnerstag, 15. September 2011 08:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered,
Re: [PD] Selecting random wavefile from folder without knowing the names
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: adam sanches adam.sanc...@gmail.com Cc: pd-list@iem.at Sent: Thursday, September 15, 2011 1:51 AM Subject: Re: [PD] Selecting random wavefile from folder without knowing the names Le 2011-09-14 à 22:14:00, adam sanches a écrit : Hi, how can i select a random wavefile from a folder withouth knowing the names of the files in my folder? how can i read all the files names in a folder and then select one? which would be the best way of doing this? [hcs/folder_list] then [list length] then [random] then [list split] then $1. You were pwned by a misnomer. [folder_list] outputs each file/dir as a symbol, so you'd need to accumulate a list from its output. -Jonathan ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ 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] pduino rewrite
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple arduinos
Hi if you're running on Linux check the [ADDITIONAL-INFOS] in the arduino-help.pd on the upper right corner in the pd-rewrite: https://github.com/reduzent/pduino as mentioned below the infos you'll find there are basically from http://answers.ros.org/answers/101/revisions/ with this method you can connect the arduino within pd due to its serial adress avoiding id-conflicts. hope this helps ø On 09/06/2011 09:27 PM, tim vets wrote: We have an installation running at www.verbekefoundation.com http://www.verbekefoundation.com with two arduino's and pd for several years now. The only thing that fries now and then are the power supplies. iirc, it's just a matter of sending the right [devicename name_of_device( to the two [comport], ( or [arduino] ?) objects. You can get those devicenames by doing ls /dev/ttyU*, which will give you something like /dev/ttyUSB0 and /dev/ttyUSB1, representing the two arduino's. (under the assumption that the newer arduino models still work the same way.) gr, Tim 2011/9/6 FernandoG dataf...@gmail.com mailto:dataf...@gmail.com Hi Anybody knows if its posible to use multiple arduinos ( 2 or 3 arduino mega) with the same pduino based puredata patch? Thanks! F ___ Pd-list@iem.at mailto: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 -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple arduinos
I just tried to open the help file on Windows XP and Natty and it crashes Pd on both platforms. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von olsen Gesendet: Donnerstag, 15. September 2011 14:52 An: tim vets Cc: pd-list Betreff: Re: [PD] multiple arduinos Hi if you're running on Linux check the [ADDITIONAL-INFOS] in the arduino- help.pd on the upper right corner in the pd-rewrite: https://github.com/reduzent/pduino as mentioned below the infos you'll find there are basically from http://answers.ros.org/answers/101/revisions/ with this method you can connect the arduino within pd due to its serial adress avoiding id-conflicts. hope this helps ø On 09/06/2011 09:27 PM, tim vets wrote: We have an installation running at www.verbekefoundation.com http://www.verbekefoundation.com with two arduino's and pd for several years now. The only thing that fries now and then are the power supplies. iirc, it's just a matter of sending the right [devicename name_of_device( to the two [comport], ( or [arduino] ?) objects. You can get those devicenames by doing ls /dev/ttyU*, which will give you something like /dev/ttyUSB0 and /dev/ttyUSB1, representing the two arduino's. (under the assumption that the newer arduino models still work the same way.) gr, Tim 2011/9/6 FernandoG dataf...@gmail.com mailto:dataf...@gmail.com Hi Anybody knows if its posible to use multiple arduinos ( 2 or 3 arduino mega) with the same pduino based puredata patch? Thanks! F ___ Pd-list@iem.at mailto: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 -- ETs DNA will not be televised http://hasa-labs.org ___ 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] pduino rewrite
On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote: On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Well, now you can and trivially install all but one of the dependencies for 'puredata' aka Pd vanilla using: apt-get install pd-cyclone pd-mapping pd-zexy Only moocow is missing. I'd bet it'll be much less work to package moocow then to rewrite and manage a fork of arduino.pd. .hc Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote: On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Well, now you can and trivially install all but one of the dependencies for 'puredata' aka Pd vanilla using: apt-get install pd-cyclone pd-mapping pd-zexy Only moocow is missing. I'd bet it'll be much less work to package moocow then to rewrite and manage a fork of arduino.pd. I'm not sure about this, but I mostly agree with you. When packaging arduino as a pd-lib.deb, it would be trivial to add the dependencies. However, I find I found some rather ugly stuff inside [arduino] that I definitely wanted to get rid of, such as [prepend] from cyclone. On the long run, I don't see the point in having two different [arduino] classes to be maintained. If at some point, improvements of both can be merged to one class, I'm all for it. Even if it means re-adding some externals. But for stuff that is very trivial to do with vanilla classes, I don't see the point in using externals. And no, I really don't think that adds a lot of maintenance load to the class. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 15. September 2011 17:48 An: Ingo Cc: 'Roman Haefeli'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc #N canvas 504 92 321 208 10; #N canvas 606 345 294 266 digital_messages 1; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 1386 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X obj 440 129 mod 256; #X connect 0 0 24 0; #X connect 2 0 15 0; #X connect 3 0 14 0; #X connect 4 0 13 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 9 0; #X connect 8 0 16 0; #X connect 9 0 17 0; #X connect 10 0 23 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 25 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 2 0; #X connect 24 0 3 0; #X connect 24 0 4 0; #X connect 24 0 5 0; #X connect 24 0 6 0; #X connect 24 0 8 0; #X connect 24 0 7 0; #X connect 24 0 33 0; #X connect 25 0 1 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 10 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 1386 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 18:43 +0200, Roman Haefeli wrote: On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote: On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Well, now you can and trivially install all but one of the dependencies for 'puredata' aka Pd vanilla using: apt-get install pd-cyclone pd-mapping pd-zexy Only moocow is missing. I'd bet it'll be much less work to package moocow then to rewrite and manage a fork of arduino.pd. I'm not sure about this, but I mostly agree with you. When packaging arduino as a pd-lib.deb, it would be trivial to add the dependencies. However, I find I found some rather ugly stuff inside [arduino] that I definitely wanted to get rid of, such as [prepend] from cyclone. I think that prepend works better, that's why. No need for [list trim]. With cyclone/prepend being in Pd-extended and Debian, it doesn't seem like too hard a thing to install it when you need it. I'm open to being proven wrong on cyclone's prepend working better. On the long run, I don't see the point in having two different [arduino] classes to be maintained. If at some point, improvements of both can be merged to one class, I'm all for it. Even if it means re-adding some externals. But for stuff that is very trivial to do with vanilla classes, I don't see the point in using externals. And no, I really don't think that adds a lot of maintenance load to the class. Maintenance is one part of it, another is so that you don't have to copy-n-paste subpatches in cases like multiple [debytemask]s, you just make as many instances as you need. Another good reason is that there are useful bits of code developed while writing the arduino.pd object, why not share them as objects? .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote: Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. Makes sense, I think having it as a Pd abstraction is good too, I did write it that way rather than in C :) I was just saying that C would be more efficient. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 15. September 2011 17:48 An: Ingo Cc: 'Roman Haefeli'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 13:29 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote: Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. Makes sense, I think having it as a Pd abstraction is good too, I did write it that way rather than in C :) I was just saying that C would be more efficient. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. But then you need a row of [+ 8] ([+ 16], [+ 24]) for each instance of debytemask. So, it's still tedious work, whether you're using an abstraction or copies of the subpatch. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Dynamic patching with audio - review
This looks very thorough and useful. It would be great to have in the http://puredata.info/docs section (once the website is back up). .hc On Mon, 2011-08-29 at 16:16 +0200, abel.jer...@free.fr wrote: Hi all, My last mail was broken by the mailing list engine. The prose in a file if you please ;-): http://abel.jerome.free.fr/pd/dynamic-patching/reviews/DynamicPatching_review-3.txt Jérôme (with accents) - Mail original - De: abel jerome abel.jer...@free.fr À: pd-list@iem.at Envoyé: Mercredi 24 Août 2011 12:49:10 Objet: Re: Dynamic patching with audio - review Hi, A new report of my researchs about audio dynamic patching techniques. The continuation of my previous reviews : http://abel.jerome.free.fr/pd/dynamic-patching/reviews/DynamicPatching_review-1.txt http://abel.jerome.free.fr/pd/dynamic-patching/reviews/DynamicPatching_review-2.txt === Pd-list archives === The issue has been discussed several times (IOhannes m zmoelnig) That's right. I've just seen that the pd dsp O/1 method was described in 2005 ! It's quite difficult to find those threads without the terms dsp tree or dsp graph or dsp chain. Indeed, I don't know anything about it. A list of the best search terms could help us (see below) and avoid those noise requests. We are trying here to make a review of all dynamic patching techniques to make it easier to understand and find the best solution for any project. It could be a page on the community website instead of the disheartening do not use dynamic patching (http://puredata.info/docs/tutorials/TipsAndTricks#how-to-avoid-audio-drop-outs). - Search engine usage When I search in the pd-list, the score show some posts where the search term are in the next or previous message links, not in the message body. How limit the search term to the body and not the links ? Futhermore, if I'm interested in one thread, it seems that if I choose to sort by thread, it's only the threads of a month. How group one thread on all months ? - Search terms audio drop-outs with pd dsp O; pd dsp 1 activate audio abstraction dynamic audio abstraction dynamic patching dynamic patching techniques update dsp-tree update dsp-graphofxPd - Threads about audio dynamic abstraction in pd-list - [PD] strange behavior upon loading dsp abstraction http://lists.puredata.info/pipermail/pd-list/2004-12/thread.html#24337 - [PD] no dsp-chain update after dynamic abstraction-creation http://lists.puredata.info/pipermail/pd-list/2005-06/028923.html - [PD] slowly load a pd-patches/abs without dropouts http://lists.puredata.info/pipermail/pd-list/2007-01/046243.html - [PD] this is crazy http://lists.puredata.info/pipermail/pd-list/2008-01/059244.html - [PD] API for manipulating a patch in real time http://lists.puredata.info/pipermail/pd-list/2008-12/066723.html - [PD] Dynamically created signal object bug http://lists.puredata.info/pipermail/pd-list/2009-02/068246.html - [PD] abstraction creation audio engine start http://lists.puredata.info/pipermail/pd-list/2009-04/069849.html === Dynamic creation of audio abstractions === - Methods 1 - DSP 0/1 2 - Add/clear an audio object (subpatch) 3 - Add/cut any object (subpatch) See : http://abel.jerome.free.fr/pd/dynamicPatching/patchs/dyn-audio-abstraction/ This methods work with any abstraction. - DSP 0/1 method - explanations From IOhannes m zmoelnig : You shouldn't dynamically create abstractions while dsp is running, as it slows down significantly. If dsp is on, and you dynamically create 10 objects in one go (in zero logical time), then the dsp graph will be re-calculated 10 times. If you turn dsp off, then dynamically create 10 objects as before, then no dsp graph will be evaluated until you turn dsp on again, summing up to exactly 1 time. Furthermore, it guarantees that the entire DSP graph is calculated and not only parts of it (because of buggy implementations) Thanks a lot for those explanations. It's clear enough to see why choose these method even if internal processes in the DSP graph are still incomprehensibles. - DSP 0/1 method - Some questions --- With one audio abstraction. If we create just one audio abstraction at one time. Is it still the best solution or is it the same than other methods ? --- Audio clics. From me: But audio clics may occur for all sounds, not just for the new one, right ? From IOhannes: no, this is wrong. (at least not, if you computer is fast
Re: [PD] notes/questions from a beginner
Le 2011-09-15 à 15:45:00, Hans-Christoph Steiner a écrit : On Wed, 2011-08-24 at 13:28 -0400, Mathieu Bouchard wrote: On Tue, 23 Aug 2011, Stephen Lavelle wrote: 4 - is there a shortcut for deleting connections? something like ctrl+click would save me a lot of time. BTW, if you select a set of objects, then cut it, then paste it, copies of the objects will reappear where the originals were, but they will be fully disconnected from the part of the patch that was not cut. And on Pd-extended, the pasted objects will be shifted down and to the right, so you can see them. We're talking cut+paste, not copy+paste, so, what you say does not apply, because the originals are gone, thus you don't have to distinguish the new objects from the originals. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo #N canvas 317 0 1025 801 10; #X obj 238 619 cnv 15 370 140 empty empty empty 20 12 0 14 -262130 -66577 0; #X floatatom 253 633 5 0 255 0 - - -; #X floatatom 253 685 5 0 0 0 - - -; #X floatatom 303 685 5 0 0 0 - - -; #X floatatom 253 731 5 0 0 0 - - -; #X floatatom 303 731 5 0 0 0 - - -; #X obj 253 665 mod 8; #X obj 253 704 div 4; #X obj 303 665 4; #X obj 303 705 2; #X text 362 628 Question:; #X obj 540 79 cnv 15 350 100 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 659 376 cnv 15 170 180 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 190 582 outlet; #X obj 190 55 route 0 1 2 3 4 5 6; #X obj 190 28 inlet; #X obj 690 495 +; #X msg 690 535 digital \$1 \$2; #X obj 690 515 pack float float; #X obj 690 378 unpack float float; #X obj 690 82 t a a; #X msg 717 102 \$1; #X msg 690 102 \$2; #X obj 690 55 route 0 1 2 3 4 5 6; #X obj 690 28 inlet; #X obj 550 159 trigger float float float float float float float float ; #X obj 690 582 outlet; #X obj 659 619 cnv 15 170 140 empty empty empty 20 12 0 14 -232576 -66577 0; #X text 668 663 There is no need to; #X obj 959 193 cnv 15 50 50 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 972 199 15; #X obj 972 220 * 8; #X text 668 726 selects this pin group.; #X text 668 711 The route object already; #X text 362 648 is the 1st calculation using [mod] and; #X text 362 663 [div] heavier on cpu cycles than [ 4]; #X text 362 678 and [ 2] due to different processor; #X text 362 693 instructions?; #X text 687 6 debyte; #X text 668 691 defined by the firmata.; #X text 668 676 calculate the pin number; #X text 668 628 The objects marked here; #X text 668 643 are not necessary.; #X obj 336 722 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 336 682 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 4 188 cnv 15 920 120 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 370 206 mod 128; #X obj 310 206 mod 64; #X obj 250 206 mod 32; #X obj 190 206 mod 16; #X obj 130 206 mod 8; #X obj 70 206 mod 4; #X obj 10 206 mod 2; #X obj 70 226 div 2; #X obj 430 226 div 128; #X obj 130 226 div 4; #X obj 190 226 div 8; #X obj 250 226 div 16; #X obj 310 226 div 32; #X obj 370 226 div 64; #X obj 10 246 change -1; #X obj 70 246 change -1; #X obj 130 246 change -1; #X obj 190 246 change -1; #X obj 250 246 change -1; #X obj 310 246 change -1; #X obj 370 246 change -1; #X obj 430 246 change -1; #X msg 10 266 digital 0 \$1; #X msg 70 286 digital 1 \$1; #X msg 130 266 digital 2 \$1; #X msg 190 286 digital 3 \$1; #X msg 250 266 digital 4 \$1; #X msg 310 286 digital 5 \$1; #X msg 370 266 digital 6 \$1; #X msg 430 286 digital 7 \$1; #X obj 430 206 mod 256; #X msg 550 264 0 \$1; #X msg 596 284 1 \$1; #X msg 643 265 2 \$1; #X msg 690 284 3 \$1; #X msg 736 266 4 \$1; #X msg 783 284 5 \$1; #X msg 830 267 6 \$1; #X msg 877 284 7 \$1; #X obj 550 206 1; #X obj 596 205 2; #X obj 643 205 4; #X obj 690 205 8; #X obj 736 205 16; #X obj 783 205 32; #X obj 830 205 64; #X obj 877 205 128; #X obj 596 225 1; #X obj 643 225 2; #X obj 690 225 3; #X obj 736 225 4; #X obj 783 225 5; #X obj 830 225 6; #X obj 877 225 7; #X obj 550 244 change; #X obj 596 245 change; #X obj 643 245 change; #X obj 690 245 change; #X obj 736 246 change; #X obj 783 247 change; #X obj 830 247 change; #X obj 877
