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:h...@at.or.at] > > Gesendet: Donnerstag, 15. September 2011 17:48 > > An: Ingo > > Cc: 'Roman Haefeli'; pd-list@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 > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list