Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: 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 was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. 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. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus on the message processing part, unless you deal with message rates of several thousands per second. This is certainly not always true, but in my own experience it most often is. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 11:32 +0200, Roman Haefeli wrote: On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: 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 was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). It turns out that difference is not significant. On my box, processing 100 floats takes ~160ms ([mod],[div]) vs. ~150 ([],[]). Probably all the message parsing overhead is consuming more than the actual computation of the numbers. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Here's the reason why I started really to simplify any patch, no matter if audio or control objects: I have been programming for about 4 years on one single patch (fulltime - only with breaks to get the hardware/OS going and sampling/editing sampled instruments). You can imagine the amount of code that is in the patch by now. When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). At a certain point (about 2 years ago) the machine was completely overloaded! Then I measured that a EWI-USB wind controller can send up to 500 midi CC messages per second. I had a function that could multiply the messages to six different midi channels. That makes it 3,000 messages floating around. The sample voices have at least 500 [receive] objects (there are close to 500 parameters per voice). There were 16 voices which adds up to 8,000 [receive] objects. Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. That should be as much data shifting around only for checking [receive] objects as it would take to move the data of several hundreds of audio channels around. The first fix was easy: assigning the parameter to receive from midi Ch01 if voices are stacked. That cut the message transfer by 6. The second fix was to replace the wireless sends with hard wired patch chords. That took care of most of the rest. The machine was working again. Unfortunately this second fix took 3-4 full months!!! This is when I decided to think about efficiency in running mode first. If you have a piece of code that has to check between 10 different options and in a certain case only two options are available then it is worth it copying the object and take out all unnecessary options. It's more work while programming but it saves in this particular example several hundred percent cpu time when running. When such a programming style is used consistently I am sure you can get at least double or more of the performance of a computer. Even with messages where you would think they are not too heavy. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 11:32 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: 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 was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. 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. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus on
Re: [PD] pduino rewrite
To make sure boards that are larger than 56 digital in pins you should copy a couple more of these objects to go up to 128. Of course since [] and [] seems to be slightly faster that would be the choice. To be even more efficient the object [pd route digital/analog] should be bypassed by adding the addresses [144 145 146 ... 151] to the route object inside the parent patch making it [route 249 240 144 145 146 147 148 149 150 151]. The last outlet goes into [pd route digital/analog]. The [route 0 1 2 3 4 5 6 7] inside the [pd digital messages] should be replace by 8 individual inlets. BTW you could keep going on with this forever ... All I wanted originally was to get the correct messages coming out of the patch ... Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 14:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 14:05 +0200, Ingo wrote: Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. I think I'm going to put your much more efficient version into the git version. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo, On 16/09/11 13:02, Ingo wrote: When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | And using nested abstractions you could create the receives based on $args, and if you need lots of voices you could use dynamic patching to instantiate them. Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Actually, packing an id before the actual data and using a route object to distribute all separate destinations from one single [receive] - [route] - parameters would do the trick. Maybe that's what you meant? I just cannot picture a [route] object with up to 500 outlets, yet. But there might be ways to organize it using a small number of [receive] and a small number of [route] and sub-[route] objects. However, it would take just as much time to rewrite an existing patch like this as it takes to hardwire the sends. I still think that these considerations need to be made when starting to write any kind of code because problems only start showing up when it's almost too late. Once the patch gets kinda huge fixing will become very time consuming. Optimizing any code to the least amount of parsing data/messages around is the key for doing any complex patches. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 16. September 2011 16:42 An: 'Claude Heiland-Allen'; pd-list@iem.at Betreff: Re: [PD] pduino rewrite Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ 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
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] 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] 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] 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
Re: [PD] pduino rewrite
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 anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! #N canvas 490 1631 331 170 10; #N canvas 571 1511 538 392 digital 0; #X obj 58 3 inlet; #X obj 58 286 outlet; #X msg 58 113 0 \$1; #X msg 96 113 1 \$1; #X msg 134 113 2 \$1; #X msg 172 113 3 \$1; #X msg 210 113 4 \$1; #X msg 248 113 5 \$1; #X msg 286 113 6 \$1; #X msg 328 113 7 \$1; #X obj 58 208 +; #X obj 394 106 15; #X msg 58 261 digital \$1 \$2; #X obj 394 127 * 8; #X obj 58 230 pack float float; #X obj 58 163 unpack float float; #N canvas 0 69 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X obj 32 186 change; #X obj 82 187 change; #X obj 132 187 change; #X obj 182 187 change; #X obj 232 188 change; #X obj 282 189 change; #X obj 332 189 change; #X obj 382 189 change; #X connect 0 0 25 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 26 0; #X connect 19 0 27 0; #X connect 20 0 28 0; #X connect 21 0 29 0; #X connect 22 0 30 0; #X connect 23 0 31 0; #X connect 24 0 32 0; #X connect 25 0 8 0; #X connect 26 0 9
Re: [PD] pduino rewrite
On Wed, 2011-09-14 at 11:48 +0200, Ingo wrote: Hi Roman, thanks for taking the time looking at the code. Unfortunately your version will be sending even many more wrong numbers. I have put some list messages into your patch. Keep clicking onto them randomly and you will see that the headers change between 6, 7, 14 and 15. Sometimes they are correct - sometimes not. The problem is due to the change object inside the debyte object. Leaving it out would always send all 8 bits for the group of pins. Leaving it in will keep holding old values. Gotcha. I removed the [change] objects from the [pd debytemask] subpatch. And I also agree, that it would be ugly, if digital pins fire without changing their state. I cannot see any way other than using individual debyte objects for each group unless you would come up with something completely different like storing everything into an array and sending from there (after checking what has changed) which would be much more complicated. Actually, I found the table based approach not that complicated and I think it is more scalable (it covers all possible 16 groups). I added a [pd polychange] subpatch that does exactly what you describe. I hopefully tested it more thoroughly this time. See attached patch. Cheers Roman #N canvas 0 53 450 300 10; #N canvas 179 119 538 392 digital 0; #X obj 42 17 inlet; #X obj 42 334 outlet; #X msg 42 120 0 \$1; #X msg 80 120 1 \$1; #X msg 118 120 2 \$1; #X msg 156 120 3 \$1; #X msg 194 120 4 \$1; #X msg 232 120 5 \$1; #X msg 270 120 6 \$1; #X msg 312 120 7 \$1; #X obj 42 215 +; #X obj 378 113 15; #X msg 42 310 digital \$1 \$2; #X obj 378 134 * 8; #X obj 42 237 pack float float; #X obj 42 170 unpack float float; #N canvas 289 142 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X connect 0 0 8 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 9 0; #X connect 19 0 10 0; #X connect 20 0 11 0; #X connect 21 0 12 0; #X connect 22 0 13 0; #X connect 23 0 14 0; #X connect 24 0 15 0; #X restore 42 85 pd debytemask; #X obj 42 38 t a a; #X msg 69 60 \$1; #X msg 42 60 \$2; #N canvas 315 128 443 301 polychange 0; #X obj 23 20 inlet; #X obj 23 242 outlet; #X obj 236 12 table \$0.digital.in.cache 128; #X obj 23 87 tabread \$0.digital.in.cache; #X obj 23 64 unpack f f; #X obj 23 109 !=; #X obj 23 131 sel 1; #X obj 23 42 t a a; #X obj 23 153 list append; #X obj 83 242 tabwrite \$0.digital.in.cache; #X obj 23 175 t a a a; #X msg 248 215 \$1; #X msg 83 213 \$2; #X connect 0 0 7 0; #X connect 3 0 5 0; #X connect 4 0 3 0; #X connect 4 1 5 1; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 4 0; #X connect 7 1 8 1; #X connect 8 0 10 0; #X connect 10 0 1 0; #X connect 10 1 12 0; #X connect 10 2 11 0; #X connect 11 0 9 1; #X connect 12 0 9 0; #X restore 42 273 pd polychange; #X connect 0 0 17 0; #X connect 2 0 15 0; #X connect 3 0 15 0; #X connect 4 0 15 0; #X connect 5 0 15 0; #X connect 6 0 15 0; #X connect 7 0 15 0; #X connect 8 0 15 0; #X connect 9 0 15 0; #X connect 10 0 14 0; #X connect 11 0 13 0; #X connect 12 0 1 0; #X connect 13 0 10 1; #X connect 14 0 20 0; #X connect 15 0 10 0; #X connect 15 1 14 1; #X connect 16 0 2 0; #X connect 16 1 3 0; #X connect 16 2 4 0; #X connect 16 3 5 0; #X connect 16 4 6 0; #X connect 16 5 7 0; #X connect 16 6 8 0; #X connect 16 7 9 0; #X connect 17 0 19 0; #X connect 17 1 18 0; #X connect 18 0 11 0; #X connect 19 0 16 0; #X connect 20 0 12 0; #X restore 7 13 pd digital messages roman; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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 anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! ___ 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
Upon further testing I have found two bugs so far. On is in the firmata and the second one is in the [debytemask]. This makes fixing it a bit difficult. 1) firmata: instead of sending two values for a digital pin connected or disconnected it sends three. The first one should be the address and the second one the value for the group of 8 pins. There may be a reason why it sends another 0 at the end but that's not too important anyway. The bad thing is that when disconnecting a pin it sends these number five times (sometimes only three times) in a row while going back and forth between the last value and the current one. That's 15 bytes instead of two. (I am using an inc/dec wheel with the arduino and now I know why it doesn't respond like it should.) I havn't checked the analogue ins so far. 2) [debytemask]: there is only one debytemask for all addresses. This means - since there is a [change] object inside - there will be a wrong value when the same button of a different group of pins is pressed or released twice after each other. This could be still correct if all other pins of the group have identical values but creates random numbers if the other pins change. Not sure yet what else gets affected. I am going to try to fix the problem with the [debytemask] but I don't know if the firmata stuff has any big influence on it. I just added another 6 buttons to my remote (using all 12 digital and 6 analogue ins of the Diecimila / Duemilanove now) and the whole thing is going crazy now sending wrong stuff all over the place. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Freitag, 9. September 2011 16:41 An: Ingo Cc: 'Roman Haefeli'; 'pd-list' Betreff: Re: [PD] pduino rewrite I basically haven't used an Arduino in 2 years, so I am a poor candidate for debugging this stuff. Roman and Olsen are much better candidates for this job. The digital input pins are reported using the hardware-level ports, the hardware is organized around pins 0-7 being one port, 8-15, another, and 16-23 (analog pins) another. As for the pull-up resistor, you activate them just like you would in an other code for an Atmel AVR chip: switch the pin mode to INPUT then set that pin to HIGH (i.e. output a 1 to that pin). .hc On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything
Re: [PD] pduino rewrite
Hi Roman, Olsen and Hans, Here' a replacement object that fixes the behaviour that wrong digital in pins get recognized when more than the first 6 pins are used. I hope there is nothing else interfering with those pins anymore. The object digital_messages inside the patch should be placed here to replace the current object digital messages: Arduino/convert to symbolic commands/ Please test if it is working on other systems! I have no idea if this works with the mega or not since I don't have one to test it. If anyone could check this out it would be great to know! Ingo #N canvas 0 0 450 300 10; #N canvas 702 733 318 273 digital_messages 0; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 2032 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 440 129 mod 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 connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 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 23 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 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 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 1 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 2032 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 440 129 mod 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 0 \$1; #X msg 80 216 digital 1 \$1; #X msg 140 196 digital 2 \$1; #X msg 200 216 digital 3 \$1; #X msg 260 196 digital 4 \$1; #X msg 320 216 digital 5 \$1; #X msg 380 196 digital 6 \$1; #X msg 440 216 digital 7 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 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 23 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 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 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 1 0; #X restore 43 70 pd resolve-bits_0-7; #N canvas 2032 0 534 360 resolve-bits_8-15 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 440 129 mod 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
Re: [PD] pduino rewrite
There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed this bug for over two years! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I forgot to mention: I tested with a Duemilanove. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 9. September 2011 10:04 An: 'Roman Haefeli'; 'olsen'; 'pd-list' Betreff: Re: [PD] pduino rewrite Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? 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] pduino rewrite
On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I basically haven't used an Arduino in 2 years, so I am a poor candidate for debugging this stuff. Roman and Olsen are much better candidates for this job. The digital input pins are reported using the hardware-level ports, the hardware is organized around pins 0-7 being one port, 8-15, another, and 16-23 (analog pins) another. As for the pull-up resistor, you activate them just like you would in an other code for an Atmel AVR chip: switch the pin mode to INPUT then set that pin to HIGH (i.e. output a 1 to that pin). .hc On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) 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] pduino rewrite
I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. Ingo Betreff: Re: [PD] pduino rewrite I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ 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
This is a great start, it needed some loving. I'll check it out when I have some time. .hc On Fri, 2011-09-02 at 12:20 +0200, olsen wrote: buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ø ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
