[PD] pduino rewrite

[Hans-Christoph Steiner]

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:hans at at.or.at]
> > Gesendet: Donnerstag, 15. September 2011 17:48
> > An: Ingo
> > Cc: 'Roman Haefeli'; pd-list at 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
>