hi.

i stripped the "zexy" from the subject-line.

David Powers wrote:

Bad news:

BUT - there are some SERIOUS problems with Gem, and the entire patch is now broken!!! I'm trying to understand more of the problems, but what I see right now, is something wrong with pix_buffer, and pix_freeframe, and something with the fonts, in particular. There's an error with rotateXYZ but I don't think that's important. Any suggestions??? This is on WinXp, pd-extended RC 1.

let's have a look.

Here is the output when I first load my patch:

[tabdump] part of zexy-2.1 (compiled: Apr 14 2007) Copyright (l) 1999-2006 IOhannes m zmölnig, forum::fÌr::umlÀute & IEM expr, expr~, fexpr~ version 0.4 under GNU General Public License MAN::resetState entered GEM: loaded image: C:/vid/gem-vj/crab.jpg [tabset] part of zexy-2.1 (compiled: Apr 14 2007) Copyright (l) 1999-2006 IOhannes m zmölnig, forum::fÌr::umlÀute & IEM pix_film:: directshow support handle 0 AAF0D98 filmQT created pix_film:: quicktime support handle 1 AAF0F48 handle 2 12FCA98 handle 3 12FCB38 handle 4 12FCBD0 handle 5 12FCC70 handle 6 12FCD18 pix_buffer_read: couldn't find pix_buffer '1115-buff'

[pix_buffer]: there is a minor annoyance, where [pix_buffer_read] (and [pix_buffer_write]) do a check for an existing [pix_buffer] at creation time (which is a bad time to check, since the corresponding [pix_buffer] might be yet non-existant). usually you can safely ignore this warning. (however, i was not able to detect any other problems from your error logs, which does not mean that there are none).

GEM: loaded images: C:/vid/gem-vj/img/aliens1/ .jpg from 0 to 18 skipping 1 [urn] part of zexy-2.1 (compiled: Apr 14 2007) Copyright (l) 1999-2006 IOhannes m zmölnig, forum::fÌr::umlÀute & IEM img-loadhack ... couldn't create handle 0 12FE8F0 filmQT created handle 1 12FE9E8 handle 2 12FEAA0 handle 3 12FEB40 handle 4 12FEBD8 handle 5 12FEC78 handle 6 12FED20 pix_buffer_read: couldn't find pix_buffer '1121-buff' GEM: loaded images: C:/vid/gem-vj/img/mad/ .jpg from 0 to 13 skipping 1 trying to load C:/vid/gem-vj/freeframe/PeteSlide C:\vid\gem-vj\freeframe\PeteSlide: couldn't load error: GemException: couldn't load FreeFrame-plugin pix_freeframe freeframe/PeteSlide ... couldn't create

just to make sure: you DO have a PeteSlide.dll in C:/vid/gem-vj/freeframe/? and Gem has been able to load this dll in previous incarnations?

afaik, Gem for w32 is still just directly pulled from gem.iem.at (instead of compiled on the autobuild farm); this might still be a problem with compiler versions and the like...

trying to load C:/vid/gem-vj/freeframe/PeteGaussianBlur C:\vid\gem-vj\freeframe\PeteGaussianBlur: couldn't load error: GemException: couldn't load FreeFrame-plugin pix_freeframe freeframe/PeteGaussianBlur ... couldn't create handle 0 12FC708 filmQT created handle 1 12FC800 handle 2 12FC8B8 handle 3 12FC958 handle 4 12FA350 handle 5 12FA3F0 handle 6 12FA498 pix_buffer_read: couldn't find pix_buffer '1141-buff' GEM: loaded images: C:/vid/gem-vj/img/fly/ .jpg from 0 to 14 skipping 1 GEM: loaded images: C:/vid/gem-vj/img/universe/ .jpg from 0 to 12 skipping 1 error: GEM: rotateXYZ: needs 0 or 3 arguments error: GEM: rotateXYZ: needs 0 or 3 arguments error: GEM: rotateXYZ: needs 0 or 3 arguments error: GEM: rotateXYZ: needs 0 or 3 arguments

this has always been like this: [rotateXYZ] either needs no or exactly 3 arguments; try to find out why your patch gives another number of arguments to this object.

[demultiplex] part of zexy-2.1 (compiled: Apr 14 2007) Copyright (l) 1999-2006 IOhannes m zmölnig, forum::fÌr::umlÀute & IEM error: GEMtext: unable to open font C:/vid/gem-vj/over/vera.ttf

Gem's default font has changed from arial.ttf to vera.ttf for legal reasons. just copy your old C:/vid/gem-vj/over/arial.ttf to C:/vid/gem-vj/over/vera.ttf....

mfga.sdr IOhannes

David Powers wrote:

Just to be clear and follow up, some of this was caused because I was not only missing randomF, but also tripleRand (replacing with abstractions in my extra directory was easiest solution.) That's cleared up, and as a whole my monster Vj patch does run. (And the font

ya, i noticed that most problems have been solved when reading your other mail after sending my reply....

issue isn't a big deal, in fact arial never worked "out of the box" anyway you had to copy the font over somewhere).

fonts are searched using the pd-paths (as, to my knowledge, is documented in the help-files...); so you can just add "-path C:/windoze/fonts" (or whatever) to give you direct access to all installed truetype-fonts)

The [pix_freeframe] problem, however, seems to be the only real remaining problem. Note that these worked with my previous pd+Gem combo. The only thing that has changed is my version of PD. But the plugins just won't load now. I'm using the identical patch except for replaced objects. So would I want to replace this Gem with some other one, wait for a new pd-extended, or what? Adding those plugins certainly gives Gem a nice extra range of pix manipulation abilities, though not essential to my work.

yes, that's the point of having a freeframe-loader available....

anyhow, could you try replacing the current Gem.dll with an older one (where you know that it worked) and report back? make sure you do have backups though...

mfg.asdr IOhannes

Perhaps it's a matter of missing documentation? I don't think, that discussing something on a mailing list counts as "documentation". There is a readme file that loads up when I install Pd-extended, I would expect such a file to tell me of the kind of changes that will totally break my work when I upgrade. Perhaps just a big BOLD notice telling users to check in flatspace folder for missing externals.

I guess I missed all this discussion you refer to, but if I read this list when I am in the middle of workday coding bad PHP or Ajax, I'm not so likely to remember some things. In fact, the only thing I knew about was counter, I had no idea about the random stuff and no recollection of ever seeing this discussion. I guess that's weird, maybe I'm getting old and forgetting everything... ;-)

I guess I didn't realize how much was moving to flatspace, the discussion made me think it was things I didn't really use and not a very large amount of externals. Now that I've looked in that folder I see what you are talking about!!!

Anyway in this case I rebuilt the externals as abstractions, which wasn't so hard. The randomF I posted was missing a loadbang though, so attached is the corrected one for posterity's sake...

~David

Anyway I missed a loadbang in my last patch, so here are the

~David

On 6/3/07, Frank Barknecht fbar@footils.org wrote:

Hallo, David Powers hat gesagt: // David Powers wrote:

...

Second issue, which to me is perhaps a bigger problem: the utility externals seem to have disappeared from Gem with no warning.

IIRC the "warning" was kind of discussed several times on the Gem/Pd-related lists, but nevertheless: the MarkEx files have been moved out of Gem to their own "library" called "markex" in pd-extended. There they are also part of what's called "flatspace" in pd-extended-lingo.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Just to be clear, I think this package is great, and clearly superior to previous ones. I know it takes time, but things are clearly going in the right direction! And I know it's hard sometimes to get everyone on the same page in an open source project where things aren't managed in such a hierarchical way.

I'm still a little confused about this "flatspace" folder, ie. just what is there and why. But most important, is that at least now I know I should check it.

~David

On 6/3/07, Hans-Christoph Steiner hans@eds.org wrote:

Things are not moving to flatspace, that's from the "pd-externals" package build system. Unfortunately, a couple devs have been removing things from flatspace. It should be kept as is for backwards compatibility.

You are right, all this stuff should be documented much better. It's a matter of someone doing the work, I don't think anyone is opposed to having more documentation. Part of the big drive for making Pd- extended is to have a common platform of all this code. If you used externals before the externals packages and Pd-extended, you'll remember lots of pain related to that. Now that it's starting to take shape, perhaps more people can contribute to making it better documented, work smoother, etc.

.hc

On Jun 3, 2007, at 11:25 AM, David Powers wrote:

...

Perhaps it's a matter of missing documentation? I don't think, that discussing something on a mailing list counts as "documentation". There is a readme file that loads up when I install Pd-extended, I would expect such a file to tell me of the kind of changes that will totally break my work when I upgrade. Perhaps just a big BOLD notice telling users to check in flatspace folder for missing externals.

I guess I missed all this discussion you refer to, but if I read this list when I am in the middle of workday coding bad PHP or Ajax, I'm not so likely to remember some things. In fact, the only thing I knew about was counter, I had no idea about the random stuff and no recollection of ever seeing this discussion. I guess that's weird, maybe I'm getting old and forgetting everything... ;-)

I guess I didn't realize how much was moving to flatspace, the discussion made me think it was things I didn't really use and not a very large amount of externals. Now that I've looked in that folder I see what you are talking about!!!

Anyway in this case I rebuilt the externals as abstractions, which wasn't so hard. The randomF I posted was missing a loadbang though, so attached is the corrected one for posterity's sake...

~David

Anyway I missed a loadbang in my last patch, so here are the

~David

On 6/3/07, Frank Barknecht fbar@footils.org wrote:

...

Hallo, David Powers hat gesagt: // David Powers wrote:

...

Second issue, which to me is perhaps a bigger problem: the utility externals seem to have disappeared from Gem with no warning.

IIRC the "warning" was kind of discussed several times on the Gem/Pd-related lists, but nevertheless: the MarkEx files have been moved out of Gem to their own "library" called "markex" in pd-extended. There they are also part of what's called "flatspace" in pd-extended-lingo.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

<randomF.pd> <tripleRand.pd>

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

---

                         kill your television

Hallo, David Powers hat gesagt: // David Powers wrote:

Perhaps it's a matter of missing documentation? I don't think, that discussing something on a mailing list counts as "documentation". There is a readme file that loads up when I install Pd-extended, I would expect such a file to tell me of the kind of changes that will totally break my work when I upgrade.

Definitely. However I wouldn't really count on this to be in the general pd-extended README, as I guess it's impossible for Hans to follow all changes in all libraries: there are too many of them.

Anyway in this case I rebuilt the externals as abstractions, which wasn't so hard. The randomF I posted was missing a loadbang though, so attached is the corrected one for posterity's sake...

Generally I think, building simple things like randomF or demux with Pd builtins is better in the long run than relying on externals, that might not always be available. You can replace demux with

[list prepend 0] | [route 0 1 2 ...]

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__