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)