Sine Sine Everywhere a Sine

[billstei]

Linux?! I thought I was the only heretic here.

I too am a sinner

Why isn't Shamanix on DistroWatch yet ?

[Shamanix]

LOL

[Mark Landman]

The biggest problem that I anticipate is I have no way of doing an OSX build. Linux (for sure) and MS Windows look doable. I'm still wondering how many people will actually use this thing...

I'd happily use it, but I'm on OSX.

[billstei]

The biggest problem that I anticipate is I have no way of doing an OSX build. Linux (for sure) and MS Windows look doable. I'm still wondering how many people will actually use this thing...

I'd happily use it, but I'm on OSX.

Assuming that I make this open source (probably) then I can't see any reason to think that someone with real Apple hardware/OS couldn't build it for OSX. In it's present form, all the necessary components are available for OSX. It's just that I can't build it.

[xh3rv]

I'd be happy to compile for OS X, it's the kind of thing I should be doing for educational value anyway.

[billstei]

I'd be happy to compile for OS X, it's the kind of thing I should be doing for educational value anyway.

I am using CodeLite as an IDE (so BlueberryThing is saved/built as a CodeLite project), so you could try installing CodeLite (I don't actually use the most recent version -- I'm using 1.0.2759) You also need wxWidgets installed with all the development headers and libraries. Don't ask me how you do that on OSX, I have no idea. Assuming you have that stuff, you can see if you can use the CodeLite project Wizard to make a wxWidgets Application.

1) Use menu Workspace->Create New Workspace
2) The wxWidgets wizard tool (6th one from the left) will un-gray as "New wxWidget Project", and you can click it, and type in a project name, and select "GUI Application with Main Frame".
3) Menu Build->Build Project, should compile and link.
4) Menu Build->Run, should run the app as a (very) simple window that you can Close/Quit (and not much else).

Of course there's a gazillion things that can go wrong, but if you can do that, then you've made a good start.

[xh3rv]

Of course there's a gazillion things that can go wrong, but if you can do that, then you've made a good start.

Mercifully, nothing went wrong at any point, built wxWidget stuff from source and CodeLite hardly required configuration. Smoother transplant than Steve Jobs' liver (can't believe KVR doesn't have a liver transplant emoticon!)

After a very brief look at documentation it looks like there are just a couple of flags to set or wxWidget library calls to tweak for optimal OS X compilation (universal binary, packaging the end result as a .app, a few platform-dependent tweaks to make wxWidget stuff to cooperate with OS X GUI a little better). So far, so good.

[billstei]

Of course there's a gazillion things that can go wrong, but if you can do that, then you've made a good start.

Mercifully, nothing went wrong at any point, built wxWidget stuff from source and CodeLite hardly required configuration. Smoother transplant than Steve Jobs' liver (can't believe KVR doesn't have a liver transplant emoticon!)

After a very brief look at documentation it looks like there are just a couple of flags to set or wxWidget library calls to tweak for optimal OS X compilation (universal binary, packaging the end result as a .app, a few platform-dependent tweaks to make wxWidget stuff to cooperate with OS X GUI a little better). So far, so good.

If you get the CodeLite wizard to work and you get the basic "GUI Application with Main Frame", I would be curious what the compilation looks like, for example this is my Linux build output for that wizard generated project: http://pastebin.ca/1469963

[xh3rv]

There was a prefab project template called GUI / 'wxWidgets wxFB Frame' that I used here.

Code: Select all

----------Build Started--------
"make"  -j 2 -f "TEST4_wsp.mk"
----------Building project:[ TEST4 - Debug ]----------
g++ -o ./wxAppMini.app/Contents/MacOS/wxAppMini ./Debug/gui.o ./Debug/main.o  "-L."   -O2              -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System  -lwx_macud-2.8  
----------Build Ended----------
0 errors, 0 warnings

This is the compilation with CodeLite set up to output an OS X app package, which is really just a special file folder but required for some basic functionality (otherwise the window acts like a coma patient, doesn't take input or make interesting conversation or anything . . .). I think I've got universal binary and compiling for OS X 10.4 worked out too, which complicates the compiler output a bunch, but is the proper thing to do for true OS X support. These tweaks are done via CodeLite's Workspace/Project settings so it should be really straightforward to adapt for your stuff.

[billstei]

There was a prefab project template called GUI / 'wxWidgets wxFB Frame' that I used here.

Code: Select all

----------Build Started--------
"make"  -j 2 -f "TEST4_wsp.mk"
----------Building project:[ TEST4 - Debug ]----------
g++ -o ./wxAppMini.app/Contents/MacOS/wxAppMini ./Debug/gui.o ./Debug/main.o  "-L."   -O2              -framework QuickTime -framework IOKit -framework Carbon -framework Cocoa -framework System  -lwx_macud-2.8  
----------Build Ended----------
0 errors, 0 warnings

This is the compilation with CodeLite set up to output an OS X app package, which is really just a special file folder but required for some basic functionality (otherwise the window acts like a coma patient, doesn't take input or make interesting conversation or anything . . .). I think I've got universal binary and compiling for OS X 10.4 worked out too, which complicates the compiler output a bunch, but is the proper thing to do for true OS X support. These tweaks are done via CodeLite's Workspace/Project settings so it should be really straightforward to adapt for your stuff.

That only showed the linking, not the compiling. Could you do a menu Build->Clean Project first and then paste the first build run (probably you should use something like http://pastebin.ca to post so the KVR ppls don't get annoyed by this meaningless stuff ) Anyway I'm mostly just curious about it.

In any event it looks like the OSX world is pretty similar to Linux. There are two libraries that are needed that you will somehow have to acquire (maybe you already have them?) One is libfftw3 (I am using ver 3.1.2), and the other is libsndfile (I am using ver 1.0.17). Since you managed to compile all of wxWidgets (?!) worst case you could compile these from source too. From here: http://www.mega-nerd.com/libsndfile and here: http://www.fftw.org These are pretty standard libraries in the open source world, but again you may have to work at it a bit. In Ubuntu it's easy peesy repo stuff so I don't break into a sweat

[billstei]

Can someone please run over to Stonehenge and look for Howard? Be sure to check for him hiding under any bushes or rocks. If you do move one of the rocks, please put it back where you found it so we don't loose track of the time.

[billstei]

The real deal:



Since I can't figure out what to do with cosines in Spectro mode, I'm thinking there needs to be some Greek/Roman gods lounging around eating blueberries, and drinking blueberry wine, in that part of the GUI. The gods drank blueberry wine, right? No? I wasn't there, maybe Howard knows.

[xh3rv]

Fixed compiler output: http://pastebin.ca/1470227

FFTW and libsndfile both compiled / installed without a hitch (or at least AFAIK ). My understanding of Linux-y stuff is really spotty but instructions from those sites was permutations of make / make install, which I kinda understand builds libraries and makes them accessible to shell commands ($PATH stuff)

I think OS X is kinda like a mullet with regards to porting from Unix/Linux. There's sort of two file structures, a formal Mac structure accessible from the GUI/Finder, and a Unix-y system (/bin /dev /etc. ...) one can get to via a terminal shell. It's set up to work according to the conventions of either development style, so shell commands mentioned by documentation for these libraries so far have just kind of worked.

Also, it's completely ridiculous to think that re-arranging the megaliths at Stonehenge will alter the flow of time. All that will do is alter the date for alien invasion.

[e] OOooh, aaaahh at that app screenshot

[Howard]

@billstei
I'm still here reading these posts - can't understand dev-speak, so I have nothing to add to the conversation. Yet

[billstei]

Fixed compiler output: http://pastebin.ca/1470227

FFTW and libsndfile both compiled / installed without a hitch (or at least AFAIK ).

To see if it's the same as I have here in Linux, in a terminal do this:

ls /usr/include/fftw3.h
ls /usr/include/sndfile.h

ls /usr/lib/libfftw3f.a
ls /usr/lib/libsndfile.a

Note: fftw3.h is not fftw3f.h -- the latter does not exist.

You can also check for libfftw3.a (which does exist) but I don't think the linker will look for it, but it might, not sure. Each time the ls command should echo back the existence of that file. The .h's are the header files you need to compile with. The .a's are the static libraries you need to link with. They might also end up in /usr/local/include and /usr/local/lib, but the important thing is to just be aware of where they are.

My guess at this point is it will be "easy" to make an OSX version of Blueberry Thing.

P.S. In case you're wondering what the difference is in the fftw libraries, it's like this:

libfftw3.a - Integer FFT routines
libfftw3f.a - Single precision float FFT routines
libfftw3l.a - Double precision float FFT routines

I seriously doubt that double precision will do anything useful other than make the program run slower so I am using single for now.