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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev