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