My question was prompted by the fact that Hans' OSX installer no longer had zexy.pd_darwin compiled as a library. He is now packaging individual externals from zexy separately. I have now placed zexy.pd_darwin in my extras folder and am comfortable, although as an advocate for other users I am wondering why the change has been made.
Also, thanks for everyone who reminded me that I could load the libraries in each patch rather than through Startup. I think I will adopt this practice from now on for ease of use for the people I design software.
I am not terribly concerned about my own RAM usage, although the slow Pd startup time with zexy did irritate me slightly. I do design audio software for other people to use, however, and like to maximize the use of their systems. I know zexy isn't a big memory hog; I was just trying to understand a little better about how things worked.
Mr. Steiner, awesome job with the Help menu! That's exactly what I have been waiting for. When I get some time on Turkey Day when everyone is napping, maybe I will take a look at your scripts to see how you got the nested menus to work right.
sb
On Nov 23, 2005, at 10:31 AM, IOhannes m zmoelnig wrote:
Burt wrote: So, what solutions do I have for my problem? If I cannot put more than ten zexy externals to load at startup, do I need to just put zexy.pd_darwin back into my extras folder and load it? While creating objects neamed [Gem] or [pmpd] might work, [zexy] won't do anything until I have zexy.pd_darwin in my extras folder. This leads me to my last question: libraries and externals (like [z~]) can be loaded through the Startup script, while only libraries can be loaded with a [library] object being placed in a patch, right?
no it is far simpler. if a library is compiled as single externals (like zexy in the pd-extended) you have a dll (in your case .pd_darwin) for each object. the first time you create a [z~] object, the z~.pd_linux will get loaded and that's it. you don't have to bother about loading zexy (as a whole lib, which doesn't exist in the extended-build) at all, as long as the .pd_darwin files you need are in a searched place (e.g. extra/). that's the idea of splitting a library up into single externals.
I appreciate having all the zexy objects separated to keep the RAM usage down, but it seems to complicate things a bit. Unless anyone has a better solution, I'm just going to stick zexy.pd_darwin back in my extras folder and load that.
you must be _very_ low of RAM is this is a concern to you. the zexy.pd_linux is about 148k big, the zexy.pd_darwin might be bigger, but i doubt if it is larger than 300k.
in theory it should be totally transparent, so i don't understand your problem at all. (i understand that you might be bothered by the error pd throws, when it fails to load zexy.pd_darwin; but have you tried to create [z~]?).
the only problem that might arise is, if you have a nameclash (namely cyclone might be a problem); you only have to make sure the nameclashing objects you want from zexy are loaded before any other library; this you can do via the startup-flags (if you want to load the offending lib via startup flags)
additionally you could try to specify more than 10 libraries at startup by using this notation: "cyclone:Gem:toxy" in 1 single slot. (i haven't tested whether this works, but i don't see a reason why it shouldn't)
mfg.adr. IOhannes
again it is one of these days where i can't stop answering...
Burt wrote:
My question was prompted by the fact that Hans' OSX installer no longer had zexy.pd_darwin compiled as a library. He is now packaging individual externals from zexy separately. I have now placed zexy.pd_darwin in my extras folder and am comfortable, although as an advocate for other users I am wondering why the change has been made.
but what was your actual problem? or was there none?
hans is splitting up the externals because:
- it could be a way to allow users resolv nameclashes (but then i think
that most users of the pd-extended installer will not dig into the depths of the bundle to exchange the binaries of this external against that one)
- because with externals the users need not think about loading a
library to get a special object. they just load the object.
- ...
mfg.asdr. IOhannes
IOhannes m zmoelnig wrote:
- because with externals the users need not think about loading a
library to get a special object. they just load the object.
- ...
Surely it would be better if an external that needs some library functionality should be able on its own to silently load the library, so for instance making a [gemhead] would automatically load Gem. Is this what you mean?
Martin
seems like i have a frog in my mouth that turns all the words i write to something else.
Martin Peach wrote:
IOhannes m zmoelnig wrote:
- because with externals the users need not think about loading a
library to get a special object. they just load the object.
- ...
Surely it would be better if an external that needs some library functionality should be able on its own to silently load the library, so for instance making a [gemhead] would automatically load Gem. Is this what you mean?
no.
if a library is borken up into externals (like zexy in the pd-extended), it is no longer a "library" in the sense of 1 big file containing all the objects. a better term would be "collection": it is just a punch of objects that happen to belong together for various reasons (e.g. functionality; but also such triviata like "once being objects provided by the zexy.dll")
so: in pd-extended there is no zexy library but there is a zexy collection of objects (externals/abstractions) like [z~], [limiter~] and [niagara].
use these objects; you don't have to know anything about "zexy" (whether it is whatever); the object gets loaded on demand (when you create it).
mfg.asd.r IOhannes
On Nov 23, 2005, at 11:02 AM, Burt wrote:
My question was prompted by the fact that Hans' OSX installer no
longer had zexy.pd_darwin compiled as a library. He is now packaging
individual externals from zexy separately. I have now placed
zexy.pd_darwin in my extras folder and am comfortable, although as an
advocate for other users I am wondering why the change has been made.
The zexy lib stopped compiling for me, so since the objects are already
included, I didn't spend any time trying to fix the lib compiling. If
someone fixes it, I have no problem including the zexy lib.
Also, thanks for everyone who reminded me that I could load the
libraries in each patch rather than through Startup. I think I will
adopt this practice from now on for ease of use for the people I
design software.I am not terribly concerned about my own RAM usage, although the slow
Pd startup time with zexy did irritate me slightly. I do design audio
software for other people to use, however, and like to maximize the
use of their systems. I know zexy isn't a big memory hog; I was just
trying to understand a little better about how things worked.
There is a problem with MIDI on OSX that causes slow startups. If you
are taking a delay like 5 seconds longer, that's more likely the MIDI
bug than the libs loading.
Mr. Steiner, awesome job with the Help menu! That's exactly what I
have been waiting for. When I get some time on Turkey Day when
everyone is napping, maybe I will take a look at your scripts to see
how you got the nested menus to work right.
Thanks! Recursion is the key! I love recursion! ;) Actually, the
Help menu is a temporary measure, the grand plan is to have a help
browser that uses meta data to catalog and organize the info. But for
now the help menu will have to do. Now I need to get it working on
Linux and Windows...
.hc
On Nov 23, 2005, at 10:31 AM, IOhannes m zmoelnig wrote:
Burt wrote: So, what solutions do I have for my problem? If I cannot put more
than ten zexy externals to load at startup, do I need to just put
zexy.pd_darwin back into my extras folder and load it? While creating
objects neamed [Gem] or [pmpd] might work, [zexy] won't do anything
until I have zexy.pd_darwin in my extras folder. This leads me to my
last question: libraries and externals (like [z~]) can be loaded
through the Startup script, while only libraries can be loaded with a
[library] object being placed in a patch, right?no it is far simpler. if a library is compiled as single externals (like zexy in the
pd-extended) you have a dll (in your case .pd_darwin) for each object. the first time you create a [z~] object, the z~.pd_linux will get
loaded and that's it. you don't have to bother about loading zexy (as a whole lib, which
doesn't exist in the extended-build) at all, as long as the .pd_darwin
files you need are in a searched place (e.g. extra/). that's the idea of splitting a library up into single externals.I appreciate having all the zexy objects separated to keep the RAM
usage down, but it seems to complicate things a bit. Unless anyone
has a better solution, I'm just going to stick zexy.pd_darwin back in
my extras folder and load that.you must be _very_ low of RAM is this is a concern to you. the zexy.pd_linux is about 148k big, the zexy.pd_darwin might be
bigger, but i doubt if it is larger than 300k.in theory it should be totally transparent, so i don't understand your
problem at all. (i understand that you might be bothered by the error
pd throws, when it fails to load zexy.pd_darwin; but have you tried to
create [z~]?).the only problem that might arise is, if you have a nameclash (namely
cyclone might be a problem); you only have to make sure the
nameclashing objects you want from zexy are loaded before any other
library; this you can do via the startup-flags (if you want to load
the offending lib via startup flags)additionally you could try to specify more than 10 libraries at
startup by using this notation: "cyclone:Gem:toxy" in 1 single slot.
(i haven't tested whether this works, but i don't see a reason why it
shouldn't)mfg.adr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
The zexy lib stopped compiling for me, so since the objects are already
included, I didn't spend any time trying to fix the lib compiling. If
someone fixes it, I have no problem including the zexy lib.
now that would be interesting for me to know.
mfg.asdr IOhannes
-
Burt -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach