When using Pd-0.38.4-extended-RC3, I would like to load several of the zexy externals. Previously, I would just put zexy in the "Pd binaries to load" preference setting which of course would add lines to the plist in my Preferences so the externals in zexy.pd_darwin would load. Now that we've decided to have separately compiled zexy externals in the extra folder instead of one big zexy.pd_darwin, how would I tell Pd to load them when the Startup options only give me ten slots? Say I wanted to load Gem, xsample, vasp, dyn~ pmpd, cyclone, memento, toxy, limiter~, zexy~, and envrms~. Can I specify some libraries as startup flags? Is it bad form to load more libraries than one is actually using in any given patch? Should there be some way of specifying which libraries to load with each patch?
Also, when I used to load the full zexy.pd_darwin, my Pd startup time was fairly slow. I didn't really test not loading zexy, but I have noticed that this new Pd extended loads faster. Were the zexy externals one reason load-time took so long? Do extra externals effect Pd's performance? I'm wondering if anyone's done any tests.
samuel burt
On Nov 22, 2005, at 10:31 PM, Burt wrote:
When using Pd-0.38.4-extended-RC3, I would like to load several of the
zexy externals. Previously, I would just put zexy in the "Pd binaries
to load" preference setting which of course would add lines to the
plist in my Preferences so the externals in zexy.pd_darwin would load.
Now that we've decided to have separately compiled zexy externals in
the extra folder instead of one big zexy.pd_darwin, how would I tell
Pd to load them when the Startup options only give me ten slots? Say
I wanted to load Gem, xsample, vasp, dyn~ pmpd, cyclone, memento,
toxy, limiter~, zexy~, and envrms~. Can I specify some libraries as
startup flags? Is it bad form to load more libraries than one is
actually using in any given patch? Should there be some way of
specifying which libraries to load with each patch?
There are a few solutions in the works for this. Günter Geiger's
[using] object would be quite nice, it allows you to load libs from a
patch (i.e. [using zexy]. Then, I plan on redoing the preference
panels so that they are more usable, including unlimited paths and libs
fields.
Its not a big deal to load all the libs, it'll just take longer to
start, and use up more RAM.
Also, when I used to load the full zexy.pd_darwin, my Pd startup time
was fairly slow. I didn't really test not loading zexy, but I have
noticed that this new Pd extended loads faster. Were the zexy
externals one reason load-time took so long? Do extra externals
effect Pd's performance? I'm wondering if anyone's done any tests.
With objects compiled individually, the code is only loaded when it is
used. With a lib, the whole lib is loaded on startup. So yes, not
have a lib will make it startup quicker
.hc
samuel burt
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
Hallo!
There are a few solutions in the works for this. Günter Geiger's
[using] object would be quite nice, it allows you to load libs from a
patch (i.e. [using zexy]. Then, I plan on redoing the preference
well, this would be useful, but whats the difference from [using zexy] to [zexy] - it also loads the lib because most libs implemented such a dummy object (or at least some) ?
anyway, I often make a [pd include] subpatch and there I put [zexy], [iemlib1], [PDContainer], ... but the problem is, that it's hard to load the libs in the right order (to avoid nameclashes) - so for [using zexy] there should be maybe an other argument, which influences the sequence of loading different external libs ...
e.g.: [using zexy 1] will be loaded before [using iemlib 4], ...
LG Georg
Georg Holzmann wrote:
Hallo!
well, this would be useful, but whats the difference from [using zexy] to [zexy] - it also loads the lib because most libs implemented such a dummy object (or at least some) ?
note that the library does not have to implement an object of the same name. e.g. there is no [Gem] object in Gem, but you still can load Gem by creating an object [Gem]: the creation will fail but Gem will be loaded.
so you are correct, that using [using] just for library loading is a bit of an overhead (especially since people tend to externals instead of libraries)
i think that the [using] object should automatically add (an optional) library-prefix to objects that cannot be found. imagine you have a patch that contains [using zexy] (how comes this discussion always concentrates on my libraries...) and [nop]. since pd cannot find a [nop] object anywhere in it's space, it would try to find [zexy/nop] which eventually is an abstraction ./extra/zexy/nop.pd and thus can be resolved and loaded.
mfg.asd.r IOhannes
oops, i see we are in the never ending namespace discussion again and thus change the subject accordingly
Hallo!
note that the library does not have to implement an object of the same name. e.g. there is no [Gem] object in Gem, but you still can load Gem by creating an object [Gem]: the creation will fail but Gem will be loaded.
yes, an other problem is, that e.g. [zexy] has to be created before [nop] ...
i think that the [using] object should automatically add (an optional) library-prefix to objects that cannot be found. imagine you have a patch that contains [using zexy] (how comes this discussion always concentrates on my libraries...) and [nop]. since pd cannot find a [nop] object anywhere in it's space, it would try to find [zexy/nop] which eventually is an abstraction ./extra/zexy/nop.pd and thus can be resolved and loaded.
yes, two things about that:
abstractions is not guaranteed - there could be nameclashes ...)
python "import nop from zexy" or in C++ "using zexy::nop" ...)
(but I think we already discussed this ...)
LG Georg
Georg Holzmann wrote:
Hallo!
note that the library does not have to implement an object of the same name. e.g. there is no [Gem] object in Gem, but you still can load Gem by creating an object [Gem]: the creation will fail but Gem will be loaded.
yes, an other problem is, that e.g. [zexy] has to be created before [nop] ...
that's an important point. [using] should be guaranteed to be called before any other object in the patch. and as you ahve pointed out in your previous mail, having a way to specify the order of [using]s would be nice too.
yes, two things about that:
- this should be local to each abstraction (otherwise reausability of
abstractions is not guaranteed - there could be nameclashes ...)
but hard to do...
- there should also be a way to not load all externs of a lib (like in
python "import nop from zexy" or in C++ "using zexy::nop" ...)
(but I think we already discussed this ...)
that's why it's a zombie.
mfg.adr IOhannes
On Nov 23, 2005, at 5:12 AM, Georg Holzmann wrote:
Hallo!
note that the library does not have to implement an object of the
same name. e.g. there is no [Gem] object in Gem, but you still can
load Gem by creating an object [Gem]: the creation will fail but Gem
will be loaded.yes, an other problem is, that e.g. [zexy] has to be created before
[nop] ...i think that the [using] object should automatically add (an
optional) library-prefix to objects that cannot be found. imagine you have a patch that contains [using zexy] (how comes this
discussion always concentrates on my libraries...) and [nop]. since pd cannot find a [nop] object anywhere in it's space, it would
try to find [zexy/nop] which eventually is an abstraction
./extra/zexy/nop.pd and thus can be resolved and loaded.yes, two things about that:
- this should be local to each abstraction (otherwise reausability of
abstractions is not guaranteed - there could be nameclashes ...)
Yes, for sure. But that'll be a much bigger project. For now, [using]
will probably just use the same mechanism as loading a lib with -lib or
whatever.
- there should also be a way to not load all externs of a lib (like in
python "import nop from zexy" or in C++ "using zexy::nop" ...)
The libdir format/geiger namespaces do this if the objects are
individual files. i.e. [zexy/drip]. This is one of the many reasons
why the Pd-extended builds avoid the old lib format whenever possible.
.hc
(but I think we already discussed this ...)
LG Georg
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos
Williams
Hallo!
- there should also be a way to not load all externs of a lib (like
in python "import nop from zexy" or in C++ "using zexy::nop" ...)
The libdir format/geiger namespaces do this if the objects are
individual files. i.e. [zexy/drip]. This is one of the many reasons
why the Pd-extended builds avoid the old lib format whenever possible.
yes, I know that this is possible, but (again) it is in some cases simply not possible/meaningful to make for each object an individual binary, and I was thinking about that ...
LG Georg
On Nov 23, 2005, at 12:35 PM, Georg Holzmann wrote:
Hallo!
- there should also be a way to not load all externs of a lib (like
in python "import nop from zexy" or in C++ "using zexy::nop" ...)
The libdir format/geiger namespaces do this if the objects are
individual files. i.e. [zexy/drip]. This is one of the many reasons
why the Pd-extended builds avoid the old lib format whenever
possible.yes, I know that this is possible, but (again) it is in some cases
simply not possible/meaningful to make for each object an individual
binary, and I was thinking about that
Please describe a situation where its not possible and one where its
not meaningful. I don't see it at all. If you are talking about
sharing code among objects, you can do this with a DLL/shared lib. For
an example, Thomas got his flext externals working this way in
Pd-extended: each object is its own file, but flext is a shared lib.
As for meaningful, I can't think of an example where the meaning of the
objects are related to the format that they are stored and loaded from
the filesystem.
.hc
"Information wants to be free." -Stewart Brand
Hallo!
Please describe a situation where its not possible and one where its
not meaningful. I don't see it at all. If you are talking about
sharing code among objects, you can do this with a DLL/shared lib. For
an example, Thomas got his flext externals working this way in
Pd-extended: each object is its own file, but flext is a shared lib.
hm, okay, of course, that's possible ...
just an example: PDContainer.pd_linux has 528kB here on my system, if I compile only one object: e.g. h_map.pd_linux has 213kB - so the half of the whole lib (and there are now 10 objects in PDContainer) ... ... okay, after thinking I must admit that I can make one "master" shared lib and then one binary for each object of course ... :)
... but is this more user-friendly ? e.g. (correct me if I'm wrong) in windows you would have to load this "master-lib" before the other externals or move it to a folder like windows\system ... (at least with threadlib and sndfiler, which works exactly in your proposed way, I had this problem ... if threadlib.dll was only in pd/extra, then loading of sndfiler.dll failed - I had to move threadlib.dll to windows/system )
LG Georg
On Nov 23, 2005, at 4:08 PM, Georg Holzmann wrote:
Hallo!
Please describe a situation where its not possible and one where its
not meaningful. I don't see it at all. If you are talking about
sharing code among objects, you can do this with a DLL/shared lib.
For an example, Thomas got his flext externals working this way in
Pd-extended: each object is its own file, but flext is a shared lib.hm, okay, of course, that's possible ...
just an example: PDContainer.pd_linux has 528kB here on my system, if
I compile only one object: e.g. h_map.pd_linux has 213kB - so the half
of the whole lib (and there are now 10 objects in PDContainer) ... ... okay, after thinking I must admit that I can make one "master"
shared lib and then one binary for each object of course ... :)... but is this more user-friendly ?
Yes, you have much more flexibility in the way you load libs, and its
much easier to deal with name conflicts.
e.g. (correct me if I'm wrong) in windows you would have to load this
"master-lib" before the other externals or move it to a folder like
windows\system ... (at least with threadlib and sndfiler, which works exactly in your
proposed way, I had this problem ... if threadlib.dll was only in
pd/extra, then loading of sndfiler.dll failed - I had to move
threadlib.dll to windows/system )
That I don't know about, but it would suck (but not be surprising) if
it was true. I would guess its a matter of paths, and there is
probably a way to set the path. Installing into %SystemDirectory%
(usually C:\windows\system32) is not so bad though, that's why that
directory is there. And the Inno Setup installer can handle that quite
well.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
On Wed, 23 Nov 2005, Georg Holzmann wrote:
pd/extra, then loading of sndfiler.dll failed - I had to move threadlib.dll to windows/system )
You can put it into the pd\bin folder, thats where pd looks first for its .dll's on Windows.
Günter
LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Please describe a situation where its not possible and one where its not meaningful. I don't see it at all. If you are talking about sharing code among objects, you can do this with a DLL/shared lib.
For an example, Thomas got his flext externals working this way in Pd-extended: each object is its own file, but flext is a shared lib.
Not sure if i'm the best example for splitting of external libraries into single externals. In my own externals i often opted for packing externals into libaries because i can optimize across externals using C++ and inline functions. See xsample for reference. It would be pretty difficult to get the same performance in the same compact amount of maintainable code with C and split external objects. I'm sure that everything _can_ in principle be realized in separate externals, but i still don't see the reason why it should be.
best greetings, Thomas
On Nov 23, 2005, at 7:32 PM, Thomas Grill wrote:
Please describe a situation where its not possible and one where its
not meaningful. I don't see it at all. If you are talking about
sharing code among objects, you can do this with a DLL/shared lib.
For an example, Thomas got his flext externals working this way in
Pd-extended: each object is its own file, but flext is a shared lib.Not sure if i'm the best example for splitting of external libraries
into single externals. In my own externals i often opted for packing externals into libaries
because i can optimize across externals using C++ and inline
functions. See xsample for reference. It would be pretty difficult to
get the same performance in the same compact amount of maintainable
code with C and split external objects. I'm sure that everything _can_ in principle be realized in separate
externals, but i still don't see the reason why it should be.
Well, for the very good reason that it works. Right now there is a
working namespace if you compile objects as individual files. There is
no namespace with objects compiled into libs, and even worse, all
symbols are loaded when a lib is loaded whether or not they are used.
Plus packaging objects as individual files means that there can easily
be a common library format for all objects, no matter what language
they are written in, compiled or not.
Also, there is a strong precedent for this: Java's jars. They are
directories with individual .class files compressed into a .zip file
named .jar.
http://java.sun.com/docs/books/tutorial/jar/
.hc
News is what people want to keep hidden and everything else is
publicity.
- Bill Moyers
hi all,
Hans-Christoph Steiner wrote: ...
- this should be local to each abstraction (otherwise reausability of
abstractions is not guaranteed - there could be nameclashes ...)
Yes, for sure. But that'll be a much bigger project. For now, [using]
should not be too hard. The main points could be:
. add new member "t_symbol *me_libname" to struct _methodentry;
. fill that member with an extern name, when calling class_addmethod() in class_new();
. define struct _libentry {t_symbol *le_name; t_libentry *le_next};
. add new member "t_libentry *gl_liblist" to struct _glist;
. duplicate (for speed) the main loop in pd_typedmess() for the special case of pd_objectmaker target, for which the test for a method name would be extended with current glist's library list traversal; other targets ignore the me_libname member;
. in canvas_saveto() run the gobj_save() loop in two passes: first for objects of well-known classes (declarations), like "using", second for the rest;
. inherit parent's library list when creating child canvases;
. define the "using" class itself (or rather, "declare libs", if possible); it would just append its args to the current glist's gl_liblist, but before the inherited part.
Krzysztof
On Nov 23, 2005, at 4:06 PM, Krzysztof Czaja wrote:
hi all,
Hans-Christoph Steiner wrote: ...
- this should be local to each abstraction (otherwise reausability
of abstractions is not guaranteed - there could be nameclashes ...)
Yes, for sure. But that'll be a much bigger project. For now,
[using]should not be too hard. The main points could be:
. add new member "t_symbol *me_libname" to struct _methodentry;
. fill that member with an extern name, when calling class_addmethod() in class_new();
. define struct _libentry {t_symbol *le_name; t_libentry *le_next};
. add new member "t_libentry *gl_liblist" to struct _glist;
. duplicate (for speed) the main loop in pd_typedmess() for the special case of pd_objectmaker target, for which the test for a method name would be extended with current glist's library list traversal; other targets ignore the me_libname member;
. in canvas_saveto() run the gobj_save() loop in two passes: first for objects of well-known classes (declarations), like "using", second for the rest;
. inherit parent's library list when creating child canvases;
. define the "using" class itself (or rather, "declare libs", if possible); it would just append its args to the current glist's gl_liblist, but before the inherited part.
Krzysztof
Great, want to code it?! ;)
.hc
There is no way to peace, peace is the way.
-A.J. Muste
On Wed, 23 Nov 2005, Krzysztof Czaja wrote:
. define struct _libentry {t_symbol *le_name; t_libentry *le_next};
Why should new C-based components still use linked lists instead of some other data structure?
. add new member "t_libentry *gl_liblist" to struct _glist; . inherit parent's library list when creating child canvases;
How do you ever get to deallocate t_libentry ?
(also, if there is no reference-counter then you can't share portions of the liblist among several patchers and so there's no point in making it a linked list either. you have to copy the liblist every time)
. duplicate (for speed) the main loop in pd_typedmess() for the special case of pd_objectmaker target, for which the test for a method name would be extended with current glist's library list traversal; other targets ignore the me_libname member;
Wouldn't it be interesting to implement a kind of delegation or inheritance directly in Pd's core in a way that a special case wouldn't be needed?
. in canvas_saveto() run the gobj_save() loop in two passes: first for objects of well-known classes (declarations), like "using", second for the rest;
The order of objects in a glist is important, as this is what is used to generate "#X connect" lines. Do you really mean to save [using] decls first?
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
hi Mathieu,
Mathieu Bouchard wrote:
On Wed, 23 Nov 2005, Krzysztof Czaja wrote:
what I wrote was a rough sketch, written only to show that adding per-canvas declarations is not as hard as one might have thought.
Why should new C-based components still use linked lists instead of some other data structure?
for simplicity
. add new member "t_libentry *gl_liblist" to struct _glist; . inherit parent's library list when creating child canvases;
How do you ever get to deallocate t_libentry ?
(also, if there is no reference-counter then you can't share portions of the liblist among several patchers and so there's no point in making it a linked list either. you have to copy the liblist every time)
why not to do it by copying entries? Btw, inheritance should apply only to subpatches, not abstractions.
The order of objects in a glist is important, as this is what is used to generate "#X connect" lines. Do you really mean to save [using] decls first?
you are right, although this might be fixed easily by increasing a value returned by canvas_getindex(x, y) with a count of declaration objects that are y's successors in x. Another way might be to keep a glist properly sorted in the first place (sorting all newly created objects into their proper places).
Krzysztof
On Nov 23, 2005, at 4:02 AM, IOhannes m zmoelnig wrote:
Georg Holzmann wrote:
Hallo! well, this would be useful, but whats the difference from [using
zexy] to [zexy] - it also loads the lib because most libs implemented
such a dummy object (or at least some) ?note that the library does not have to implement an object of the same
name. e.g. there is no [Gem] object in Gem, but you still can load Gem
by creating an object [Gem]: the creation will fail but Gem will be
loaded.so you are correct, that using [using] just for library loading is a
bit of an overhead (especially since people tend to externals instead
of libraries)
It is a miniscule bit of overhead for real interface rather than a
hack, and it would allow you to easily specify loading order. Plus
[using] would be able to load alternate lib formats like libdirs.
i think that the [using] object should automatically add (an optional)
library-prefix to objects that cannot be found. imagine you have a patch that contains [using zexy] (how comes this
discussion always concentrates on my libraries...) and [nop].
since pd cannot find a [nop] object anywhere in it's space, it would
try to find [zexy/nop] which eventually is an abstraction
./extra/zexy/nop.pd and thus can be resolved and loaded.
This already exists. Its known as the "path". But it doesn't work for
the old lib format. Works fine with geiger namespaces/libdirs,
wherever objects are in single files.
.hc
"Information wants to be free." -Stewart Brand
On Nov 23, 2005, at 3:38 AM, Georg Holzmann wrote:
Hallo!
There are a few solutions in the works for this. Günter Geiger's
[using] object would be quite nice, it allows you to load libs from a
patch (i.e. [using zexy]. Then, I plan on redoing the preferencewell, this would be useful, but whats the difference from [using zexy]
to [zexy] - it also loads the lib because most libs implemented such a
dummy object (or at least some) ?anyway, I often make a [pd include] subpatch and there I put [zexy],
[iemlib1], [PDContainer], ... but the problem is, that it's hard to
load the libs in the right order (to avoid nameclashes) - so for
[using zexy] there should be maybe an other argument, which influences
the sequence of loading different external libs ...e.g.: [using zexy 1] will be loaded before [using iemlib 4], ...
I think you could just make it all in one object box, i.e.:
[using zexy iemlib] would achieve what you are saying above. And
would be simpler syntax.
.hc
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism."
-
retired U.S. Army general, William Odom
There are a few solutions in the works for this. Günter Geiger's [using] object would be quite nice, it allows you to load libs from a patch (i.e. [using zexy]. Then, I plan on redoing the preference panels so that they are more usable, including unlimited paths and libs fields.
how about a "browse" button? Also check out my old LML, which was an alternate GUI for PD perferences (acually all the command line flags) Most of the stuff that now needs to go into "extra flags" was in there. Anyhow here it is to check out:
http://www.ekran.org/ben/research/lml/lml-v0.1-TEST8-osx.tgz
Not this is abandoned, but the tk GUI stuff may still be of some use. (I recall the GUI was generated from a table that said the type of paramter, and if it was a flag (on-off) or option (requires argument).
.b
On Nov 23, 2005, at 11:17 AM, B. Bogart wrote:
There are a few solutions in the works for this. Günter Geiger's [using] object would be quite nice, it allows you to load libs from a patch (i.e. [using zexy]. Then, I plan on redoing the preference panels so that they are more usable, including unlimited paths and
libs fields.how about a "browse" button? Also check out my old LML, which was an alternate GUI for PD
perferences (acually all the command line flags) Most of the stuff that now needs
to go into "extra flags" was in there. Anyhow here it is to check out:http://www.ekran.org/ben/research/lml/lml-v0.1-TEST8-osx.tgz
Not this is abandoned, but the tk GUI stuff may still be of some use.
(I recall the GUI was generated from a table that said the type of
paramter, and if it was a flag (on-off) or option (requires argument).
It could be a good starting place. I was thinking it'd be nice if the
lib prefs scanned for the libs, then you could just check them off or
on. It would be easy to scan for libdirs, donno about standard libs.
.hc
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism."
-
retired U.S. Army general, William Odom
Burt wrote:
Also, when I used to load the full zexy.pd_darwin, my Pd startup time was fairly slow. I didn't really test not loading zexy, but I have noticed that this new Pd extended loads faster. Were the zexy externals one reason load-time took so long? Do extra externals effect Pd's performance? I'm wondering if anyone's done any tests.
i doubt that. i can only test on linux and i don't use pd-extended, but here's a test i just made:
zmoelnig@ferrari:~$ time pd pdquit.pd pd_gui: pd process exited
real 0m0.466s user 0m0.001s sys 0m0.023s zmoelnig@ferrari:~$ time pd -lib zexy pdquit.pd pd_gui: pd process exited
real 0m0.466s user 0m0.003s sys 0m0.017s
the "pdquit.pd" just closes pd with a loadbang. so there is not really a difference.
trying the same with "-nogui" i get:
zmoelnig@ferrari:~$ time pd -nogui pdquit.pd
real 0m0.004s user 0m0.001s sys 0m0.002s zmoelnig@ferrari:~$ time pd -nogui -lib zexy pdquit.pd ©©©©©©©©©©©©©©©©©©©©©©©©©©©© © the zexy external 2.1 © © (l) forum::fÌr::umlÀute © © compiled: Oct 27 2005 © © send me a 'help' message © ©©©©©©©©©©©©©©©©©©©©©©©©©©©©
real 0m0.005s user 0m0.003s sys 0m0.000s
mfg.ads.r IOhannes
On Nov 23, 2005, at 10:35 AM, IOhannes m zmoelnig wrote:
Burt wrote:
Also, when I used to load the full zexy.pd_darwin, my Pd startup time
was fairly slow. I didn't really test not loading zexy, but I have
noticed that this new Pd extended loads faster. Were the zexy
externals one reason load-time took so long? Do extra externals
effect Pd's performance? I'm wondering if anyone's done any tests.i doubt that. i can only test on linux and i don't use pd-extended,
but here's a test i just made:
Well, if you were loading a lot of libs, and it triggered swapping,
then it would be noticably slower.
.hc
zmoelnig@ferrari:~$ time pd pdquit.pd pd_gui: pd process exited
real 0m0.466s user 0m0.001s sys 0m0.023s zmoelnig@ferrari:~$ time pd -lib zexy pdquit.pd pd_gui: pd process exited
real 0m0.466s user 0m0.003s sys 0m0.017s
the "pdquit.pd" just closes pd with a loadbang. so there is not really a difference.
trying the same with "-nogui" i get:
zmoelnig@ferrari:~$ time pd -nogui pdquit.pd
real 0m0.004s user 0m0.001s sys 0m0.002s zmoelnig@ferrari:~$ time pd -nogui -lib zexy pdquit.pd ©©©©©©©©©©©©©©©©©©©©©©©©©©©© © the zexy external 2.1 © © (l) forum::für::umläute © © compiled: Oct 27 2005 © © send me a 'help' message © ©©©©©©©©©©©©©©©©©©©©©©©©©©©©
real 0m0.005s user 0m0.003s sys 0m0.000s
mfg.ads.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously.
- Benjamin Franklin