Building (Open) AstroMenace on Debian

To start, download the sources from http://sourceforge.net/projects/openastromenace/, install the required dependencies (ReadMe.txt will tell you, or you can try just building it and see what it complains about missing), and build (cd build; cmake ..; make;).

While trying to build (Open) AstroMenace on Debian I encountered the following error:


OpenAstroMenaceSVN/AstroMenaceSource/Core/RendererInterface/OGL_Draw3D.cpp:38: error: ‘PFNGLCLIENTACTIVETEXTUREPROC’ does not name a type

Googling only turned up this, which was exactly the problem I encountered, but offered no solution.  I figured out it was missing a definition from some OpenGL header.  So I traced back the includes, and found the following text in OpenAstroMenaceSVN/AstroMenaceSource/Core/Base.h

#ifdef WIN32

        ...

#endif

#if defined(__APPLE__) && defined(__MACH__)

       ...

#else

        #define __glext_h_  // Don't let gl.h include glext.h

        #include      // Header File For The OpenGL32 Library

        #include     // Header File For The GLu32 Library

        #undef __glext_h_

#endif

Now, it has the comment "Don't let gl.h include glext.h".  However, I don't see why not!  Because when I comment out the #define and #undef statements, it compiles fine!  It should look like:

#else

        //#define __glext_h_  // Don't let gl.h include glext.h

        #include      // Header File For The OpenGL32 Library

        #include     // Header File For The GLu32 Library

        //#undef __glext_h_

#endif

So then it compiled correctly, but still got a very strange error when linking:

Linking CXX executable AstroMenace

c++: `sdl-config: No such file or directory

make[2]: *** [AstroMenace] Error 1

make[1]: *** [CMakeFiles/AstroMenace.dir/all] Error 2

make: *** [all] Error 2

It seems like some sort of quotation mismatch error.  I went through the CMake setup file, and it seemed fine. So instead, I just tried to manually link it myself.  I found the linker command it was trying to execute in CMakeFiles/AstroMenace.dir/link.txt, but I couldn't find anything wrong with it, so I copied the contents, put them into a terminal, and pressed enter. For some reason, this now worked!  For reference, this is what the file contained for me: http://pastebin.com/U8UifLAq

Once it built, I then went to download the necessary data files (under the vfs section of openastromenace downloads on sourceforge, download the data, and a language), and extracted their contents into the build directory.

Then run ./AstroMenace and .... well...it works for me at this point!

Creating a voice with Festvox for Festival in debian/linux

Okay, Debian provides packages for speech-tools, but they aren't complete.  On top of that, the latest package versions provided at festvox.org are of incompatible versions with eachother.  Instead of trying to figure that out, I suggest downloading the svn: http://developer.berlios.de/svn/?group_id=3272

All we care about are speech_tools and

./configure and make them both.

Then start following this tutorial:

http://festvox.org/bsv/x1003.html

However, there might be a few problems.  Recording audio is a little bit funky, as they use na_record, which doesn't support ALSA.  However, hopefully you have oss support enabled.  When you get to the point where you are going to execute bin/prompt_them you might want to modify it first.

the line 

$ESTDIR/bin/na_record -f 16000 -t $duration  wav/$f.wav

can be replaced with

$ESTDIR/bin/na_record -audiodevice /dev/dsp1 -f 16000 -time $duration  wav/$f.wav

if you want to send it to the oss device /dev/dsp1

Or, you can replace it with arecord (which uses ALSA) like so:

arecord -Dplughw:1 -r 16000 -d $duration  wav/$f.wav

(this will record from the ALSA device plughw:1).

You can also uncomment various features inside this file, such as waiting for you to press return before recording, or playing back your recording immediately after you record it.

I'll update this as I encounter more problems.

Merging in git while ignoring newlines (or, Convert newline style to match file-by-file)

Basically, I want to merge two commits that are mostly the same, except some of the files have different newline endings.
Basically my problem looked like this.
      
     First commit with strange line endings
       | |
       V
A-B-C-D-E-F-G

        H
        ^
        ||
   Second commit with strange line endings.

I wanted to rebase H on top of C, and then merge with G. but C and H had differing newline endings, and there was no order to which files had which type.  So my solution was to hack together an absolutely horrible script that went through each file in H and converted it to UNIX or DOS newline styles, depending on which one would cause it to have a smaller diff with the same file in C.


Here it is:

    find . \! -type d -exec sh -c "unix2dos -q '{}';DOS=\$(git diff COMMITC -- '{}' | wc -c); dos2unix -q '{}'; UNIX=\$(git diff COMMITC -- '{}' |wc -c); if \[ \$DOS -lt \$UNIX ]; then unix2dos '{}'; fi" \;

You execute it with commit H checked out, and COMMITC replaced with the name of your "commit C" in my diagram.

Building Hypermammut in Debian.

So, I've been trying to get hypermammut to compile and run for me.  The released tarball has a few problems in it.  I've gotten it to compile, but it still crashes when I try to open a file.  However, I figure the steps I've shown are at least closer to getting it to work.

I should note that I am on a 64 bit system, but I think I will explicitly point out everywhere where this is relevant.

First of all, you need to install the proper dev files.  Obviously you need a C++ compiler, etc, but the libraries you need to install specially are (and I list them with their Debian package names): magick++-dev libfftw3-dev
libwxgtk2.8-dev libaudiofile-dev.  You also need to install the build tool scons.  I should note that there is also a package named libmagick++-dev, which is not the same as magick++-dev.  The former will not work, and the two are mutually exclusive.

 Second the Scons build script is horribly broken (SConstruct).  I don't know scons, but I was able to figure out enough to fix it.

It would try to generate commands like

g++ -o IO/AInput.o -c -fPIE -pie "-ggdb `wx-config --cppflags` -Wno-unused-macros" IO/AInput.cpp

The double quotation marks just messing things up.  Additionally, it was missing the correct flags for fftw and audiofile in some cases.

I was able to clean it up enough to this point (I am only posting the bottom part of the file, because the top is just a big list, which I didn't change at all.)


env = Environment();
SConsignFile(".scons-signatures")
env.ParseConfig('Magick++-config --ldflags --libs')
env.ParseConfig('wx-config  --libs --cppflags')
env.ParseConfig('pkg-config fftw3f audiofile --libs')
env.Append(CCFLAGS = '-ggdb')
env.Append(LINKFLAGS = '-ggdb')
env.Program('test_s2i2s',lista);

Another issue which popped up (I'm pretty sure only due to 64 bit architecture) was in Process/Generator/Random.cpp. In the function Random::Random(), you need to replace the line

s1=get32bits()+(int) this;

with

s1=get32bits()+(int) ((intptr_t)this);

and add the include

#include <stdint.h>

to the top of the file.  This basically does the proper cast when ints and pointers aren't necessarily the same size.

Also, the file UI/ParametersDialog.cpp is missing the include

#include <wx/wx.h>

Now, run 

scons

It will build (at least on my system).  It will create the executable "test_s2i2s".  Unfortunately, whenever I try to load a file, it crashes.  If it is an audio file, it says

Audio File Library: could not open file 'test.wav' [error 3]

ERROR: Could not import audio file.

If it is an image file, it says 

test_s2i2s: magick/semaphore.c:525: LockSemaphoreInfo: Assertion `semaphore_info != (SemaphoreInfo *) ((void *)0)' failed.

Aborted

I don't have the time nor energy to track down these bugs, but they seem to be much deeper than misconfigured dependencies.  Hopefully I've sent someone down the right path to getting it to build correctly.

Uninstall/Disable feature/plugin in Eclipse Helios (3.6)

Not that I want to editorialize often, but Eclipse is just horrible when trying to remove a plugin.

I tried going to help ->install new software -> check what's already installed... The uninstall option is grayed out for all the relevant plugins.  No indication whatsoever why, or how to fix this.

I instead try going to Help-> Check for New updates.  It simply pops up a dialog saying no updates were found.  No further options.

I try going to Help-> Eclipse marketplace.  It seems Solutions (which are the only things you can modify using this dialog) are different than plugins.

I try going to Help->about eclipse ->installation details.  I get the same menu as if I click install new software.

I try googling.  It either says go to Help->about eclipse ->installation details (which I already tried), or to do  Help -> Software Updates -> Manage Configuration. The second suggestion is simply not available on Eclipse Helios.  I assume I am looking at the documentation for a different version of eclipse.  I find the documentation for Eclipse Helios (3.6), and nope, it's exactly the same.  At this point I hit a lucky break, and I notice that the text describing the menus to open is a link.  I click on it and it says "you can only do this with local help".  I find the same page again in the local eclipse help.  I click the link.  Viola, the magical hidden window pops up that finally allows me do uninstall the plugins.  Did it really have to be that hard?

Grub not listing Windows (7) installation.

(This works for me on Debian, but probably works on similar systems as well.)

If your grub menu does not list an OS partition which you know is installed, try running update-grub.  If it still isn't listed, try installing os-prober (apt-get install os-prober). This is a program designed to locate non-linux OSes.  Run sudo os-prober.  Hopefully, it will detect the Windows installation you want it to, and it will print out a line indicating the device name and detected OS.  If it doesn't, I can't really help you, but your next step would be to somehow get os-prober to detect the installation.  Assuming you have os-prober detecting the OS as you want it too, try running update-grub again.  It will print out a line indicating that it has detected the installation.  When you reboot, the option should appear on the grub menu.

If os-prober is detecting the OS, but update-grub isn't, look for the file /etc/grub.d/30_os-prober (or something similar), that is the problem (either it isn't installed there, or it is misconfigured).

This really should be the first step you take if it isn't detecting a windows install properly.  No need to do Wndows MBR recovery or any sort of custom grub.d configuration.

EDIT: I found that there can also be issues detecting the install if the Windows 7 bootmgr is corrupted (don't ask me how that happened).  If you start up the windows recovery environment (you can download a recovery CD iso easily if you google) and then recover the boot manager, os-prober will now detect the install.  Just run update-grub to add it to the startup menu.

Building Tartini on Debian

Tartini is a cool real-time "music analysis" program (http://miracle.otago.ac.nz/tartini/index.html).  The issue is that the sources don't immediately compile on my Debian system.

UPDATE: I've actually gone through and fixed all the issues and created a Debian package for it.  You can download the source at https://github.com/jeremysalwen/tartini-debian  Hopefully it will be in debian too soon.

Obviously, as the instructions say, qt 4, fftw 3, and qwt 5 must be installed for it to compile.  Installing the packages fftw3-dev and libqt4-dev is straightforward.  Make sure that if qt3 is installed, all of the build tools point to the qt4 versions. However, be careful with qwt, as the debian repositories contain a package "qwt-dev" which is not version five.  Instead, install libqwt5-qt4-dev.


As the build instructions state, you then have to modify pitch.pro to tell it where the includes and libraries are.  On a typical debian system, the important part of the file should look like:

unix{
  macx{ #MacOSX
    MY_LIB_PATH += -L/Users/student/usr/local/lib
    MY_INCLUDE_PATH += /Users/student/usr/local/include
  }else{ #Linux
    MY_LIB_PATH += -L/usr/lib
    MY_INCLUDE_PATH += /usr/include/qt4 /usr/include/qwt-qt4 /usr/include
  }
}

Then, qmake will still give you the error

RCC: Error in 'pitch.qrc': Cannot find file 'pics/tartinilogo.png'

For some reason it's looking for a png when the file is really a jpg.  Just modify pitch.qrc to replace tartinilogo.png with tartinilogo.jpg

qmake will then work, but make will still complain about

error: invalid conversion from ‘const char*’ to ‘char*’

a bunch of times.   mystring.cpp and mystring.h are the offending files.  Basically there is a bunch of code that seems to be just *wrong* in how it handles constness.  If you make the local variable "char * ext;" into "const char * ext;" in two functions, and make getFileExtension return type "const char*" instead of "char*", it will work.  (don't forget to change the function in both the cpp and the header file.

Meanwhile, prony.cpp gives a cryptic warning about the included file "cstdio", which seems to be caused by the line:
#define _GLIBCXX_USE_C99

I am not really sure if this affects the functionality of the code, but when I comment it out, it compiles and runs fine.  Apparently there is strange functionality surrounding this symbol anyway: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443234

You will also get a linking error because it tries to link with -lqwt, when the qwt5 package only provides qwt-qt4.  Again, under the linux section of pitch.pro, replace the line

LIBS += $$MY_LIB_PATH -lfftw3f -lqwt -lasound

with

LIBS += $$MY_LIB_PATH -lfftw3f -lqwt-qt4 -lasound

Still, when you build it, it segfaults when you try to run fixing up calculateAnalysisData in mytransforms.cpp, we replace

if(chunk > 0 ) {
with

if(chunk > 0 && prevAnalysisData->highestCorrelationIndex!=-1) {

To stop the segmentation fault if the previous highest correlation index is -1 (not found).

And that should be enough to get a working Tartini build on Debian.  I would post a diff or a zip of all the corrections, but I can't attach it here.