Raving on: Part 2

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:

Selecting clipboard units from the menu.

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:

The Clipboard Information window.

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:

The Project Information window.

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!

The Polish lesson

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.

Dusted off: some of my Polish computer mags from the late 1980s.

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!

Is your Polish a bit rusty? Time to brush it up!

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!

Raving on

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

The Edit menu.

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.

The file requester (with the Control menu open).

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!

Demoscene: The Amiga Years, Volume 1

I had barely finished my January blog post when – THUD! – something rather heavy fell through the mail slot. I had been buying a lot of stuff online because of the Covid pandemic, so I had somewhat lost track of my orders: I knew it could be anything from frozen pizza to a framed picture of a disappointed horse. After unpacking, it turned out to be a book!

I’m not a great fan of crowdfunding but I have supported a few campaigns, mainly those aimed at documenting the history of the home computer era. As it coincided with my formative years, I now feel very strongly about things that help preserve the legacy of this wonderful technological age. So when it became known that an independent French publisher, Éditions 64K, had started an Indiegogo campaign for an extensive book about the Amiga demoscene, I was sold immediately. Considering how large and busy the scene had once been, it didn’t come as a surprise that the book got successfully funded in only two weeks.

Yet I wasn’t really expecting it when the book was delivered, mainly because the planned publishing date sounded a wee bit optimistic to me. Let me see: the campaign started in June 2020, with shipping expected for December. The publisher promised a mighty 450-page hardback covering approximately 90 demos from 1984 to 1993, in full colour print on quality paper. It was supposed to contain not only visual material but also a great deal of text describing the demos as well as giving interesting background on their development. I had previously worked for the publishing industry, so I knew you could easily deliver such a book in six months if your source material was more or less ready. But there were certain signals that the hay was nowhere near the barn. First of all, well into the campaign the publisher decided to change the title: the book was originally meant to be called – and was even promoted as – Demomaker, which admittedly was a major misnomer. Why’s that? Back in the early 90s, the Demomaker was an infamous Amiga program that allowed noobs and lamers to build simple demos from a set of ready-made effects and routines. Because such a program embodies a perfect antithesis of what the demoscene stands for, giving the book the same name would have been highly ironic.

Left: Demomaker by Red Sector Inc. Right: The original book cover mock-up.

Having chosen a much more appropriate title, the publisher then went on to announce a string of new sceners joining in and contributing their productions and stories. Which is great of course, but any such addition naturally inflates the project and adds to the production time. Given the ultimate number of contributors, combined with the fact that the demoscene is international and not all sceners are native speakers, it was clear the publisher would have a hell of a time organizing, editing, translating and proofreading the text content on top of all the graphic and typesetting work. I had a strong hunch that unless some corners were cut, Santa’s reindeer sleigh would end up short of cargo in December. So yes, the January delivery came as a nice surprise to me.

Upon unpacking I could immediately see that no expense was spared on the materials and binding. Chunky and substantial, the book presents itself as a formidable volume that will deserve a prominent position on your bookshelf. There is no dust jacket, but the cover is sturdy and very nice to the touch. It features pattern coating of glossy varnish and the book title is made in silver finish, which adds to the impression of a luxury item. Even just holding the book and flipping through its pages will make you feel that money has been well spent here.

As for the contents, I need to start with a small caveat. The book is called Demoscene, and the title may suggest that some kind of comprehensive account or analysis of the demo-making community is offered here. This is not the case, and let’s make it perfectly clear that such a thing was not the intended scope of the project. (If it were, the book would surely have to provide a more systematic coverage of two vital elements of scene life: diskmags and demoparties.) Instead, the book was conceived as a demo showcase right from the start, and indeed this is what you get in the first volume: ninety influential Amiga demos from the years 1984–1993. Although we need to add that the first three items were included mainly for historical reasons rather than for being actual demoscene productions.

If you followed the scene in the late 80s and early 90s, chances are high that you’ll be more than happy with the selection. I for sure can say that all of my personal favourites are there: the RSI Megademo by Red Sector – a demo I ran for weeks on end until the two disks developed serious read errors. Both megademos by Budbrain, showing that the scene didn’t lack a sense of humour and was not only about fame and competitiveness. The quirky Mental Hangover by Scoopex, a technological milestone that ushered us to the new dynamics of the trackmo era. Enigma by Phenomena with its phenomenal soundtrack. Digital Innovation by Anarchy, an unbelievable 30 minutes of graphics, effects and music squeezed on just one floppy disk. Hardwired by Crionics & The Silents and Desert Dream by Kefrens, epic demos that employed elements of film-inspired storytelling. And of course State of the Art by Spaceballs, a frantic visual performance that could easily be mistaken for a video taken from MTV. I could go on and on.

Left to right: Enigma by Phenomena, Revelations by Cryptoburners, and Voyage by Razor 1911.

I’m glad the demos are presented in chronological order rather than alphabetically or sorted by group. An obvious advantage of this arrangement is that you can clearly see how the scene, its techniques, skills and aesthetics developed over the said period. You won’t fail to notice certain ugliness that is intrinsic to the early “megademo” phase, and the growing artistic aspirations of the post-1991 production. Better than any sociological study the book captures the predominantly adolescent male character of the scene, which reflects in demo themes (often inspired by the sceners’ reading lists of science fiction and fantasy) as well as in graphic artwork (obsession by the feminine, an element that the scene noticeably lacked). The visual material alone provides great insight and serves as a valuable document of the times.

But it was the text content I mainly bought the book for, and as far as new information is concerned, the volume certainly doesn’t disappoint. I have seen (and yawned over) retro-oriented publications that merely rehash well-known facts and then quote people with rose-tinted glasses on how great the Amiga was. This is not one of them: the book brings a look behind the scenes in the true sense of the phrase. Although the copyright page names Christophe Boucourt as author, the text is apparently not a systematic account written by one person; it was in fact co-authored and largely collected or adapted from various contributors directly associated with the demoscene. This makes the text content rather varied and somewhat lacking in coherence as a whole, but on the other hand it adds to authenticity because you know the information comes right from the horse’s mouth. The parts where sceners introduce their computing background may come across as a bit repetitive because the stories tend to be quite similar (“I had a Commodore 64 before I got an Amiga”), but otherwise the book is packed with interesting trivia and sheds a lot of light on scene life. Group wars and animosities, membership changes, rise to fame and fall to oblivion, the challenge of technology, creativity and the spirit of competition, long nights up getting things ready for the next day’s demo contest, parties raided by the police… it’s all there, testifying to the fact that the Amiga demoscene at the turn of the decades was a vibrant and a thoroughly unique subculture.

My only gripe about Demoscene: The Amiga Years, Volume 1 is the language quality of the book. As I hinted above in one of the opening paragraphs, corners had to be cut somewhere if such an ambitious project was to meet the no less ambitious deadline. I’m sorry to say that much as I appreciate the text content of Demoscene, the proofreaders really did a sloppy job here. I understand that the text incorporated pieces sent by a multitude of different people (sometimes in different languages) and that it wasn’t easy to unify the whole thing, so I’m fine with the style being sometimes a bit rough around the edges. Similarly I don’t get offended by the occasional factual mistake: the musician Moby could hardly have bought an Oric-1 computer in 1993 (p. 421); Cryptoburners’ demo wasn’t exactly called Hunt of 7th October (p. 92); there was no member of Kefrens called “Mellican” (p. 362), etc. However, what I cannot pass over in silence is the grammar and spelling errors, the number of which is beyond acceptable. I have no idea how much the proofreaders were paid for their work, and I’m sure the book was a labour of love and won’t make the publisher rich. But a project of such magnitude and of such immense documentary value certainly deserved better. I would have easily lived with a delay if only it had resulted in a more polished text, making the reading experience even more enjoyable.

Here’s hoping that the planned second volume will receive more love in the language department, and that this much-needed project will continue to cover other periods and areas of the demoscene. I’ll be eagerly waiting in line to chip in!

Boucourt, Christophe (ed.) Demoscene: The Amiga Years. Volume 1 (1984–1993). English edition. Biarritz: Éditions 64K, 2020. 447 pages. ISBN: 978-2-9575080-0-6.

A word on project synergy

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.

My Workbench screen showing various configurations of the ToolBar Gadget.

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.)

Toolbar overflow in MultiEdit.

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:

Notice the zoom section in the toolbar that now shows the zoom-in level.

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!

The crest of a Rave

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.

The Amiga Developer team at the 2017 DevCon in Cardiff, Wales.

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!

Rave’s tabbed interface allows working with several projects within a single program window.

Applying amplitude level gain using the Level plugin.
Loop-playing a sample selection.
Opening a sample using Rave’s dedicated file requester.

Back on track(ing)

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

Vectors & friends at The Thirty Party, June 2019

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?”

At work
Left: AmigaOS 4.1 Final Edition running MilkyTracker and AmiSoundEd.
Right: Me at work. The “Make Amiga great again” cap is courtesy of Steven Solie.

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.

The Rear Window Studio
Left: The 2020 incarnation of the Rear Window Studio.
Right: My AmigaOne X5000 tucked away at the bottom of the rack case.

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!

Opening the Rear Window…

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.