[PD] array size (was Re: arraysize)
Miller Puckette
msp at ucsd.edu
Tue Oct 2 23:09:08 CEST 2012
I'm not sure that any of the Windows, MaacOS, and linux dynamic loading
systems will support having multiple versions of a library loaded in the
same address space. But here's a simpler way anyhow: libraries such as
vanilla could maintain compatibility by querying the version number of
the patch at run time.
In the case of hip~ I'm genuinely not sure whether the "correct" behavior
would then be to revert to the old behavior for all old patches or only on
request. The confusing scenario I worry about is that you have a patch with
an old hip~ object in it, save it from 0.44, and then have it switch to the
new behavior next time it's loaded.
I think I have found ad hoc ways to fix the other problems without breaking
old patches.
cheers
Miller
n Tue, Oct 02, 2012 at 11:36:47AM -0400, Hans-Christoph Steiner wrote:
>
> I think having a compatibility version stamp in the patch is a good
> idea. This ties in well with the experiments I've been doing with
> splitting out all of the objects from pd itself. If all of the core
> objects are a standard library, then that means its easy to choose which
> version of the standard library that a patch is using. In Pd-extended,
> this is called the 'vanilla' lib, and its been included in some form
> since 0.42.
>
> Then if a patch has a compatibility version stamp in it, Pd can
> automatically look to see if it has a copy of that version of the
> standard library, and load it. Otherwise, it would load the version
> closest to that, and throw a warning, or optionally that could be
> considered an error.
>
> To make this work well, the key missing feature is the ability to change
> which loaded library an object name maps to in the canvas-local
> namespace. Currently, once an object name is mapped to a loaded
> .pd_linux, that is a global association. This is needed so that patches
> using different standard libs can be open at the same time.
>
> Then making the versioned standard libs would be pretty easy, mostly
> just bundling the right .c files into a lib.
>
> .hc
>
>
> On 10/02/2012 11:15 AM, Miller Puckette wrote:
> > This is in my long-range plan but hasn't yet risen to the level of "urgent".
> > However, this migth be a good moment to get started on this because several
> > other backward- and even forward-imcompatible needs are also rising to the
> > fore:
> >
> > 1. there's a bug in hip~ - its DC gain is slightly (and possibly considerably)
> > greater than 1. "fixing" this will change the audio output of older patches,
> > usually much too slightly to matter, but there will have to b a "-pre-0.44-hip"
> > flag or something to allow strict back compatibility;
> >
> > 2. There's no place in the pre-0.43 file format to alow specifying individual
> > box widths and font sizes; I put an "f" (=format) message to the canvas
> > object in 0.43 so that in 0.44 I can make it set font size and box width and
> > perhaps leave an opening for other formatting info.
> >
> > 3. the upsampling inlet~ by default zero-pads its input. This is incorrect as
> > its DC gain is less than one. (Try using that as input to a phasor~ for
> > instance - bad surprise!) I want to change the default so that it acts like
> > a sample-and-hold, which I believe is an option now. To preserve back
> > compatibility I'd keep all the "upsampling methods" in place but only change
> > default behavior for patches with a 0.44 or later version stamped on them.
> >
> > Each of these presents a different spin on the age-old issue of keeping
> > total back compatibility in place, even when the compatibility is to preserve
> > a big as in (1) and (3) - and arguably in the file searching too; I'm not sure
> > whether to regard that as a bug or just over-hasty design.
> >
> > cheers
> > Miller
> >
> >>
> >> Here's a good sketch of the idea
> >> (http://puredata.info/dev/PdSearchPath):
> >>
> >>
> >> Proposed Functionality
> >>
> >> for path in paths do -- the core does this bit
> >> for loader in loaders do
> >> loader(path, library, object)
> >>
> >>
> >> Existing Functionality
> >>
> >> for loader in loaders do
> >> for path in paths do -- the loader does this bit
> >> loader(path, library, object)
> >>
> >> .hc
> >>
> >>
> >> _______________________________________________
> >> Pd-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list
mailing list