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 > >> > >> > >> _______________________________________________ > >> [email protected] mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
