Installation under Linux

[yaxu]

Tantalising, but I haven't managed to get it working.. Here's some notes. The stock Debian Jessie glfw was too old, but installed that from source, no problems there.

GLXW is a dependency, and I'm not sure where to get it, it's not in debian.. This seems to be it:
https://github.com/rikusalminen/glxw

There is no install process, I manually moved the header files into /usr/local/include, not sure whether that is the right thing..

I then get this error:

weltfrieden.c:103:5: error: expected expression before ‘:’ token
     ::exit(EXIT_FAILURE);

I solve this by deleting the colons.

Then I am in the realm of missing x11 dependencies:

/usr/bin/ld: /usr/local/lib/libglfw3.a(x11_init.c.o): undefined reference to symbol 'XIQueryVersion'

I add -lX11 -ldl -lXi -lXxf86vm -lGL -lXinerama -lXCursor -lXrandr to the LDFLAGS as it asks for them..

I also copy in glxw.c, and add it to SOURCES in the Makefile..

Then it compiles!! and..

alex@olga:~/src/weltfrieden$ ./weltfrieden 
Segmentation fault

[yaxu]

Here's what gdb says:

(gdb) run
Starting program: /home/alex/src/weltfrieden/weltfrieden 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000403fc2 in main (argc=<optimized out>, argv=<optimized out>)
    at weltfrieden.c:78
78    const GLubyte* renderer = glGetString (GL_RENDERER); // get renderer string

[lennart]

@yaxu I haven't run this on linux and I am definitely not sure why I added the glxw header (including the casing for linux and windows)

If I remember correctly it should compile fine without the glxw.h include. (and did run—though shaders fail—on a raspberry pi 2 (debian, but I guess sid/unstable))

The segfault appears when reading opengl version information, which seems rather odd, can you try recompiling (make clean && make) without the glxw.h ?

[yaxu]

@lennart It still segfaults. With optimisation turned off (i.e. removing -O3) it fails at printing out the version...
Oh wait this time I ran it, it didn't segfault. Hmm! We seem to have an intermittent fault.

[yaxu]

Yes now it seems to run every time, can't get it to segfault whether or not -O3 is on. But I just get a black window, no shaders here either. It does seem to be receiving the osc, though..

[lennart]

It could be that your graphics card does not support the current shaders. Can you tell me the log output from weltfrieden, mine says:

Renderer: NVIDIA GeForce 9400M OpenGL Engine
OpenGL version supported 3.3 NVIDIA-10.0.37 310.90.10.05b12
Starting Rendering

Regarding shaders, I'll be adding a DEBUG flag to turn on Shaderlogging.

[yaxu]

Renderer: Mesa DRI Intel(R) Haswell Mobile 
OpenGL version supported 3.3 (Core Profile) Mesa 10.3.2
Starting Rendering

[lennart]

are you on irc?

as I am trying to get a test setup running in a virtual machine and would be interested to get this working on linux.

I’d be interested if the shaders cannot be loaded correctly on your side, or if it is something different.

On 10 Oct 2015, at 09:40, Alex McLean [email protected] wrote:

Renderer: Mesa DRI Intel(R) Haswell Mobile
OpenGL version supported 3.3 (Core Profile) Mesa 10.3.2
Starting Rendering
—
Reply to this email directly or view it on GitHub #1 (comment).

[lennart]

I updated the instruction for dependencies and setup for linux (and osx). I have this working on a raspberry pi 2 (though with explicitly sourcing from the debian sid repositories), it even works with glfw3 installed via apt-get.

libepoxy is added to load the correct gl headers on linux based systems. There is no need for glut anymore. I did not use any extension loader (no GLEW, or GLAD), so these will not needed or linked against.

I added logic for choosing the shading level and choose the appropriate shaders for your graphics card. Since you have a OpenGL 3xx capable card, you should be able to use most of the shaders.

[yaxu]

Thanks it's working now! Compiling + working out of the box. Fun stuff!

I did notice that the timing isn't right. Tidal calculates and sends dirt messages so many times per cycle (I can't remember, maybe 4), which dirt then schedules according to the timestamp. This is to iron out any network jitter. As you're not doing the scheduling this isn't well timed: s1 $ sound "basic*3"

You can switch off this behaviour so Tidal does the scheduling for you:

let splashState = Sound.Tidal.Context.state "127.0.0.1" 7772 (dirt {timestamp = NoStamp})

But you'd then also need to change weltfrieden to not expect the timestamp related parameters.

BTW you might be better off making a new OscShape with parameters that make sense for weltfrieden (although I can see why you're reusing the dirt one)..

[lennart]

Great it works!

Regarding timing, I opened another issue for that.