revast / dvj

Automatically exported from code.google.com/p/dvj
GNU General Public License v3.0
0 stars 0 forks source link

problems under Linux - syphon #240

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?

follow the install guide from the wiki plus comments from issue 142

1.svn checkout [successful]
2. install packages [successful]
3. make 

What version of the product are you using? On what operating system?
svn revision from today, ubuntu Maverick amd64 on an HP laptop with nvidia 
quadro graphics card.

after fixing 

tux@ubuntu:/media/roota/b0/dvj/dvj$ make
make[1]: Entering directory `/media/roota/b0/dvj/dvj/src'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/media/roota/b0/dvj/dvj/src'
make[1]: Entering directory `/media/roota/b0/dvj/dvj/tools'
make[2]: Entering directory `/media/roota/b0/dvj/dvj/tools/diskWriter'
make[3]: Entering directory `/media/roota/b0/dvj/dvj/tools/diskWriter/src'
    make LGL.module
make[4]: Entering directory 
`/media/roota/b0/dvj/dvj/tools/diskWriter/src/LGL.module'
    make oscpack.module
make[5]: Entering directory 
`/media/roota/b0/dvj/dvj/tools/diskWriter/src/LGL.module/oscpack.module'
    g++ PrecompiledHeaders.gch
In file included from PrecompiledHeaders.pch:5:0:
OscHostEndianness.h:70:2: error: #error please edit OSCHostEndianness.h to 
configure endianness
In file included from PrecompiledHeaders.pch:13:0:
UdpSocket.h: In constructor 
‘UdpListeningReceiveSocket::UdpListeningReceiveSocket(const IpEndpointName&, 
PacketListener*)’:
UdpSocket.h:152:47: error: ‘printf’ was not declared in this scope
make[5]: *** [obj/lin/PrecompiledHeaders.h.gch] Error 1
make[5]: Leaving directory 
`/media/roota/b0/dvj/dvj/tools/diskWriter/src/LGL.module/oscpack.module'
make[4]: *** [oscpack.module/obj/lin/module.lin.lib] Error 2
make[4]: Leaving directory 
`/media/roota/b0/dvj/dvj/tools/diskWriter/src/LGL.module'
make[3]: *** [LGL.module/obj/lin/module.lin.lib] Error 2
make[3]: Leaving directory `/media/roota/b0/dvj/dvj/tools/diskWriter/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/media/roota/b0/dvj/dvj/tools/diskWriter'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/media/roota/b0/dvj/dvj/tools'
make: *** [default] Error 2

with #include <stdio.h> in UdpSocket.h and 

#ifndef OSC_HOSTENDIANNESS_H
#define OSC_HOSTENDIANNESS_H

#define OSC_HOST_LITTLE_ENDIAN 1

#endif /* OSC_HOSTENDIANNESS_H */

in OscHostEndianness.h, 

compiling sdl to /opt/dvj/sdl,

(which did succeed after commenting out #define SDL_INPUT_LINUXEV 1
in SDL_config.h)

libturbojpeg to /opt/dvj/libturbojpeg 
and then setting 

#include </opt/dvj/libjpeg-turbo/include/jpeglib.h> 

in LGL.cpp, 

and setting these environment variables

export 
CPLUS_INCLUDE_PATH=/opt/dvj/libjpeg-turbo/include/:/opt/dvj/sdl/include/:CPLUS_I
NCLUDE_PATH
export LD_LIBRARY_PATH=/opt/dvj/libjpeg-turbo/lib:/opt/sdl/lib:LD_LIBRARY_PATH

before issuing make, 

I am now able to compile dvj without disturbing the builtin system libraries. I 
think I will also have to do that with ffmpeg...

But I am stuck at syphon - dunno why it would want to compile it under linux. 
but it tries..

tux@ubuntu:/media/roota/b0/dvj/dvj$ make
make[1]: Entering directory `/media/roota/b0/dvj/dvj/src'
    make LGL.module
make[2]: Entering directory `/media/roota/b0/dvj/dvj/src/LGL.module'
    make oscpack.module
make[3]: Entering directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/oscpack.module'
    oscpack     clang++     PrecompiledHeaders.pch
    g++ PrecompiledHeaders.gch
    g++ IpEndpointName.cpp
    g++ NetworkingUtils.cpp
    g++ Null.cpp
    g++ OscOutboundPacketStream.cpp
    g++ OscPrintReceivedElements.cpp
    g++ OscReceivedElements.cpp
    g++ OscTypes.cpp
    g++ UdpSocket.cpp
    ar rcs obj/lin/module.lin.lib
    cp obj/lin/*.o ../obj/lin/
make[3]: Leaving directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/oscpack.module'
    make RtMidi.module
make[3]: Entering directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/RtMidi.module'
    RtMidi      mkdir -p    obj/
    RtMidi      mkdir -p    obj/lin/
    RtMidi      mkdir -p    obj/osx/
    RtMidi      mkdir -p    obj/w32/
    RtMidi      clang++     PrecompiledHeaders.pch
    g++ PrecompiledHeaders.gch
    g++ RtMidi.cpp
    ar rcs obj/lin/module.lin.lib
    cp obj/lin/*.o ../obj/lin/
make[3]: Leaving directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/RtMidi.module'
    make syphon.module
make[3]: Entering directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/syphon.module'
    syphon      mkdir -p    obj/
    syphon      mkdir -p    obj/lin/
    syphon      mkdir -p    obj/osx/
    syphon      mkdir -p    obj/w32/
    ar rcs obj/lin/module.lin.lib
    cp obj/lin/*.o ../obj/lin/
cp: cannot stat `obj/lin/*.o': No such file or directory
make[3]: *** [obj/lin/module.lin.lib] Error 1
make[3]: Leaving directory 
`/media/roota/b0/dvj/dvj/src/LGL.module/syphon.module'
make[2]: *** [syphon.module/obj/lin/module.lin.lib] Error 2
make[2]: Leaving directory `/media/roota/b0/dvj/dvj/src/LGL.module'
make[1]: *** [LGL.module/obj/lin/module.lin.lib] Error 2
make[1]: Leaving directory `/media/roota/b0/dvj/dvj/src'
make: *** [default] Error 2

so how do I stop it from doing so? I hope I get further. I am a bit afraid you 
integrated syphon w./o. linux users in mind...

I know you would not want to do (or have no time to) do binary releases, for 
distributions, but ... At least a build where all dependencies are thrown into 
one folder, that would be really nice. Like firefox linux release from website 
or ardour3 are doing. People that just want to try your work, will have it easy 
as 1.2.3 -> download,  unzip, and run.  (space is big on modern harddisks, and 
you would have all the dependencies in one folder and with the versions known 
to work best..)

As for mac users (you do not do it differently on mac, there is also everything 
in one folder, isnt it? (except for jack, I assume)), if the dmg is easy to do 
(I bet it is looking at svn log ) I think it would be great to have one. Syphon 
is great, sadly not for linux...

Original issue reported on code.google.com by M8R-rp...@mailinator.com on 17 Oct 2011 at 7:31

GoogleCodeExporter commented 9 years ago
I bet the syphon compile problem can be solved with some makefile-fu if 
statements, or some #defines. openframeworks, for example, also does it that 
way (in part) already, but that's built with cross-platform in mind.
the message about the endianness is an oscpack thing. could also be avoided. 
http://code.google.com/p/oscpack/issues/detail?id=2

Original comment by Christop...@gmail.com on 17 Oct 2011 at 7:45

GoogleCodeExporter commented 9 years ago
Well I for my part am not a coder, but distributor. I have learnt to cope with 
compile errors etc, but there is no way I am gonna fix this as I do not 
understand enough in terms of c++, defines and makefiles. 
I would really love to have this program up and running, as its one of the few 
of its kind, running on linux.

Christoph, Have you ever had success in compiling a version for ubuntu? would 
you mind to share the binaries? Even if they are older, I would grab them. We 
even have the same brand of laptop with same graphics card, so I should be able 
to get it run...

Original comment by M8R-rp...@mailinator.com on 17 Oct 2011 at 9:53

GoogleCodeExporter commented 9 years ago
Sadly no, I gave up after trying the stuff documented in Issue 142 (and also 
because I didn't want to disturb my system libraries), so I got no binaries. 

Original comment by Christop...@gmail.com on 18 Oct 2011 at 7:02

GoogleCodeExporter commented 9 years ago
at least we know now how to override that.

LD_LIBRARY_PATH
CPLUS_INCLUDE_PATH

let you add things into your system paths, temorarily. So one can just make a 
folder with everything in, and a little script to define the paths so dvj finds 
the right versions of libraries and include paths before it finds the system 
ones.

Original comment by M8R-rp...@mailinator.com on 18 Oct 2011 at 9:05

GoogleCodeExporter commented 9 years ago
ahm, I got it to compile.  I tried to find the svn version before syphon was 
added...

r569        
Fix newline madness
    Feb 5, 2011

which I checked out.

I had to tinker around with the include paths again, as my previously suggested 
solution did not work any more. dunno why. So I renamed (with nautilus root) 
/usr/include/SDL and /usr/lib/pkgconfig/sdl.pc and replaced them by symlinks of 
their pendants in /opt/dvj/sdl. Then I moved all libsdl* files in /usr/lib to 
somewhere else, and replaced them with libsdl* symlinks from /opt/dvj/sdl/lib. 
well, a bit of a hazard, but works. I then realized that I had built 
libsdl_image against system sdl, not dvj one, and had to build it again, so 
that it worked. libjpegturbo did not seem to be necessarry, system libjpeg 
worked fine for now. but this procedure is also possible with it...

now for ffmpeg. The version from dep/src is older, has libavcore, which was 
merged into libavutil in later versions. So I removed the -lavcoce switch for 
now out of all makefiles.

then , with ffmpeg 0.6.2, it compiled through, and linked successfully.

 the tools folder then wants to compile, and gives the same error with endianess and udpsocket, and after resolving, surprisingly the syphon error?!?, though no syphon should be in this rev. So I replaced the LGL.module folder in the /src folder of all of the tools, by the one in src, removed the obj directories, and they compiled trough, until logDrawer, which refused to. ( http://pastebin.com/9WzQYqzU)

nevertheless, now I have a dvj.lin executeable. Which gives  

terminate called after throwing an instance of 'ConfigFile::file_not_found'
Aborted

when I try to start it...

well I think this should be solveable...

and for distribution I now just need to add an export 
LD_LIBRARY_PATH=/path/to/libs/that/dvj/needs/:LD_LIBRARY_PATH (/opt/dvj/sdl/lib 
in my case, or put it in the same folder as the executeable and do a export 
LD_LIBRARY_PATH=$(pwd):LD_LIBRARY_PATH ), and itChristoph, sould run without 
having system sdl compromized...

Christoph, if you want I can upload the binaries or the altered src.

Original comment by M8R-rp...@mailinator.com on 22 Oct 2011 at 5:51

GoogleCodeExporter commented 9 years ago
hmm Seems like it is not so easy to get that config file written - or create 
one from scratch. the code parts leave me puzzled, and the .apps on osx from 
newes svn revision just crash / do not generate a configfile (osx 10.6.3 
hackintosh, http://pastebin.com/A45YwymC ) 

well then I can just hope about Chris helping out soon...

Original comment by M8R-rp...@mailinator.com on 24 Oct 2011 at 8:22

GoogleCodeExporter commented 9 years ago
Sry, you can't expect much help from me, I got my hands more than full at the 
moment. maybe the dev can shed some light, or help out?

Original comment by Christop...@gmail.com on 24 Oct 2011 at 8:57

GoogleCodeExporter commented 9 years ago
Sorry for the delay, I'll try to join in this conversation when I get home from 
work, tonight.

Original comment by interim....@gmail.com on 24 Oct 2011 at 6:08

GoogleCodeExporter commented 9 years ago
Hi.

I thank you for your interest, and I'm sorry that most of the answers won't be 
to your liking.

Important issues have been fixed since I added syphon support. I would 
anticipate an imperfect UX with pre-syphon versions, so, really, don't use them.

I've committed a change that should stub out all references to syphon in linux. 
I hope. Let me know if you're still seeing failed syphon linkage. My linux 
machine is on the wrong coast for me to test this directly.

That having been said, I don't advise, encourage, or desire dvj running on a 
hackintosh. Or linux, for that matter.

In my years working on this project, I found it essential to have a solid, 
uniform platform. Linux is awesome, but it can come in a million flavors. 
Realtime kernel? Audio drivers? Video drivers? A good xorg.conf? Shoddy 
hardware? There's a million things that can go wrong on a linux machine. In 
years of development, I couldn't get dvj running adequately on my linux machine 
without hiccups. Upon porting to OSX, the hiccups vanished. I suspect the linux 
nvidia drivers, but I don't know for sure.

Regardless, there's no way in hell I can promise an acceptable linux UX under 
the myriad different combinations of hardware, kernels, drivers, and userland 
software. As such, I have no desire for dvj to be used by anyone under linux 
until the platform provides the same level of reliability and consistency as 
osx. Sorry. I really wish it were different, but that's how it is. Maybe 
there's other DJ/VJ software out there for linux that has more resources than I 
do, that can provide a UX they consider acceptable. I hope so.

You'll notice there's no OSX app bundles that are distributed for dvj, either. 
Although this is the program that powers Shpongletron, I don't desire any users 
until I feel the UX is nearly Apple-like. It may never get there, and that's 
ok. But I'm not going to release something imperfect, and suggest people use 
it. That just causes trouble for everyone involved.

I develop in the open because it is the right thing to do. I should make it 
more clear on dvj's landing page that it's not intended for users, yet. Sorry 
for the time you spent on this, and I'm sorry this software isn't yet ready for 
general use. This class of software, intended for performance in front of 
audiences of thousands, cannot be released until it's perfect at what it does. 
A single crash under such circumstances taints the artist, the software, and 
myself. Otherwise, lesser suboptimal UX isn't acceptable, either.

Original comment by interim....@gmail.com on 25 Oct 2011 at 9:00

GoogleCodeExporter commented 9 years ago

Well, thanks for answer. At least I want it to compile properly on Linux, and 
then judge myself. Would be very nice if you could provide that. I will try to 
make a selfcontained binary release, where all depencencies are inside one 
folder.

I have checked out from svn again, and now I get

make[3]: Entering directory 
`/media/roota/b0/dvj/dvj-/src/LGL.module/quicktime.module'
    ar rcs obj/lin/module.lin.lib
    cp obj/lin/*.o ../obj/lin/
cp: cannot stat `obj/lin/*.o': No such file or directory
make[3]: *** [obj/lin/module.lin.lib] Error 1
make[3]: Leaving directory 
`/media/roota/b0/dvj/dvj-/src/LGL.module/quicktime.module'
make[2]: *** [quicktime.module/obj/lin/module.lin.lib] Error 2
make[2]: Leaving directory `/media/roota/b0/dvj/dvj-/src/LGL.module'
make[1]: *** [LGL.module/obj/lin/module.lin.lib] Error 2
make[1]: Leaving directory `/media/roota/b0/dvj/dvj-/src'
make: *** [default] Error 2

hrmph.. seems like the detection of what to compile on which platform is 
disfunct. I do not really understand makefiles, so I am not shure how to fix 
this, I tried to rename the quicktime.module and syphon.module (which gives the 
same error), then comment out the syphon include line 77 in LGL.h it then went 
on, in LGL.cpp I commented lgl_SyphonExit(); on line 3014, chaged path to my 
libjpegturbo, and now it gives 

LGL.cpp:3195: error: ‘UnsignedWidePtr’ was not declared in this scope
LGL.cpp:3196: error: expected ‘,’ or ‘;’ before ‘{’ token
LGL.cpp: In member function ‘double LGL_Timer::SecondsSinceLastReset() 
const’:
LGL.cpp:3229: error: ‘UnsignedWide’ was not declared in this scope
LGL.cpp:3229: error: expected ‘;’ before ‘currentTime’
LGL.cpp:3230: error: ‘currentTime’ was not declared in this scope
LGL.cpp:3230: error: ‘Microseconds’ was not declared in this scope
LGL.cpp:3231: error: ‘ConvertMicrosecondsToDouble’ cannot be used as a 
function
LGL.cpp: In member function ‘void LGL_Timer::Reset()’:
LGL.cpp:3249: error: ‘UnsignedWide’ was not declared in this scope
LGL.cpp:3249: error: expected ‘;’ before ‘currentTime’
LGL.cpp:3250: error: ‘currentTime’ was not declared in this scope
LGL.cpp:3250: error: ‘Microseconds’ was not declared in this scope
LGL.cpp:3251: error: ‘ConvertMicrosecondsToDouble’ cannot be used as a 
function
LGL.cpp: In function ‘int lgl_video_decoder_preload_thread(void*)’:
LGL.cpp:10277: error: ‘LGL_PRIORITY_VIDEO_PRELOAD’ was not declared in this 
scope
LGL.cpp: In function ‘int lgl_video_decoder_readahead_thread(void*)’:
LGL.cpp:10402: error: ‘LGL_PRIORITY_VIDEO_READAHEAD’ was not declared in 
this scope
LGL.cpp: In function ‘bool lgl_decode_jpeg(unsigned char*, long int, unsigned 
char*, long int)’:
LGL.cpp:11928: error: ‘jpeg_mem_src’ was not declared in this scope
LGL.cpp: In function ‘unsigned int LGL_CPUCount()’:
LGL.cpp:31886: error: ‘CTL_HW’ was not declared in this scope
LGL.cpp:31887: error: ‘HW_NCPU’ was not declared in this scope

which I assume is mac specific code, as 
http://www.meandmark.com/timingpart1.html and   
http://www.opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/MacTypes
.h assume. 

Original comment by M8R-rp...@mailinator.com on 28 Oct 2011 at 2:45

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
You know, it is a bit like chicken and egg problem when argumenting like that.
As I see how much work you have done here, I understand you. But I do think it 
would be nice to have an alpha/beta release for linux to get people attracted, 
so they can honour what you have done so far, and eventually help out/join in 
development. I can only assume that this is not in your scope because of time 
constraints, but I refuse to let dvj lie around, when it could be working quite 
fine on linux, despite of many other vj programs in linux, which are also 
nowhere near perfect. But thats ok. If people can use them, know that they are 
there, they can attract users, and eventually get a crowd of people interested 
in it.

I for my part am doing a Linux distribution called openArtist, which is why I 
know most if not all vj programs for linux. I would be more than pleased to get 
dvj into my distro, despite the issues you mentioned. I koww about the 
"Problems" one faces, in comparison to osx, but I have worked towards that, 
finding more and more solutions. I try to put my flavour into a stable base for 
multimedia. I know the divers etc. issue, Its not nice. but It works quite well 
for most people.

I have now tried to build with revision 719, but It does stop at the quicktime 
error again...

Well I hope you read this and at least do not fully drop the linux build 
capability. I can also wait for the version which you think is ready for 
public, If you think its the right thing to do, but I am quite eager to try dvj 
and play around with the software for my personal use. 

Original comment by M8R-rp...@mailinator.com on 6 Nov 2011 at 4:09

GoogleCodeExporter commented 9 years ago
(sorry, but a bit offtopic): openArtist looks interesting! Is there a list of 
contained software? I couldn't find one. It would be nice to have, so people 
can get a quick overview of what they get, and what applications are out there. 
Personally, I would like to know if there are any VJ programs I don't know 
about yet...

Original comment by Christop...@gmail.com on 6 Nov 2011 at 6:26

GoogleCodeExporter commented 9 years ago
you are right. ok I have done such a list now. I have limited time on working 
on openArtist right now, you are welcome to try it out/Join in with some help, 
e.g documentation...

Original comment by M8R-rp...@mailinator.com on 7 Nov 2011 at 4:03

GoogleCodeExporter commented 9 years ago
huh, that's a huge list. Are those all programs which work in openArtist? For 
example, I never succeeded in properly running Resolume Avenue on Ubuntu 
(+Wine) - does that work?

Original comment by Christop...@gmail.com on 7 Nov 2011 at 4:27

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Yes, all these programs should work with openArtist. 

There is, however the System tools category, called Controlcenter, Which is not 
included in this list right now.. and there are definitely bugs here and there.

Also resolume works - to a degree. there are some quirks with it. You can go 
fullscreen with the preview window, but you cannot get out of it again. so 
output is limitied to preview window, which you can make capionless and move to 
second monitor in right resolution. It eats quicktime movies quite well. The 
cinepack codec avi files which come with it do not work in wine, so I replaced 
them with resolumes dxdi codec quicktime files. I have MPEGStreamcilp in the 
distro, which is a frontend to quicktime, and allowsyou to encode into dxdi. 
Audio works fine, also via ASIO. which then allows you, via wineasio,  to 
connect resolume with jack aware applications.

  haven't tried new version 4 yet...

Original comment by M8R-rp...@mailinator.com on 11 Nov 2011 at 6:54

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
As I see that the dvj linux side is disfunct right now, I will at least try to 
compile on my hackintosh 10.6.3. 
I will report my impressions then..

Original comment by M8R-rp...@mailinator.com on 11 Nov 2011 at 11:22

GoogleCodeExporter commented 9 years ago
as I said before, It would be really nice to retain linux compatibility. 
I would be more than willing to help out for that.

Original comment by M8R-rp...@mailinator.com on 11 Nov 2011 at 11:24

GoogleCodeExporter commented 9 years ago
i too would really love to see this working on linux, i will try to get a 
friend to compile it on his macbook pro. but i run linux, and love it, and use 
it for visuals with all sorts of programs already(lpmt mandlebulber, openshot, 
vsxu, projectm + more) yeah, it is not perfect, yeah it crashes sometimes (i 
just did a show where the visuals were down half the time due to tech 
difficulties, just means i have to smooth them out for next time, sure it was a 
little discouraging, but the promoter still wants me to do work for her and i 
want to continue to evolve)...im super interested in this software, and would 
like to get it working on linux so bad that i can offer up 100 canadian dollars 
and my eternal gratitude to the person who can get this compiling and running 
on linux for me.
Mike Savage,
Open to Source
http://www.opentosource.net

Original comment by savageon...@gmail.com on 28 Feb 2012 at 12:39