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, 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