Re: [PD-dev] tilde object rework ideas

2022-09-03 Thread info
But for SIMD to be fun, data should be interleaved...Yes and no.While interleaved channels would certainly help with "channel-wise" vectorization, it would make things *worse* for multi-channel "block-wise" vectorization. IMO, any object that can do block-wise vectorization would likely do so with

Re: [PD-dev] tilde object rework ideas

2022-09-03 Thread IOhannes m zmölnig
(re-sending to the list) Am 2. September 2022 20:12:54 MESZ schrieb Miller Puckette via Pd-dev : 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

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Christof Ressi
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

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Miller Puckette via Pd-dev
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

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Alexandre Torres Porres
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.

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Antoine Rousseau
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 >

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Dan Wilcox
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

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread Antoine Rousseau
> 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, > >

Re: [PD-dev] tilde object rework ideas

2022-09-02 Thread IOhannes m zmoelnig
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

Re: [PD-dev] tilde object rework ideas

2022-09-01 Thread Christof Ressi
Hi Miller, this sounds great! First-class multi-channel support would be a real game changer. Actually, after Winfried Ritsch told me about the "pd_snake" project, I came up with a couple of ideas on my own. You can find them here:

[PD-dev] tilde object rework ideas

2022-09-01 Thread Miller Puckette via Pd-dev
Hi Pd dev - I'm preparing to rework the DSP network to give tilde objects more control over their inputs and outputs, for instance allowing for multi-channel signals and to allow objects to decide for themselves whether to promote float inputs to signals (so that you don't have to say "+~ 0 to