Thanks Guenter, That did the trick,

but *now* upon loading PD refused to load gem because the mpeg3_has_video symbol can't me found. arg. Can't help but think that there is a chain of undefined symbols behind this one that I can only see one at a time.

So what is this symbol, I'm using libmpeg3 version 1.4-114 on SuSE8 Is this library to old? to new?

Thanks Ben

On Sat, 15 Jun 2002, =?X-UNKNOWN?Q?g=FCnter_geiger?= wrote:

On Fri, 14 Jun 2002, Ben Bogart - FMPM/F1999 wrote:

...

I've got gem .87 compiled again (without the 1394 error) but now It's complaining about the glutsolidteapot symbol again!

how do I disable that object?

remove it from the Make.source file in the Geos directory and remove traces of it in Base/GemSetup.cpp make clean; make

Greetings

Guenter

...

I tried moving the teapot files from Geos but the compile still tries to find it and fails (teapot is required by all) I could not find a reference to which objects are compiled.

I'm using SuSE 8, glut3.6 (from www.opengl.org)

I got no errors setting up glut so I don't know what the symbol would be missing... I'd be happy to get it to work, but I don't have much use for the teapot!

Thanks Ben

B. Bogart

B. Bogart

Ben Bogart - FMPM/F1999 wrote:

Thanks Guenter, That did the trick,

but *now* upon loading PD refused to load gem because the mpeg3_has_video symbol can't me found. arg. Can't help but think that there is a chain of undefined symbols behind this one that I can only see one at a time.

yeh. it really seems that your external libraries are not found, what does the configure (after "rm config.cache") say ? where does it fail ?

where are the main libraries (like libmpeg3.so, libglut.so) ?? maybe you should add the correct path by hand to the Gnu/Makefile

So what is this symbol, I'm using libmpeg3 version 1.4-114 on SuSE8 Is this library to old? to new?

maybe it is really too old. i am compiling against 1.5-4 of woody (debs can be found at marillat.free.fr)

mfg.cds.ar IOhannes

Thanks Ben

Ben Bogart - FMPM/F1999 wrote:

Thanks to Alexandre, I've not the libmpeg3.so problem solved, now (yes I knew it) I've got yet another symbol problem!

glmFacetNormals__FP8GLMmodel

this is from glm (part of GemLibs). you have to make ./makeauxlibs

mfg.cd.sasdr IOhannes

Ben Bogart - FMPM/F1999 wrote:

I did do ./makeauxlibs as per the README.build... ./makeauxlibs does not print any errors, completes with "finished..."

What else could cause this?

GemLibs is along side my gem-0.87 tree. The GemLibs/glm folder contains:

Makefile glm.c glm.h glm.o libglm.a

perfect!

does the configure find the glm-library ? there should be something like

<snip> checking for main in -lglm... no checking alternate -lglm in ../../../ ... ../../../GemLibs/glm configure: warning: Trying to use glm library in ../../../GemLibs/glm </snip>

btw: the glutSolidTeapot should have been found by the configure too.

by the way (no i remember): glm depends on glut: that is why i chose to put the teapot in Gem (it makes no sense, but it was just there)

you do not have to have a libglut.so, a libglut.a will do too. ;-)

mfg.cdsa.asd IOhannes

Thanks again. Ben

On Mon, 17 Jun 2002, IOhannes zmoelnig wrote:

...

Ben Bogart - FMPM/F1999 wrote:

...

Thanks to Alexandre, I've not the libmpeg3.so problem solved, now (yes I knew it) I've got yet another symbol problem!

glmFacetNormals__FP8GLMmodel

this is from glm (part of GemLibs). you have to make ./makeauxlibs

mfg.cd.sasdr IOhannes

B. Bogart

Hi all,

So I've been looking at midi timing with PD 0.35test26 and trying to get things running nicely.

I have an RME multiface which I'm using for audio and midi I/O.

Using the MMIO driver (the default in PD) and using -sleepgrain 1 I can get nice, tight midi timing irrespective of the audiobuffer size.

Using the ASIO driver (which should have the usual advantages for audio) I can't get any better than 10ms granularity / jitter in the delivery of MIDI messages. The -sleepgrain option has no effect, nor does playing with the -audiobuf option as far as I can see.

BTW how does the -audiobuf option interact with the ASIO buffer size setting for the audio driver?

Thanks, Daniel

Hi Miller,

Ah. Thanks for this info.

As for latencies, I've not tested under heavy CPU load but seem to be able to run at -audiobuf 24 (24ms?) with both ASIO and MMIO with occasional dropouts when loading patches etc. That seems to be as low as PD will let me go with MMIO before hitting minimum number of buffer limits. Using ASIO I can go lower but start to suffer dropouts in general operation.

On the CPU usage issue: I'm guessing that the main advantages of ASIO in this regard are a more efficient buffer replacement strategy and direct floating point input/output? So one would expect to see only small differences in CPU usage, unless many channels are being used. Somewhat unscientifically, I tried the denoise example patch (at random) under ASIO and MMIO and was surprised to note that CPU usage seems to double under ASIO... (from ~5% under MMIO to ~11% under ASIO). The other patches I tried seem to have no discernible difference at all (which is what I'd expect for stereo in stereo out tests). (PIII-M 1.1Ghz running w2k, rme multiface). I was just using the Windows Task Manager for CPU measurement so there may be other spurious factors.

My biggest problem in this area is actually running audio at the same time as GEM. To allow loading the CPU up doing GEM frame processing means that the audio latency has to be at least a frame time (40 or 50ms). I guess the only way around this is to put GEM rendering into a separate thread. I might look into that possibility.

Thanks, Daniel

-----Original Message----- From: Miller Puckette [mailto:mpuckett@man104-1.ucsd.edu] Sent: Wednesday, 19 June 2002 1:13 AM To: Daniel Heckenberg Cc: pd mailinglist Subject: Re: [PD] Midi timing and ASIO under NT

There's no control over blocksize in ASIO, but there should be. In the ASIO interface, Pd blocks in chunks of the audio blocksize, whereas for MMIO it blocks in periods of "sleepgrain" (because it does audio I/O by polling, not blocking.) ASIO really should be done the same way, but in the meantime I should just offer control over the "blocksize" which I haven't yet... I'll try to put that in.

By the way, with the RME hammerfall I'm getting about the same latencies (30-ish MSEC) and CPU loads using MMIO as ASIO, which doesn't sound right.

cheers Miller

On Tue, Jun 18, 2002 at 11:53:33AM +1000, Daniel Heckenberg wrote:

...

Hi all,

So I've been looking at midi timing with PD 0.35test26 and trying to get things running nicely.

I have an RME multiface which I'm using for audio and midi I/O.

Using the MMIO driver (the default in PD) and using -sleepgrain

1 I can get

...

nice, tight midi timing irrespective of the audiobuffer size.

Using the ASIO driver (which should have the usual advantages

for audio) I

...

can't get any better than 10ms granularity / jitter in the

delivery of MIDI

...

messages. The -sleepgrain option has no effect, nor does playing with the -audiobuf option as far as I can see.

BTW how does the -audiobuf option interact with the ASIO buffer

size setting

...

for the audio driver?

Thanks, Daniel

Thanks for all the responces, still can't get past this glm symbol problem. I've always been removing the config.cache file before ./configure. configure finds the glm library, and it finds GlutSolidTeapot as well.

I have a libglut.so registered by ldconfig.

I looked though the Makefile and made a few changes. This is the Makefile produced by the ./configure:

LDFLAGS = -L/usr/X11R6/lib -L../../../GemLibs/glm -L../../../gem-0.86/src/AuxLibs/liborb -L../../../gem-0.86/src/AuxLibs/particle LIBS = -L/usr/lib -lglib -lz -lparticle -lorb -lgltt -lttf -ljpeg -ltiff -lglm -lmpeg3 -lmpeg -lglib -lpng -lquicktime -lglut -lGLU -lGL -lm -Wl,-shared -Wl,-export-dynamic -lXxf86vm -lXext -lX11 INCLUDES = -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gltt -I../../../gem-0.86/src/AuxLibs/particle -I../../../gem-0.86/src/AuxLibs/liborb -I../../../glut-3.6/progs/demos/smooth -I/usr/local/include -I..

I tried making these changes:

LDFLAGS = -L/usr/X11R6/lib -L../../../GemLibs/glm -L../../../GemLibs/liborb -L../../../GemLibs/particle -L/usr/lib/ LIBS = -L/usr/lib -lglib -lz -lparticle -lorb -lgltt -lttf -ljpeg -ltiff -lglm -lmpeg3 -lmpeg -lglib -lpng -lquicktime -lglut -lGLU -lGL -lm -Wl,-shared -Wl,-export-dynamic -lXxf86vm -lXext -lX11 INCLUDES = -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/gltt -I../../../GemLibs/particle -I../../../GemLibs/liborb -I/usr/local/include/GL -I/usr/local/include -I.. -I/usr/include/libmpeg3

I also tried Guenter's suggestion changing the glm.h to point to GL/gl.h rather than GL/glut.h

Gem always compiles fine, no errors, not always refuses to load with the glmFacetNormals__FP8GLMmodel symbol "missing"

I've been trying to get gem.87 to work since it was released on multiple linux distros. Why can't I get it to work!?

I really appreciate everyones efforts.

Thanks Ben

On Tue, 18 Jun 2002, IOhannes zmoelnig wrote:

you might have to add the correct library path by hand so something like "-L/usr/local/glut-3.6/lib/glut/" in the LDFLAGS-line

...

I'd appriciate any help. Thanks Ben

...

mfg.cdsa.asd IOhannes

B. Bogart

I'm using gcc 2.95.3

I tried adding that clause to my model.h and multimodel.h and the Gem compile fails at:

In file included from model.h:24, from model.cpp:17: ../../../glut-3.6/progs/demos/smooth/glm.h:33: redefinition of struct _GLMmaterial' ../../../glut-3.6/progs/demos/smooth/glm.h:40: previous definition here ../../../glut-3.6/progs/demos/smooth/glm.h:49: conflicting types fortypedef struct GLMtriangle GLMtriangle'

Its quite important to me to get this thing working, because I imagine new releases of Gem will have more in common with 87 than 86. Why am I the lucky one?! ;) hehehe.

whats the relation between: glut-3.6/progs/demos/smooth/glm.h and GemLibs/glm/glm.h

all the GL stuff is driving me crazy.

PS: anyone working on interfacing mbone tools (openMash.org) with PD?

Thanks again. Ben

On Tue, 18 Jun 2002, =?X-UNKNOWN?Q?g=FCnter_geiger?= wrote:

On Tue, 18 Jun 2002, Ben Bogart - FMPM/F1999 wrote:

...

I also tried Guenter's suggestion changing the glm.h to point to GL/gl.h rather than GL/glut.h

Gem always compiles fine, no errors, not always refuses to load with the glmFacetNormals__FP8GLMmodel symbol "missing"

I've been trying to get gem.87 to work since it was released on multiple linux distros. Why can't I get it to work!?

I really appreciate everyones efforts.

There is one thing that you could try, that is putting extern "C" { #include <glm.h> } clause in model.h and multimodel.h ...

but this is only a slim chance. It could be that your compiler doesn't define __cplusplus Which version of gcc are you using ?

Guenter

...

Thanks Ben

On Tue, 18 Jun 2002, IOhannes zmoelnig wrote:

...

you might have to add the correct library path by hand so something like "-L/usr/local/glut-3.6/lib/glut/" in the LDFLAGS-line

...

I'd appriciate any help. Thanks Ben

...

mfg.cdsa.asd IOhannes

B. Bogart

B. Bogart

Thank you Johannes,

Ben

On Wed, 19 Jun 2002, IOhannes zmoelnig wrote:

Ben Bogart - FMPM/F1999 wrote:

...

I'm using gcc 2.95.3

I tried adding that clause to my model.h and multimodel.h and the Gem compile fails at:

In file included from model.h:24, from model.cpp:17: ../../../glut-3.6/progs/demos/smooth/glm.h:33: redefinition of struct _GLMmaterial' ../../../glut-3.6/progs/demos/smooth/glm.h:40: previous definition here ../../../glut-3.6/progs/demos/smooth/glm.h:49: conflicting types fortypedef struct GLMtriangle GLMtriangle'

Its quite important to me to get this thing working, because I imagine new releases of Gem will have more in common with 87 than 86. Why am I the lucky one?! ;) hehehe.

whats the relation between: glut-3.6/progs/demos/smooth/glm.h and GemLibs/glm/glm.h

OK i tried to fix the configure stuff yesterday, but somewhat was in a hurry and ended up with "openGL is mandatory" (which it is not)

i will continue today...and hope i will get it fixed (at least for ben)

the glm-"library" (it is one c-file) is stripped of the glut-example. it just provides an object-loader and i found it much more elegant than the old one (which was broken on linux then (hahahaha))

give me 3-4 hours (i have to do a presentation right now)

mfg.cd.sadf IOhannes

...

all the GL stuff is driving me crazy.

B. Bogart

on my debian gnu/linux system i made the experience that quicktime movies should be compressed with photo jpeg or motion jpeg-a, other codecs are not yet supported.

ulrich

On Wed, 26 Jun 2002, Jim Ruxton wrote:

. I get an error saying alea.mpg does not appear to be a supported movie. Same message for anim-1.mov .

so: you have to have one (or more) of the following DEVeloper-packages (headers + libs) installed before running configure and make: libquicktime4linux libmpeg libmpeg3

I have the quicktime installed at /usr/include/quicktime This includes all header files and librairies . / configure still says: "checking for quicktime_open in -lquicktime... no" My gem source is at /usr/lib/pd/gem/gem0.87/src/Gnu . Any other thoughts why quicktime isn't being found? Do you know where I can get the most recent versions of: libquicktime4linux libmpeg libmpeg3

Heroine Warrior http://heroines.sourceforge.net/quicktime.php3 no longer supports quicktime4linux or libmpeg3 . Thanks again.

Jim

I am trying to get pix_movie to load one of the example files (alea.mpg) . I get an error saying alea.mpg does not appear to be a supported movie. Same message for anim-1.mov . I installed quicktime directory underneath directory gem-0.87/quicktime ie. beside gem-0.87/src etc. Is this the proper place to put it? Anyone have any ideas what else could be wrong? Thanks. Jim

Are you using precompiled binaries or have you compiled it yourself? I'm not sure what options are available with the precompiled binaries, but there are three compiler flags that can be set:

-DHAVE_QUICKTIME -DHAVE_MPEG -DHAVE_MPEG3

...so ya might wanna check the makefile to see which ones are being used, and then adjust to your setup...btw, I don't know how the quicktime lib is supposed to be installed, so you may want to double check that your doing it correctly...

l8r, jamie

On Mon, 17 Jun 2002, IOhannes zmoelnig wrote:

btw: the glutSolidTeapot should have been found by the configure too.

by the way (no i remember): glm depends on glut: that is why i chose to put the teapot in Gem (it makes no sense, but it was just there)

actually glm doesn't depend on glut .. You can replace the <glut.h> with <GL/gl.h> in the glm.h file and it still compiles and works.

Generally I think we should maintain those libraries within the gem sources, because the chances are very slim that they will ever be a standard. (talking of glm, particle, liborb)

We could then get rid of all this searching stuff in configure I added a few years ago, which makes the build system quite ugly ... (and very slow sometimes)

Guenter

On Wed, 19 Jun 2002, Frank Barknecht wrote:

Very slow here, indeed. I have very big harddisks, and I think, most people do nowadays, and the searching took really long.

The problem is that with the new version it searches everywhere, whereas before it was searching only in gem/.. and its subdirectories. (Which was still slow if you extract gem in your (huge) home directroy directly). Another problem that existed was that it would find libraries in one of your old gem-xx source trees, therefore reincorporating bugs that where already fixed ..

Guenter