Hallo, Marc Lavallée hat gesagt: // Marc Lavallée wrote:

Of course I don't agree, since I prefer my patch... One problem with Frank's patch: the f object is indefinitely incremented.

Yep, you're right, but that is easy to fix by resetting the f object after one cycle. My patch was more intended as a proof of concept that shows an alternative way to reach the same goal.

ciao

Frank Barknecht _ ______footils.org__

Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:

yet another alternative: sending 'updown, carrybang' to a [counter 0 6], then reading from 2nd and 3rd outlet...

(ok, ok, just a plug to woo somebody into testing the beast...)

Cyclone/Hammer needs to get standard in Pd ;)

ciao

Frank Barknecht _ ______footils.org__

hi Thomas,

in a way, it is already there, using standard Pd arrays.

One can have multi-inlet record~, and multi-outlet play~ and wave~. So a [record~ t 8] would have 8 signal inlets (plus 2 control inlets) recording into arrays 0-t, 1-t, ..., 7-t, while a [record~ t] (without the second argument), would record into an array t. The 't' in the first case is a <namestub> argument.

There are also one-channel clients which adopt such naming scheme, i.e. those being multi-channel-aware in msp: index~, peek~, and poke~ may be given a numeric <channel> argument. If they are, an array <channel>-<namestub> will be used.

Other clients, cycle~ and lookup~, never take <namestub> argument, because they always use the first channel of a buffer~ in msp.

Btw, all these are in sickle, not hammer.

There is no buffer~ itself yet. I have not decided, if it should host its arrays ala Pd's [table], or rather use independent, separately created arrays. Besides, I am not sure, if I would like to start molesting Miller about declaring soundfiler stuff in the API, or rather try adopting vexing's sound file interface.

There are still three missing buffer~ clients: buffir~, groove~, and 2d.wave~. While buffir~ is almost ready (along with most of the filters), grroove~ is too buggy to be fun to clone, and it has to wait.

Krzysztof

Thomas Grill wrote: ...

(when) do you plan to implement buffer~ multichannel-functionality into hammer? (would be immediately supported by flext, too)

hi Thomas,

bear with my dumbness... do I understand well, that you are talking about making the cpu cache happy? Have you done real-world measurements?

Is making cpu happy worth making people unhappy with sacrificing the flexible, uniform, and standard Pd feature for a few cycles?

And, even if it was so... perhaps, it is more like time to think about introducing interleaved arrays into Pd's core, so that the soundfiler, tab<whatever>~, etc. are all aware of them?

Krzysztof

Thomas Grill wrote: ...

great that it works at all, but clearly it is far more efficient to use interleaved samples in one memory structure. I'm in the process of optimizing xsample's performance, therefore i'm interested in a more native implementation of Max's buffer~.