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 > [email protected] > https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
