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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list