When you develop software, more often than not you face what is called an “implementation dilemma”: a crossroads type of situation where you have to decide which way to go next. What makes the situation tricky is that, unlike Dean and Sal from Jack Kerouac’s On the Road, you’re not free to make an arbitrary choice. Bad design decisions always have consequences, often unforeseen and usually bigger than smaller. Take a wrong step, and you end up in a lot of rewriting!
One day I got to the point that the Rave audio editor needed proper sample loading and saving (to replace the tentative datatypes-based code I’d used for testing). I had been developing the program with modularity in mind, aiming at a lean main executable that offloads the grunt work onto external modules, so keeping the loading/saving stuff outside of the main program was a matter of course. The question was how exactly that should be done – as usual, the devil is in the detail. One possible way was to develop a dedicated loader/saver module or plugin for each file format; an approach not foreign to Amiga audio software as it has been used in SoundFX and AmiSoundEd, among others. And indeed, going for this solution sounded logical, especially as I knew I could reuse or adapt the I/O plugin infrastructure of AmiSoundEd (the source code of which is freely available).
But given the number of audio file formats I meant to support, the prospect of having to develop, maintain and test a multitude of separate modules didn’t exactly fill me with enthusiasm. So in the end I went for a monolithic approach: a single program module that handles the loading and saving in all file formats. Because there’s only so much time I can devote to reinventing the wheel, I based the module on libsndfile, a cross-platform audio library that had also been ported to AmigaOS4. Regular readers will remember that I mentioned it in one of my previous progress reports. Choosing the library (which by the way serves popular software such as Adobe Audition or Audacity) was a decision I now thank myself for every day. Not always do implementation dilemmas have such good endings!
Of the thirty or so file types and formats libsndfile can handle, Rave provides a healthy selection that has recently been upped to twenty. Now that’s what I call being spoilt for choice! And perhaps this abundance of available formats was the reason why few people noticed that Rave didn’t support raw audio in its first few releases. I didn’t consider it a priority because raw is not exactly sought for these days. Or at least it doesn’t get much use in music-making and the recording industry, where unformatted data doesn’t bring any advantage. True, I have read a few forum posts where musicians across computer platforms were trying to recreate the “classic Amiga sound” by importing samples from the old SoundTracker sample disks, many of which came in the raw format. But then again, most of these legendary (or should I say infamous?) sounds have already been converted to WAV and shared online, so why bother with raw import?
My opinion changed after I bought a sample pack from Glitchedtones, a sample provider that focuses on sound effects, cinematic sounds and ambience recordings. The sample pack, aptly named Data Disruption, was created solely by taking various digital files – program binaries, documents, bitmap graphics and the like – and importing them as raw data into an audio editor for further processing. This gave them such wonderful quirky glitch sounds that I wanted to be able to make my own, using Rave of course. And so it happened that raw support jumped up the to-do list and soon I began working on it.
A typical raw file is headerless and there is no standard suffix to identify the format (.raw is often used but is not mandatory). Therefore, an audio program has no way of knowing how to recognize the file and, more importantly, how to interpret the data contained within: properties such as sample rate or the number of channels need to be provided by the user. Starting from Rave 1.6, any file type the program doesn’t recognize can now be loaded, with the help of the import window shown above. The hidden beauty of raw is that importing the same file with different properties will produce a different waveform, so it opens ground for experimentation. The result is often weird noise and it can take a lot of attempts to discover something distantly musical or percussive, so brace yourself with patience. Your reward will be an interesting and unique sound that may be worth adding to your sample collection.
You’ll no doubt notice that most new features and improvements in version 1.6 are related to loading and saving files. Apart from adding raw data import and export, I’ve also completely rewritten the IFF-8SVX saver. During testing it turned out that the IFF files produced by libsndfile were seen as corrupted by several audio programs, namely OctaMEDSoundstudio, MilkyTracker and AmiSoundEd. I have no idea why this was the case because libsndfile is otherwise very reliable, tested by thousands of users around the world every day. The situation was the worst with MilkyTracker because while the other two programs simply displayed an error message, the tracker would hang in an endless loop when trying to load the sample. As Milky is currently my main composing tool on the Amiga and I’ve been recommending it quite a bit, you can imagine how eager I was to fix the problem.
So I sat down and wrote my own IFF saver code that bypasses libsndfile, and I’m happy to report that the resulting files now open successfully in all of the three programs mentioned above. The new implementation also comes with a little bonus: IFF-8SVX files can finally be saved in stereo! This was impossible previously because the IFF format organizes stereo data in a way libsndfile is not designed for. I personally don’t have much use for these files, but the IFF format has such a strong connection with the Amiga that it was unthinkable to leave it half-supported.
For some time I had also been trying to enable saving in the Ogg Vorbis format (to provide an alternative to MP3 and FLAC) but for reasons then unknown to me it always invited the Grim Reaper. During a recent, more serious attempt at making it work I managed to pinpoint the location of the crash: it appeared to be a problem in one of the ported libraries. But inspecting the source code I couldn’t quite see what the offending library function was doing wrong. Luckily, Fredrik Wikström – who had ported most libraries that Rave makes use of – offered to take a look at both the code and the crashlog. For me, reading a Reaper crashlog is like reading Heidegger but Fredrik is way more experienced, and so it didn’t take him long to discover that the function drained my stack by making some rather adventurous memory allocations. Because AmigaDOS doesn’t have automatic stack enlargement, such a situation will unfortunately end up in a crash. Of course I could just increase the program stack size, but Fredrik had a better idea: he rewrote the relevant code to make it more “Amiga-friendly”, and sent me a new build of the library. Lo and behold – Ogg Vorbis saving worked without a hitch!
Time to wrap up I guess; my favourite time. No epidemic of blindness has been reported of late, so I’m sure Amiga users have noticed the string of Rave releases since the program’s first public introduction nine months ago. Although the development gobbles up most of my free time, I’d like to continue this trend: I prefer not to hoard new features and, instead, release as soon as I have something useful to show. Now, I think I’ve put in enough to call it an update, so I’d better brush up the documentation, prepare the distribution package and get version 1.6 out of the door!
In September, having made three public releases of the Rave audio editor within three months, I felt I needed a little break from programming. I used the self-imposed leisure time to catch up with my reading, and so I finally managed to get through the latest issues of Amiga Future and Amiga Addict, which had piled up in my room since earlier this year. I also visited and had a lot of fun at the Amiga37 party in Germany as I reported previously.
But with the festive season approaching, I thought it would be nice of me to prepare a Christmas release. In AmigaOS4 quarters, there’s always a lot of eager expectation around Christmastime, and with operating system updates no longer being a given, the focus of attention has shifted towards software releases. The developer has inadvertently become some sort of Santa figure, so I didn’t want to disappoint and leave my users’ stockings empty. My only problem was which features I could realistically implement within the relatively limited time frame. After some thinking I opted for two main new features to form the core of the 1.4 update, which I scheduled for 25 December (of course).
One particular feature that didn’t make it into the initial releases of Rave is resampling – that is, changing the sample rate (a.k.a. sampling frequency) of the audio data. I didn’t consider it top priority because the typical sound material of today is no longer a mixed bag of data formats and properties as it was in the 1990s. Music software like Audio Evolution or MilkyTracker will happily import sounds available from major sample providers such as Loopmasters, which makes resampling somewhat redundant. But as one user rightly pointed out in a forum comment, oldschool tracker musicians will be less thrilled because Amiga programs of the ProTracker kind often use audio data sampled somewhere between 8 and 16 kHz. I had to agree that producing “tracker samples” from modern-day sound libraries can be a challenge in the absence of a dedicated resampling function.
My readers will know that I develop Rave with the aim of bringing innovation to audio editing on the Amiga. Therefore, I’m on the lookout for whatever industry standards and good practices can be brought over from major platforms, rather than trying to invent my own half-baked solutions. For resampling, I had my eye on libsamplerate, a platform-independent C library that is known to provide high-quality sample rate conversions. I even found an old OS4 port of the library done by Varthall in 2008, but I got discouraged seeing that in order to use it I would have to either pay a licence fee of 1000 Australian dollars (ouch!) or release Rave under GPL (ouch! ouch!). Luckily, when I visited the author’s website I discovered that the licence had changed in the meantime, so I no longer had to worry about restrictions. The unstoppable Fredrik Wikström was quick to provide a fresh port, and in early December I started working on the implementation.
I wrote the Rave resampler as an independent program module, which can perform sample rate as well as bit depth conversions. I find this convenient because if you have, for example, a 24-bit / 44.1 kHz sample that you want to convert to 8 bits at 16 kHz, you can do this from a single GUI window (see above). The sample rate conversion supports both downsampling and upsampling, and libsamplerate really shines here. Unlike in most other Amiga audio editors, upsampling in Rave can actually improve the sound quality, as the library’s interpolation filters try to reconstruct the signal that would have been obtained by sampling at a higher rate.
There are four quality options to choose from, affecting the accuracy and speed of the conversion. “Best” is what it says on the tin, but it is really very slow: on a full-length audio track the operation can take several minutes, even on an AmigaOne X5000! On the other hand, the “Low” option (which triggers a converter based on simple linear interpolation) is very fast but sacrifices quality. The default setting is “Good” – a reasonable compromise between quality and speed. I should also add that the resampler module works asynchronously and doesn’t block the editor, so if the conversion takes longer than you would like it to, you can always switch to another project and edit it in the meantime.
Concurrently, I was also working on the other feature that I had slated for inclusion in the 1.4 update. My aim was to rework and improve the Fade plugin. “Wait a minute,” some of you will now say, “what on Earth can be improved about fading? I thought it was just a simple function that produces a gradual rise or fall in the signal level?”
You’re right, you don’t have to be a seasoned sound engineer to have practical experience with fading. Whether you needed to remove that nasty click at the beginning of a sample, or wanted to give your song a nice smooth ending, chances are that you launched your favourite audio editor and used the Fade In / Fade Out function. If you used your Amiga to do this, I’m pretty sure that your editor produced a linear fade, leaving you with a signal curve that increases or decreases in a perfectly regular fashion. Something like this:
The problem is that while regularity will please a mathematician, the human ear may be less impressed. Have you ever felt that the fade-outs you apply at the end of your tunes sound a little too fast or abrupt, compared to songs you hear on albums? This is because your ears play a little trick on you. If you increase or decrease the signal level (which we perceive as volume) along a linear curve, the ear will hear it as if the sound level changes exponentially. Digital audio editors need to compensate for it if they want their fades to sound naturally. But do they – on the Amiga, I mean? Unless I’m mistaken, the only editor that lets you configure the fade curve is SoundFX, by way of applying a modulator:
But this is all rather technical and clumsy to set up; I wanted something a bit more intuitive and easier to use. To start with, I introduced two pre-defined non-linear fade curves to complement the existing linear one. My favourite is the “Cosine bell”, which applies half of the Hann window function to the signal, producing a smooth transition between zero and full amplitude. An alternative is the “Sine lobe” (based on the Riemann window) with a slightly slower onset and more straightforward progression. I can imagine that in the future I’ll add a few more options, or even better, a control element to finetune the slope of the fade curve. But for the time being I’d say that the plugin does the job quite nicely – see the image below, which shows three different types of Fade Out applied to the same sample:
One more thing. As I wanted the new Fade plugin to be user-friendly, I thought it would be nice if the plugin window also provided a visualization of the fade curve, to give the user a better idea about the result. For this I wrote a custom BOOPSI gadget that displays simple shapes and curves. Nothing fancy at the moment, but I still find it a welcome addition. As Rave receives more functions and plugins, I expect the gadget to get more use in the program; for example, it could display various oscillator curves in future plugins that will generate sound through synthesis, or the like.
As any software developer will tell you, writing computer applications can often take unexpected twists and turns. So just when I though I had all the hay in the barn for version 1.4, I got a feature request from one of my users. Now, past experience has taught me to be very careful with feature requests and not try to please everyone. Because if you do, the development will soon lose focus and get out of hand. New features improve your program, but they also bring more work, add overhead, and postpone release dates. So I always try to ask myself first if a particular feature is really going to contribute and improve the workflow.
Moreover, users sometimes end up not using the features they have asked for. A software engineer once told me to beware of what he called “paratroopers” – random users who come out of nowhere urgently asking for a feature, only to disappear and forget that your program exists within a week. I made my own experience with a “paratrooper” years ago when I was working on the ADRipper CD converter, which I had taken over from its original author CentaurZ. A user I didn’t know asked for a new feature that required a great deal of rewriting of the program and its inner workings. I got burnt out in the process, the planned release had to be postponed by a year, and when I finally got it out the door the guy was no longer an Amiga user. A great lesson learned!
This time, the request was to add a timer that would measure and display how long it took to load or save a file. Despite seeing the potential benefit, I meant to dismiss the request for the time being because I didn’t want to jeopardise the Chrismas Day release. But the user, Mikael, promptly sent a donation through my Ko-fi page to show me that he was serious about it, and we started discussing the feature on Discord. The implementation of the timer wasn’t a problem; the problem was where exactly to display the reading in the program GUI. Mikael suggested an information requester but that wouldn’t work because Rave is asynchronous. In a multi-project session, operations can take place simultaneously in the background, so a requester could cause confusion about which project it actually refers to. But I promised to give the matter some more thought. The following day I came up with the idea that each project would keep an activity log to register all operations (not just loading and saving), including the completion time. The Project Information window seemed to be the most logical place to put the log in, so this is where it went after a quick redesign:
And I must say that I grew to like the new feature soon! It’s very handy for testing and comparing the program performance on different OS4 systems – I wonder why I never thought of it before and instead bothered with a stop-watch?
Anyway, it’s past 7pm now and it’s high time I uploaded Rave 1.4 on OS4depot. I hope you’ll enjoy the new version, and I wish you all a very happy Christmas! Stay tuned for more updates in the new year!
I’m not a frequent Amiga party-goer. I had my fair share when I was younger, but I no longer see much point in going to far-away places only to find, typically, a dozen tables with old machines running old games. So the Amiga37 party announcement in April left me somewhat indifferent, all the more so when I realized that the venue was located over a thousand kilometres from my hometown. However, I began to have second thoughts when it became clear that it was going to be the largest Amiga gathering in years, and when many of my online friends have confirmed their attendance. The actual moment of decision came with me learning about the Setpatch Aftershow Party, which was supposed to round off the Amiga37 with live performances of the legendary Chris Hülsbeck and of the Norwegian cover band FastLoaders. With the latter featuring in the line-up, I knew it would only take a single phone call to persuade my old pal Human Factor to take me there in his car: on top of being Amiga addicts we’re both huge FastLoaders fans!
On Friday 14 October, we set off in the morning because Human Factor had estimated the journey to take pretty much the whole day. We made regular stops every two hours or so, to recharge the car and to take a rest, which became increasingly necessary as we progressed towards our destination. Well into the German territory, we stopped at downtown Kassel for a late lunch, and had a lot of fun in a local restaurant called Alex. I was in the mood for some craft beer and had one recommended, only to find strawberries floating in the glass as the waiter proudly served it. An adventurous drink to say the least! I had barely fished out the poor drowning fruit when our meals were brough and we had to bite our lips again, seeing that Human Factor’s bowl of spaghetti was covered by two unsolicited Wiener schnitzels the size of my hand! But the meal was delicious and my chicken curry came with no further surprises, so we left the Alex as satisfied customers with bellies full to the brim.
The clock was chiming 10pm when we finally arrived in Mönchengladbach and checked in at the T3 Cityloft Hotel. The receptionist on night duty couldn’t help raising his eyebrows when, instead of our accommodation and sightseeing opportunities, we rather inquired about a pub nearby that might still be serving draught beer at this hour. But that’s what you get when you send Czechs abroad: we’re a beer-drinking nation, and we’ll always be the first to admit it.
In the morning, after breakfast that either was mediocre or we were still hung over (I couldn’t tell), we called a taxi to take us to the Amiga37 venue. The Kunstwerk was located about five kilometres from the hotel, so we were there in no time and happily joined the registration queue. After a moment we realized that the two guys queuing right in front of us who looked like Dave Haynie and Ron Nicholson of Commodore were indeed Dave Haynie and Ron Nicholson of Commodore, so it was clear that the show was going to be big.
The registration didn’t take long and soon we found ourselves in, wearing stylish red wristbands indicating that we were respectable paying members of the International Amiga Brotherhood. We also received a free copy of the Amiga Future magazine, a special issue dedicated to the event. Although just a few minutes past 10am, the large hall of the Kunstwerk was already fully occupied with tables showing various Amiga as well as non-Amiga hardware. We really didn’t know where to start, so we started at the bar.
Upstairs above the hall, in a section called The Red Crocodile (Rotes Krokodil), interviews were held throughout the day featuring various Amiga luminaries past and present. The Crocodile was a very nice place, with a posh red leather sofa and armchairs on the stage. According to the schedule, David Pleasance formerly of Commodore UK was supposed to speak at eleven, but when we took our seats the man was nowhere to be seen. After a few minutes it became obvious that he wasn’t coming, also because the table down in the hall where he was supposed to promote his books was still empty. So we continued exploring the hall. I spent a few minutes at the table right next to David’s, where the director Steven Fletcher was stationed selling his documentary films and other stuff.
I had briefly met Steven at the 2017 Amiga Developer Conference in Cardiff, where he was filming material for The Commodore Story. Having seen this feature documentary two months previously, I wanted to say hello and well done to the very man who had made it. Steven told me he’d recently finished a new film, Amiga: Alive and Kicking, which he also had for sale on the table. The deal was sealed and I ended up buying three films on BluRay, plus a book that accompanies the Commodore Story film. We had a funny moment when I found myself in a photo as I was browsing through the book; Steven said that my face did look familiar but he had no idea he was talking to one of his impromptu “actors”!
Lunchtime approached and David Pleasance appeared in the hall; we felt lucky that his talk had only been postponed rather than cancelled. Unfortunately, as we were told by one of the organizers, he wasn’t going to share his Commodore-time stories but present his latest project, the so-called Commodore Amiga Global Alliance. Having mixed feelings about it we eventually decided to give the presentation a miss, and instead we popped into a nearby restaurant to have a small lunch and a few pints. The place served a decent lager called Bitburger – as computer freaks we found the name very appropriate, and even proposed a few Limited Edition variants such as the 8-Bitburger and the more powerful 16-Bitburger.
When we returned, the hall had noticeably more visitors and the event was in full swing. I visited the combined AAA stand to say hello to AmigaKit owner Matthew Leaman, and saw that they had two AmigaOne X5000 computers on display running various AmigaOS4 (and later also MorphOS) stuff. Compared to that, the ACube table located nearby looked much more static and, frankly speaking, left a lot to be desired. Considering that ACube currently has two OS4-compatible hardware models in the works (the Sam460LE and the A1222), I expected a vibrant presentation with several computers offering hands-on experience, in order to lure prospective buyers. But that didn’t happen. When I came over, ACube’s representative was just standing there looking at a few disconnected PCBs. Later, a Sam460 computer was brought in to at least show AmigaOS4 running on it but, I hate to say it, they could have done a better job presenting their products (and our platform).
One thing I love about such parties is that you get an opportunity to meet, in person, people you only know from the online world. So it was nice to finally put actual faces to names and nicknames from the AmigaOS4 forums: George ‘Walkero’ Sokianos, David ‘Skateman’ Koelman, Paul ‘Sananaman’ Koster and others. Some of the platform’s movers and shakers were present, too. I exchanged a few words with A-EON’s Trevor Dickinson (always the social animal!), I played a bit of Tower 57 on Daniel Müssener’s AmigaOne, and I’m sure a few jaws dropped when Mike Battilana (Amiga Corporation and Cloanto) was spotted in conversation with Ben Hermans of Hyperion. I wonder what the unlikely pair were talking about? Weather, or their never-ending court case?
Of course, Next-Generation Amiga computers represented a minority at the Amiga37. The event was largely about Classic systems, which were on display in numerous shapes and forms. Original Commodore hardware sat next to modern machines based on emulation or FPGA reimplementation; professional production mingled with DIY. The event oscillated between a computer fair, a games convention and a flea market in the most natural manner. It had a bit of everything for everybody, including Commodore 64 fans. For those who had no idea how big the retro thing had become, this show must have been an eye-opening experience!
Arguably, the most popular stand was that of the Apollo Computer team. It was also the most professional-looking, in my opinion. The guys put up quite a display to promote their computers and accelerators, with colourful roll-up banners, company t-shirts and, of course, a battery of Vampire V4 Standalone systems running games to play. Not that I would buy one myself (as a non-gamer I’m rather hard to please) but the team definitely deserves a mention for their stylish and well thought-out presentation.
Rambling around the hall, I also stopped by the iMica Ltd. stand and had a brief chat with the company’s owner Stephen Jones. I’d had my eye on his Checkmate cases for some time, thinking about getting the smaller Checkmate 1500 Mini for the upcoming AmigaOne A1222. But I decided against it, seeing that the case is actually quite large for a Mini-ITX board. It’s funny how misleading pictures can be because the case looks tiny in promotional materials, while in reality it’s not much smaller than its larger brother, the Micro-ATX sized Checkmate 1500 Plus. Two of these cases had a Checkmate Monitor prototype sitting on top of them. Although still waiting for their Kickstarter launch, the prototypes were fully working and attracting a good deal of interest – Stephen answered questions all the time! I normally wouldn’t care much about an LCD monitor that tries to look like a CRT model of yesteryear, but this monitor has one great thing about it. There’s an opening at the back of the chassis in which you can install a MiSTer or a Raspberry Pi board, turning the setup into an iMac-style computer-in-a-monitor solution. I can’t think of a more practical system to take to Amiga parties, so I’m sure Stephen will sell a lot of these.
With slightly different Amiga inclinations, our two-man crew spent part of the event separately, each of us going after the things he enjoys. A few times in the afternoon we would reunite upstairs at the Red Crocodile for interviews we wanted to see. We caught a bit of Amiga Bill’s Community Meet-Up, and although the show was mainly about thanking Bill’s fans and supporters, it was refreshing to experience the man’s infectious enthusiasm and positive energy. Some of the interviews were held in German, a language we’d only mastered to the point of being able to order a beer, so we skipped them and instead ordered a beer downstairs. An interview we had been looking forward to was that with former Team17 members Martyn Brown and Andreas Tadic. I hadn’t played many of their games back in the day, but Human Factor used to be a big fan and wanted to see his teenage years’ heroes (even more so now that he works in the gaming industry as well). As for me, I’ve always admired people who managed to turn their Amiga hobby into a way to make a living, and I really enjoyed listening to Martyn and Andreas sharing their stories from behind the scenes.
Having already seen most of what was happening downstairs, we decided to stay at the Red Crocodile to watch whatever was next on the programme. The online video interview with Jim Collas was apparently a last-minute addition because it wasn’t listed in the original schedule published in the Amiga Future Special. It was a welcome surprise, though. Jim talked about his bumpy ride as director of Amiga Technologies, and mentioned some of the opportunities lost during the Gateway years. His answers were open and sincere, and it seemed that his past involvement with the Amiga and its community had left some impact, because his voice was clearly getting emotional towards the end of the interview. Although Collas embodies one of Amiga’s many failures, he certainly made an impression on the audience, and the eventual round of applause was more than just a polite courtesy.
The final item on the list of talks scheduled for Saturday was the announcement of the Amiga Community Award winner. I was among the nominees, so one half of me thought it advisable to stay and wait for the results. But it was already 6pm and hunger was getting the better of us, so I made a realistic assessment of my chances and suggested that we better go get something to eat, and take a rest at the hotel before we head for the Setpatch Aftershow Party.
Mönchengladbach is a city of about 260,000 inhabitants, so you can imagine that it can get quite busy on a Saturday night. When our taxi dropped us in the centre shortly before 10pm, the streets were literally swarming with people! It took us some time to find the Projekt 42 nightclub, mainly because we couldn’t see any signs or banners betraying its existence. Finally we spotted an inflatable boing-ball hanging above the entrance door, and a queue of what we presumed to be Amigans patiently waiting for the club to open.
When we got inside, the club was shaking to the sound of DJ music and the staff at the bar were already busy serving drinks. After about thirty minutes of dubstep torture we noticed that there was no stage or instrument rigs around, and we got a suspicion that we were in the wrong place. And of course, there was another room at the opposite end of the club, which we discovered just in time because the Chris Hülsbeck concert was about to begin. The games music legend performed alongside his collaborator Patrick Nevian on keyboards, Chris himself controlled a very efficient setup that consisted of a small MIDI keyboard connected to a tablet running a software sampler or similar. The gig didn’t disappoint, they played the usual hits and some more, but of course it felt a little static: two guys on keys can hardly bring the club down.
As a hard-rock outfit, the FastLoaders were a different kettle of fish of course. The band from Bergen rose to subcultural fame thanks to their energetic cover versions of the Last Ninja game soundtracks. Since their breakthrough Ninja Musicology triple album, released in 2016, they have covered many more Commodore 64 as well as Amiga classics. FastLoaders concerts usually combine the best of both worlds, but this time their performance was based entirely on the Amiga Rocks album. Quite understandable given the occasion, but we couldn’t help feeling a little disappointed that none of the great Ninja music made it onto the set list. Anyway, they played enough hits to rock the audience and create a fantastic atmosphere: Shadow of the Beast, R-Type, Turrican II, Lost Patrol, you name it. But I think most will agree with me that the highpoint of the gig was when Jon Hare, the original author of the Cannon Fodder music, climbed onto the stage to play and sing alongside the band. Together they played “Narcissus” (the game’s melancholic menu theme) as well as the famous intro music – and we all sang along that “war has never been so much fun!”
The concert ended well past 1am, and although it left us highly energized, we knew we had to leave the club instead of staying for more fun. The prospect of our journey back (which would again take the whole day) was looming above us, and we simply needed to get some sleep to make our travel safe. We were sorry we couldn’t attend the Sunday programme, but our in-and-out visit was still an unforgettable experience. Amiga37 was a well-organized event full of interesting moments, and I’m really glad we went although we could only give it one day. The experience has worked wonders for my party-going appetite, so chances are I’ll meet you at another Amiga get-together very soon!
When Hyperion Entertainment announced in a 2014 blog article that AmigaOS4 was going to get support for accessing memory beyond the 2 GB limit, the reactions were mixed. Predictably, the most abrasive comments came from people who had never owned an OS4 system; but the camp of supporters didn’t seem over the moon, either. Perhaps the title of the article (“Breaking the Memory Barrier”) sounded too promising, and the reality couldn’t live up to the raised expectations. But there would likely have been less disappointment if people didn’t read too much into the title and, instead, took the feature for what it actually is. Because Extended Memory Objects – or ExtMem, as the feature is popularly called – was never advertised as more than a stopgap. Or did anyone seriously expect that AmigaOS would somehow miraculously adopt 64-bit memory addressing?
However, stopgaps in AmigaOS have a tendency to silently become permanent features (take AHI, for example), so eight years after the Hyperion announcement, we still don’t have a better solution. Worse, the adoption of the feature appears to have been quite slow: the system RAM Disk (adapted for ExtMem by Colin Wenzel) and Andy Broad’s SketchBlock are the only real-world applications of the feature that I’m aware of. The main reason why programmers don’t rush to use it is probably the inherent limitations because, as the critics like to reiterate, ExtMem is basically a return to the old practice of bank switching we know from the microcomputer era. Corny and technologically inane, right?
Like most audio software, my Rave sound editor can get quite memory-intensive. Popular compressed formats such as MP3 and the practice of streaming have taken our attention away from the fact that today’s audio data can easily take hundreds of megabytes when you decompress it into the computer’s memory. This may be a problem on a 32-bit system such as the Amiga. So I was naturally curious if ExtMem could help me with some of the challenges I was facing. And it didn’t take me long to start looking in one particular direction.
After I released the first version of Rave, the user feedback I received showed quite clearly that the number one wanted feature was Undo – the possibility to revert changes you’ve made to the waveform. Not a great surprise: honestly, if I were in my users’ shoes, I’d be among the first to point out the omission of such an important feature! But it’s interesting to see how much we’ve now come to take Undo for granted because, believe it or not, an Amiga sound editor with such functionality is far from being a given. I recently fired up a number of audio manipulation programs that were popular back in the day. I was curious how my new-born baby Rave compares with them, and I specifically wanted to see how they implement Undo, hoping to find some inspiration.
The results of my little research were surprising, to say the least. Of the ten programs I looked at, only three featured a dedicated Undo – and only one of the undo implementations I’d call useful. To cut a long story short, I’ve summarized my findings in a table:
Undo implementation in various Amiga sound editors.
And the winner is (drum roll): Samplemanager by Thilo Köhler!
While I don’t feel like showing this table to my PC friends, the results cheered me up because I’ve realized that many of my predecessors scratched their heads over the same thing as me. They also confirmed my little theory that the implementation of Undo is not actually straightforward from the developer’s point of view. The user may think that all you have to do is dump the sample data into a memory buffer and recall it when needed, but it’s really not as easy as that, especially if you want to do it right.
On the other hand, I knew that I was in a different position with the next-generation hardware possibilities. I was thinking: if it worked for Samplemanager on a Classic Amiga seventeen years ago, why should I be worried on an OS4 system with a much faster memory and disk access?
Preliminary tests on both of my Amiga systems, an X5000 and a Sam440ep-Flex, showed that a disk-based solution would be more than adequate, so I decided to go that way. I ruled out the idea that the Undo function would store data in regular system memory. Imagine a session with ten high-definition audio projects opened, each keeping a separate editing history, each eating a chunk of RAM every time you make a destructive change. Just thinking about the memory footprint makes me shudder! (Of course I could limit the history to, say, ten steps to prevent things getting out of hand. Surely a great improvement compared to having no Undo at all, but as I try to make a strong case for AmigaOS4 and its software, I have little mercy for half-baked solutions.)
Still, with 4 GB of RAM installed in the X5000 I was intrigued to try out ExtMem because what I had read in the documentation sounded encouraging, despite the “ugly” limitations that spoil the party for the purist. What are they, actually? By nature, AmigaOS cannot address more than four gigabytes of RAM, leaving roughly 2 GB of addressable space for application use. The ExtMem framework allows applications to store more data than that, by dividing the data into blocks (ExtMem Objects) that are stored in the physical memory beyond the addressing limit. The trade-off is that not all of the memory blocks will be available at one particular time. This is because such a block first needs to be mapped in the system memory, acquiring an address within the 2 GB range for the time the block is being used. If there’s not enough RAM to map the other blocks, they have to remain unmapped (and inaccessible) in the electronic void.
I wasn’t really bothered by this limitation because due to the way Undo works, only one piece of data is needed for each step back. In fact, as Andy Broad explained to me, the key to using ExtMem efficiently is to make sure that a memory block is never mapped unless it’s immediately needed for reading or writing. So the programmer must think ahead and keep memory things organized and prioritized.
Knowing this I had all the information I needed to write two analogical pieces of Undo code, one for ExtMem and the other involving disk storage. The result is a dual system, which brings several advantages. Above all, AmigaOS4 users with more than 2 GB of RAM installed in their computer can make use of the extra memory, which would otherwise remain a dead place. They also gain some speed increase because although mapping an ExtMem Object comes with an overhead, it is still faster than writing to disk. At the same time, the disk-based solution is good enough and provides unlimited Undo even on low-end systems such as the Sam440. It also works as a fallback in situations when saving into extended memory fails because there’s not enough free RAM to map the block: in such a case Rave will simply store the data on disk.
So now with version 1.3 out in the wild, I wish you all happy undo-ing! Also, I hope that the ExtMem framework will get more real-life use to prove its potential, and that OS4 programmers will find ways to usefully adopt it in their programs. I think it’s time to dispel the fallacy that there’s no software to make use of the extra power and resources found in machines such as the AmigaOne X1000 or X5000. Now there is, and I’m sure more will be coming in the future.
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!