It’s six weeks into the summer holidays – although this year, the word holidays rings a bit ironic to me because I don’t remember ever being so busy during summertime. Thank goodness, my current workload is not related to my day job, so paradoxical as it may sound, I’m getting a lot of enjoyment from sweating my guts out in this hot weather. Yes yes yes, I’m finally back on track, trying to catch up with my Amiga projects! And because I last published a progress report four months ago, I think it’s now time to take a little break from programming and bring my readers up to speed. So what’s the latest on the Rave audio editor?

The majority of work I did in the past weeks related to the sample editing functions and improving clipboard support. What I see as my main achievement is that all editing operations are now asynchronous. So when you, for example, copy a large chunk of audio data into the clipboard (which can take some time, especially on low-end systems), you can continue working on another sample. Sounds easy but in a multi-project environment, making things asynchronous involves much more than just disengaging the window’s busy pointer! As each project runs on a separate DOS process, you need to design an underlying system that manages and synchronizes access to various program components and resources. Rave has had such a system from Day 1, but asynchronous editing required making it more sophisticated and robust. Think of building a house: you really want it to stand on solid foundations, otherwise things will start falling apart as the construction continues!

In a program where certain functionality is provided by components running on separate processes, the first thing you need to ensure is that no “stray” processes are left running when the program ends. AmigaOS4 makes this easier thanks to certain new features in the DOS Library. One of the many great additions brought by the OS4 DOS is that processes can be put in a parent–child relation. In other words: when you start a sub-process that serves the main program process, you can identify the sub-process as a “child” that is resource-dependent on its “parent”. Unlike in older AmigaOS releases, the parent process cannot quit while its children are still running about. To help synchronize process ending, the OS4 DOS has introduced “death messages”, through which child processes can notify their parent that they’re about to quit. Implementing death messages in Rave represented one step towards solidifying the program’s project management system.

Other steps were aimed at better organizing project activity and safeguarding access to shared program resources. To that end, Rave utilizes a simple but effective message-passing mechanism that boils down to the following. Whenever some kind of interaction takes place between the main program and a child component (a module or a plugin), the one that initiates this interaction sends a message and waits for a reply confirming that everything is OK: an operation has started, data has been received, and so on. Only after receiving the confirmation message is the main program or the component allowed to continue. This helps keep things in line and avoid all sorts of potential collisions and race conditions. A welcome “side effect” is that – by imposing order on what the individual program parts do and when they do it – the confirmation messages also help in arbitrating access to shared resources. Together with mutex protection (another new feature brought by OS4), they represent an additional layer of robustness contributing to a greater stability of the program.

I got a little technical here to give you an idea of what kind of work has been done under the hood, and I’ll now focus on things that are hopefully more “visible”, or at least less abstract to describe.

Asynchronous editing quite logically led to another improvement: support for multiple clipboard units. I say logically because Cut, Copy or Paste operations wouldn’t really be asynchronous if the project needed to wait for another project to finish using the clipboard. I’ve mentioned above that a clipboard operation involving a large portion of data can take quite some time on the Amiga. (Ever tried copying 20 minutes of high-definition audio? Be my guest!) During this time the current clipboard unit is busy, but Rave now allows you to switch between units 0-2 on the fly, making it possible to have up to three operations accessing the clipboard concurrently if needed. The default unit can of course be configured in the settings. During program runtime, unit selection is done from the main menu, or through keyboard shortcuts which – as the screenshot below shows – cannot possibly be more mnemonic:

Speaking of this, I should probably explain – at the risk of getting technical again – how Rave stores the clipboard data. AmigaOS specifies that data in the clipboard needs to comply with the Interchange File Format (IFF). However, this specification is not good enough for modern audio applications because the original IFF standard only accounts for 8-bit audio data. Unlike MorphOS, which said goodbye to this legacy and wisely adopted the much more versatile AIFF container for sound clips, AmigaOS4 hasn’t dared to go this far yet. Without an updated official specification, the actual implementation is pretty much left up to the developer. Which is never a good thing, considering the legendary creativity of Amiga programmers.

To be on the safe side, I have used the same hybrid solution that Fredrik Wikstrom devised for his AmiSoundEd editor: 8-bit audio data is stored in the old IFF-8SVX format to make clipboard exchange backwards compatible, whereas anything above 8 bits is formatted as AIFF. To be honest, I’d much rather go the MorphOS route and do away with 8SVX altogether (especially as there is practically no audio software worth striving for compatibility with). My code is perfectly ready for the change, but unless OS4 adopts a new standard, things will stay this way.

Because in real use it’s easy to lose track of what you’ve put in the clipboard, I have implemented a simple information window that displays the properties of the data stored in each clipboard unit. The images below show the current contents of the three supported units:

And as you will no doubt find it useful to have similar information about the projects you are working on, I have added a window that shows detailed project properties. The Project Information window is accessible from the menu as well as from the program toolbar. The window also incorporates a Metadata section, in which you can view and edit some common metadata strings to be stored together with the audio file:

Well, that’s about all I can share at this point – I think I’d better get back to work now. I’ll post another progress update in a few weeks, during which I hope to revisit and update Rave‘s plugin framework (or whatever will need my attention). Stay tuned and watch this space!