Arkonnekt

Arkonnekt Sound:
Hello! Welcome to the arkonnekt sound home page! Arkonnekt sound is an initiative to create a solid, reusable, portable sound engine, and along the way create a Cocoa sound kit to harness the power of the sound engine, and make a decent (and free) Cocoa wave editor.

Currently the project is under active development by me, Jeremy Jurksztowicz. The engine source is really unstable at this point, and multiple API changes are in the pipeline, however the basis and design are quite stable, simple, complete, and thus fun to experiment with.

A quick note on licenses: The core is licensed ala MIT, while most of the Cocoa code is licensed ala LGPL. The core has a liberal license because there are a lot of pretty good sound engines licensed ala GPL already. I would like people to improve and expand the engine, and minimizing legal barriers to adoption is one way to foster such growth. Ole!

Download Alpha Code

View Code Documentation

Help!
I need help to make this a solid application! As you can see I am no web designer, and this webpage sucks monkey feces. Aside from my artistic cerebrum impairment I have NO TIME! So much to do, and I am not getting paid a penny to do it. Whatever, I do it because I love (programming, the cosmic hologram, sushi). So anyways, while I really like to program in Cocoa (objective-c + openstep), I would rather program the sound engine into a decent and stable peice of code at this point. However the sound engine finds direct expression (and thus testing) in the cocoa wave editor. If someone would like to drive the app development forward, that would be super cool, as it would facilitate a more stable, and more capable engine.

Todo, no really, I'll get around to it:
There is so much I would like to add to my engine, here are a few of the realistic projects and their status.

Automation (30%) - Yes full automation editing/recording with linear/logarithmic/arbitrary curve fading, the whole gamut. I have alot of the scaffolding set up, but need to get some core components working to move forward (anyone got a good lock-free linked list?).
AudioUnit graph editing (90%) - Before this project I *almost* finished a really cool Cocoa app which allowed you to create arbitrary unit graphs, actually it was called Arkonnekt. The defunct home page is at www.arkonnekt.com, where you can see that I really am not full of sh*t... honest. This is one of the cool aspects I would like to implement soon, All I need is some time to go over the code, and particularily get graph archiving/unarchiving working flawlessly.
Graph node interface (90%) - Part of the AU graph system I mentioned above. Some THREAD SAFE ways of connecting and disconnecting audio components (SoundPlayer, ArkAudioUnit, etc.) while the graph is running.
SoundPlayer AudioUnit (0%) - While I want to focus the sound engine on portability, no doubt an AudioUnit would be pretty useful.
Non-Contiguous Sound Regions (50%) - I have a really good Oscillator type class called SoundClip, a linked list of these makes a great SoundResource (SoundResource.h). If I get the time, I can give SoundPlayer some of the the features of Ableton Live and Phatmatic Pro, ie region specific pitch/time shifting.
Reverse/Scrubbing (0%) - I have implemented this before, so I think I would need a few days to get a prototype setup.
Sample Rate conversion (0%) - This is not as hard as it sounds. Especially if you just use open source libraries that do this, like libsamplerate. An alternative (non-GPL) implementation would just use the apple core audio converters... hey! Thats not portable! Oh well...

Outstanding Issues:
Yeah, there are a lot more of these to come...

Sound Core:

Sound streaming memory behavior: Sound streaming from disk works, but deleting the streamed buffers does not work right, hence massive memory leaks. This is an extremely trivial fix, it will probably take me a few minutes once I care enough to devote the time.
Sound player pausing: There needs to be a way to guarantee that the render thread will not access the player data after it is stopped, so we can safely change resources, caches, etc. Right now there is an extremely flakey semaphore system that is utterly dysfunctional.
Sound player effect fading: When changing the volume or pan, it takes effect immediatly, so there can be a harsh clipping sound, bad business, but luckily rather easy to fix. Hey, did I already mention I have no time?
AudioUnitChain needs an overhaul: AudioUnitChain (AudioUnitChain.h) needs a massive overhaul. This is an old class that I took wholesale out of it's native project setting, and recklessly inserted into this project. It should be converted to use exceptions, because of the massive duplicated error checking code. Oh yeah, did I mention it is completely unsafe? Yeah the AudioUnit API is not thread safe, so every-time I add or remove a unit, I am playing russian roulette with my applications state. The solution is simple, switch to the AUGraph API.

Cocoa :

Sound player notification delivery: Right now, if you stop a sound and delete it, it will try to send the PlayingDidChange notification through the ArkSound core, despite the fact that it is non-existant, result: nasty crash. The solution is simple, just have a critical section to remove the cocoa client class from the core before we eliminate the underlying cocoa class. That way, if the core encounters a nil cocoa client, it can ignore the notification (see ArkSound.mm for details).
Wave view... everything: Wow, this class needs a lot of work. I would really like to keep it separated from the wave instance details, hence the datasource/delegate model. A few things that need to be done: get image caching to actually work, support datasource wave caches, because right now only in memory wave data is supported to any reasonable degree, maybe an ArkWaveCache class is necessary. Also multithreaded wave caching would likely be very useful. We need either an integrated ruler, or a separate NSRulerView subclass. Finally we need to fix the ArkScrollView to properly scroll to the selected region (see ArkScrollView.m). The code that currently scrolls worked fine in 10.3, but broke mysteriously in 10.4... go figure. Oh yeah, when animating the play cursor, some artifacts (light vertical lines) follow it, I think this is due to antialiasing, but have not investigated, because it is a relatively minor inconvenience.
Sound editor... a lot: Ok here is another woefully unfinished class (ArkSoundEditor.h). Specifically dragging and dropping effects is totally wrong, again probably an extremely simple problem, but I have not the time dammit! The generic controls, such as volume and balance control are not implemented. Oh yeah, I have not properly embedded the MOKit framework in the project either. Currently only ArkSoundEditor relies on it.
Sound open panel accessory view: Due to the notification, and sound streaming bugs mentioned above this class is not functional. Just for your info, enabling the ArkSound will cause massive memory leaking followed by unavoidable crashing, but ythe sound preview 'works'.
ArkAudioUnitManager efficiency: This class makes way to many copies of (uninitialized) audio units just to create one instance, extremely inefficient, but at least it works.