[PD] mtx_* & Extended RC7 WAS Re: [GEM-dev] OSX binary with multi-blob tracking online somewhere?

[Hans-Christoph Steiner]

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