Hi,
following questions about iemmatrix:
no help file for mtx_*~. Are these the most current ones?
through the archives, but it wasn't possible to find those.
merci,
Joao
On Dec 12, 2005, at 8:52 AM, João Miguel Pais wrote:
Hi,
following questions about iemmatrix:
- I was looking for the documentation, have the files from cvs but
there's no help file for mtx_*~. Are these the most current ones?
- where is it possible to find the latest version of the dlls? I look
ed through the archives, but it wasn't possible to find those.
They are included in the Pd-extended builds as individual objects in
extra/iemmatrix.
You can access them by typing [iemmatrix/mtx_mul~] or by adding
c:/progra~1/pd/extra/iemmatrix to the path.
.hc
merci,
Joao
--
Lugostr. 14 79100 Freiburg i. Br. Deutschland +49 (0)761 7074997 jmmmp@arcor.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Information wants to be free." -Stewart Brand
- where is it possible to find the latest version of the dlls? I look
ed through the archives, but it wasn't possible to find those.
They are included in the Pd-extended builds as individual objects in
extra/iemmatrix.You can access them by typing [iemmatrix/mtx_mul~] or by adding
c:/progra~1/pd/extra/iemmatrix to the path.
thanks, I noticed. I've also installed your build to look for them. But
without wanting to dish out your work, which is quite good someone to have
in a few minutes the whole pd world, I prefer to install the one dll with
the library (in case one exists). making one dll for each object makes the
whole thing much bigger, and to my logic more confusing (I have almost all
the same dlls as you, but self-installed, and prefer to deal with
libraries as with single objects).
greetings,
joao
On Dec 13, 2005, at 8:43 AM, João Miguel Pais wrote:
- where is it possible to find the latest version of the dlls? I
look ed through the archives, but it wasn't possible to find those.
They are included in the Pd-extended builds as individual objects in
extra/iemmatrix.You can access them by typing [iemmatrix/mtx_mul~] or by adding
c:/progra~1/pd/extra/iemmatrix to the path.thanks, I noticed. I've also installed your build to look for them.
But without wanting to dish out your work, which is quite good someone
to have in a few minutes the whole pd world, I prefer to install the
one dll with the library (in case one exists). making one dll for each
object makes the whole thing much bigger, and to my logic more
confusing (I have almost all the same dlls as you, but self-installed,
and prefer to deal with libraries as with single objects).
Having one dll per object doesn't really make things much bigger,
especially when implemented properly. Its just encapsulating code in
multiple files rather than one. As for the issue of confusion, try to
deal with name conflicts when they are compiled into libraries.
If you like spending your time maintaining your Pd install, don't let
me stop you. I would just like to see us all spending less time on
maintenance, build systems, and file management, and more time writing
really cool things.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
Having one dll per object doesn't really make things much bigger,
especially when implemented properly. Its just encapsulating code in
multiple files rather than one. As for the issue of confusion, try to
deal with name conflicts when they are compiled into libraries.
well, my externals folder takes 14 Mb, the one from the extended version
130Mb - in the iemmatrix folder (which was the initial subject) the
original dll only takes 63Kb, but with all objects separated almost 2Mb.
To deal with name conflicts, keep track of what's installed and have
always a reference I update the INTRO file after each install (here's a
copy), or soon it won't do much to have so many objects, as at least I
wouldn't be able to know who does what.
If you like spending your time maintaining your Pd install, don't let me
stop you. I would just like to see us all spending less time on
maintenance, build systems, and file management, and more time writing
really cool things.
I really don't spend that much time, as I have a system for it (which has
been lasting for a few years), so it's quite automatized. That's also why
I can't change that fast, in case it might be necessary (which I try to
avoid).
I find a full-package of pd really great, but since I have the choice, and
for now it seems that there are still a few differentes between both, I
prefer to keep installing the original dll's (as long as someone keeps
coding them). Anyway I can compare both versions and check out what I am
still missing.
Joao
PS: H-C, sorry for the delay with the multi-mega version of gui-edit.pd -
I have already aligned all variables, but need a couple of days of free
time to just put it working and solve the GUI, etc.
On Dec 13, 2005, at 12:52 PM, João Miguel Pais wrote:
Having one dll per object doesn't really make things much bigger,
especially when implemented properly. Its just encapsulating code in
multiple files rather than one. As for the issue of confusion, try
to deal with name conflicts when they are compiled into libraries.well, my externals folder takes 14 Mb, the one from the extended
version 130Mb - in the iemmatrix folder (which was the initial
subject) the original dll only takes 63Kb, but with all objects
separated almost 2Mb.
Yeah, iemmatrix is currently hacked into separate DLLs, so there is a
lot of duplication of code. Pd-extended has a ton of code in there
now, so that makes its quite big too, so matter how its assembled.
To deal with name conflicts, keep track of what's installed and have
always a reference I update the INTRO file after each install (here's
a copy), or soon it won't do much to have so many objects, as at least
I wouldn't be able to know who does what.
There are some name conflicts that you can't deal with when they are in
libs, i.e. when you want one conflicting object from one lib, and the a
different conflicting object from the other lib. Luckily you haven't
run into those.
If you like spending your time maintaining your Pd install, don't let
me stop you. I would just like to see us all spending less time on
maintenance, build systems, and file management, and more time
writing really cool things.I really don't spend that much time, as I have a system for it (which
has been lasting for a few years), so it's quite automatized. That's
also why I can't change that fast, in case it might be necessary
(which I try to avoid). I find a full-package of pd really great, but since I have the choice,
and for now it seems that there are still a few differentes between
both, I prefer to keep installing the original dll's (as long as
someone keeps coding them). Anyway I can compare both versions and
check out what I am still missing.Joao
PS: H-C, sorry for the delay with the multi-mega version of
gui-edit.pd - I have already aligned all variables, but need a couple
of days of free time to just put it working and solve the GUI,
etc.<0.INTRO.txt>
No problem. That's the world of free software...
.hc
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
Yeah, iemmatrix is currently hacked into separate DLLs, so there is a
lot of duplication of code. Pd-extended has a ton of code in there now,
so that makes its quite big too, so matter how its assembled.
usually that shouldn't ve a problem nowadays, but my space is really
running low here.
There are some name conflicts that you can't deal with when they are in
libs, i.e. when you want one conflicting object from one lib, and the a
different conflicting object from the other lib. Luckily you haven't
run into those.
there are a few here, but I myself only have one way to deal with them
(which is not exactly deal): load the preferred library first. It would be
good not only to remove name conflicts, but also redundant objects from
different libraries. Well, I guess that's why you're there.
No problem. That's the world of free software...
I think I won't be able to work on it before christmas. well, or maybe
yes. who knows?
joao
On Dec 14, 2005, at 4:51 AM, João Miguel Pais wrote:
Yeah, iemmatrix is currently hacked into separate DLLs, so there is a
lot of duplication of code. Pd-extended has a ton of code in there
now, so that makes its quite big too, so matter how its assembled.usually that shouldn't ve a problem nowadays, but my space is really
running low here.
Actually, this discussion lead me to look into using the "strip"
command on Mac OS X. I think I found the correct flags, "strip -x",
which removes all but the global symbols. It shaves about 20 megs off
of the "extra" directory.
.hc
There are some name conflicts that you can't deal with when they are
in libs, i.e. when you want one conflicting object from one lib, and
the a different conflicting object from the other lib. Luckily you
haven't run into those.there are a few here, but I myself only have one way to deal with them
(which is not exactly deal): load the preferred library first. It
would be good not only to remove name conflicts, but also redundant
objects from different libraries. Well, I guess that's why you're
there.No problem. That's the world of free software...
I think I won't be able to work on it before christmas. well, or maybe
yes. who knows?joao
"The arc of history bends towards justice."
- Dr. Martin Luther King, Jr.
Actually, this discussion lead me to look into using the "strip" command
on Mac OS X. I think I found the correct flags, "strip -x", which
removes all but the global symbols. It shaves about 20 megs off of the
"extra" directory.
I guess it's too complicated to make one dll with all externals. then the
folder would be even smaller as one with the original dlls.
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
Actually, this discussion lead me to look into using the "strip" command
on Mac OS X. I think I found the correct flags, "strip -x", which
removes all but the global symbols. It shaves about 20 megs off of the
"extra" directory.I guess it's too complicated to make one dll with all externals. then the
folder would be even smaller as one with the original dlls.
However then you would always load *all* externals into memory, even if you're not actually using them.
Frank Barknecht _ ______footils.org_ __goto10.org__