[PD] PD n00b: counter kludge

[Krzysztof Czaja]

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)