hi IOhannes,
[<~] couldn't create. hans told me that i need your hex loader. so i tried to compile it:
externals/loaders/hexloader# make
make pd_linux
make[1]: Entering directory
/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here make[1]: *** [hexloader.pd_linux] Error 1 make[1]: Leaving directory/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader'
make: *** [auto] Error 2
also it would be nice to include this external in pd-extended.
and finally, what is the statut of the migration of cvs to svn? patrick
hi
patrick wrote:
hi IOhannes,
[<~] couldn't create. hans told me that i need your hex loader. so i tried to compile it:
externals/loaders/hexloader# make make pd_linux make[1]: Entering directory
/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here make[1]: *** [hexloader.pd_linux] Error 1 make[1]: Leaving directory/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' make: *** [auto] Error 2
remove the "-Werror" flag from the makefile.
also it would be nice to include this external in pd-extended.
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
however, i have no problem if you add it to pd-extended (but i have no time to do it myself)
and finally, what is the statut of the migration of cvs to svn?
nil
fgmasd.r IOhannes
On Nov 27, 2007, at 3:30 AM, IOhannes m zmoelnig wrote:
hi
patrick wrote:
hi IOhannes,
[<~] couldn't create. hans told me that i need your hex loader. so i tried to compile it:
externals/loaders/hexloader# make make pd_linux make[1]: Entering directory
/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes - Werror -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here make[1]: *** [hexloader.pd_linux] Error 1 make[1]: Leaving directory/home/pat/src/pdcvs/pure-data/externals/loaders/hexloader' make: *** [auto] Error 2remove the "-Werror" flag from the makefile.
also it would be nice to include this external in pd-extended.
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
however, i have no problem if you add it to pd-extended (but i have no time to do it myself)
Ah, ok, I was under the impression that you wanted to remove the hex
loader stuff from pd-vanilla and replace it with a loader. I think
that wouldn't be so good because then other loaders couldn't use the
hex names.
What's the hex loader do?
.hc
and finally, what is the statut of the migration of cvs to svn?
nil
fgmasd.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
also it would be nice to include this external in pd-extended.
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
however, i have no problem if you add it to pd-extended (but i have no time to do it myself)
Ah, ok, I was under the impression that you wanted to remove the hex loader stuff from pd-vanilla and replace it with a loader. I think that wouldn't be so good because then other loaders couldn't use the hex names.
other loaders can't use the hex-names anyhow.
what is currently in pd-vanilla is the hexloader _without_ the filename-mangling (only the setup-name is mangled)
What's the hex loader do?
as opposed to the hexloader in pd-vanilla, the hexloader-loader also mangles filenames.
fgmasdr IOhannes
IOhannes,
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
maybe that's why it's not working even if i removed -Werror: cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here
the include ../../../pd/src/s_stuff.h is from pd.0.41.08. patrick
patrick wrote:
IOhannes,
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
maybe that's why it's not working even if i removed -Werror: cc -export_dynamic -shared -lc -lm -DPD -DDL_OPEN -O2 -funroll-loops -fomit-frame-pointer -fPIC -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I../../../pd/src -o hexloader.pd_linux hexloader.c hexloader.c:64: error: redefinition of typedef ‘loader_t’ ../../../pd/src/s_stuff.h:55: error: previous declaration of ‘loader_t’ was here
the include ../../../pd/src/s_stuff.h is from pd.0.41.08. patrick
i see. i only ever use the pd from CVS, where these changes are obviously not there yet.
sidenote to miller: will you check the latest and greatest Pd into the CVS? should i do it for you?
in the meantime: check whether the "loader_t" declarations in s_stuff.h:55 and hexloader.c:64 are the same and if so remove (or comment out) the line in hexloader.
and it should work.
fgamsrd IOhannes
hi,
i was able to compile hexloader by removing the "loader_t" declarations in hexloader.c: hex loader $Revision: 1.4 $ written by IOhannes m zmölnig, IEM zmoelnig@iem.at compiled on Nov 27 2007 at 23:36:07 compiled against Pd version 0.41.0.extended-20071126
[<~] works!
but i have many errors while opening a patch: hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol' demultiplex 0 1 ... couldn't create convert.symbol2chars ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol'
etc... but if i create a new patch and type [relay] it will works... any ideas? patrick
patrick wrote:
hi,
i was able to compile hexloader by removing the "loader_t" declarations in hexloader.c: hex loader $Revision: 1.4 $ written by IOhannes m zmölnig, IEM zmoelnig@iem.at compiled on Nov 27 2007 at 23:36:07 compiled against Pd version 0.41.0.extended-20071126
[<~] works!
good
but i have many errors while opening a patch: hexloader: disguising as 'convert.list2symbol'
oops, that's the hexloader interfering with valid filenames. it should do no harm though (but i thought that pd will try to create an object from a .pd-file before trying to run the loaders; i'll have to check)
dollarg ... couldn't create
i have not tested how the hexloader works with other loaders (and i guess nobody has tested it the other way round).
one thing i can say for sure is: currently, other loaders will not profit from the hexloader stuff: if [import]-like functionality is implemented as loader (instead of "just" an [import] external), than this will not work: "import" zexy + [>~]; [zexy/>~] should work nevertheless. i haven't tested anything i have just said, probably it is all wrong.
apart from that, i don't see how [dollarg] should be affected by this.
mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol' demultiplex 0 1 ... couldn't create convert.symbol2chars ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol'
etc...
now that is all weird! could you send me a simple patch to test (preferrably with only zexy+iemlib+vanilla objects as i don't have any other libs installed)
mfga.dsr IOhannes
On Nov 28, 2007, at 4:04 AM, IOhannes m zmoelnig wrote:
patrick wrote:
hi,
i was able to compile hexloader by removing the "loader_t"
declarations in hexloader.c: hex loader $Revision: 1.4 $ written by IOhannes m zmölnig, IEM zmoelnig@iem.at compiled on Nov 27 2007 at 23:36:07 compiled against Pd version 0.41.0.extended-20071126[<~] works!
good
but i have many errors while opening a patch: hexloader: disguising as 'convert.list2symbol'
oops, that's the hexloader interfering with valid filenames. it should do no harm though (but i thought that pd will try to
create an object from a .pd-file before trying to run the loaders; i'll have
to check)dollarg ... couldn't create
i have not tested how the hexloader works with other loaders (and i guess nobody has tested it the other way round).
one thing i can say for sure is: currently, other loaders will not profit from the hexloader stuff: if [import]-like functionality is implemented as loader (instead of "just" an [import] external), than this will not work: "import" zexy + [>~]; [zexy/>~] should work nevertheless. i haven't tested anything i have just said, probably it is all wrong.
[import] has nothing to do with the loader stuff, it is just a
different interface to the [declare] code.
.hc
apart from that, i don't see how [dollarg] should be affected by this.
mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol' demultiplex 0 1 ... couldn't create convert.symbol2chars ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'convert.list2symbol' dollarg ... couldn't create mergefilename space ... couldn't create relay symbol ... couldn't create hexloader: disguising as 'scale.symbol'
etc...
now that is all weird! could you send me a simple patch to test (preferrably with only zexy+iemlib+vanilla objects as i don't have any other libs installed)
mfga.dsr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
¡El pueblo unido jamás será vencido!
patrick wrote:
hi,
etc... but if i create a new patch and type [relay] it will works... any ideas?
right, i found out that hexloader does a bad job when trying to load patches. this part of the hexloader is obviously still experimental. what it does is to register a dummy class for an abstraction which it thinks it should handle. (unfortunately currently it also thinks it should handle "normal" abstractions, that do not need hexmangling) when the objectclass gets instantiated it is really the hexloader-external that gets called (hence the "disguising as..." message), and tries to load the abstraction.
for whatever reasons this does not work with abstractions containing abstractions.
i will have a look at this.
fgmasdr IOhannes
On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
right, i found out that hexloader does a bad job when trying to load patches. this part of the hexloader is obviously still experimental. what it does is to register a dummy class for an abstraction which it thinks it should handle.
Why do you need dummy classes?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
hi
patrick wrote:
IOhannes,
_part_ of it is included in pd-vanilla (a bug has been fixed recently with pd-0.41-test6 (or 7))
maybe that's why it's not working even if i removed -Werror:
[...]
the include ../../../pd/src/s_stuff.h is from pd.0.41.08. patrick
are you sure? i cannot find a loader_t in s_stuff.h of pd-0.41-0test8. have you patched the pd-sources?
mfga.dfr IOhannes
hi IOhannes,
http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout-developer-la...
rm -rf pd unpack pd.0.41.08 to pd cd pure-data/packages/
vi Makefile (removed Gem because it doesn't compile on gutsy (avifile)) make patch cd linux_make make install
- install pd in /usr/local (cp -R ...)
- chmod +s /usr/local/bin/pd
- edit /usr/local/lib/pd/default.pdsettings
- compile the missing externals (flext, py, xsample...)
patrick
patrick wrote:
hi IOhannes,
http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout-developer-la...
rm -rf pd unpack pd.0.41.08 to pd cd pure-data/packages/
vi Makefile (removed Gem because it doesn't compile on gutsy (avifile)) make patch
so you are patching the pd-sources.
i only have time to make hexloader compatible with one flavour of pd and i chose pd-vanilla.
to make it work on pd-extended, please create a diff that removes the offending line and submit it to the pd-extended's patches to be automatically applied when you do "make patch".
fgmadr IOhannes
On Nov 28, 2007, at 4:08 AM, IOhannes m zmoelnig wrote:
patrick wrote:
hi IOhannes,
http://pure-data.cvs.sourceforge.net/pure-data/scripts/checkout- developer-layout.sh?rev=HEAD
rm -rf pd unpack pd.0.41.08 to pd cd pure-data/packages/
vi Makefile (removed Gem because it doesn't compile on gutsy
(avifile)) make patchso you are patching the pd-sources.
i only have time to make hexloader compatible with one flavour of
pd and i chose pd-vanilla.to make it work on pd-extended, please create a diff that removes the offending line and submit it to the pd-extended's patches to be automatically applied when you do "make patch".
You might consider, Pd-extended is pd-vanilla plus the patches that
have been submitted to the patch tracker. Miller ends up taking most
of these patches. I believe he would be more likely to accept
patches that have been used successfully in Pd-extended.
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
Hans-Christoph Steiner wrote:
You might consider, Pd-extended is pd-vanilla plus the patches that
have been submitted to the patch tracker. Miller ends up taking most
of these patches. I believe he would be more likely to accept
patches that have been used successfully in Pd-extended.
yes this is fine: as soon as the loader_t line shows up in Pd-vanilla's s_stuff.h i will remove it permanently from the hexloader.c
my main intention is still compatibility with pd-vanilla.
you (not necessarily hcs; anybody who wants to do it) could also just add the hexloader to Pd-extended's build-system and while doing so apply a wee patch in Pd-extended's makefile that removes the line. something like :
"sed -i -e 's|^typedef int (*loader_t)(t_canvas *canvas, char *classname);$|' hexloader.c"
(that's al in one line)
mfa.sdr IOhannes
On Nov 27, 2007, at 4:11 PM, IOhannes m zmoelnig wrote:
hi
patrick wrote:
IOhannes,
_part_ of it is included in pd-vanilla (a bug has been fixed
recently with pd-0.41-test6 (or 7))maybe that's why it's not working even if i removed -Werror:
[...]
the include ../../../pd/src/s_stuff.h is from pd.0.41.08. patrick
are you sure? i cannot find a loader_t in s_stuff.h of pd-0.41-0test8. have you patched the pd-sources?
This is the patch in question, it exposes the loader_t and
sys_register_loader() in s_stuff.h. That seems like something
worthwhile to support, no?
hans@palatschinken > cd ~/code/pure-data/packages/patches/
hans@palatschinken > grep loader_t *
expose_sys_register_loader-0.41.0-test03.patch:-typedef int
(*loader_t)(t_canvas *canvas, char *classname);
expose_sys_register_loader-0.41.0-test03.patch: loader_t loader;
expose_sys_register_loader-0.41.0-test03.patch:+typedef int
(*loader_t)(t_canvas *canvas, char *classname);
expose_sys_register_loader-0.41.0-test03.patch:+EXTERN void
sys_register_loader(loader_t loader);
It seems either I forgot to submit that patch to the tracker, or it
got deleted somehow. Strange, I don't know why I wouldn't have
submitted it, I wonder if SourceForge is having some issues, or I am
losing my mind. I (re?)added it.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
On Wed, 28 Nov 2007, Hans-Christoph Steiner wrote:
This is the patch in question, it exposes the loader_t and sys_register_loader() in s_stuff.h. That seems like something worthwhile to support, no?
If you look at the bulk of s_stuff.h, you'll see that those are functions that you never use when making externals. They are part of a file that is never included by externals (ok, there are some special cases). The only public API is still m_pd.h, even though g_canvas.h has crept to a de-facto semi-public, but still, m_pd.h is the only header added by make install.
So, I don't know what's your goal with putting it in s_stuff.h... do you want to hide it? ;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Nov 27, 2007, at 1:03 PM, IOhannes m zmoelnig wrote:
also it would be nice to include this external in pd-extended.
_part_ of it is included in pd-vanilla (a bug has been fixed
recently with pd-0.41-test6 (or 7))however, i have no problem if you add it to pd-extended (but i
have no time to do it myself)Ah, ok, I was under the impression that you wanted to remove the
hex loader stuff from pd-vanilla and replace it with a loader. I
think that wouldn't be so good because then other loaders couldn't
use the hex names.other loaders can't use the hex-names anyhow.
what is currently in pd-vanilla is the hexloader _without_ the
filename-mangling (only the setup-name is mangled)What's the hex loader do?
as opposed to the hexloader in pd-vanilla, the hexloader-loader
also mangles filenames.
I am curious why you chose to make it a loader rather than to make it
part of the core? For example, it would be nice to be able to write
<~ in tcl with tclpd, if need be.
.hc
http://at.or.at/hans/
Hans-Christoph Steiner wrote:
I am curious why you chose to make it a loader rather than to make it part of the core?
??? just to refresh everyones memories: i have originally written the hexloader as a patch against pd-vanilla. zthe functionality was: setupfun-mangling and filename-mangling. this was in times before the sys_loader mechanism existed. miller then applied my patch (i think for pd-0.39, but i am not sure about pd-versions). miller also applied tg's sys_loader patch. in the next release of Pd, the hexloader was reduced to setupfun-mangling only.
i then thought (and still think) that miller has some reason to reduce the hexloader-functionality in pd-core. however, at the same time he provides an alternative to create your own loader, so why not use that one instead?
e.g. i could have bothered to get [>~] into core pd for 7 long years. instead i chose the suggested way by writing an external that provides [>~]. this has worked fine, why should i change it? why should i have spent energy to get something i already have? (why do i have to spend energy in explaining this?)
For example, it would be nice to be able to write <~ in tcl with tclpd, if need be.
yes indeed it would be nice. how do you think it should work (if done in core-pd)? why do you think it is impossible to do this with an external loader?
mfga.sdr IOhannes
On Nov 28, 2007, at 3:49 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I am curious why you chose to make it a loader rather than to make
it part of the core???? just to refresh everyones memories: i have originally written the hexloader as a patch against pd-vanilla. zthe functionality was: setupfun-mangling and filename-mangling. this was in times before the sys_loader mechanism existed. miller then applied my patch (i think for pd-0.39, but i am not
sure about pd-versions). miller also applied tg's sys_loader patch. in the next release of Pd, the hexloader was reduced to setupfun- mangling only.i then thought (and still think) that miller has some reason to
reduce the hexloader-functionality in pd-core. however, at the same time he provides an alternative to create your
own loader, so why not use that one instead?e.g. i could have bothered to get [>~] into core pd for 7 long years. instead i chose the suggested way by writing an external that
provides [>~]. this has worked fine, why should i change it? why
should i have spent energy to get something i already have?
Ah, ok, I didn't realize that Miller has scaled back the loader stuff.
(why do i have to spend energy in explaining this?)
Maybe because you want people to use your code? :D
For example, it would be nice to be able to write <~ in tcl with
tclpd, if need be.yes indeed it would be nice. how do you think it should work (if done in core-pd)? why do you think it is impossible to do this with an external loader?
As a loader that worked for other loaders would be even better.
.hc
All information should be free. - the hacker ethic
Hans-Christoph Steiner wrote:
yes indeed it would be nice. how do you think it should work (if done in core-pd)? why do you think it is impossible to do this with an external loader?
As a loader that worked for other loaders would be even better.
i agree that this would be nice. how do you think it should work (if done in core-pd)? why (and) do you think it is impossible to do this with an external loader?
probably i am just too tired to think of a good idea.
i don't like matju's suggestion to provide an API, as this would require to have hexloader be loaded before all other externals that rely on that API.
what might be a better solution is to tell Pd to try to load a different class instead (kind of recursively calling the loading stuff).
mfga.sdr IOhannes
On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
i don't like matju's suggestion to provide an API,
Ideally, hexloader should be merged into the core and the API would be a single function shared by the loader and the parts of the internals that do the same thing as the hexloader does (the symbol mangler).
I'm not really advocating that an external exposes an API otherwise than as pd objects and methods... but then, this is also what Gem need to do if some externals are not linked directly into Gem... so it must not be that ugly. GridFlow will also have to do it eventually. I just think that doing it for one function is a waste.
Anyway, because virtually the same code is already in the core, it makes sense to have that shared function in the core, so the issue of linking to an external should be moot.
as this would require to have hexloader be loaded before all other externals that rely on that API.
Not if the linker knows about it. (The problem is how to tell the linker about it)
what might be a better solution is to tell Pd to try to load a different class instead (kind of recursively calling the loading stuff).
I don't understand.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
By the way, I just read thru the whole hexloader README. Looks like
nice work, I think you covered every possibility that I could think
of :)
.hc
On Nov 28, 2007, at 10:05 PM, Mathieu Bouchard wrote:
On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
i don't like matju's suggestion to provide an API,
Ideally, hexloader should be merged into the core and the API would
be a single function shared by the loader and the parts of the
internals that do the same thing as the hexloader does (the symbol
mangler).I'm not really advocating that an external exposes an API otherwise
than as pd objects and methods... but then, this is also what Gem
need to do if some externals are not linked directly into Gem... so
it must not be that ugly. GridFlow will also have to do it
eventually. I just think that doing it for one function is a waste.Anyway, because virtually the same code is already in the core, it
makes sense to have that shared function in the core, so the issue
of linking to an external should be moot.as this would require to have hexloader be loaded before all other
externals that rely on that API.Not if the linker knows about it. (The problem is how to tell the
linker about it)what might be a better solution is to tell Pd to try to load a
different class instead (kind of recursively calling the loading
stuff).I don't understand.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
On Tue, 27 Nov 2007, Hans-Christoph Steiner wrote:
Ah, ok, I was under the impression that you wanted to remove the hex loader stuff from pd-vanilla and replace it with a loader. I think that wouldn't be so good because then other loaders couldn't use the hex names.
Yes, that was my comment on the sourceforge page. the problem is that unless the hexloader exposes an API that other language interface externals rely on, those externals have to duplicate most of the code of hexloader.
Compared to the existing load of copy-paste and of almost-copy-paste in pd source and externals sources in general, it's not a big deal, but still I'm happier when there is no excuse for more copy-paste.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
patrick