Sine Sine Everywhere a Sine

[billstei]

Yeah, I checked - libSDL.a and libSDL_mixer.a are in /usr/lib (as are .a and .dylib files, apparently .dylib is like a .so for OS X) and CodeLite->GCC doesn't have problems with the other libraries (sndfile, fftw) which are in /usr/lib

Are you doing a Debug or Release build? I just noticed I did not yet add the SDL_mixer library to the linker parameters in the Release setup. Will fix that and upload it... but you can just use a Debug build in the meantime.

I noticed that CodeLite is a bit cranky when it first deals with a new Workspace, as you would have after doing the svn checkout, so it might help to do a Build->Clean Project, or even shutdown CodeLite after switching the workspace, and then start it up again.

Maybe post the Build output into http://pastebin.ca like you did a couple weeks ago (again do a Clean Project first) and maybe I can spot something.

[xh3rv]

http://pastebin.ca/1494196

Also, in the OS X FAQ for SDL mentions some stuff about having to call SDL_main() or linking libSDLmain.a (which is in my /usr/lib). If this isn't done there will be a "_main undefined" error which is similar to the actual error Undefined symbols: "_main" . . . the actual FAQ is more detailed.

I *think* the logic of why this has to be done on OS X is related to getting SDL access to Cocoa stuff. I'm clueless as to where to link libSDLmain.a or anything like that, but that's my best guess.

(e) have been doing Debug build

[billstei]

http://pastebin.ca/1494196

Also, in the OS X FAQ for SDL mentions some stuff about having to call SDL_main() or linking libSDLmain.a (which is in my /usr/lib). If this isn't done there will be a "_main undefined" error which is similar to the actual error Undefined symbols: "_main" . . . the actual FAQ is more detailed.

I *think* the logic of why this has to be done on OS X is related to getting SDL access to Cocoa stuff. I'm clueless as to where to link libSDLmain.a or anything like that, but that's my best guess.

(e) have been doing Debug build

According to that FAQ:

"If you are developing using the UNIX variant of SDL, you can link libSDLmain.a into your application, which simply contains a precompile version of SDLmain.m."

and it might be as simple as that... so if you right-click "blueberrything" in the Workspace View on the left-hand side, second from the top of the tree (not the first one "BlueberryThing" with caps), at the bottom of that pop-up menu is "Settings", and third tab over "Linker", at the bottom is Libraries, which I have set to:

sndfile;fftw3f;SDL_mixer

It looks like you may have already changed that to: sndfile;fftw3f;SDL ? Anyway, you can add SDLmain like this: (note the semi-colon delimiters)

sndfile;fftw3f;SDL_mixer;SDLmain

and the build output (compare with line 16 of http://pastebin.ca/1494196 ) should now show:

-lsndfile -lfftw3f -lSDL_mixer -lSDLmain

along with all the other (many) linker parameters. Let me know if that makes any difference. I added it here on Linux, and even though it's not needed, it doesn't seem to cause any problems.

The bigger question is whether this slight-of-hand SDK_main() will interfere with wxWidgets... it might

[xh3rv]

Compiling ended up going through with zero errors using:
sndfile;fftw3f;SDLmain;SDL;SDL_mixer. However, running the resulting executable doesn't quite load, http://pastebin.ca/1494350 is the terminal output. Is that likely to be a result of a wx / SDL incompatibility? I can dig around a bit more tomorrow but out of time today, maybe could comment out the SDL bits and see if it's a conflict or just wx.

[e] http://code.technoplaza.net/wx-sdl/ is someone's efforts at something like this, at a cursory glance is a library for using wx inside of SDL . . . not using the most recent versions of wxWidgets or SDL, don't know if that is important or not

The other thing I wonder it might be is, some of the OS X wx documentation mentions packaging apps in an OS X .app (glorified folder) bundle. That'd be a different set of problems I guess, but there is relevant documentation.

[billstei]

@xh3rv - I suppose it's possible there's a conflict, but the error seems unrelated. There are only a couple of places where I do a Blit (also, wx is undoubtedly doing blits on my tool button images), and you could even try turning off the methods that do a blit, just to test it, but I don't want to drag you into the C++ world unless this is something you're interested in.

In any event, the fact that SDL initialized and opened the audio device, seems to be A Good Thing (tm).

Edit: @xh3rv - Try SVN ver 12, it might fix the problem.

[billstei]

Some user feedback.

[Howard]

Some user feedback.

Got the important info up first

[Cyoon]

So, how far is this Blueberry thing already? just curious..

Especially for the Mac version..

can we have a beta or so?

[xh3rv]

Edit: @xh3rv - Try SVN ver 12, it might fix the problem.

Just attempted ver 13 (or whatever was the latest as of writing this), still getting the DoBlit error. I commented out SDL stuff to the point of not needing SDL stuff with the linker, and am still getting the Blit stuff, will try commenting out the Blit stuff later today.

I don't mind digging around the C++ stuff if you don't mind that I don't have real great ability to dig around I took a C++ course in 2001, haven't coded in it much since, am considering grad school with some programming (taking a Scheme-based course atm) so - I'm not very qualified to dig around but I'm not totally unqualified, I think. If this were brain surgery I'd kill the patient

[e] Commenting out some stuff w/ blit in optionspanel.cpp (line 503) and zebrawavepanel.cpp (line 64) has succeeded! Blueberrything now opens without error (this is with blit-y stuff off and SDL off).

[billstei]

Edit: @xh3rv - Try SVN ver 12, it might fix the problem.

Just attempted ver 13 (or whatever was the latest as of writing this), still getting the DoBlit error. I commented out SDL stuff to the point of not needing SDL stuff with the linker, and am still getting the Blit stuff, will try commenting out the Blit stuff later today.

I don't mind digging around the C++ stuff if you don't mind that I don't have real great ability to dig around I took a C++ course in 2001, haven't coded in it much since, am considering grad school with some programming (taking a Scheme-based course atm) so - I'm not very qualified to dig around but I'm not totally unqualified, I think. If this were brain surgery I'd kill the patient

[e] Commenting out some stuff w/ blit in optionspanel.cpp (line 503) and zebrawavepanel.cpp (line 64) has succeeded! Blueberrything now opens without error (this is with blit-y stuff off and SDL off).

Okay, and there is yet another Blit() added in SVN 14 to do the windowing function highlighting (a very cool feature actually). I'm surprised it didn't get fixed, but I'm pretty sure now this is not SDL related. To further test SDL audio, try loading a *mono* audio wav (stereo wav will do bad things) and press the green arrow when that wav is the current page of the notebook, you should hear it play.

[billstei]

So, how far is this Blueberry thing already? just curious..

Especially for the Mac version..

can we have a beta or so?

Sorry but it's not even beta yet, more like pre-alpha, and crashes on OSX. But the way it's going I think there will be a Mac version long before a MS Windows one, which I did not dream would happen TBH.

[billstei]

@xh3rv - I found what might be a bug on one of the blit calls Am going to redo it slightly, but the newer blit (as of SVN 14) will still be there (no other way to do that one). Stay tuned for SVN 15...

[xh3rv]

try loading a *mono* audio wav (stereo wav will do bad things) and press the green arrow when that wav is the current page of the notebook, you should hear it play.

The file browser dialog is acting a little weird, namely it allows some navigation but the "open" button remains grayed out XD Not finding much relevant via Google but I'll keep looking.

[e] Would you say you're going to do things a blit different on SVN 15?

[billstei]

[e] Would you say you're going to do things a blit different on SVN 15?

Oh, it looks like Howard is not the only old guy who misses the awesome pun.

P.S. Started working on stereo wav handling code around about SVN 19+, so the forecast is for partly crashy with a 50% chance of scattered bungerstorms.

[billstei]

@xh3rv (and all other DIYers) - SVN 30 (0.0.2.26) has the stereo audio handling code more or less complete, and I disabled the test tool buttons, so this might be a good version to remember.

There are at least 3 (major) parameter/architectural flaws that I want to address next (not to mention GeoBlend capability is still missing), so SVN 31+ will be scary for a while.