[PD-dev] multichannel signals, preliminary support

[Miller Puckette]

Quick responses to below...
> 

> - 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")
> 

Good idea, and this needs to be a more general strategy somehow.

> - 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)
> 

yep.  I was even thinking of putting "overlap" as a separate (public)
member, but then again i couldn't think of how to use it compatibly in
vanilla objects so ended up not doing it.  But if that would be useful
perhaps I should add support.

> - 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)
> 
This is so that externs can call "class_setdspflags()" explicitly if
they use the new features - older pd versions won't load them and crash.

> - 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.
> 
The use case is a bit rare... if someone puts a scalar in the left inlet
of a binop (like zero into "-" to negate a number) this allows the
binop to use a scalar operation and save a wee bit of compute time.
Not sure if this is ever going to matter.

> - [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.
> 
Hmm... well, old patches should run OK if the lib is explicitly loaded.
But it's a bother that new patches that pull zexy in explicitly won't
be able to use pack~ and unpack~.  The best solution I can think of is
to either find a different (unused) name for the new pack~/unpack~ or
to offer a new name to zexy's versions (and keep the old ones too, perhaps
in a separate "library").

> vmgs
> IOhannes




> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev