Serge

Both DOTT and Hit the Road were both still made for a Roland thing 🙂 - just not MT-32, but Roland SoundCanvas (55, I believe, but Zaarin knows better). I don't think there has been a MIDI-based SCUMM game ever that was originally composed (or arranged) for SoundBlaster or Adlib. But of course, that doesn't mean people aren't allowed to prefer them. 😁

Personal aside: Annie and David were both instrumental in me getting into programming, writing not one, but three of the first books I read on the topic. A few years later I first played Maniac Mansion and Zak McKracken, and although I noticed "David Fox" in the credits, I didn't even realize the connection to those early programming books of theirs until a few years ago. 😁

Nope... iMUSE doesn't have any tempo specific hooks or markers. It's possible to change the tempo from SCUMM, but that was rarely done. All of the MIDIs (just checked) have initial tempo as standard MIDI meta events, as well as tempo changes when applicable (see fourth purple line): iMUSESequencer scan for standard MIDI system messages in all files from FOA - all of them have at least one tempo (initial or change) - labelled "set-tempo" here (excerpt): However, only the first track in an iMUSE MIDI will have an initial tempo - because none of the other tracks are independently played - they will all follow in some kind of sequence from the first track. Hence, Misty doesn't include any tempo in the split MIDI files, except for the file created from the first track - because it has no way of knowing what that initial tempo should be for the others: If the tempo changes halfway through track 1, and iMUSE then happens to jump to track 2, then the tempo of track 2 will be that changed tempo, not the initial tempo. ETA: Haven't checked FOA specifically, because I'm not that familiar with FOAs MIDIs - which ones use iMUSE heavily and which don't. But here's an example from the DOTT opening titles - DOTT uses a different version of iMUSE ("v2"), so it actually also does include initial tempo on all tracks (which Misty would then also include in the split MIDIs). But other than that, this is an example of the tempo being changed, and then conditionally jumping to track ("chunk") 6 (actually, 7 - unlike Misty, iMUSE Sequencer (and iMUSE itself) counts tracks from 0). Tracks 2-5 are used for delaying the theme when a platform is too slow at loading the graphics for the next part of the title sequence.

Even more quickly added (hour of dev), even less tested - I considered adding an option to split each MIDI file into new tracks based on channels (which we did for HighLand), but decided I don't have the time right now. 🙂 https://github.com/Jither/iMUSE-Sequencer/releases/tag/Misty-1.1.0 New "verb" is split - it also allows remapping at the same time. You can, of course, just use the output format that is built in, which will store the output files in the same folder with the same name and tracknumber appended. There's another example of a format in the examples. Beware that if you don't include "{track}" in the format, it'll generate the same name for every file, and they'll overwrite each other - a format like "{folder}/{name}.mid" will even overwrite the original file without warning. 😉 This is all very hacky development for now.

Well, what's done here (Stan's Theme) is setting up all the variations that happen for each repeat of the theme - adding instruments, removing them, transposing them, and changing them for other instruments. 🙂 Anyway, here's the first release... Like I said, it's "cooked together" - very quickly done, but seems to leave the MIDIs exactly the same, except for remapping all instrument references. https://github.com/Jither/iMUSE-Sequencer/releases/tag/Misty-1.0.0 Just decompress the .zip to a folder. The command line provides help (and examples) for each verb (two of them - one for the actual remapping, one for getting the mapping in a more readable format with instrument names). Just type misty or misty help. It then lists the verbs - you can get help for those by typing misty <verbname> help. (Also works to just type misty remap - since it will find that the required input file parameter is missing, so it will show the help for the verb - it doesn't, however, work that way for misty mapinfo - because the mapinfo verb can be called with no parameters). So, misty remap file.mid is the simplest usage, which will use the default mapping file that's included (the one you sent, but with a single changed line - which allows the mapping info "verb" to find the instrument names). You can create multiple mapping files and specify a different one with -m path-to-file or --mapping path-to-file. After remapping, it outputs to a file with the same name, in the same folder, except for replacing the extension with ".remapped.mid". (Note that it will *not* warn or prompt if the output path already exists - it will just overwrite it). You can also just specify a second file name that it should output to, rather than letting it create a default output path. ETA: Forgot: Requires .NET 8.0 runtime - https://dotnet.microsoft.com/en-us/download/dotnet/8.0 - the one named ".NET Runtime 8.0.x" will do, but you might as well install the one named ".NET Desktop Runtime 8.0.x" - just adds support for GUI apps (SCUMMRev 8, if it ever appears, will be one of those).

For now, they most likely won't be. It'll just change the instruments in the actual messages that involve instruments. Changing them to patch changes would rarely make sense anyway, since they'll often also be transposed etc. iMUSESequencer does allow dumping all the iMUSE messages, though (iMUSESequencer dump -i filename.mid😞 The numbers on the left are <bar>.<beat>.<ticks> [<seconds>] (<total ticks>). So, here you can see that it changes the instrument on track 7 to 85 at bar 13, beat 4, tick 398 - if the current hook ID (set by SCUMM) is 1. You'll also note it disables that track at the same time (hook-part-enable with state 0) - and that there are no hook-part-enable that enable it (they all have "state: 0". That's because in this case, iMUSE will disable the track based on the hook, and a command in the SCUMM script for the room will reenable the track later. iMUSE in general is a bit like untangling spaghetti of MIDI hooks and markers intertwining with SCUMM calls to determine what's actually going on - often SCUMM will do something that might as well have been done through hooks in the MIDI - and vice versa. 🙂

Looks right. Almost done (although I have done zero testing yet while writing all the code...), and for good measure I made a quick verb on the command that lists out the mapping with instrument names (if it has a "comment" about what standards are used on both sides - only support GM and MT-32 so far, though): ' ETA: Does seem to be working - at least from doing byte comparisons on input and output. It also allows inputting raw ROL chunks (and other chunks) - i.e., it just removes the LEC headers from those. Still need to test the part of the functionality where it remaps iMUSE instrument changes in addition to the standard Program Change messages. So, will probably be ready tomorrow.

Sure, I'll try and see if I can cook something together - probably won't be until in a few days, though.

Not that I know of - also, it's not a 1:1 process - MT-32 has many more variations of e.g. strings or pianos than General MIDI does. But I could probably relatively quickly do a simple command line tool that takes a MIDI input file and outputs a remapped file, based on a text list of mappings. I.e., a text list like: 1 : 5 # remap (MT-32) instrument 1 to (GM) instrument 5 2 : 4 # remap (MT-32) instrument 2 to (GM) instrument 4 3 : 3 5 : 2 ... 126 : 81 127 : 86 SCUMMRev 1 did it (it's what we used as a basis for conversion of HighLand MIDIs) - but SCUMMRev 1 hasn't existed for almost 25 years. 🙂

Yeah, that continued to be the case in later games. For example, as far as I recall, there's an organ part in the Adlib version of the DOTT opening or end credits, which isn't in the GM version (which is particularly strange, because it's not a matter of a channel missing or something - since the GM version does have the organ, just not all the notes that the organ plays). Also worth noting that iMUSE limited the number of channels that could actually be used at a time - which means even if a part is in the MIDI, it may not actually play in the game. The MT-32 iMUSE driver only allowed 8 channels (+ percussion), and the GM driver only allowed 9, even though both MT-32 and GM allowed 15 channels + percussion. Since, of course, multiple MIDIs may be playing at a time during transitions, the choice of which channels to include in the game are based on priority - each part specifies its priority at the beginning. But it also does happen that the number of channels in a single file exceeds those limits - meaning there are parts that will never play in the game. ETA: Should you need the original sound numbers (e.g. because the titles I gave them are short - for script output purposes - so you might need to compare to some other lists of FOA sounds, which are likely to be in numeric order - you can find them in the symbols file I posted in another thread - https://gist.github.com/Jither/7ed7b65fb77acc0f3cd2bd28ec4c5a9f - look for the section starting with sounds {. 😉

Here are all the sound files from the CD version of FOA ripped with SCUMM Revisited's potential successor... They all play back fine in iMUSE Sequencer sending to an MT-32, so the instruments are correct, and so are the tempo changes (those that aren't actually implemented in script through iMUSE commands, rather than MIDI). The MT-32 versions are obviously the ones named "ROL.MID". The ones without ".MID" are raw rips of the block, which include iMUSE's headers, and hence won't be read by any standard MIDI reader. The content of those headers can be found in the .txt files. https://www.dropbox.com/scl/fi/jn128u4vvb5v3ug109y4h/foa.zip?rlkey=z16uhvdzbr62ieflw73lqc49l&dl=0 (note: this file will likely be gone in a week) Note that iMUSE simply stores its "bits" as separate tracks in a single file - Standard MIDI format 2 (0 = single track, 1 = the typical multiple simultaneous tracks, 2 = multiple independent tracks). That may be the ones VGMRips has, verbatim. That's also how these MIDs are stored - they're just raw rips from the files. But then, I'm pretty sure the SCUMMRev ones were too - as far as I recall, it simply changed the format 2 bit to format 1, in order to allow it to be read by more applications. The only difference in any MIDI compliant app would be that it would interpret it as multiple tracks to be played at the same time. ETA: As for the HighLand MIDIs, their main problem in terms of orchestrating isn't that we sequenced them based on taste - it's that they're remapped to General MIDI instruments, which does not cover all the instruments available on the MT-32 - and even MT-32 timbres with the same name (say, "Clarinet") may sound very different from the typical GM instrument with the same name - or the soundfont we used as target. Of course, can't go back, since the MT-32 has three acoustic pianos, four electric pianos, three string sections, etc. - which would have been mapped to fewer GM instruments. Also, the MT-32 allowed custom timbres through sysex - which had to be mapped to some mostly fitting GM instrument. Hence, the original MT-32 MIDIs should always be the reference. The HighLand MIDIs were for easy listening on a GM/GS device. ETA2: The files that contain actual music, as opposed to sound effects, should mostly be named "-theme" (the names are from the names they get in decompiled scripts) - but I cannot guarantee that I've been 100% consistent when naming them, so some of them may be "-sound" - or "sound-xxx" (used for sounds I haven't named yet).

I'm not in SCUMM Decompiler mode at the moment, but here's its symbols for FOA as they look at the moment, in SCUMM Decompiler's symbol syntax. Still far from complete, but might have some you're missing. Do note that some (like variables and classes) will be missing, simply because this file inherits from symbol files shared between games (see the top "include" directives) - those define common variables, classes, states, verbs, etc. Also note that some of them may not actually be correct, since the first FOA symbols were gathered when the decompiler didn't have a concept of e.g. room local variables. https://gist.github.com/Jither/7ed7b65fb77acc0f3cd2bd28ec4c5a9f

A very old different attempt (end titles, though - and without most of the percussion, and some panning issues in places that I never fixed) - towards the end of this video. 🙂 Was actually thinking about getting back to it with newer samples. But I really like your arrangement so far. 🙂

Another quick example today - not 100% annotated, some scripts and verbs are still unnamed. But to show the flexibility of SCUMM, here's the "logo" room from Last Crusade. This room, like in many of the other games, also contains the boot script as well as the global scripts that handle input, default responses, global scripts for room entry/exit etc. (And yeah, the script from the intro cutscene is also there, even if it takes place in the college halls). It's these scripts that allow a game like Loom to have a completely different interface. The SCUMM sentence building interface with verbs and inventory isn't a SCUMM feature as such - it's implemented *in* SCUMM. The setup concepts in this boot script would pretty much be the same all the way up to CMI. The scripts ending in "build-sentence" are the ones that handle key presses, clicking on verbs or the rest of the screen etc. - in different contexts. The term "verb" in SCUMM has two different meanings, and both meanings are not necessarily what you'd think: In their "visual" meaning, verbs are just text or graphics on screen that can (mostly) be clicked. This means that the inventory items are also "verbs" - as are the arrows to scroll through the inventory, and the sentence line itself. And - as discussed earlier - the dialog choices. In their "non-visual" meaning, verbs are scripts that are owned by a specific game object. They may (and often do) contain scripts that respond to a specific verb used on an object ("open door"). But they can be anything relating to that object. Which is why the choice of inventory icon for objects in later games is also chosen by implementing a verb on the object. Another "verb" sets the "quick-verb" - the verb that's used when right-clicking an object. Verb scripts are also used to define the response when the actor cannot reach an object. Etc. In a way, they allow simple "object oriented programming". The important thing is that they're not restricted to being responses to open/close/talk etc. https://scumm.jither.net/?Jither/036e506282f14a7932d85808e13c7fcc Note that the boot script has a few "special" string assignments for the save/load dialog and error messages. These use string format tokens (%c etc.) that don't follow the standard SCUMM syntax of %token%. I've finally updated the syntax highlighting to support this special case. So if much of the script just displays grey text (because it thinks a string token never ends), clear your cache and reload it. 🙂

Pretty sure it's a "made up" sculpture. Douglas Crockford famously wrote that while making the NES version, they claimed to Nintendo that it was a Michelangelo. Michelangelo only made a couple of female nudes, and they got lucky, and one of them (Dawn) looks somewhat like it. If you squint your eyes and turn your head 30 degrees. And you're partially blind. According to Crockford, it was Winnick who looked through an art book to find the Michelangelo "reference". Surely Winnick would have known if it was originally based on a closer reference. 🙂 (It was still removed from the NES version).