This happens once per project, and for me it seemed there’s no other solution than to create a completely new XIB.

Today, I found a workaround:

1. Remove the NSOpenGLView that’s causing the crash
2. Restart Xcode, reload the project
3. (never touch NSOpenGLView in the interface builder again)
4. Add a “Custom NSView” and move it into place, set all the NSView settings for it as you would with the OpenGLView
5. Set the class for that custom view to NSOpenGLView or a class derived from that
6. For the view controller, add an IBOutlet NSOpenGLView *object or the derived class
7. Connect that outlet to the Custom NSView in interface builder
8. Add some proper initialization code for the view (straight from Cocoa API documentation) – this is what you don’t have to do when using the NSOpenGLView but now it’s necessary:

// in the controller class .m
- (void)awakeFromNib {
 // set the pixel format and depth buffer and other parameters as you wish
 NSOpenGLPixelFormatAttribute attrs[] = {
 NSOpenGLPFADoubleBuffer,
 NSOpenGLPFADepthSize, 32,
 0
 };
 NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs];

 // assuming your class has an IBOutlet NSOpenGLView *m_gl
 [m_gl initWithFrame:[m_gl frame] pixelFormat:pf];
}

… and you’re set. No crashing.

Edit: this only seems to happen on an Xcode older than 4.2 or on 4.2 that’s not a clean install but updated from 4.1 or older.

Cabo Blanco
Cabo Blanco

Running
Running

Train Roof RundownTrain roof rundown

Africa “Flyover Cliché” track
Africa

Light
Light

Adventure Legend
Legend

Chest of Tales
Chest of Tales

More “electronic” stuff:

Access Denied
Access Denied

Sneak
Sneak

“Don’t make any big projects with it.”
– A random Dashcode user

After a while, when the project gets bigger, you’ll have some 20+ Javascript files, thousands of lines of code, several data sources (which are great, btw), it gets really slow. First, basic things like moving controls to places starts to take time. Then saving the project becomes really painful, not even mentioning deploying the project. If you want to use undo, just forget about it – for some reason, each undo takes as much time as saving the project.

Then, debugger stops working. The Dashcode’s small embedded fake HTTP server can’t handle the simultaneous requests made by the main page to load all the scripts. You might circumvent this by making a script loader that somehow loads them gradually, one by one. I tried it but it didn’t work, instead started giving way more exotic error messages.

This is until the project grows even bigger and you reach the point where Dashcode crashes when autoloading your project.

Dashcode preferences

It didn’t happen on Snow Leopard, though, so I guess this is some random incompatibility problem with OSX Lion. Even choosing the setting “Do nothing when Dashcode starts” doesn’t disable the autoload completely. This is probably because closing the big project on Dashcode crashes it and it reloads the last project when starting again.

I found a workaround for that:

1. Open Dashcode
2. Quickly press CMD-W when the project loads up
3. Quickly press CMD-Q when the project is closed
4. Open Dashcode again
5. Open the project from the Recent projects menu

Handy and easy.

Another possible solution for this could be if someone figured out a way to include JavaScript files to the main page in a way that Dashcode wouldn’t understand them and wouldn’t load and parse the sources every time you open the project. I guess that is what crashes the editor.

Anyway, it’s a shame that it seems this program has been neglected by Apple for some time now. Hope they’ll get more active on it one day again.

But there’s a PHP script on the server side that makes the appropriate query and returns the data as XML for the JavaScript side to parse. And every time a query contained this one particular entry, it broke. The XML was returned normally, but it didn’t work. Empty set.

So, I decided to make the query manually, giving it as Base64-encoded SQL query to check what’s wrong.

It returned a nice set of XML – with one exception: the browser said there’s a 0×0 character on row 15. That would explain a lot, so I checked row 15. Just normal written text as UTF-8 string in the database. I copied the text and pasted it to Skype for the person who wrote it, with a note after the text.

Black hole, galactic representation of a NULL character. Photo by Alain Riazuelo.

The note disappeared. Found the null character.

After a quick search I learned that it is actually possible to write a NULL character from the keyboard. Didn’t know that. This brings up a whole bunch of new problems that everyone should keep in mind when writing software. Especially when dealing with HTTP servers, as they, sometimes when it’s possible, also send the size of the page in the headers, and the client side then downloads everything but doesn’t expect a NULL character, and sometimes, when no size is sent, client may stop at a NULL. Both times you’ll probably end up mishandling the data.

Here’s a simple script you can put in your non-deployment target, just click Add Build Phase (+) / Add Run Script and copy/paste the following code:

cd $CONFIGURATION_BUILD_DIR/$CONTENTS_FOLDER_PATH/Resources
for a in `find . -name "*.rbo"`; do rm -f $a; done

This isn’t pretty, but does the trick.

Also, you will probably want to go ahead and disable gdb for the development target. There’s no use in observing the ruby binary in case of its errors. Disabling gdb speeds up the launch of ruby tenfold.

First, get an ffmpeg binary. This can be done by either compiling it by yourself or googling for a ready compiled binary. If you’re on a Mac, you probably have it already, as many of the video converters from Mac App Store come with the ffmpeg binary hidden inside their directories. Just open a terminal, type:

cd /Applications
find . -name "ffmpeg"

…and you’re set. Copy the found binary to /usr/bin or wherever you want it.

If you’re on Windows, google for ffmpeg.exe, copy it anywhere and it’ll work, unless it doesn’t, which is pretty much a 50/50 possibility.

On Linux, using any repository system you use, install the package ffmpeg, only to realize it doesn’t support mp3, because mp3 is apparently not an industry standard.

Not depending on if it’s a good standard or not, you’ve got 1072 mp3 files you’ve recorded for some reason, and they’re all too silent. By a factor of 10.

Go to the directory with the files, and type (example):

cd SilentMP3s
mkdir LouderFiles
for a in *.mp3; do ffmpeg -i $a -vol 2560 LouderFiles/$a; done

Now you’ll see a lot of text flowing through your terminal for a while, and when it’s done, you’ll find all of the files, 10 times louder in a subfolder named LouderFiles.

The ffmpeg -vol parameter amplifies the sound. The default value is 256 (no amplification), and you can adjust the number accordingly. Here it’s 2560, as it’s 10 times louder. Note that these are not decibel values or anything that sophisticated, but just an integer value. 512 equals to twice the volume, 768 three times, 1024 four times, etc.

The best way to find the correct amplification might be to look at the actual waveform in an audio editor, e.g. Audacity, and then try the amplification on one file. You’ll quickly see what is the appropriate value for the -vol parameter.

Not true.

I just finished installing Cubase Studio 5 on Lion, with HSO working just fine, both as a VST plugin and through ReWire.

As the script for copying the samples from the DVDs is made for PPC and needs Rosetta, it probably won’t run. But if you already have the samples loaded on a Mac, you can just copy the samples to their place from the other Mac after installing the plugin (latest from the Steinberg website – not the one that comes on the discs).

The path to look for is /Library/Application Support/Steinberg/ReWire/HALion Symphonic Orchestra. For the 16-bit edition, there should be approx. 11 GB of data, for the 24-bit version probably some 50% more.

This is not recent news, as it also worked on Lion Developer Preview and Cubase Studio 5.5.0, which was also not supposed to work on Lion…

Link to Mac App Store

Here’s a short trailer:

Click here to view the video on YouTube.

Vector

Strongly influenced by Tron: Legacy soundtrack.
Vector

HD1

Tried to capture the classic feeling of Vangelis’ Chariots of Fire.
HD1

Bronze

Tries to be like the stuff they play in saunas at Impuls+.
Bronze

Puzzle

Older track, found it lying around unfinished.
Puzzle

The text in UTF-8 format doesn’t go too well into an AJAX call GET URL. So it has to be further encoded with an encoding that can be used as a parameter. BASE64 is one such.

There’s a handy JavaScript BASE64 encoder available at webtoolkit.info. It handles the UTF-8 encoding / decoding properly. In the PHP script, you can use the built-in base64_decode to decode back to UTF-8. But there’s one caveat using this method: BASE64 encoding contains sometimes the plus (+) sign. This, usually, is transformed into a space in URLs. So when the server gets the AJAX call with a BASE64 encoded parameter containing a +, it can no longer decode it, base64_decode only returns an empty string. This can be worked around:

$result = base64_decode(str_replace(" ","+",$_REQUEST['base64encodedparameter']));

And you have your UTF-8 encoded string in $result.

Also, base64_decode doesn’t care if the trailing = characters get lost on the way, so this method should be safe to use.

There are probably a hundred better way to do this, but I found it working great.