On 9/2/22 01:00, Christof Ressi wrote:
Hi Miller,

this sounds great! First-class multi-channel support would be a real game changer.


yes. that would be so cool!


typedef struct _signal
{
     int s_n;            /* *TOTAL* number of points in the array */
     t_sample *s_vec;    /* the array */
     t_float s_sr;       /* *TOTAL* samples per second */
[...]
     t_float s_rate;     /* sample rate */
     int s_length;       /* number of points in each channel */
     int s_nchans;       /* number of channels */
     int s_overlap;      /* number of times each sample will appear */
}
Personally, I would keep s_n as the number of samples /per channel/. The total number of samples is simply s_n * s_nchans. Existing externals - that do not know about s_nchans - would effectively operate on the first

i think the idea is that with "s_n = s_nchans * s_length" existing externals would automatically process *all* channels.

that's nice if the external does not do any delays or so (as they would automatically become multi-channel aware), but not so nice if they *do* things in the time domain (as there would be weird cross-talk between the channels).

i'm not favouring any of the two approaches, just wanted to point their differences.

i somewhat agree with christof's implication, that it's probably best to not have redundant data in the struct.
- 's_n = s_nchans * s_length' (or 's_totalsamples = s_nchans * s_n')
- 's_sr = s_rate * s_overlap * s_nchans'

(my issue being, that with redundancy it's more likely to have inconsistent data; what if the struct says 's_n = 128; s_nchans = 3; s_length = 1024'?)

apart from that:
probably "s_length" might be called "s_frames" as this seems to be the less ambiguous term.

and i would personally prefer "s_samplerate" and "s_channels".
that would make for an easy distinction: the abbreviated names "s_n" and "s_sr" are the convoluted ones, whereas the long names have the data you'd expect.



channel and ignore the rest. Newer multi-channel-aware externals, on the other hand, may use all the channels.

I also think that DSP objects would need a new API method to create multi-channel /outputs/. The general idea is that the /input /channel counts are taken from upstream, but the /output /channel counts are specified by the object and passed downstream. (There might be objects where input and output channel count differs; any kind of merger/splitter/mixer objects comes to my mind.)

+1

vgmasdrf
IOhannes

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to