On Nov 9, 2009, at 2:42 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
This is what we saw with the introduction of [pow~] to Pd-vanilla.
Many people were using cyclone's [pow~] before. Since Pd-vanilla's
pow~ is built into the pd binary, there is no way to use an
abstraction called 'pow~.pd', and it even overrides pow~.pd_linux.
Sure, but can't you still use -lib to load your own pow~.d_fat in Pd
since 0.42 (which would print "warning: renamed old pow~ to
pow~_aliased" or similar)? Or am I completely missing the meaning
of those printouts?
I am not positive how that mechanism works. Based on my understanding
of it, you could force it to load a particular object class (i.e.
cyclone's pow~) using the pd -lib technique you mention, provided that
object class is a binary, and not an abstraction. If the problem
involved an abstraction being overridden by a pd internal, you are
shit-out-of-luck.
So its not really a solution to the aforementioned problem. There are
other issues with that aliasing technique as discussed in the
archives. For these reasons, the auto-aliasing is disabled in Pd-
extended 0.42.5, but we still need to figure out how to deal with the
new pd-internal [pow~] and its conflict with cyclone's [pow~].
The only way to maintain compatibility that has been proven is to
use the same versions of everything.
Exactly - no need to care too much about backwards compatibility,
because you could always use pd-0.38-devel for your old patches and
pd-0.43-guirewrite for your current patches and pd-0.44 for your
next decade patches...
The missing piece here is an auto-upgrade tool for pd patches,
similar to what lilypond uses:
http://lilypond.org/doc/v2.9/Documentation/user/lilypond/Updating-files-with-convert_002dly
Personally, I think we can improve the situation quite a bit, that's
why I wrote that paper for PdCon. Of course, sticking to the same
versions of everything is the only guarantee, but we can do a lot to
avoid incompatibilities.
The simplest one is making it so that externals and abstractions
included in the same folder as a patch have precedence over all
others, including pd-internals. That way you can stick your own
[pow~] in the same folder as your project, and you'll always know its
your [pow~] in use.
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
