<html><head><title>Review of ReMIDI</title></head><!--(c) G.C. '98 A.R.R.-->
<body background="../../images/tile">
<center><h3>Review of ReMIDI</h3></center>
<p>
 On our native platform, we have several notational music formats, from Maestro files to Digital Symphonies. In the PC world, however, the standard notational format is that of MIDI. One of the concepts of MIDI is the General MIDI specification, a group of over a hundred instruments that anything playing MIDI files must be able to reproduce. Generally, the top quality MIDI reproduction systems were all in hardware, although, over the past few years, MIDI playback has started to shift more and more into software. ReMIDI is one result.
<p>
 Something should be cleared up before we begin: ReMIDI is a General <i>MIDI file player</i>, not a <i>MIDI emulator</i>: if a MIDI sequencer (editor) needs a MIDI board fitted to work, ReMIDI will not pretend to be so; neither will it intercept and play data for an x86 second processor using something like PCSoundPro. ReMIDI will only replay MIDI files loaded into it.
<p>
<h4>Components...</h4>
<p>
 The ReMIDI package can be split roughly into two (but not down the middle): the first component is the <tt>!ReMIDI</tt> software itself, which takes less than 500k; the second is the package of <i>patches</i> the sampled voices which ReMIDI uses as instruments, which absorbs just a tad over five megs. The problem (for those of you who, like me, are struggling with a small amount of free space on their drives) could be slightly alleviated, but, when I try to run the software from a Sparkive, it crashes, although ArcFS, SparkFS or (especially) TBAFS might do better.
<p>
 Another difficulty will, for some people, be the size of the task's wimpslot. Two megabyte users could find that they just can't play some tracks and, more than likely, they'll have to kill everything else off to play a good deal more; I'm not sure it'd be sensible for one meg users to try using ReMIDI.
<p>
<h4>Features...</h4>
<p>
 ReMIDI brings up its main window when you load it, which has the data on the current track playing, including its filename and how far (in minutes and seconds) it is in to the track, as well as providing a slider for volume control. A nice feature is the <i>action</i> slab, which displays useful data on the current goings on of the software, such which patch it is currently loading. A space is even provided for real-time display of song lyrics, encoded within the MIDI file. Another slider is attached to the current song position and it is possible to drag the slider to change the position.
<p>
 When I first started playing tracks, the software didn't seem respond after it had finished loading all samples. However, it just turned out that it took a while to start outputing sound, as a natural consequence of the way it generates it (see below); ARM 2 users will probably experience even more severe delays than I; if it looks dead, don't kill it!
<p>
 If the main window is too large for your screen mode, which isn't the case in mode 12, or you just want it smaller, which may be the case in mode 12, it is possible to configure the main window to be small, although this does cut out a lot of the information.
<p>
 You can perform some basic queueing, such as fast forward and reverse with stop, using the options buttons at the base of the main window. You can also choose to repeat a track, which sends a copy of that name to the top of the playlist of tracks waiting to load; the playlist is added to whenever you try to load a MIDI file and one is already playing; it is possible to save the playlist out as plain text and, if there are tracks still queueing in the playlist when the software is quit, they will be remembered for when it is reloaded. Make sure that the MIDI file is still there: if it's on an ejected floppy, you can put it back in after the usual ADFS <i>disc not found</i> error, but files in RAM which have been deleted just cause ReMIDI to crash, with a nice stack backtrace, courtesy of <i>Acorn Desktop C</i>.
<p>
<h4>Options...</h4>
<p>
 ReMIDI allows quite comprehensive control of the quality of sound that is produced. Of course, the better the sound produced, the more processing power is needed to implement it. Perhaps the most prolific values here are the sample rate values and whether the output is mono or stereo; higher sample rates produce finer quality sound, although what sort of minimum sample rate is required for any instrument to be clear is thoroughly variable. ReMIDI also allows you to configure the note delay, which determines how long it takes for the sound of a note to die down, and setting this to a small value produces reasonably large speed gains; similarly, the desktop will pick up speed if interpolation is disabled.
<p>
 ReMIDI generates the sound to output in a buffer, the size of which is configurable; it basically mixes all the samples, at the requested frequency, volume and pitch, and puts this single (or double, for stereo), resulting track in a block of memory, the buffer, from where it is sent to the sound system, whenever it is needed; advantages of this include an ability to play a very large number of notes simultaneously (ReMIDI has 64 note polyphony, compared to the 8 note polyphony you'd get on an 8 bit sound system, where you have a maximum of one note per channel), the ability to play a MIDI file out into a (huge!) sound sample and the ability to pre-prepare some of the track (so, while you're out of the desktop, it can, for a while, keep on playing), while disadvantages include that it is probably more processor intensive. A bar showing how full the buffer is is on the main window and you can use this to find out both the maximum quality settings your processor can handle, without the buffer emptying before it can refill itself, as well as good values to allow ReMIDI to play in the background, without making the desktop very sluggish. On my ARM 610, I have to disable stereo sound to allow uninterrupted work in the desktop; indeed, this may not be possible on slower machines.
<p>
 Because of the buffer system, any changes you make to playback (such as scuppering instruments, changing volume or introducing interpolation) take a while to kick in, because of the difference in time between performing the operation in the buffer and playing that data; bigger buffers will increase the problem. You can set ReMIDI to flush the buffer whenever you change the song position, but it isn't really all that effective and it still won't deal with changing the instruments or resetting other options.
<p>
 ReMIDI also allows you to control which voices are allowed to play, either by muting some out or selecting one to act solo.
<p>
 ReMIDI also includes some experimental processing on the sound generated from the MIDI file. Spatial, which can only be used while stereo is active, applies delays to instruments, depending on their stereo positions, so that they are first heard on the side they have come from.
<p>
<h4>The Downside...</h4>
<p>
 There are a number of minor problems with ReMIDI. Because it needs to access, often, large numbers of samples, ReMIDI loads them into its workspace; however, because it extends the wimpslot and loads them into that, rather than into the relocatable module area, the task slows down in RISC OS 3.5 and 3.6, because the desktop periodically needs to remove the memory used in an application's wimpslot from what the rest of the computer can <i>see</i> and, if there is more memory to move out, it's going to to take longer. If you've got loads of memory and one of these versions of the operating system and you load up an eight megabyte file in Edit, you may feel the desktop become less responsive; even when ReMIDI is not doing anything, the wimpslot remaining from the previous track's instruments alone can make the desktop appreciably more sluggish.
<p>
 Each time you load a new MIDI file, the samples to go with that file are loaded. It would be nice if ReMIDI could keep any sample in memory from the last file and use them if they come up in the next, so save reloading time. Furthermore, I've also found it to be the case that, when you play the same track twice, ReMIDI's wimpslot still increases, even though it can only be loading the same instruments. Any software leaking memory is a bad thing; something so memory intensive as ReMIDI with this problem is quite inconvenient; on my 26 meg machine, I've sometimes had need to kill my ten meg RAM standing disc to allow a long playlist to run to conclusion; I would predict that 2 meg users are going to have problems playing out <i>very</i> long playlists. We can, at least, be thankful that, on running out of memory, ReMIDI gives us the chance to reclaim any need without quitting, a much appreciated touch.
<p>
 It should be pointed out that ReMIDI's buffer filling routine works only in the desktop, so, if you drop into the command line, it'll start repeating after a few seconds. Also, if you're running a BASIC task out of the desktop, try to avoid pressing <tt>Escape</tt>, as stray escapes can tell ReMIDI to stop playing, which is annoying side effect of a generally useful feature.
<p>
 Miscellaneous gripes include that all the graphics, including sprites for the filer, are in 256, not 16, colours and, because records of the playlist are stored as text files, whenever any text file is loaded while ReMIDI is, ReMIDI traps it, which is now <i>really</i> beginning to get on my nerves.
<p>
<h4>Conclusions...</h4>
<p>
 Whether you'll find ReMIDI useful or not depends on what you want to do with the MIDI system. If you intend to write MIDI files, that'll need a sequencer, which is going to need complete MIDI card emulation. MIDI playback through games is also not an option, mainly because ReMIDI only works in the desktop. If, however, you're just looking to <i>play</i> MIDI files, ReMIDI is not only just what you need for the job, but is also very economical. I doubt the other options would be any less memory or processor intensive and, either way, I am tempted to place very minimum requirements of ARM 3 and 2 megabytes of RAM, which isn't conservative. Sure, I've a few niggling complaints, but, when you look a the big picture, what we're considering here is a piece of software that can play any general MIDI file (I've not yet seen it fail on one, including poorly formed ones) reasonably fast, is very featured and configurable, never ceases to give feedback to the user, is performed without hardware and all for <i>under seven quid</i>. A bargain, or what?
<p>
Author: Michael-Dennis Biemans (michaeld@stack.nl)<br>
Status: Commercial, price 6.25 through The Datafile, for those not online, or 5 direct, by sending a five pound note (no cheques), or equivalent in your own currency, to:<br>
<address>Michael-Dennis Biemans<br>
Willem Frisostraat 20<br>
5616 BE Eindhoven<br>
The Netherlands</address><br>
for e-mail distribution<br>
Availability: Most PD libraries should have a copy of the demo version, with only 90 seconds playtime, including on PDCD4 and PDCD5<br>
</body>
</html>