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-bounces@iem.at [mailto:pd-list-bounces@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