mtx_* & Extended RC7 WAS Re: [GEM-dev] OSX binary with multi-blob tracking online somewhere?
Hey all,
After a lot of Jamie's help I finally got a gem CVS version to work on my OSX machine. I ended up having to use RC7 to load the Gem binary for some reason, and I could not get my local copy to work (PD said it was loaded, but I could not create any Gem objects).
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_* which is needed by the blobtracker help. :(
mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to get a recent verson of Gem to load into PD using anything but RC7 (RC4 did not work). blech!
Thanks.
.b.
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work
on my OSX machine. I ended up having to use RC7 to load the Gem binary
for some reason, and I could not get my local copy to work (PD said it was
loaded, but I could not create any Gem objects).
...good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_*
which is needed by the blobtracker help. :(mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to
get a recent verson of Gem to load into PD using anything but RC7 (RC4
did not work). blech!
...actually, these are included in RC7, but they would have to be
accessed as [iemmatrix/mtx_*]...I don't think this issue is really
covered in the docs, certainly not in the RC* series, so this is a
major documentation oversight, IMHO...
...the ReadMe.html also only lists a few of the included libs and
versions, with no mention of how to access anything from, say zexy...
james
On Jan 18, 2006, at 6:43 PM, james tittle wrote:
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work
on my OSX machine. I ended up having to use RC7 to load the Gem binary for
some reason, and I could not get my local copy to work (PD said it was
loaded, but I could not create any Gem objects)....good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_*
which is needed by the blobtracker help. :(mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to
get a recent verson of Gem to load into PD using anything but RC7 (RC4 did
not work). blech!...actually, these are included in RC7, but they would have to be
accessed as [iemmatrix/mtx_*]...I don't think this issue is really
covered in the docs, certainly not in the RC* series, so this is a
major documentation oversight, IMHO...
mtx_* is not included because filesystems don't generally like "*" in
files. I think there is another alias like mtx_mul. Someone should
make a version of mtx_* using IOhannes' hex loader patch, that would
solve this.
...the ReadMe.html also only lists a few of the included libs and
versions, with no mention of how to access anything from, say zexy...
There is a fair amount of stuff on this list, and in
http://puredata.org/docs/developer but yes there should be more docs,
but I won't have time to write them for a while.
.hc
News is what people want to keep hidden and everything else is
publicity.
- Bill Moyers
Hmmm,
Unless mtx_ conflicts with something else should they not be instanciated by mtx_* and not iemmatrix.mtx_*
I like these namespaces, but it does make using patches from non-installer machines a little irritating. (searching for broken objects and replacing with the namespace name...)
Maybe we need this [import] stuff sooner than later...
.b.
james tittle wrote:
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work on my OSX machine. I ended up having to use RC7 to load the Gem binary for some reason, and I could not get my local copy to work (PD said it was loaded, but I could not create any Gem objects).
...good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_* which is needed by the blobtracker help. :(
mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to get a recent verson of Gem to load into PD using anything but RC7 (RC4 did not work). blech!
...actually, these are included in RC7, but they would have to be accessed as [iemmatrix/mtx_*]...I don't think this issue is really covered in the docs, certainly not in the RC* series, so this is a major documentation oversight, IMHO...
...the ReadMe.html also only lists a few of the included libs and versions, with no mention of how to access anything from, say zexy...
james
On Jan 19, 2006, at 10:49 AM, B. Bogart wrote:
Hmmm,
Unless mtx_ conflicts with something else should they not be instanciated by mtx_* and not iemmatrix.mtx_*
I like these namespaces, but it does make using patches from non-installer machines a little irritating. (searching for broken objects and replacing with the namespace name...)
If you load all the libs, then it'll act as if everything was directly
in extra. So if you load "iemmatrix" as a lib, then [mtx_print] will
work without [iemmatrix/mtx_print].
Maybe we need this [import] stuff sooner than later...
Yes indeed! A real import would be lovely. But unfortunately, not so
simple. There is a very basic [import] included in Pd-extended. In
order for it to work, it needs to be the first object loaded in a
patch. You can ensure that by cutting every object in a patch except
[import], then pasting it all back and saving it.
.hc
.b.
james tittle wrote:
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work on my OSX machine. I ended up having to use RC7 to load the Gem binary for some reason, and I could not get my local copy to work (PD said it was loaded, but I could not create any Gem objects).
...good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_*
which is needed by the blobtracker help. :(mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to get a recent verson of Gem to load into PD using anything but RC7 (RC4
did not work). blech!...actually, these are included in RC7, but they would have to be accessed as [iemmatrix/mtx_*]...I don't think this issue is really covered in the docs, certainly not in the RC* series, so this is a major documentation oversight, IMHO...
...the ReadMe.html also only lists a few of the included libs and versions, with no mention of how to access anything from, say zexy...
james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
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?
Johannes, I'm not sure about this blobtracker depending on iemmatrix is a good idea...
.b.
Hans-Christoph Steiner wrote:
On Jan 19, 2006, at 10:49 AM, B. Bogart wrote:
Hmmm,
Unless mtx_ conflicts with something else should they not be instanciated by mtx_* and not iemmatrix.mtx_*
I like these namespaces, but it does make using patches from non-installer machines a little irritating. (searching for broken objects and replacing with the namespace name...)
If you load all the libs, then it'll act as if everything was directly in extra. So if you load "iemmatrix" as a lib, then [mtx_print] will work without [iemmatrix/mtx_print].
Maybe we need this [import] stuff sooner than later...
Yes indeed! A real import would be lovely. But unfortunately, not so simple. There is a very basic [import] included in Pd-extended. In order for it to work, it needs to be the first object loaded in a patch. You can ensure that by cutting every object in a patch except [import], then pasting it all back and saving it.
.hc
.b.
james tittle wrote:
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work on my OSX machine. I ended up having to use RC7 to load the Gem binary for some reason, and I could not get my local copy to work (PD said it was loaded, but I could not create any Gem objects).
...good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the help patch but it seems that the pd extended RC7 does not include mtx_* which is needed by the blobtracker help. :(
mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to get a recent verson of Gem to load into PD using anything but RC7 (RC4 did not work). blech!
...actually, these are included in RC7, but they would have to be accessed as [iemmatrix/mtx_*]...I don't think this issue is really covered in the docs, certainly not in the RC* series, so this is a major documentation oversight, IMHO...
...the ReadMe.html also only lists a few of the included libs and versions, with no mention of how to access anything from, say zexy...
james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On Jan 19, 2006, at 7:24 PM, 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?
For Pd-extended, if would have to be -lib iemmatrix to load the lib,
the [iemmatrix] trick doesn't work with libdirs. But since help files
and object files are in the same directory in libdir format, you don't
need to load the lib for the help patches.
For example, if you get help on [iemmatrix/mtx_print], it will bring up
iemmatrix/mtx_print-help.pd which can have [mtx_print] and it'll work
fine.
Johannes, I'm not sure about this blobtracker depending on iemmatrix is a good idea...
It would be fine if everything was in Pd-extended. It wouldn't be too
hard to sort out.
.hc
.b.
Hans-Christoph Steiner wrote:
On Jan 19, 2006, at 10:49 AM, B. Bogart wrote:
Hmmm,
Unless mtx_ conflicts with something else should they not be instanciated by mtx_* and not iemmatrix.mtx_*
I like these namespaces, but it does make using patches from non-installer machines a little irritating. (searching for broken objects and replacing with the namespace name...)
If you load all the libs, then it'll act as if everything was directly in extra. So if you load "iemmatrix" as a lib, then [mtx_print] will work without [iemmatrix/mtx_print].
Maybe we need this [import] stuff sooner than later...
Yes indeed! A real import would be lovely. But unfortunately, not so simple. There is a very basic [import] included in Pd-extended. In order for it to work, it needs to be the first object loaded in a patch. You can ensure that by cutting every object in a patch except [import], then pasting it all back and saving it.
.hc
.b.
james tittle wrote:
On Jan 18, 2006, at 4:50 PM, B. Bogart wrote:
After a lot of Jamie's help I finally got a gem CVS version to work on my OSX machine. I ended up having to use RC7 to load the Gem binary
for some reason, and I could not get my local copy to work (PD said it was loaded, but I could not create any Gem objects)....good to hear!
Anyhow I have pix_multiblob working, and I was trying to use the
help patch but it seems that the pd extended RC7 does not include mtx_* which is needed by the blobtracker help. :(mtx_* ... couldn't create mtx_* ... couldn't create mtx_* ... couldn't create
Could this be added to the extended installer? Since I am unable to get a recent verson of Gem to load into PD using anything but RC7 (RC4 did not work). blech!
...actually, these are included in RC7, but they would have to be accessed as [iemmatrix/mtx_*]...I don't think this issue is really covered in the docs, certainly not in the RC* series, so this is a major documentation oversight, IMHO...
...the ReadMe.html also only lists a few of the included libs and versions, with no mention of how to access anything from, say
zexy...james
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
__ ____
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
"Information wants to be free." -Stewart Brand
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
mfg.as.df IOhannes
TODO: remove MarkEx from Gem!!
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
-
B. Bogart -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle