[PD-dev] help designing multichannel aware externals
Christof Ressi
info at christofressi.com
Wed Jan 25 23:17:27 CET 2023
The implementation of signal_setoutchans() looks good to me! There is
indeed no danger of breaking signal aliasing. Since the dummy output
signals are "empty" (s_nchans = 0), they are allocated from the "borrow"
free list and not from the "real" free list. Nice :-)
I think signal_setoutchans() is quite elegant and pleasant to use. Thanks!
Christof
On 25.01.2023 18:04, info at christofressi.com wrote:
> > yep - and in fact I need length to be correct, otherwise there's no
> easy way
> to get it.
>
> That's what I was hinting at :-)
>
> I find the empty signal quite elegant. Only s_nchans and s_vec are 0,
> the rest stays intact. This makes sense conceptionally because
> s_nchans * s_length is still 0.
>
> > sp[2] = signal_makemultichannels(sp[2], outchans);
>
> I like this! I think the naming is very descriptive.
>
> Christof
>
> Am 25.01.2023 17:39 schrieb Miller Puckette via Pd-dev
> <pd-dev at lists.iem.at>:
>
> On Wed, Jan 25, 2023 at 05:34:48PM +0100, IOhannes m zmoelnig wrote:
>
> > conceptually, i like this; though i would suggest "channels=0;
> length=64"
> > (or whatever).
> >
> yep - and in fact I need length to be correct, otherwise there's
> no easy way
> to get it.
>
> > > and instead of (for example)
> > > sp[2] = signal_swapforchans(sp[2], outchans);
> > > you'd just write
> > > signal_setchans(sp[2], ouchans).
> >
> > hmm, wouldn't that modify the t_signal* struct that sp[2] points
> to,
> > potentially breaking the reuse? (so it ought to be
> "signal_setchans(&sp[2],
> > outchans)")
> >
> I _think_ it works just to pass sp[2] in place - it's a (t_signal
> *) and
> all that's needed is to alter member element s_vec, s_nchans.
>
> > and i find the "swapforchans" slightly confusing (which fo(u)r
> channels are
> > being swapped? the actual swapping is done by re-assigning a new
> value to
> > sp[2]).
> > so how about:
> > sp[2] = signal_makemultichannels(sp[2], outchans);
> >
> so this would become moot.
> >
>
>
>
>
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230125/53b3d704/attachment-0001.htm>
More information about the Pd-dev
mailing list