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 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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list