[PD-dev] multichannel signals, preliminary support
IOhannes m zmoelnig
zmoelnig at iem.at
Tue Jan 17 08:32:35 CET 2023
On 1/17/23 04:23, Miller Puckette via Pd-dev wrote:
> To Pd dev -
>
> I've pushed what I think is working support for multichannel signals.
this is huge.
thanks a lot.
random thoughts:
- the size of t_signal has changed. i think this is fine, as the
trailing members (affected by the change) are private only. i wonder
though whether this privateness should be made more explicit in the
m_pd.h (basically: add a line saying "hic sunt dracones: the following
members are private - DO NOT USE")
- since the t_signal members now have a bit of documentation, could we
just mention that s_sr has the overlap-factor pre-multiplied? (assuming
this will stay that way - which is most likely for backwards compatibility)
- why do we need a "class_setdspflags()"? (i'm not opposed; merely
wondering)
shouldn't those flags just go into class_new()? is it for symmetry
with class_getdspflags() which in turn is required to not expose the
internals of t_class? but then: d_ugen.c could already just directly
access t_class (via m_imp.h), and i wonder whether an external would
ever need the class_getdspflags() (or at least, an external that doesn't
otherwise need to access private data from m_imp.h)
- isn't CLASS_NOPROMOTELEFT somewhat redundant? e.g. the code could just
check whether there's an explicit "float" method for the class, and if
so automatically declare to not promote signals on the left.
- [pack~] and [unpack~] are of course natural names for these objects.
*unfortunately* i have added objects of the same name (but with
different functionality) to zexy about 23 years ago. (the objects
predate zexy's use of *any* VCS; but the copyright boilerplate says
2000/09/01 and i have no reason to distrust it).
so i expect that either old patches that use zexy's [pack~]/[unpack~]
are going to break, or the new multichannel [pack~]/[unpack~] won't be
usable if zexy is loaded as a multi-object library.
vmgs
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230117/4cd0ab7f/attachment-0001.sig>
More information about the Pd-dev
mailing list