[PD-dev] multichannel signals, preliminary support

[IOhannes m zmoelnig]

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>