[PD] pduino rewrite

Roman Haefeli reduzent at gmail.com
Fri Sep 16 11:32:01 CEST 2011

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 was told that it is. Bit shifting and bit mask matching is supposed to
be faster than integer division and modulo with an arbitrary (inclusive
non-power-of-two integers). 
However, I can't tell you whether they are really faster in the real
world. But you should be able to test it in your own setup with
[realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million
numbers in 0 logical time, stop [realtime]. Do the same with a [& 4]-[>>
2] chain and compare the results.

>  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.

You could also test the whole [pd digital message] subpatch with the
above mentioned approach. 

Frankly, I'm not yet convinced that those little improvements in
[arduino] will significantly improve the overall Pd performance. Using
one less tilde object somewhere in your patch would save some order of
magnitudes of CPU power more of what you ever will be able to squeeze
out of the [arduino]. Message processing is usually so cheap compared to
signal processing, that most often it's hardly worth to focus on the
message processing part, unless you deal with message rates of several
thousands per second. This is certainly not always true, but in my own
experience it most often is. 


More information about the Pd-list mailing list