[PD] pduino rewrite

[Roman Haefeli]

Wow, I just compared your version of [pd digital message] with mine and
yours takes only 180ms to process 1000000 of messages, while mine uses
over 8s. 
Frankly, I wouldn't have expected such a big difference.... Let me dig
into this.

Roman


On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote:
> > 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
> 
> Not sure what you mean by "labor-intensive", Hans. Are you talking about
> manually changing 8 numbers per object (which took me less than 1 minute for
> 56 channels) or are you talking about cpu processing?
> 
> Which leads me to the next question: is the Boolean approach using [& 4] and
> [>> 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd
> handles such calculations and how it talks to the cpu. I'd be really very
> interested to find out if there is a difference.
> 
> 
> Since the pin numbers are predefined when you are using a [route] object to
> sort out the groups I don't see the point why the pin number should be
> calculated again (in this case of multiple instances). This is why I
> hardcoded them into the message boxes.
> 
> I put the two approaches next to each other to see how much simpler my
> approach is object wise and calculation wise. Still with the question mark
> which calculation method is more cpu friendly. Anyway changing [mod 8] and
> [div 4] to [& 4] and [>> 2] shouldn't take more than a minute.
> 
> The main difference to Romans approach is that it uses more fixed code to
> end up doing less when actually working.
> 
> BTW I think Romans approach makes generally more sense for most cases since
> it is scalable and does not need any different code for any number of pins
> (up to 128 in the current version) which makes it much simpler to use.
> 
> I have attached a patch that shows the difference between the two debyte
> methods.
> 
> Ingo