[PD] pduino rewrite

[Ingo]

> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: arduino-debyte_comparison.pd
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110916/573676d4/attachment.txt>