Shortly after I released the first version of the Rave audio editor I received an e-mail from a fellow user, Daniel Reimann of the amiga-news.de team. He asked me where I find motivation for my Amiga projects. We exchanged a few rather general words about things that give you drive and energy in life, and then we went on to discuss other topics such as the family or holiday destinations. But the more time passed since our little conversation, the more I wondered myself: “Why do I keep doing the things I do, spending time with a computer system that only has a few hundred users?”

It’s a well-known fact that different people get motivated by different things. And it’s probably good to know what these things are: not only because they ask you at job interviews but, more importantly, to avoid making efforts that won’t give you the necessary spark anyway. Really, expecting motivation from things that motivate others (but not you) is a waste of time. So I sat down and came up with a short list of what typically makes me engaged – and as I was getting through a particularly fine bottle of Pinot Noir my wife gave me for Father’s Day, the list ultimately turned into this blog post.

For starters, I do things because I enjoy the process. Yes, I’ve realized that I’m a process-oriented person, rather than a goal-oriented one. My harddrive can testify to this. If you look into my development drawer you’ll see that it contains a lot of abandoned projects. Similarly, my old Protracker drawer has a good deal of material that are mere sketches of ideas for music. Many people would say that I’m not a finisher, that I need to set my eyes on the prize and see the ultimate result. But I can’t help it: I simply love it when I start my computer, make a cup of coffee, put on some music, and get cracking on whatever my current project is. I believe that “enjoying the creative process” is a perfectly valid reason why we do things, and in fact, it’s often a prerequisite to achieving other goals. Trying to produce a result in frustration because the creative process feels like a burden can’t come to any good.

The second item on my personal list of motivation factors is learning. While I may have decades of Amiga experience to rest on, I always learn something new when I work on a program or a piece of music. Heck, I could write a full book about what I’ve learned in the past few years working on Rave! Programming in particular may seem a mundane and repetitive activity but in fact, you rarely get the “been there, done that” feeling. The creative process always makes you face new challenges, bringing in return deeper insight and new skills.

By nature I’m not a noisy person, so I wouldn’t find it appropriate to express my inner self like the guy in Edvard Munch’s famous painting The Scream. Instead, I use creativity as an outlet. Not that I fire up MilkyTracker to compose a brooding song every time I feel a bit on the low side, or a club banger when I need to let off steam! But the various psychological aspects of creative work can also act as great motivators. I personally like the idea that we leave a bit of ourselves in the things we make; a personal imprint if you will. It’s obvious in music and other artworks, which often stem from emotions and thoughts of a very private nature. But it doesn’t stop with art: I strongly believe that programming is a form of expression too, and as such it bears traces of your thinking, attitude, decision-making and solution-finding. I don’t care that the end user most likely can’t see them: knowing that the software will contain something that is uniquely mine helps me see my efforts as worthwhile and rewarding.

And of course, speaking of psychological aspects, we all know that work can be a great way to take your mind off things. The activities I like to do on the Amiga require a lot of patience and concentration, so when I start working on a software project or a tune, I soon realize that my mental capacity is fully occupied with what I’m doing. This often feels very relaxing, paradoxical as it may sound. So I don’t find it particularly hard to jog myself into working on an Amiga project, because I know that I’ll be in fact taking a little break from the troubles and pressures of the world.

Next on my list is what I think psychology calls social approbation: the notion of being valued by the community. Between the years 2000 and 2009 I was a normal Windows user, and I tried to build on my Amiga hobby by running a small home studio for music production. Far from a professional affair but still, some ten thousand euros sank into it over the years, so I was able to do things I wouldn’t have imagined in the old Amiga days. But nobody seemed to care what I was doing because there were thousands of people like me. Thousands of bedroom composers trying to reach an audience! The situation was no less frustrating in programming. Whenever I thought of a project I could do, I found out that a similar piece of software already existed, with a dozen competing alternatives.

On the PC, I got very little feedback on my work, which ruined my sense of achievement. In the end I didn’t get any joy from my hobby because I felt I wasn’t making any contribution to anybody. And so I realized that I need to feel that I’m useful to get motivated. The Amiga gives me that feeling: the community is small, so it’s much easier for your work to get noticed and appreciated. It doesn’t take ages to establish a reputation if you’re good enough. Unlike on Windows, a lot of software is still missing, so as a programmer you never get short of ideas for new projects. The Rave editor came into existence because I felt there was a gap to be filled, and that AmigaOS4 was losing to its Classic counterpart in the music department. I wanted to change that and give people one more reason to use their system. I wanted OS4 to have something unique.

Which takes me to the last item on my list: bringing innovation. I know that the word “innovation” is somewhat relative on our platform, but still, my motivation levels run high when I know I can bring something new to the old Amiga table. Although still in its infancy, Rave can already boast a number of “Amiga firsts”, and not only because it’s the first native AmigaOS4 sample editor in thirteen years. The program’s I/O module is based on industry-standard libraries, providing the widest range of audio formats ever supported by an Amiga editor. For the latest version, I went to some trouble to introduce preview playback in the file requester – something I always missed on the Amiga. I have a massive library of samples (we’re talking several dozen gigabytes), and looking for the right sound has become a tedious process, much like seeking the proverbial needle in a haystack. There’s still room for improvement, but I can honestly tell you that the new feature really improves workflow and saves a lot of time.

Now all we need is more AmigaOS4 musicians and sound tinkerers. Oh, that would send my motivation levels right through the ceiling! 🙂

In management circles, there is a running joke that the last five per cent of a project takes 95 per cent of the entire completion time. If you’re a software developer, this funny paradox may ring some bells because it is in fact well rooted in experience. Your project proceeds quickly until it reaches a point where it is almost finished, save for a few little things that make it unsuitable for release. These “few little things” can turn the final phase of the project into a nightmare that will drag for months, if not years.

I learned my own lesson when I was working on my first AmigaOS4 application, the WordNet dictionary, back in 2009. I had only recently rediscovered the Amiga passion after nine years of solely using a PC, and I was very excited about developing for a community where every new piece of software seemed to make a difference. I had a rough version of the program going in about two weeks, with GUI and all – and then I spent two more months polishing WordNet and getting it to release state! One of the reasons was that I had to learn some OS4 specifics as well as brush up on things I had forgotten. But in all honesty, it was my poor planning that caused most delay. The notion of the minimum viable product completely escaped me at the time, and I kept adding feature after feature until I was overtaken by fatigue and frustration.

It may appear that I fell into a similar trap with the Rave project, especially if you remember that in my previous blog post I was hoping to be able to release the program before the end of March. But the reason was different this time, and I can honestly say that the release would have happened if only things didn’t get the better of me again.

While stress-testing Rave in early spring I realized a design flaw in the program’s project management system that made it difficult to reliably and safely abort an operation in progress. As re-designing the inner workings of Rave would take a considerable amount of time (which I didn’t have), I thought I’d release the program as it was and improve it later. However, towards the end of March the school I work for informed me that I’d be supervising a group of students during their internship in Germany, which was supposed to take place in May. The idea of spending a whole week free of parenting pressures clicked with me in an instant, because it smelled like an opportunity to have a closer look at the problem.

The internship was in Chemnitz, a city in Saxony formerly known as Karl-Marx-Stadt. It soon became obvious that my students’ training was organized with the proverbial German thoroughness and efficiency, which rendered me virtually useless as a supervisor because everything had been taken care of. So I had even more time on my hands than I had expected, and (with the exception of an occasional sightseeing stroll) I spent most of the week in my room chasing bits and bytes on my trusty laptop.

The ability to concentrate on Rave for several hours a day made a world of difference, compared to my weary late-night sessions at home. I remember a forum post in which a well-meaning Amiga user tried to motivate developers by telling them to try and sit down to programming every day, even if for five minutes only. But this is not how it works, unfortunately. In reality a programmer can do little work in an hour, let alone five minutes – especially when working on a large project. In this regard the week in Chemnitz turned out to be a heaven sent. Diving in with full focus allowed me to completely rewrite the project management system including the plugin API and the I/O module; something that otherwise might take months to achieve. The result is a simpler design that is more reliable and requires less communication between the individual program components.

Among other things, it is now easier to create a plugin because the main program and the plugin master module have newly been entrusted with certain common chores. The plugin architecture surely needs more work: currently only processing plugins are supported, i.e. ones that take audio data and modify it. This is suitable for applying effects, but I’d also like to introduce plugins that generate sound, or simply analyze the data and display information about it. It’s going to take quite some time before the architecture becomes good enough, but when it does I’ll open it up so that other people can develop plugins for Rave if they feel like it.

And of course: the problem that started it all is now gone, so as I’ve already told people who follow me on Facebook or Ko-fi, any operation in progress – that includes loading, saving and processing – can now be safely aborted by pressing the Escape key. I actually think that Rave handles aborting better than SoundForge Audio Studio 16, which is my go-to editor on the PC. When you abort an operation in SoundForge, the program displays a confirmation requester but the operation continues uninterrupted. So if you take your time and don’t click on the “OK” button right away, the operation may have already finished in the meantime. I don’t find this very useful (or logical), to be honest. In Rave, the operation waits until you deal with the requester, and then it either continues or stops. This, I believe, is the expected behaviour, and it’s one of the benefits of my rewrite.

Most importantly, the program is now ready to hit the world. During the past year there were moments when I seriously doubted I’d ever be able to say it, but: I’m happy to report that the last five per cent of the project have been completed, and that the initial version of the Rave editor can finally be downloaded from OS4depot. Saying it feels so great that I’m tempted to say it again, which is plain silly but you can imagine how happy I am now that the weight is off my chest. It feels like dropping a stone the size of the Karl Marx head in Chemnitz!

Christmas 2021 was approaching fast and it was clear to me that I’d miss the magic release date again. Sigh. I had been working on the Rave audio editor for well over two years, and you can imagine how frustrated I was that I still wasn’t ready to put out a working version, with all the features I had envisioned for the initial public release. Worse: I began to fear that – despite documenting the development process on this blog and posting screenshots on Facebook – some of my followers might have got sceptical enough to believe that the program is nothing but vaporware! Luckily, around the same time I got an e-mail from Roman ‘kas1e’ Kargin, one of the driving forces behind several exciting AmigaOS4 developments. Roman’s message read along the lines of “Hey, how about you send me a demo and I’ll make a video of it, showing the program in action?”

I hadn’t thought about making a video myself because, first, I lack the skills and experience to do so and, second, such a task would only eat more of my precious time for Amiga programming. But I knew that a video is worth a thousand screenshots, so I gladly accepted Roman’s offer and waited eagerly for the outcome. He released the video on Boxing Day, and as it appears now, I couldn’t have hoped for better timing. The festive period always brings a lot of expectations in the Amiga camp, so there was a chance that some big news would steal all the attention. But last year’s Christmas was rather short on major OS4 releases, so I was happy to see that the video got noticed all right. In case you haven’t seen it:

Now that Roman’s video has shown that Rave is alive and well, you may be wondering what the actual hold up is. In all honesty, the main culprit is my perfectionist self. I know the advantages of the “release early and improve later” approach, but that’s not how I work. I hate to release something that I don’t consider good enough, and while I understand that the notion of “good enough” is relative and subjective, this is simply how I felt about Rave towards the end of the year. Not that the program suffered from major quirks, but there was one missing feature that – if the editor got released – would surely attract negative comments, making Rave look worse than it is. That missing feature was MP3 support.

“No MP3 you say? Unthinkable!” The reason why Rave wasn’t ready to handle the popular format is that it wasn’t supported by libsndfile, the audio library used by my editor’s I/O module. At that point, Fraunhofer’s MPEG audio patents had already expired but although the main obstacle was gone, the author of the library didn’t seem to care. I was contemplating writing my own MP3 handling routines when a forum post mentioned that one of the new libsndfile maintainers had finally started looking into it. This sounded like good news! A new public version was finally released in January 2021, and guess what – MP3 support was still missing. “Never mind, it’ll come later in the year,” I thought. And then suddenly Christmas was around the corner, and it was clear that Rave would unfortunately have to stay on the back burner a little longer.

Nevertheless, the positive feedback I received after Roman’s video appeared on his YouTube channel gave me a little push. Shortly after New Year’s Day I contacted Fredrik Wikstrom and asked if he could port the latest non-public version of libsndfile for me. I estimated my chances as rather slim because Fredrik, on top of being a core AmigaOS4 developer, is busy working on his own projects. Well, he got back to me three days later and didn’t even bother to say “yes” – he sent me the ported library right away! It wasn’t the first time Fredrik had helped me, so I didn’t hesitate to visit his website again and use the Donate button at the bottom of the page. Really, it’s people like Fredrik who embody the wonderful Amiga spirit, and I’m eternally grateful to them for keeping the boat afloat.

Using a non-public, under-tested version of a library written for a different operating system was, naturally, a bit of a gamble. But I’m happy to say that things went smoother than I had expected. Now that the last missing piece was in place, adding MP3 support in the editor was just a matter of a few lines of code. One great thing about using a library like libsndfile is that when a new audio file type is added, Rave will automatically benefit from the addition. The version sent by Fredrik also came with an unexpected bonus: the Opus format (a relatively new member of the Ogg family), and MP3’s less successful predecessor MPEG Audio Layer II, better known as MP2. So after a simple re-compile of my I/O module, Rave added three new audio formats in one go! The current number of supported file types is nineteen – I wonder if there’s an Amiga editor that could top that?

So what’s left to be done, and how far are we from getting the thing out of the door?

There are a few things I’m working on at the moment. First of all, saving needs configuration code and GUI for the individual formats, which I’ve been adding one by one. Only major audio formats are going to be supported in the initial versions of the program; saving in less common formats will come at a later point if there’s interest. Tracker musicians will probably be pleased to hear that saving in the legacy IFF-8SVX format is already implemented, though only in mono for the time being. (Given the cherished image of the Amiga as “the world’s first multimedia computer”, it is hard to believe that Electronic Arts’ original IFF specification didn’t consider stereo waveforms – support for them was only added later by a third party. Unfortunately, IFF files store stereo data in a non-standard way that libsndfile doesn’t support, so I need to write my own saver. Oh bother!)

To add insult to injury, one of my testers has reported certain memory-related problems on his Sam460, which we’re currently looking into. To this end I’ve dug up my old Sam440ep-Flex from storage and re-installed it so that I have one more machine for testing; I really want Rave to work plausibly across the OS4 hardware range. With its low specs the Sam is more suitable for simulating dire memory conditions (you simply run out of RAM more quickly) compared to my X5000, and I’ve already fixed an out-of-memory problem that my trusty old computer helped reveal. So things are looking up and if no more roadblocks come in the way, the Rave editor should hit the wild in a couple of weeks. As usual: stay tuned and watch this space.

Sitting at my old demo group’s 30th anniversary party (which I mentioned in this blog post), I had no inkling that we were in fact reviving a tradition. I’m happy to say that since that first reunion, we’ve been meeting on a fairly regular basis to compare notes, play with our machines and discuss all things Amiga. We’re now a mixed bunch consisting of retro hardware collectors, next-gen enthusiasts (yes, me) and occasional emulation users, but the meetings are always great fun!

Although the hotel that hosted our anniversary get-together was great, we felt that for future meetings we had better look for a less formal venue. And it didn’t take much brainstorming to come up with one. High on our mental list was a cabin at the shore of the Vranov Lake, a place near the border with Austria where we last stayed in mid-1990s. At that time, the Czech Amiga demoscene was having its finest moments, and the poor cabin saw the leading scene groups coming down for annual summer parties (which we now like to present as legendary). “Is the cabin still available for hiring?” we asked Lagya of the Guru Team, who used to organize the parties. He promised to find out with the owner, and in a few days the answer came that we got the green light. This was last September, and our very laid-back revival weekend at the cabin left no one doubting that we’d hit the lakeside again this year.

I took a day off work so that I could arrive on Thursday evening, because weekends in the countryside always feel too short. Erm… okay, I’ll own up: the real reason was that Human Factor (our group’s graphic artist and co-founder) offered to drive me in his Tesla. As a non-driver I don’t care about cars very much, but I must admit that the Model S is a slick and comfortable vehicle – and more importantly, the rides with Human Factor are always good value because of the talks we have. The two of us really go way back! In the Amiga days we tried to make a name in the game development business, and like many other sceners dreamed of turning our creative skills into a paid job. But while I chickened out after a few unsuccessful projects (and instead pursued a safe, salaried career), Human Factor didn’t give up trying, and after a few bumpy years his company Krieg Games started making some serious bucks on mobile platforms. I’m really happy for him – especially as he never hesitates to acknowledge that the Amiga played a key role in his professional upbringing.

Upon arriving at the lake, I realized to my horror that in the hustle of packing (combined with the darkness of the storage room) I had grabbed the wrong monitor stand, which wouldn’t hold my 24″ screen. The ugly DIY that I performed to make it fit would surely cause some raised eyebrows at Hewlett-Packard, but at least the situation was saved and I could finally hook up my X5000. The Classic section was represented by two MiSTer FPGA computers – a new thing at the party but one that quickly won us over. The sheer number of systems this little box can emulate is very impressive, and the level of Amiga compatibility is so high that nobody seemed to miss the two genuine A500s we had there last year. At one point I was seriously considering putting the MiSTer on my Christmas wish list, but second thoughts crept in as I pictured the look on my dear wife’s face. You know, the look that says “Is this power brick really a computer?!”

None of my pals in our group owns a next-generation Amiga system, and I’ve never tried to coax them into buying one. They haven’t experienced the turbulent excitement of Amiga’s PowerPC transition, so they might not see a point in getting a toy to which – unlike to the Classic Amiga – they have no emotional attachment. Still, I always like to take the opportunity to demonstrate OS4 and the latest developments on the platform. One reason is that when my X5000 boots up and shows the Workbench screen, people often tend to regard it as little more than a prettied-up, high-resolution version of AmigaOS running on PowerPC. It’s good to show them that despite its troubled history and uneven development, OS4 brings more than just eye candy. So at last year’s Vranov party I previewed the Emotion media player with hardware-accelerated video playback, put the finishing touches to my Mindsurfin’ demo tune in the OS4 version of MilkyTracker, and played some games that had recently been ported to the platform thanks to the new 3D enhancements.

This year I didn’t have any heavy-hitting stuff to surprise with, so my system got less focus than it normally would (also thanks to the heavy competition from the two MiSTer machines). But it was heard all right, for during meal times and talks I streamed various online radios with the help of George Sokianos’ new tuner application MediaVault. The SID Station, a chip music-oriented radio based in Holland, became an instant favourite, so there was a lot of bleeping in the room. The incredible works of Matt Gray, Rob Hubbard or Chris Huelsbeck cannot hope for much airplay at home when your wife’s around, but among computer geeks with 8-bit roots, the music always reaches the right ears.

Anyway, back to MediaVault. It really is one of those under-appreciated little programs that spice up your computing life – and I’m very proud to have contributed a small bit of code to it in its early stages. MediaVault is also one of the things I’ll want to show next time somebody asks, “So what can your glorious OS4 machine do that my Classic Amiga can’t?” George has recently updated his freeware program to cover podcast support, which brings a whole new level of fun and makes MediaVault a perfect solution for your online listening. He has also set up a page on Ko-fi.com, a Patreon-like website where he frequently posts news and development progress updates. We all know that talented AmigaOS4 programmers don’t grow on trees, so why not buy George a nice cup of coffee to support his efforts and show your appreciation? Hell yeah, let’s turn him into a caffeine addict!

Oh, the smell of fresh brew, the smell of morning! I’m an early riser, which gave me about two hours of peace and quiet before the other guys crawled out of their beds. I made good use of this solitary time (and the coffee) to further work on my Rave audio editor, specifically, on the new Process menu, which is shaping up very nicely. At the cabin I was able to add a Fade plugin, which at this point is still very basic, but as it sits on top of Rave’s object-oriented plugin framework, new functionality can easily be added without touching the main program code. My very short-term goal is to add support for logarithmic fading. Essential in professional audio, this feature is in fact a rare find in the Amiga world. Now that I think of it, of all Amiga sound editors I’ve ever used, Stefan Kost’s SoundFX is the only one that can do logarithmic fades – but like everything else in SoundFX, they’re rather complicated to set up there. I’m sure AmigaOS4 composers and sound designers will find them a welcome addition once my Fade plugin gets updated. Other Process menu functions I’ve recently finished include audio channel swapping and conversion, the latter featuring 64-bit floating-point precision mixing for stereo-to-mono conversions.

But the morning time I spent tickling the Rave code was just a nice little extra, a few private hours in which I deliberately allowed work to prevail over fun. There were many great moments at the party – and not just because we had beer on tap and you could self-service yourself to oblivion. Or because you didn’t need to feel awkward watching quirky demos you made quarter a century ago. Thanks to the emulation capabilities of the MiSTer, I was able to correct some of my Amiga-centric views of what other historical computer platforms had to offer, which was an illuminating experience. With quite some trepidation I watched Lagya’s efforts to bring a dead A500 back to life, and I felt a lot of relief that my X5000 saves me from this kind of hardware voodoo; an illuminating experience again. I made a lasting impression on my mates by cooking my trademark goulash, which some of them had the opportunity to see one more time after a bumpy car ride; this experience was not illuminating at all.

But the high-point of the party was our Saturday afternoon visit to the Terra Technica Time Travel Museum in Hatě. I hadn’t heard of the place or visited a similar one before, which added to the power of my experience and turned our trip into an unheralded gem of the weekend. Located just a few kilometers from the Austrian border (and owned by an Austrian guy called Ronnie Seunig), the museum presents itself as “the world’s largest museum of jukeboxes and pinball machines”. Such a description would leave me perfectly cold if, in fact, the place weren’t much more than just that. While the jukebox and the pinball halls were cool with their flashy, deliberately overdone American feel, we preferred to spent more time in the Pixelworld. This video games section of the museum had all the retro computers we love, plus over a dozen machines we had never seen in real life. There were several Amigas including two rare A500 models from Commodore Germany’s 1989 “New Art Limited Edition”, featuring trendy cases designed by the late Stefanie Tücking. I bought my first Amiga in Germany, and I remember I almost went for the ball design A500 because the computer shop was eager to drum up the sales of the Limited Edition, but after some internal struggle I bought the regular one. Silly me. If only my visual taste had been less conservative: I could have a collector’s item now!

When it comes to video games, I must not forget a battery of arcade cabinets they had in a separate hall. Some of these were very old, predating the late 1970s/early 80s arcade game boom, and you simply had to marvel at the resourcefulness of the people who were able to design such wonderful machines through purely electro-mechanical means. Many (if not all, I didn’t check) cabinets were token-operated and playable, just like the pinballs in the other hall. How could we possibly pass up on such an opportunity to relive a bit of our childhood days? I can tell you that a lot of hard-earned cash fell into the token dispenser before we moved on to the last (and newest) section of the museum. The Sound & Vision room, while much lower on the hands-on factor compared to the games hall, was a great place to round off our visit. As the name suggests, this section is dedicated to the history of audio-visual technology. And as if the museum owner thought we hadn’t seen enough interesting gadgets, we found ourselves surrounded by a plethora of historical devices, tools and media, from Edison’s phonograph through shellac discs to early digital recorders. You bet that my audiophile heart bounced with joy!

And then it was Sunday and it was time to put our computers back into their transport boxes, finish the keg, and wrap the party up. Interestingly enough, although we extended our lakeside weekend by one day this year, we were still in the mood for more. Must be some kind of Amiga paradox because this is a feeling I get from almost any Amiga-related event I attend. Another paradox is that I needed almost two months to cover our four-day party, but this is because family matters got in the way unfortunately. I nevertheless hope you’ve enjoyed this belated report as much as we enjoyed our geeky get-together. There’s every indication that it will turn into an annual fixture, so Amigas on the lake are there to stay!

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 the operation of the program components and synchronizes access to shared 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 clearly saying how to put 16-, 24- or 32-bit sounds in the clipboard, 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 call for attention). Stay tuned and watch this space!

Cieszyn is a quiet border town in Silesia, a historical region that now spans parts of Poland, Germany and the Czech Republic. It is in fact two towns, for fate and politics had it that after World War I and the collapse of the Austro-Hungarian Empire, Cieszyn got divided between Poland and the newly formed country of Czechoslovakia. It wasn’t a very fair split and it’s quite understandable why: with the majority of the local population being Polish, the larger part of the town including the nice historic centre went to Poland, while Czechoslovakia acquired the industrial suburbs in the west.

I remember that at the end of the 1980s, Czech Cieszyn was a run-down place where apathy and despair could be sold in quantity. Grey suburban ugliness shook hands with the communist town-planning butchery, and the ubiquitous feeling of decline was augmented by the grim border guards who, armed to the teeth, patrolled the two bridges separating the town from its Polish sibling. Far off the sightseeing map, the place gave you little reason to come for a visit. Yet I found myself travelling to Czech Cieszyn on an almost monthly basis, and so did many home-computing fans from my area. There was one particular reason why we would happily suffer two hours on a slow train and two hours back – and it certainly wasn’t the snack in the salmonella-infested railway station bistro. The reason was that the bookshops in Czech Cieszyn sold Polish books and magazines.

Now, that probably needs some explanation. At that time, Czechoslovakia was ruled by an authoritarian communist gerontocracy that neither welcomed nor understood modern technology. While in the West the home-computer revolution was in full swing, Czechoslovakia literally sneaked into the new era along the sidelines, thanks to enthusiastic individuals and local communities that found ways, often illegal, to fill in for the non-existent computer market. Surprisingly enough, obtaining hardware wasn’t the biggest problem (although the Iron Curtain was still firmly in place); in fact, by the end of the decade many Czech households owned a Sinclair, an Atari or a Commodore. But information was a precious commodity. The country’s only off-the-shelf magazine devoted to computer technology, Elektronika, largely focused on industrial applications in the Soviet Bloc, and provided little material on home computers. As a teenager with a shiny C64 on your desk, you really didn’t want to read about a bulky mainframe from Bulgaria.

Things were very different in Poland, where computerization was taken more seriously. While also ruled by communists, the country actually had adopted a nationwide computer literacy programme, which went under the official slogan “The Game for Tomorrow.” The Polish government believed that encouraging young people to use computers productively would bring, at a later point, highly skilled workforce that would make an impact on the country’s ailing economy. Among the results of the official policy were two computer magazines that made us Czechs green with envy: Bajtek (which was mainly home-computer oriented) and Komputer (which focused on users from the professional sphere). Compared to our puny Elektronika, both magazines contained far less ideological fluff, and happily covered the latest technological developments in the West. And as a Slavic language, Polish represented a much lower barrier than the German we found in magazines occasionally smuggled from the neighbouring Austria or West Germany. So Bajtek and Komputer provided a good reason to hop on the train and take the lengthy Saturday trip to Czech Cieszyn. The refreshing read made the journey well worth it.

I know that history makes a point of repeating itself, but I’m still finding it hard to believe that – more than thirty years later – I’ve bought a Polish computer magazine again. Why did I bother, now that I can choose from about half a dozen different titles in my native language? Well, this particular mag has one great thing about it: it’s an active, Amiga-oriented print magazine that focuses on the next-generation branch of the platform. Which came as a surprise because for a long time the post-Commodore systems had, at best, shared pages with the classic Amiga in the remaining few magazines such as Amiga Future. This suggested that things had never been peachy enough in the next-gen quarters to justify a dedicated mag. Well, that’s what I thought before I heard of Amiga NG.

Four years ago in Poland they decided to take the plunge and start a magazine to cover the three NG flavours, that is, AmigaOS4, MorphOS and AROS. More importantly (because starting a mag is easy), they were really serious about it. The brainchild of Adam Mierzwa went from a simple PDF-only pilot publication to a full-colour 64-page printed magazine that, at one point, became a regular quarterly and earlier this year made it to issue #10. (This is the part where you say wow!) The efforts of editor-in-chief Mierzwa and his small team have been supported by the Polish publisher Adam Zalepa, whom you may also know as a prolific author of Amiga-themed books and user manuals. Initially unconvinced, Zalepa gradually warmed to the idea of a new magazine, and Amiga NG became part of the impressive range of computer mags published by Zalepa’s company Bitronic. And although I doubt it brings the publisher any profit (considering the low print run, which doesn’t exceed 100 copies), from the buyer’s point of view Amiga NG is certainly not a let-down.

In your hands, the magazine feels unusually heavy with all of its pages printed on thick glossy paper. Very thick in fact – the paper weight surely exceeds that of Amiga Future or Amiga Addict. One cannot help asking if such luxury material is really necessary for a hobby mag, and whether a bit of money could have been saved here to spend it on something else. For example, on page design and typesetting, which is a little crude and basic in Amiga NG. Because quite predictably, the project cannot afford to employ a regular graphic designer, leaving the chief editor responsible for graphic chores on top of his editorial, writing and organizing duties. Someone really ought to come and take the load off the back of that busy Mr. Mierzwa!

As for the magazine content, Amiga NG brings the usual: news, hardware and software reviews, tutorials, reports, interviews, and of course the occasional ad. The 64-page format is rather generous and provides plenty of room for screenshots; it also allows the interviews to go into greater depth. Indeed, I’ve found it is the interview section that is my favourite. The magazine team makes good use of their podcasting experience, so the interviews are well-conducted and bring a lot of interesting information, often spanning several pages. What I especially like is that zeal and optimism do not choke the critical mind. Instead of painting a rosy picture, the mag is often very blunt about the various problems that plague the next-gen Amiga world. I appreciate this realistic mindset, which I think is more beneficial to the platform than self-delusion.

All right, so shall we all now start learning Polish to be able to read Amiga NG? Is that what I’m trying to say here?

No, of course not: the lesson mentioned in the title of this article is purely metaphorical, and has nothing to do with language learning. The educational point is in something else. I’m writing this text because I realize that, for the second time in my life, my Polish neighbours have shown me that a can-do attitude is the perfect recipe for bad times. I can see that whether your computing fun is spoilt by the communist grip or by the frustrating legal mess that is currently ruining the AmigaOS4 ecosystem, you can still have your way if you put in hard work and enthusiasm. From this viewpoint, it appears rather ironic that the international next-generation Amiga scene hasn’t even started contemplating a dedicated periodical to represent itself through – now that we know that users in Poland have had one for several years. Some food for thought perhaps. At any rate, the Polish lesson teaches us that things can be done if the rope is pulled in one direction. Thanks for the reminder, Amiga NG!

“April is the cruelest month,” says T. S. Eliot in the opening of his most famous poem, The Waste Land. Well, I sincerely hope this year will be an exception because I’d say that March was tough enough. The Covid-19 pandemic got a little out of hand here in the Czech Republic, resulting in another hard lockdown, so I really wouldn’t like to see April compete in cruelty with its predecessor!

I had every intention to release a beta preview of the Rave audio editor before the end of the month, as I had announced in my December post. But given the circumstances, I just couldn’t get to the finish line. With daycare facilities closed as of 1 March, my wife and I became full-time teachers, activity leaders and cooks on top of our daily jobs, and although our five-year-old is a great little fellow, having him around 24/7 doesn’t leave one with much time and energy for programming. I normally enjoy my late-night Amiga sessions, but with so much to do during the day I often struggled to stay awake past 8pm. So, quite understandably, March has seen much less progress than I had planned and hoped for. To add insult to injury, at the time of this writing I still haven’t got the foggiest idea when the lockdown will be lifted and I’ll be able to pick up speed again.

Ironically enough, March was an exceptionally good month for AmigaOS4, with some major releases seeing the light of day. The cross-platform multimedia-oriented programming language Hollywood went up to version 9, bringing the biggest update in six years (see this link for a non-exhaustive list of new features). A few days later we saw the much-anticipated Release 2 of the Enhancer Software pack, the undisputed high point of which is hardware-accelerated video playback and various improvements to the graphic subsystem. My favourite media player AmigaAmp also got updated in March, and as if it were not enough, on the very last day of the month Harald Kanning made a surprise release of a new AHI driver. Amiga platforms (classic or next-gen) don’t see AHI drivers released very often, so the choice of OS4-compatible sound cards has until now been rather limited. What Harald’s driver brings to the party is cards compliant with the Intel HD Audio specification, which are cheap and easy to come by. This means that one no longer has to resort to older models, which often can only be sourced second-hand.

So it’s not that AmigaOS4 users have no new toys to play with at the moment – quite on the contrary. But given my inability to add to the string of happy releases I feel it would at least be fair to give some news on Rave. So this is a brief development progress report and a summary of what I managed to do in the past month or so.

First, my old friend Jan designed a logo for Rave and also provided me with some additional graphics for the program. Jan and I have collaborated on various projects since the early 1990s when we both were in the demoscene, and although he’s now a busy professional lad (and probably looks upon my continuing Amiga passion with a benevolent smile), he has never turned me down when I needed his skills. Thanks to his contribution I was able to implement a simple splash screen that indicates the progress of the program start-up:

I also found some spare time to extend the program’s Edit menu and add several new functions to control sample range selection and manipulation. On top of the usual Cut, Copy and Paste combo, I have implemented the highly useful Trim (only keeps the selected range and removes everything else) along with Clear (sets the selected sample data to zero), Delete (same as Cut but does not copy the data into the clipboard) and Grab (creates a new project containing data copied over from the selected range). The new Paste Special sub-menu extends your pasting options with some handy functions for specifying the position at which the clipboard data should be inserted. Furthermore, in order to make range selections easier, a few related commands have been added to the Edit menu as well. All this means that although the initial version of Rave will be relatively basic and limited (especially as regards the number of effect plugins), it should at least get you covered for reasonably comfortable waveform editing.

Nevertheless, the program component that has lately received the most attention is the file requester module. One of the early screenshots I published shows that Rave utilizes a custom file requester, instead of the standard one provided by the system via the ASL Library. While this may sound unnecessary, there are good reasons why I decided to go to such lengths. Above all, the ASL requester falls very short when it comes to customizing it for the needs of more complex software. For example, in a modern audio editor you will expect to be able to enquire about sample properties, possibly even preview your sounds before you load them. Similarly, when you save audio files you’ll want to configure the output format from the file requester rather than via a separate configuration window (as is typically the case in Amiga sound editors). This leaves the ASL requester out of the question: you need to develop your own.

In Rave, file selection is handled by a separate program module implemented as a private BOOPSI class. The initial idea was to make it streamlined for audio use, focusing particularly on the features my editor needed. The result was a requester that did its job (except for audio preview, planned to be implemented later) but lacked some of the ASL features. Certain properties such as file display order were not configurable, the requester did not support DOS links (because audio files are rarely linked), and there were no functions for file management such as Create New Drawer or Rename. But after some time, second thoughts crept in. I realized that with the ASL requester being so ubiquitous in AmigaOS, many users would take its features for granted and might consider my custom replacement half-baked. Therefore I took to adding more functionality, as the March situation permitted, to get closer to the original. And I think the current result is a very good compromise: it retains a lot of the ASL look and feel, while being tailored for the program’s needs and closer to what you see in professional audio software on other platforms.

So the good news is that although the plan to march on in March kind of fell through and the beta version will need some more time to get completed, Rave has still received quite a lot of love and the development is certainly going on. Which reminds me of the old I Ching that says: “Going on means going far” – I really like the sound of that!

Outlining my programming activities in the previous blog post I also mentioned that I had been involved with the Amiga Developer project for quite some time. After the post went live a few people asked me whether it meant that I would work less on the project now that I develop my own software. The answer is no, not really. In fact, there is a good deal of synergy between Rear Window and the work I do for Amiga Developer, and the two efforts have benefited from each other.

I for sure am biased because of my personal stake, but I’ll say that one of the better things the Amiga Developer initiative has produced is the Enhancer Software Core classes: a free collection extending the standard GUI toolkit provided by the operating system. Indeed, the main reason why I like to promote the Core is because it brings new possibilities to Amiga GUI programming. So when I started working on my Rave audio editor, I knew I wanted to use the new classes on top of the traditional ones. What I didn’t know was that Rave would soon become an important test bed, a trial of fire in which the Core classes would have to prove themselves.

Regardless of how thoroughly you design it, a software component only reveals its true colours when used in real software. By which I mean not only that real-life use exposes bugs and drawbacks that went unnoticed at design stage or during beta testing. Actual use in software also tends to throw new light on how the component could work and what features might be missing. I’ll hazard a guess that a lot of the AmigaOS gadgetry has seen progress because a developer working on particular software was short of a particular feature. Or is it pure coincidence that the GUI toolkit received major updates while Simon Archer, one of the key OS developers, was working on his CodeBench IDE suite? I don’t think so. And that’s just one case in point.

Having access to the Amiga Developer source code repository I was, similarly to Simon, in the lucky position that I could shape the classes I’d decided to use in my software. As a matter of fact, all of the recent updates I have made to the Select Gadget (originally written by Massimo Tantignone) and the InfoData Gadget (Mark Ritter) were motivated by something that cropped up while I was working on Rave. And it won’t come as a surprise that my audio editor is also directly responsible for the very fresh addition to the Enhancer Software Core: the ToolBar Gadget class, which I have recently covered for the Amiga Developer Blog. Here’s how it all came about.

I have a habit of starting my projects by designing the GUI. Although in the end it usually bears little resemblance to the original version, I prefer to do it this way because seeing something tangible on the screen jogs my creativity. (It also tricks me into feeling a sense of accomplishment, despite the fact that the program doesn’t do a thing yet.) So I was sitting there designing an early toolbar for Rave when I once again realized how much I hate the standard SpeedBar Gadget, because it takes ages to set up. In an ensuing act of bravado I decided to put the work aside and write a custom toolbar gadget class: one that would be basic in features but extremely easy to get going. I thought, few programs use their toolbar for more than triggering action, so why not focus on the primary function? It turned out to be a relatively quick job, and it would have remained a one-off affair (and I would have no article to write now) if I hadn’t made a classic mistake: I shared my work with others.

In a way, I shot myself in the foot by offering the ToolBar Gadget as a contribution to the Enhancer Software pack. I fell prey to semantics, not realizing that if something is called “Enhancer”, people will invariably expect more features from it. Well, my gadget class didn’t have more features than the SpeedBar, it just represented a simpler alternative – which apparently didn’t come across as added value. The subsequent reactions ranged from indifference to downright scorn, and they were a painful lesson to learn. One fellow developer kindly sent a list of features my class absolutely needed to have before he even bothered to use it; isn’t team spirit great? But we Amiga programmers are renowned for our resilience (on top of the fact that we can cook a decent curry, which puts us in constant demand at registry offices), so I didn’t give up that easily and continued working on the class alongside the Rave project. This turned out to be a very sensible decision because as the program evolved, so did the ToolBar Gadget in response to my growing needs. Thus one feature led to another until one fine day (whew!) I finally felt that my dear little creation could no longer be blamed for not enhancing the Enhancer enough.

A brief look at the screenshot above may suggest that there is little visual difference between the ToolBar and the old SpeedBar. And yes, when the ToolBar Gadget saw its first public release, a few users seemed disappointed that the two classes didn’t look any different. On closer inspection, however, you’ll notice certain details that go beyond the default look and hint at the advanced configurability of the ToolBar. Most prominently, the new class features a borderless mode, which arguably looks more modern and helps reduce clutter in crowded GUIs. There are also smaller and less conspicuous improvements such as support for multiple image sets (and easy switching between them), adjustable inner padding of the toolbar buttons, or configurable style of the separator bars.

One feature I’m really proud to have implemented is overflow handling. What is that? Well, some toolbars can be quite long and take up a lot of space in the program window, which may complicate use (especially where screen estate is limited). Therefore, toolbar classes are typically designed as “collapsible” GUI elements, to allow shrinking the window to a smaller size. When the window becomes too small to fit all of the toolbar members, we get a situation called overflow. How this situation is handled depends on the particular class. For example, the SpeedBar Gadget employs a scrolling mechanism that is triggered by holding the SHIFT key and then dragging the mouse left/right (or up/down if the gadget is vertically oriented). I’ve always found this behaviour rather quirky and unintuitive, so I preferred a smarter solution. As the image below shows, the ToolBar Gadget reacts to overflow by displaying a selector button on the right. Clicking on the selector invokes a pop-up menu the individual items of which correspond to the toolbar members that are currently out of view. So even in a minimum-sized window it’s really quick and easy to access the program functions. (Potential naysayers will be happy to know that overflow handling is optional, so if you prefer to have a “static” toolbar that is always displayed in full, you simply don’t turn the feature on.)

Having finally released the updated ToolBar in October 2020 I though I’d give the Enhancer classes a rest for a while and fully concentrate on my audio editor, but as every seasoned programmer knows – man proposes, software disposes. Soon after I got down to business, working on Rave provoked another idea. Now, unlike in other spheres of human activity, ideas in programming can be really dangerous because they often lead to feature creep and, ultimately, projects that never get finished. Large software companies even hire professional hunters to locate staff programmers with ideas and shoot them on the spot. But as a humble freelancer I didn’t need to worry, and because the Christmas period promised some extra free time, I decided to have one more go at the ToolBar Gadget. So, what was this idea about?

Well, the main program toolbar in Rave contains a section with buttons that control the zoom of the waveform display. Originally I had the current zoom level indicated in the status bar at the bottom of the GUI, which was OK but somehow didn’t feel right. From the viewpoint of user interface design, I believe that if a GUI element controls a particular value, the value should preferably be displayed in the proximity of the controlling element, to have clear visual correspondence between them. So I started thinking: what if the zoom level value were displayed in the same toolbar section, i.e. next to the zoom buttons, rather than somewhere far below in the status bar? Of course, the ToolBar Gadget wasn’t exactly up to this: you could create a text-only button, you could even change the text on the fly, but it would still look and act as a button. What I needed was a new type of toolbar member, a read-only display area streamlined for dynamic text content. Luckily, the internal design of the gadget allows me to add pretty much anything (as long as it’s a BOOPSI object), so before the New Year chimed in I had the textbox member type ready and on the job. This is what it looks like in the current development version of Rave:

For good measure I also threw in support for colours and text styles, because it was clear to me that someone would ask for these features sooner or later. Now that I’m thinking about it, in the end I must have made the ToolBar one of the most versatile and configurable classes of the entire AmigaOS4 BOOPSI set. Why do I suddenly feel so tired?

All right, it’s getting long (and late), so time for some closing words. An old Slavic proverb says that you can’t sit on two chairs at the same time. And there’s a good deal of truth in it: working on two simultaneous projects often means that one will rob the other of your time and focus. On the other hand, projects can also inspire each other, grow together and produce a synergistic effect between them. This has worked very well for me: both the Enhancer classes and the Rave audio editor have greatly benefited from the synergy. I’m quite sure there will be more in the future. And I’ll be here to tell you, so keep an eye on the Rear Window!

I realize it’s high time I shed some light on my Amiga programming activities and on the software I’m developing at the moment. Pressed for time before Christmas I originally planned to write just a short heads-up note but because there’s a bit of a story behind it, I’ve decided to turn it into a regular blog post in the end.

The story begins in late 1980s. I took my first steps in programming on the infamous IQ 151, a bulky personal computer that was produced in the Eastern Bloc back then. The manufacturer of the machine must have had a weird sense of humour to name it this way because there was nothing intelligent about the computer in terms of technology, features, or the user experience it provided. But it was there at the right time, and the excitement and sense of adventure programming brought to my life stuck with me. To cultivate my newly-found passion my parents bought me a second-hand Commodore 64, where the marvellous Simons’ BASIC provided everything a budding programmer could possibly hope for on an 8-bit computer. It was great fun while it lasted.

Fast forward to the 90s. Unheard-of at the time, the multimedia capabilities of the Commodore Amiga blew my generation away. It was such an eye-opener that for a few years I kept my programming pretty much on the back burner; instead I got involved with music making for the demoscene, as I already explained in a previous post. But for various reasons my demo-making flame dwindled down towards the end of the decade, and I found myself more and more interested in producing something that others could use as a productivity tool rather than just watch for pleasure. This is when I finally learned the C language and delved into documentation on Amiga system programming. Yet with hindsight I can see I was still merely fooling around, and it wasn’t before I acquired my first AmigaOS4 system that I started producing real software for real users.

Encouraged by positive feedback on my first OS4 release, an English dictionary built upon Princeton University’s WordNet database, I went on to write the preferences editor for Thomas Wenzel’s AmigaAMP audio player. I also developed several plugins for the popular CD ripping software ADRipper, and when its author Adrien decided to quit the Amiga hobby, I took over the entire development and produced two major updates to the program. (Some achievement, considering that the original code documentation amounted to a dozen comments written in French!) Not long after that I was contacted by A-EON Technology, who invited me to join their new Amiga Developer initiative, a project that brings you the Enhancer Software and that I have been part of for more than five years now. My main responsibility on the team is the development and maintenance of new GUI classes – building blocks that extend the functionality of the AmigaOS Intuition system.

There’s no doubt that working alongside some of the most talented Amiga developers of today is a great learning experience, and I find my involvement rewarding in many ways. But while I have definitely enjoyed contributing to a team effort, I gradually realized that given the time constraints of family life, working on the project keeps me away from the productivity tools I wanted to make in the first place. At this point I started contemplating the idea of my very own, independent project that ultimately became the Rear Window.

As you would expect, the first question I asked myself was: “What kind of software do I actually want to develop?” Well, my academic and professional background is in languages and translation, so I initially thought I’d write something in the vein of WordNet – that is, a new dictionary, a lexical analyzer, or perhaps a translation tool. But then I remembered it was the multimedia aspect that drew me to the Amiga, and as a musician I could see logic in developing something related to audio. Incidentally, my old music-making passion was warming up again at the time and I was looking for an audio editor to use with my sample library. It didn’t take a lot of research to see that the current offering is not great: the existing editors either showed incompatibilities with OS4, choked on modern audio file types, or were otherwise too limited in features. But frustration often brings about good ideas, and so I finally had a plan and a sense of direction.

I’m now happy to report that after some eighteen months of mostly late-night work the new AmigaOS4 audio editor has progressed to a stage where I can present it as a working piece of software. The program is called Rave, as I wanted a short name bearing strong associations with music and freedom. (It is also close enough to wave in both spelling and pronunciation, which I find playful.) It’s still rather basic in features but a lot of work has gone under the hood, allowing me to easily extend the program within the modular framework it is built upon. And although it’s a little early to promise a particular release date, I’m pretty confident to say that the program is currently in beta rather than alpha stage. I might also add that I expect to be able to publish a sneak-peek preview in the first quarter of 2021. And of course that I’ll cover some of the program features in more detail in the subsequent blog posts!

For now, they say a picture is worth a thousand words, so why not have a look at a few preliminary screenshots?

And of course: Merry Christmas, Amigans!