[PD] pduino rewrite

[Ingo]

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.

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.

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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: arduino-convert_digital_messages.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110915/7174154b/attachment.txt>