On Jan 20, 2006, at 3:46 AM, IOhannes m zmoelnig wrote:
hi.
please don't take anything i write below too serious....
B. Bogart wrote:
Ok... So just to clarify Johannes could just put [iemmatrix] in the help patch? or that I would have to start pd with -lib iemmatrix?
probably i'll also should put a line into the help-patch that says
that you need pd to use it ;-) for now, i will put a note into INSTALL.txt that you have to load
iemmatrix to use it. and i will put a note in the help-patches, that they are part of
iemmatrix (which is implied via the "mtx_" prefix, but this is not
obvious) i am somewhat reluctant to automatically load a library when opening
the help-patch unless namespaces are better sorted out (probably i'll
have a look at the pd-extended one day, but it is not high on my
priority list)Johannes, I'm not sure about this blobtracker depending on iemmatrix
is a good idea...i do think so (else i wouldn't have done it that way) i don't know how else i should do it: a) rewriting the entire logic in plain pd is currently not possible. b) make a separate object that uses whatever comes from
[pix_multiblob] and does the tracking (something like the guts of
[pix_blobtracker], but written in C/C++); where should i put that
object: make it a separate external (then you have the very same
problem as with iemmatrix); or put it into Gem?? (i refuse to do so
since it has nothing to do with Gem's functionality as a
graphics/video-library; this object would do pure post-processing of
whatever data) c) just make another Gem-object [pix_blobtracker] (e.g. combine
[pix_multiblob] and the tracking-code into one object); well, yes, we
could just write a tracking application and communicate to pd via OSC
(or skip pd entirely, and write out own application in fortran)i agree that it might be good, to have [pix_multiblob] output "matrix"
messages only on demand (either settable with a message or via an
argument, or probably both)what is the exact source of your problem?
- the need to install several pd-libraries?
- the use of one library (iemmatrix) within the abstraction of
another? (i admit it is less than optimal; however, to make things
straight, i could just put the "[pix_blobtracker]" object into a
separate "library" that depends on both Gem and iemmatrix. apart from
straighting things out, this would gain us nothing: just one more
library...
- that you had a hard time to get Gem running and THEN having a
pd-extended which seemed to not have iemmatrix within? - both are
unrelated to the blobtracker; however it made it hard to get the
blobtracker running (and added up to frustration)anyhow, i hope it works now
This highlights the whole reason why I work on Pd-extended. If we
can't build objects that build upon existing code, we are severely
crippling ourselves. Having a Pd platform (rather than Pd and a bunch
of code that you can download) makes this totally feasible.
TODO: remove MarkEx from Gem!!
Yay! Should be easy enough. I think the vector stuff needs to be
split out into something else, since its a lib, IIRC.
.hc ________________________________________________________________________ ____
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver