“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!

Much of my creative activity in the 1990s was related to the Amiga demoscene. I was lucky to live in a city which, albeit small, concentrated enough local talent to have formed a full-fledged demo group called Vectors, which I joined in early 1993. Unlike many other demo groups, the members of which were often scattered across different cities or even countries, we could easily meet up in person to discuss things, work on our projects, or just have some serious fun with our Amigas. This gave us a strong sense of belonging, and I dare say that our creative endeavours were driven by the fact that we were pals, above all.

Last year some good soul remembered that Vectors would soon turn thirty, and we organized a get-together to celebrate the anniversary. Most of us hadn’t met for good twenty years, so I expected a brief and rather subdued social occasion attended by life-worn, pot-bellied family guys. To everyone’s surprise the event extended into the small hours, well past the time our function room was hired for. Demos ran rampant, monitors flickered, beer flowed like a river, so it was inevitable that someone would eventually stand up and say, “Yes, we can! Let’s make a new Vectors demo!”

The drunken idea would have been all buried and forgotten were it not for our trusty coder Defor (the tallest guy in the photo above), who sent us an e-mail a few months later saying “All right boys, so I’m working on the demo, remember? How about you make some graphics and music for it?” I immediately knew I was in trouble because I hadn’t composed any demo tune since 2000. So I first thought I’d just fish out some unused music I made in the 90s and be done with it. But as others picked up speed and kept showing new stuff, my cowardly decision became more and more embarrassing. I also couldn’t help noticing that my old Protracker modules sounded really horrible, considering today’s standards. So it was clear that my AmigaOne X5000, which I had mainly used for system programming and occasional gaming, would soon get a new task to prove itself.

AmigaOS4 is not short of music trackers, although the choice is naturally not as wide as on classic Amigas. After some experimenting I finally opted for MilkyTracker, which is actually a FastTracker 2 clone but can export songs in the Protracker format. Good – I had the right tool and now it was time to bite the bullet and do my piece of work. It’s not that I hadn’t composed any music in the previous two decades; in fact I ran a small production studio for a few years, but it was all PC-based and very MIDI-oriented, with the Steinberg Cubase sequencer being my staple software. So it naturally took me some time to put all my trust in the Amiga again and get back into the tracking mood. “Will I still enjoy it?”, I asked myself. “Will the final result be worth the effort? And will my wife not kill me when she sees what I’m doing?”

As it turned out, neither the Amiga nor the tracker paradigm were the roadblocks. But I had completely forgotten how limited Protracker was with audio samples! Although MilkyTracker was more than happy to import material from my sample collection (most of which are 16-bit stereo .wav files sampled at 44100 Hz), when working on a tune to be eventually saved in the .mod format you want to keep an eye on the Protracker specification right from the start, to avoid unwanted surprises at a later time. I learned something of a bitter lesson there before I finally decided to play it safe and just converted everything to 8-bit mono at 22050 Hz (i.e. half the original sample rate), which seems to have worked well. Compared to the sounds I used in my old songs, none of which were sampled above 16 kHz, I can hear that this project has really benefited from the increased sample rate and got the extra spark in the higher frequency range, allowing the drum track to stand out and making synth sounds more vivid. The individual instrument parts are more defined and the overall sound is less muffled. Apparently, good old 8-bit sound can still cut the mustard.

Once I got the samples in it was time to brush up my tracking skills, knowledge and techniques. To my surprise, after a few late-night sessions using the tracker was like wearing old shoes. It was still there! I even remembered many of the Protracker effect and control commands, which only testifies to the fact that human memory has a tendency to keep the most useless things of all. Anyway, to cut a long story short: I had the tune pretty much complete in about two weeks of burning the midnight oil. I spent some more time optimizing the song in order to get under the size limit imposed on me, for we had agreed that the demo would be a true retro piece running on a lowly Amiga 500 (with a 512 KB Fast RAM expansion as an afterthought). During the entire process MilkyTracker was a pleasure to work with and never crashed or locked up, which suggests that the port is a job very well done. I can certainly recommend the program to any AmigaOS4 user interested in making music for demos or games.

With all the artwork and code in place we finally released the demo at a local Amiga party held in late September, a real close shave because the government’s Covid-19 restrictions hit back the following week. We decided to call the demo Mindsurfin’, which I find a particularly apt name not only because of the laid-back atmosphere but also for the reason that working on the demo was one big trip down the memory lane. And there was one more thing in it for me personally. I was excited to see our labour of love run on a classic Amiga, knowing that my next-generation Amiga was so instrumental in the project. It felt like two worlds shaking hands in a much-delayed reunion.

Enough said, enough done. You can download Mindsurfin’ as an .adf image from the demoscene portal Pouët.net (which also hosts old Vectors productions, in case you were interested in what we did in our years of youthful folly). The demo has been tested on a genuine Commodore Amiga 500, on a Vampire V4 Standalone, and in various emulation environments including Amiga Forever and E-UAE. You can also watch it on YouTube as an alternative. Last but not least, a few people have asked me if the music .mod can be downloaded from somewhere, so I’ve made it available here for anyone interested.

Enjoy and spread the word!

Browsing through old diskmags always makes me notice how much Amiga-related writing I did in the 1990s. But of course: the Amiga was my computer of choice back then, I used it throughout the decade as my main productivity tool. I used the Digita Wordworth for all my written coursework, including the master’s thesis; I composed several dozen tunes for demoscene productions in Protracker; I took my first programming steps in GFA Basic and, later, Storm C… So there was a lot to write about, and writing about it was great fun.

I haven’t written anything since I rekindled my interest in Amigas around the year 2009. The usual pressures of life are largely at fault of course, but now I realize I’ve been using “next-generation” Amigas for longer than I actually used the classic ones – so I find it quite absurd that I’ve never tried to share my experience. In a fit of self-honesty I also admit to myself that I’ve secretly missed my writing all the time, hence this little blog.

The name

There are three reasons why I decided to call my blog Rear Window. First of all, I’m a big fan of Alfred Hitchcock’s film of the same name – it’s just pure cinematic class! Second, my Amigas and I spent many years in small rented rooms with a single window looking out on the backyard. Over time, this had become such a predictable coincidence that, at some point, I started calling every man-cave I moved into after the rear window it had. And third: a backyard full of old junk and memories is an arcane place, neglected and out of sight but calling for adventure and inviting explorers; a perfect metaphor for the Amiga world today!

I am, therefore, opening my Rear Window on the backyard. Let’s see what we can see there.