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
Yep, s_nframes is best.
To Iohannes's point (s_n, s_nframes, and s_channels are redundant) , s_n needs
to be kept in the struct, and
then we could either have s_nframes, or s_nchannels,
in which case you'd get the other one by dividing.?? I have a deep horror of
integer division (if you ever
This would be like 'mc' objects in MAX, right? That's awesome!
btw, I see merging season has started, I already updated some documentation
files to include the merged changes, please consider merging that soon as
well. https://github.com/pure-data/pure-data/pull/1594
cheers
Em sex., 2 de set.
Sorry forget it, "frames" actually corresponds with the comment
/* number of points in each channel */".
Le ven. 2 sept. 2022 à 10:55, Antoine Rousseau a
écrit :
> > probably "s_length" might be called "s_frames"
>
> I'm not sure about that: in many APIs the word "frame" means one
>
Howdy Miller,
Multi-channel will be very useful, especially in the context of some of the
sound spatialization work we have used libpd for at ZKM. A good idea from
Ableton/Max which we can profit from as well. :)
I agree with the naming suggestion from IOhannes.
The CoreAudio API also uses
> probably "s_length" might be called "s_frames"
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.
Le ven. 2 sept. 2022 à 09:36, IOhannes m zmoelnig a
écrit :
> On 9/2/22 01:00, Christof Ressi wrote:
> > Hi Miller,
> >
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
