Developer @ Chaotic Box

I've had limited time to work on eDrum MIDI Mapper recently so I've decided to release a final-candidate build now, rather than let it sit idle until I find time to update the documentation and installer (which invariably take more time than updating the actual application).

Download: eDrumMIDIMapper_v12fc1.zip (1.7MB)

The zip archive contains an updated exe and brief change log. This new exe can be used along side the v1.1 release, but you might want to save a backup of your v1.1 settings just in case something goes screwy.

This release contains a few minor bug fixes plus a couple frequently requested features. One new feature is essentially invisible but useful nonetheless; Notes, controller messages, and polytouch events are now echoed to the output as-is if they aren't filtered by a pad. More and more hosts are gaining native edrum support so this change lets you set up filters only for the few triggers that may need special attention, and lets the host handle the rest of the kit.

This build also features more flexible choking options. On the input side, you can now define a "choke note" to support hardware that doesn't send polytouch messages, such as the Alesis Trigger IO. You can also define a "choke note" on the output side for hosts that use mute groups for cymbal chokes, like XLN Audio's Addictive Drums. These input and output options are entirely separate, so no matter what the hardware sends (note or polytouch) and no matter what the host expects (note or polytouch) the filter can deal with it and get things working.

Please report any bugs/problems with this build by commenting to this post or through my contact page. If all goes well this build will be repackaged as the official 1.2 release in a couple weeks time.

Please note that "attributes" is now a reserved word as of REALbasic 2008r2 and since some of my open source code uses "attributes" as a property name it will fail to compile. This will be fixed in the next revision of each affected project but for now a simple search-and-replace should fix the issue if you are affected.

April was a bit of a blur and although I can't offer any release dates I did want to post an update of things coming down the pipe.

First, I've put quite a bit of work into my OxMath Classes, (finally) adding 2D and 3D line segment "bounds" classes and a way to control the fudge-factor for certain point and line intersection tests to counteract rounding errors.

Another big OxMath addition is all new animation path classes and interpolation methods. The paths are based on cubic-Hermite curves for predictable results (paths always pass through control points) and provide distance-based samples and direction normals. Basically these classes let you easily animate an object along a path at a constant rate while simultaneously returning the current path direction - click the thumbnail for a preview. Naturally, the path classes come in both 2D and 3D flavours, and the low-level interpolation methods used to grab parametric curve values between anchors are also globally exposed.

I'm also considering releasing a plugin I wrote a while back based on the public-domain stb_image.c source. That code is a tight cross-platform image loader capable of reading PNG, JPG, TGA, BMP and PSD files - though in most cases only a subset of features are supported, no interlaced PNGs or progressive JPGs for example. Even though the loader is somewhat limited, I've found it to be ideal for loading external assets such as game textures. The plugin itself doesn't touch the Rb Picture class, but instead returns a custom class that essentially just wraps raw 8-bit image data (oddly enough, the class and plugin are named ImageData). This may not seem all that useful in general, but anyone using OpenGL in Rb via declares or plugins knows what a pain in the arse it is to get OpenGL-compatible image data out of the standard Rb Picture object. I'm still on the fence as to whether or not to release this however, as it will take some work to make it presentable and I'm currently only maintaining a Mac OS X target. So please let me know if you're interested.

That's about it for now - I'm also working on an update to my oft-neglected eDrum MIDI Mapper shareware so don't expect any open source updates till that's released.

Firelight recently released a new stable FMOD Ex branch (v4.14) which inevitably breaks compatibility with my FMOD Ex classes for REALbasic. The only issue I can see this time around is a potential crash when trying to read FMEx.OutputsAvailable on Windows while using raw speaker mode and ASIO output - in other words, most users won't even notice. The fix is simple; just update these private constants to the values noted below:

  FMEx.kAdvancedSettingsSize = 66
  FMEx.kMinimumVersion = &h00041400

The next revision will contain these fixes but I didn't think this warranted a full release at this time. Please let me know if you run into any other problems with the FMOD Ex 4.14.xx releases.

In other REALbasic related news, I've decided to pass the torch in regards to maintenance of my PNG Utilities and ZZip Utilities plugins. Both of these will require updates in the coming months for better compatibility with new REALbasic and Mac OS X releases, but I haven't actually used these plugins in my own projects for years so the motivation to keep them updated simply isn't there. I've already found a company willing and capable of taking these on, and you can be assured they will remain free and open source. Expect more details and possibly some preliminary updates closer to the end of May.

If you've noticed a trend away from REALbasic plugins here on Chaotic Box you're not imagining things. Fact is, there are fewer and fewer reasons where plugins make more sense than native code/declares nowadays, and there are more and more reasons to avoid plugins. I'll admit the new Rb plugin SDK is now more sensible and homogenized, but much of the lower-level functionality has been deprecated in favour of "dynamic access" APIs, which require more code, and are often much slower. I still rely on plugins when performing certain math operations on large sets of vectors, and for loading pixel data straight to raw memory buffers, but other than those and perhaps a few other situations (like wrapping C++ libraries) there's little reason to touch the plugin SDK.