Hey,
I am cc'ing the Pd list with the discussion about [import] since I
think it is of general interest.
On Sep 17, 2008, at 3:46 AM, Phil Stone wrote:
Hey Hans,
Thanks for replying.
I'm [import]ing mrpeach and cyclone -- I'm using svf~ from cyclone
and some mrpeach OSC objects at least once for each polyphonic
instantiation of synthesizer voice. Are [import]ed "libdir style"
objectclasses loaded once and shared by all instances, or loaded
once for each instance?
The state of namespaces is currently a work in progress. So with
abstractions, using import means that they are loaded into the parent
patch's canvas-local namespace only. But with binary/compiled
externals, once they are loaded, they are loaded globally. I plan on
focusing on fixing this stuff later this year for the next Pd-
extended release.
Are mrpeach and cyclone libdir-style libraries?
In Pd-extended, yes.
Can I ask your recommendation for the best way to do external- inclusion in this (auto-generated poly-objects) situation? I'll
stick with [import] if it is not some kind of performance or memory
hit, but I don't fully understand the trade-offs, if any.
There aren't really any major performance considerations here that I
am aware of. Mostly it is about ensuring that your patch will work
on the widest array of computers. If you want to guarantee that you
always get the right object, then use a namespace prefix, like
[cyclone/prepend]. Then you'll always get cyclone's prepend no
matter how the person's Pd-extended is setup, or what [import]s are
used. For Pd-vanilla users, they would just need to have cyclone
installed as individual files per object-class in "extra/cyclone" and
it would work the same (i.e. by copying "extra/cyclone" from Pd-
extended, or building it themselves).
.hc
Phil
Hans-Christoph Steiner wrote:
Hey,
Sorry, I am super slammed at the moment. Whether it loads it into
memory depends on the library type. With the old single-file- multiple-objectclass format, like Gem, PDP, etc. the whole thing
is indeed loaded into memory. With the "libdir" style, no
objectclass is loaded into memory until you use it..hc
On Sep 16, 2008, at 7:09 PM, Phil Stone wrote:
Hi Hans,
Sorry to bug you directly on this, but I think my question got
lost in the noise, and I'm trying to figure this out before I
release a big chunk of abstraction to the Pd community (another
polyphonic synthesizer, granular this time).Re-iterating my question from below: when [import] says "loaded
library: blah", is that literally what it's doing, loading the
library into memory, once for every one of the messages in a
multiple [import] situation as described below?I doubt that it is, as that would be incredibly inefficient, but
I would like to make sure.Thanks,
Phil
multiple copies of cyclone (for instance, as below) are not
really getting loaded are they? Pardon my ignorance of the
mechanics of [import].Phil
Phil Stone wrote:
I'm using [import] on an abstraction (as discussed earlier);
this > abstraction does some automatic object instantiation
(via [polypoly]) > and each of the generated objects has an
[import ...] in it. This leads > to a barrage of console
output, like:[import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local
objectclass path
libdir_loader: added 'cyclone' to the canvas-local
objectclass path
[import] loaded library: 'cyclone' libdir_loader: added 'cyclone' to the canvas-local
objectclass path
libdir_loader: added 'cyclone' to the canvas-local
objectclass path
. . . (repeat for number of voices created by [polypoly].
"Free software means you control what your computer does. Non-free
software means someone else controls that, and to some extent
controls you." - Richard M. Stallman
There is no way to peace, peace is the way. -A.J. Muste