[PD] pduino rewrite

Roman Haefeli reduzent at gmail.com
Thu Sep 15 08:43:35 CEST 2011


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 at iem.at [mailto:pd-list-bounces at iem.at] Im Auftrag von
> > Hans-Christoph Steiner
> > Gesendet: Mittwoch, 14. September 2011 22:33
> > An: Roman Haefeli
> > Cc: pd-list at 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 at iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> > 
> > 
> > 
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list





More information about the Pd-list mailing list