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