<div dir="auto"><div>Sorry forget it, "frames" actually corresponds with the comment</div><div dir="auto"> /* number of points in each channel */".<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le ven. 2 sept. 2022 à 10:55, Antoine Rousseau <<a href="mailto:antoine@metalu.net">antoine@metalu.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>> probably "s_length" might be called "s_frames"</div><div dir="auto"><br></div><div dir="auto">I'm not sure about that: in many APIs the word "frame" means one "multi-channel sample", e.g 2 samples for a stereo stream.<br><div dir="auto"><br></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le ven. 2 sept. 2022 à 09:36, IOhannes m zmoelnig <<a href="mailto:zmoelnig@iem.at" target="_blank" rel="noreferrer">zmoelnig@iem.at</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/2/22 01:00, Christof Ressi wrote:<br>
> Hi Miller,<br>
> <br>
> this sounds great! First-class multi-channel support would be a real <br>
> game changer.<br>
<br>
<br>
yes. that would be so cool!<br>
<br>
<br>
>> typedef struct _signal<br>
>> {<br>
>>      int s_n;            /* *TOTAL* number of points in the array */<br>
>>      t_sample *s_vec;    /* the array */<br>
>>      t_float s_sr;       /* *TOTAL* samples per second */<br>
[...]<br>
>>      t_float s_rate;     /* sample rate */<br>
>>      int s_length;       /* number of points in each channel */<br>
>>      int s_nchans;       /* number of channels */<br>
>>      int s_overlap;      /* number of times each sample will appear */<br>
>> }<br>
> Personally, I would keep s_n as the number of samples /per channel/. The <br>
> total number of samples is simply s_n * s_nchans. Existing externals - <br>
> that do not know about s_nchans - would effectively operate on the first <br>
<br>
i think the idea is that with "s_n = s_nchans * s_length" existing <br>
externals would automatically process *all* channels.<br>
<br>
that's nice if the external does not do any delays or so (as they would <br>
automatically become multi-channel aware), but not so nice if they *do* <br>
things in the time domain (as there would be weird cross-talk between <br>
the channels).<br>
<br>
i'm not favouring any of the two approaches, just wanted to point their <br>
differences.<br>
<br>
i somewhat agree with christof's implication, that it's probably best to <br>
not have redundant data in the struct.<br>
- 's_n = s_nchans * s_length' (or 's_totalsamples = s_nchans * s_n')<br>
- 's_sr = s_rate * s_overlap * s_nchans'<br>
<br>
(my issue being, that with redundancy it's more likely to have <br>
inconsistent data; what if the struct says 's_n = 128; s_nchans = 3; <br>
s_length = 1024'?)<br>
<br>
apart from that:<br>
probably "s_length" might be called "s_frames" as this seems to be the <br>
less ambiguous term.<br>
<br>
and i would personally prefer "s_samplerate" and "s_channels".<br>
that would make for an easy distinction: the abbreviated names "s_n" and <br>
"s_sr" are the convoluted ones, whereas the long names have the data <br>
you'd expect.<br>
<br>
<br>
<br>
> channel and ignore the rest. Newer multi-channel-aware externals, on the <br>
> other hand, may use all the channels.<br>
> <br>
> I also think that DSP objects would need a new API method to create <br>
> multi-channel /outputs/. The general idea is that the /input /channel <br>
> counts are taken from upstream, but the /output /channel counts are <br>
> specified by the object and passed downstream. (There might be objects <br>
> where input and output channel count differs; any kind of <br>
> merger/splitter/mixer objects comes to my mind.)<br>
<br>
+1<br>
<br>
vgmasdrf<br>
IOhannes<br>
_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at" rel="noreferrer noreferrer" target="_blank">Pd-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
</blockquote></div></div></div>
</blockquote></div></div></div>