The MMAS & QSA Message Board

I've created an initial Rosegarden studio definition for the Roland CM-64 with a separate fully-contained device for each PCM memory card permutation (Edited 2019-02-01 - Corrected SN-U110-02 Keymappings now that I own one and noticed missing percussion elements): There's an undocumented SysEx command that was discovered by Cloudschatze in 2009 on the archive.org mirror of queststudios (https://web.archive.org/web/20140910135 ... 30286.html) that sets overflow assign on the CM-64 which I, luckily, stumbled upon recently! Cloudschatze's discovery was quite amazing, but would probably be more useful to me if I had a CM-32L or another CM-64. I don't think the MT-32 and CM-64 really work together that well. Or, perhaps I need to assign a '1' to each device, enabling it on both? Either that, or I have to send all instrument programming SysEx to each sound module prior to connecting to an OUT port for overflow. Too many questions, I really need to do more tests sometime...

Anyway, I also noticed in the Dr. T manual that the MT-32 modifies the patch bank to use memory patches since it's already allocated all 128 program change numbers to the built-in patches. This, along with my realization that one of the CM-64's cards (SN-U110-07 - Electric Guitar) can't be used with all of its patches (due to overrunning the 128 program limit), got me wondering if there exists SysEx to use higher numbered card patches in the CM-32P/CM-64. It probably is documented in the CM-64's (or CM-32P's) manual, but I have yet to gain much of a grasp on the address maps there.

If anyone has considered this before, please let me know.

Thanks,

Lucas

After posing my question, I began investigation of a way to use the extra SN-U110-07 sounds with the CM-64 (although this applies to the CM-32P as well, I should think). I turned to Dr.T's MT-32 Editor/Librarian and captured some of its SysEx while programming patches to the temporary area. Then I compared it to the relevant SysEx section in the MT-32 manual, and later looked for similar PCM SysEx in the CM-64 manual. I cobbled this together from it, which worked in programming the CM-64's channel 11 to guitar harmonics with the SN-U110-07 card plugged in:
So, amazingly, my first attempt had worked (guitar harmonics was a good choice to make it extra obvious), and I decided to move on to another, more versatile, method: mapping the 7 unusable SN-U110-07 patches to PC#11-17 (previously "A.GUITAR 1" to "SLAP 4") in the CM-64's (PCM) patch memory. That way panning, volume, etc. can be set separately using standard controllers and any combination of CM-64/CM-32P PCM channels (11-16) can be assigned to the card's patches. It took me a while notice in the CM-64 manual, that addressing is 7-bit, but realizing that made it easier. Another main goal I was focused on was in being able to revert any patch mapping painlessly, and programatically, without resorting to the reset command (which resets the entire sound module, turns all notes off, etc.). Here's how I attempted to decode the SysEx commands:

F0 41 10 16 12 {base address} 01 {tone number} 0C 32 06 00 7F 00 01 0F 40 40 40 07 07 00 07 0F 00 {checksum} F7
01 == tone media (0..1==internal,card)
{tone number} (0..127==1 to 128, Electric Guitar card unusable 64 to 70 normally==0x40,0x41,0x42,0x43,0x44,0x45,0x46)
0C == key shift of 0 (0..24==-12 to 12, 12(0x0C)==0)
32 == fine tune of 0 (0..100==-50 to 50, 50(0x32)==0)
06 == bender range of 6 (0..12, 6==CENTER)
00 == key range lower (0..127==c1 to g9, 0==c1)
7F == key range upper (0..127==c1 to g9, 127(0x7F)==g9)
00 == assign mode (0..3==poly1,poly2,poly3,poly4, "assn mode" is defined in Dr.T's manual on page 66 and on page 45 all shown are 1 (0))
01 == reverb switch to on (0..1==off,on, 1==on)
0F == velocity sensitivity (0..15, 15(0x0F)=MAX)
40 == envelope attack rate of 64 (0..127, 64(0x40)==MID)
40 == envelope release rate of 64 (0..127, 64(0x40)==MID)
40 == lfo rate of 64 (0..127, 64(0x40)==MID)
07 == lfo auto delay time (0..15, 7==MID)
07 == lfo auto rise time (0..15, 7==MID)
00 == lfo auto depth (0..15, 0==MIN)
07 == lfo max rise time (0..15, 7==MID)
0F == lfo max depth (0..15, 15(0x0F)==MAX)
00,32 == detune depth (0..50, 25(0x19)==MID, Use the instrument definition?: If "DETUNE" then==50 (0x32), else==0). All the card patches need 0, see the CM-64 manual, page 32 (internal PCM sounds) to derive the reset DETUNE or not values. I think this "DETUNE or not" guess was incorrect in practice, but maybe not. It could have just been envelope or lfo settings.

But I just couldn't seem to get the reset commands to return to the exact same sound. That is, until I discovered that page 32 of the CM-64 manual gives an "Internal Tone list" that differs in numbering from the PC#, and also that if I sent less bytes (like, stopping at velocity sensitivity) I didn't have to guess at values for the envelopes, etc. when rewriting the original patches. Of course, there could be differences in the patches depending on the PC# they're mapped to because of the trailing values left behind, but I've only tried them at these PC#s, and the SN-U110-07 patches sound correct to me there. It's also noteworthy that any SysEx command that changes a PC# mapping, must be followed by a program change message (to the PC#) before the patch will actually be loaded and may be heard.

These are what I finally came up with: Sets pc#11 to <program id="128" name="DSG FB 7 (2Ptl) (Forte &amp; Feedback (Harmonics, Slow))"/> Sets pc#12 to <program id="129" name="DSG FB 8 (2Ptl) (Forte &amp; Feedback (Fundamental, Slow))"/> Sets pc#13 to <program id="130" name="DSG FB 9 (2Ptl) (Forte &amp; Feedback (2nd Harmonics, Slow))"/> Sets pc#14 to <program id="131" name="DSG FB 10 (2Ptl) (Forte &amp; Feedback (3rd Harmonics, Slow))"/> Sets pc#15 to <program id="132" name="DSG FB 11 (2Ptl) (Forte &amp; Feedback (4th Harmonics, Slow))"/> Sets pc#16 to <program id="133" name="DSG FB 12 (2Ptl) (Forte &amp; Feedback (5th Harmonics, Slow))"/> Sets pc#17 to <program id="134" name="PICKING HM (1Ptl) (Picking Harmonics)"/>

All Concatenated:
And to revert them: Sets pc#11 back to default 16==15==0x0F <program id="10" name="A.GUITAR 1 (1Ptl)"/> Sets pc#12 back to default 18==17==0x11 <program id="11" name="A.GUITAR 3 (2Ptl)"/> Sets pc#13 back to default 19==18==0x12 <program id="12" name="A.GUITAR 4 (2Ptl) (&amp; -1 octave)"/> Sets pc#14 back to default 21==20==0x14 <program id="13" name="E.GUITAR 1 (1Ptl) (Mute/Non-mute)"/> Sets pc#15 back to default 22==21==0x15 <program id="14" name="E.GUITAR 2 (1Ptl) (Mute)"/> Sets pc#16 back to default 27==26==0x1A <program id="15" name="SLAP 3 (1Ptl) (Thump/pull, H>F#4)"/> Sets pc#17 back to default 28==27==0x1B <program id="16" name="SLAP 4 (2Ptl) (Thump/pull, H>F#4)"/>

All Concatenated:
Figuring that out felt great, but then I'd noticed (on page 32 of the CM-64 manual) that there are more internal PCM sounds than the 64 mapped to PC#s, so I decided to hear each of them at PC#17 (SLAP 4) and came up with these to perform my tests:
0x05 A. Piano 6 (DETUNE) 0x07 A. Piano 8 (DETUNE) 0x0B E. Piano 2 (SINGLE) 0x0D E. Piano 4 (SINGLE) 0x10 A. Guitar 2 (DETUNE) 0x14 A. Guitar 5 (V-SW) 0x16 E. Guitar 3 (SINGLE) 0x17 E. Guitar 4 (DETUNE) 0x18 Slap 1 (SINGLE) 0x19 Slap 2 (DETUNE) 0x1E Slap 7 (SINGLE) 0x1F Slap 8 (DETUNE) 0x29 Fretless 2 (DETUNE) 0x33 E. Organ 1 (SINGLE) 0x35 E. Organ 3 (SINGLE) (Just like Old Time Radio Shows!) 0x37 E. Organ 5 (SINGLE) 0x39 E. Organ 7 (SINGLE) (Not working, still sounds like a slap bass; I suspect the 0x80 checksum is the cause) 0x39 E. Organ 7 (SINGLE) (Try 2: Extended it so not a 0x80 checksum. It worked!) 0x41 Soft Tp 2 (DETUNE) 0x4C Sax 4 (DETUNE)



I also wrote a non-graphical GNU/Linux program that I used to perform the checksum calculations, but it has some UI bugs I want to fix before releasing it.


Finally, I'm delighted to report, probably to nobody's surprise, that the MT-32 in overflow mode, communicates perfectly with the CM-64. First, I tried loading a custom SysEx patch with the CM-64's IN port connected to the MT-32's OUT port, moved the CM-64's input to the MT-32's THRU, and played that patch, verifying that each sound module had been programmed properly. That's proof that SysEx is passed through the MT-32's OUT port when it's got "Overflow Assign" enabled. Next, I tested a file I've long suspected to run out of partials: EOX Studios' "CM-32L song" (downloadable in the description at https://www.youtube.com/watch?v=xg_F7Zy_ygg). And monitoring just the CM-64's output, separately with an audio level meter, I could see certain partials being played through it, while the MT-32 played all the rest! Finally, it sounded like no notes were being dropped while the sound modules were mixed and set to the same audio volume. These tests passed, and should suffice, but so far I've been too lazy to create a real test file that would purposefully overflow partials while using all custom SysEx patches. Anyway, Rhizome's "Reply #38 on: August 09, 2009, 08:00:49 AM" (again at https://web.archive.org/web/20140910135 ... 30286.html), assuming that TFX uploads custom patches, implies that they work in "Overflow Assign" too. I haven't tested making the CM-64 the overflowing module with the SysEx there from Cloudschatze yet either, but am confident it will work in the same way. The only reason I can think of for previously believing that the MT-32 and CM-64 were incompatible with "Overflow Assign", is that I may have been under the misapprehension that it applied to channel overflow (mysteriously remapping all channels above 10 to the second sound module).

Whew, sorry that's such a mountain of text. Enjoy!

Recently I noticed that Munt 2.3 adds a configuration option to set the number of partials! After trying it out with success, I was curious about how many partials generally overflow in the real hardware. To get meaningful output, I decided to put the CM-64 into overflow assign mode with the unofficial Cloudschatze SysEx and used the MT-32 as the overflowed-to module with its display (beyond the flashing "MIDI MESSAGE" LED of the CM-64 with it as the overflowed-to module). Only then did I notice the bug in this unofficial (perhaps for this reason) overflow mode... The last NewRisingSUn post (on the archive.org page linked to in my first post) described and solved it beautifully, though. Being on GNU/Linux I had to look for a compatible MIDI message mangler, and I chose QMidiRoute as I'd used it for other things. Now, it didn't have a filter type for "Note Off" messages, so I edited its source code and came up with a patch (and filter configuration file) that works nicely for this purpose. I've just finished submitting the patch to the developers, so I hope the functionality will be added eventually for everyone. Then I added this functionality to my custom MIDI device which works regardless of OS and I hope to release someday to the community.

Anyway, the MT-32 displays what are probably controller, pitch bend and SysEx messages on its "MIDI MESSAGE" LED (just like the CM-64), and parts are always set (and likewise custom patches are shown when loaded) and sometimes play (as you're used to seeing normally when it's the only or the overflowed-from module) by the part number(s) becoming a solid box. It does seem that a fair amount of compositions for the MT-32 do overflow partials at least somewhat. With Munt configured for 64 partials, I've seen it run out, but it gets too slow on the computer I compiled it on to test that out without stuttering. If I ever get another module in this family, I'll have to try three-module overflow, but I don't actually hear dropouts with the two I have. It's not surprising, but putting it in overflow assign mode, and sending both modules the MTGM SysEx reveals that much more partial overflows arise when General MIDI compositions are played, as they weren't being designed around these devices.

It is truly a joy to hear no dropouts (& sometimes a more full sound) on the sierra soundtracks I've become fond of. Of course, they're great either way. Thanks to Tom for capturing them (as I'm not too good at the games yet )!

I'm attaching the Overflow Assign enable and disable MIDI files I created from the SysEx described by Cloudschatze, and the fix described by NewRisingSun in the form of my QMidiRoute patch (I used debian's source for version 0.4.0, but it may apply to others) and configuration (.qmr) file:

I'd love to hear some samples, if you can share.
I still have my trusty old CM-64 connected. I've actually recorded a CM-64 version of the Leisure Suit Larry 3 soundtrack using both LA and PCM parts of the module (including several tracks with added SN-U110 expansion cards). I also have the midi files at hand if anyone's interested.

Ari wrote: ↑Thu Jan 30, 2020 2:14 am I'd love to hear some samples, if you can share.
I still have my trusty old CM-64 connected. I've actually recorded a CM-64 version of the Leisure Suit Larry 3 soundtrack using both LA and PCM parts of the module (including several tracks with added SN-U110 expansion cards). I also have the midi files at hand if anyone's interested.

You'll have to wait a bit longer, but I'm now in the process of recording some soundtrack samples for you. I keep thinking of more that would be nice (with varying overflow assign necessity), so I'm recording a bit too many. On a mostly unrelated note, because I've been experiencing digital overflow volume clipping from the CM-{64,32L} even with the MT-32 first in line (from some of the older Sierra games of course), I just decided to buy another MT-32 (old). I'm skipping the worst-clipping tracks for now. Back on topic, if you have any requests, preferably already sequenced by Tom or others, I will try to oblige.

Yes, I'd love to hear your CM-64 Leisure Suit Larry 3 tracks! Hopefully I'll have the right SN-U110 cards. So far, I've got Latin & F.X. Percussions, Ethnic, Electric Guitar, Synthesizer, and Rock Drums.

Thanks!

Ari wrote: ↑Thu Jan 30, 2020 2:14 am I'd love to hear some samples, if you can share.
I still have my trusty old CM-64 connected. I've actually recorded a CM-64 version of the Leisure Suit Larry 3 soundtrack using both LA and PCM parts of the module (including several tracks with added SN-U110 expansion cards). I also have the midi files at hand if anyone's interested.

At (not so) long last, here are the samples I promised:
https://drive.google.com/open?id=1x6sla ... f7yq1jNTlP

And a long description to get the discussion going:

SQ1MT-Soundtrack (MT-32->CM-64->CM-32L): The initial music on this one is what comes to my mind first when thinking of overflowing partials. Although the fanfare of most games is likely to overflow partials, this one uses lots more. I had the MT-32 (old) first (then the CM-64->CM-32L) to try to get the "Space Alvin" on it, so it would sound correct. Since the soundtrack doesn't program the sounds fully, I pre-loaded the SysEx bundled with the individual songs. Even with the MT-32 first, the CM-64 exhibits some minor digital volume overflow in this one.

LSL3MT-Soundtrack (CM-64->CM-32L->MT-32): I hadn't listened to this often before I had overflow assign, but you mentioned it so maybe you'll hear extra partials.

LSL5MT-Soundtrack (CM-64->CM-32L->MT-32): Just great music. This version is not modified, so it doesn't play some of the CM-* sound effects. As mentioned in its own topic, the game loaded the MT-32 defaults, essentially muting some CM-* effects.

KQ5MT-Soundtrack (CM-64->CM-32L->MT-32): Some more favorable songs here too, with probably moderate partial overflow, but I don't remember locations.

SQ3MT-Soundtrack (MT-32->CM-64->CM-32L): One of my favorites but it doesn't overflow partials as much as SQ1.

RobinMT-Soundtrack (MT-32->CM-64->CM-32L): An obvious choice as this one you can hear dropped notes on the guitar throughout. On my first recording attempt, I noticed the CM-* gunshot sound effect (along with some others), near the end. To mitigate it, I moved the MT-32 first, and played the LSL5 SysEx before this. Next, I played the initial SysEx for Robin's individual files, since the full soundtrack doesn't program them fully. Something of note about this file, is that it causes digital volume overflow, on the MT-32 itself, in a couple tracks! I didn't want to duck the volume for these reference recordings, though. - Edit 2/09/2020: Actually, on subsequent plays I realized it's just a purposeful "Crackles" sound that I mistook for the clicks heard when digital volume clipping.

CNIMT-Soundtrack (MT-32->CM-64->CM-32L): Another obvious partial overflowing title. It's doubtful that this game needed the MT-32 first, but I was lazy enough to leave it that way at the time. At about this point I began to default to loading the SysEx from the individual songs before each soundtrack, just in case some sounds aren't fully programmed by the soundtrack.

Eco-Singles-Together (MT-32->CM-64->CM-32L): One of my favorites (though I can't remember if it overflows many partials), so I just had to create a playlist of the individual song tracks and combine them here. That should be close enough to a soundtrack without replaying the whole game while capturing the MIDI. To make sure trailing notes aren't cut off abruptly, I used my 2-seconds-nothing-and-then-gs-reset.mid file between songs (since of course GS isn't recognized by these modules, it provides only the 2 second gap). Also to be sure no sounds are left unprogrammed, I loaded the initial SysEx before each song.

HOC-Singles-Together (MT-32->CM-64->CM-32L): One of my favorites, again combined into a pseudo soundtrack. This one definitely overflows partials in places, although you don't notice so much since it's not dropping notes, but its full sound requires more. It has two initial SysEx files, and I used HOC-000-Initial-SysEx.mid for all but HOC_7.mid & HOC_8.mid. That's just how I've had my playlist setup since the beginning, and I must have done it that way for a reason.

WillyMT-Soundtrack (CM-64->CM-32L->MT-32): It probably doesn't partial overflow often (it did in the last one-third somewhere for sure), but I don't listen to it enough to recognize a difference.

SilpMT-Soundtrack (CM-64->CM-32L->MT-32): I like it a lot, but think the sounds used and layering is simple enough to not really overflow partials that much, if at all.

Zel-Singles-Together (CM-64->CM-32L->MT-32): Another I like enough to cobble together a pseudo soundtrack for. I remember it overflowing partials throughout, but I'm not sure it's that audible. You can be the judge of that.

Gateway-Start (CM-64->CM-32L->MT-32): A diversion from my plan to keep this easy. Since discovering Gateway, I've liked the opening sequence and "Your Quarters" music (likely more, but I haven't gotten too far in the game yet). I decided to capture those parts as a standard MIDI format file to include it. Partial overflow probably only happens partially.

Beneath-a-Steel-Sky-Elevated (CM-64->CM-32L-MT-32): Since I was doing extra work, I decided to capture one song from Beneath a Steel Sky that I get stuck in my head from time to time: just after going up the elevator. I don't remember it overflowing partials, though.

TFX-Short-Play (CM-64->CM-32L->MT-32): I had read about this in a post by Rhizome in that same CM-* overflow assign discovery thread on queststudios (https://web.archive.org/web/20140910135 ... 30286.html). Shortly after that, I bought the game, but I still don't want to learn those controls. The music makes the MT-32's display inscrutable due to the fast instrument changes, but yes it does sound quite good with overflow assign working. I had to pre-load the first song's initial SysEx file through my custom SysEx delaying device so the MT-32 sounds right. Luckily (since later songs' sounds are messed with by SysEx delays) the MT-32 doesn't seem to be used much after that.

TFX-Reprimand (CM-64->CM-32L->MT-32): A song that played while I was being scolded for the destruction of my aircraft. It overflows partials all the way through to the MT-32 (which sounds fine without SysEx delays on this song). I wasn't able to separate the SysEx properly for it, so I'm providing a song-only MIDI file, in addition to a capture with a rushed startup sequence and then this song.

Now I'm unsure which, but for certain tracks (that likely aren't full soundtracks), I used mt-32-cm-32l-cm-64_master-volume-48-only.mid to tame possible digital volume clipping, so I'm including it again too.

It's a lot of data, so I chose not to archive the .ogg files, giving you the option to save bandwidth by only downloading what you're interested in.

Thanks,

Lucas

jaffa225man wrote: ↑Sun Feb 02, 2020 5:01 pm

Ari wrote: ↑Thu Jan 30, 2020 2:14 am I'd love to hear some samples, if you can share.
I still have my trusty old CM-64 connected. I've actually recorded a CM-64 version of the Leisure Suit Larry 3 soundtrack using both LA and PCM parts of the module (including several tracks with added SN-U110 expansion cards). I also have the midi files at hand if anyone's interested.

You'll have to wait a bit longer, but I'm now in the process of recording some soundtrack samples for you. I keep thinking of more that would be nice (with varying overflow assign necessity), so I'm recording a bit too many. On a mostly unrelated note, because I've been experiencing digital overflow volume clipping from the CM-{64,32L} even with the MT-32 first in line (from some of the older Sierra games of course), I just decided to buy another MT-32 (old). I'm skipping the worst-clipping tracks for now. Back on topic, if you have any requests, preferably already sequenced by Tom or others, I will try to oblige.

Yes, I'd love to hear your CM-64 Leisure Suit Larry 3 tracks! Hopefully I'll have the right SN-U110 cards. So far, I've got Latin & F.X. Percussions, Ethnic, Electric Guitar, Synthesizer, and Rock Drums.

Thanks!

I have the exciting news that my second MT-32 (old) arrived today, with a bit of a surprise. I hadn't anticipated it at all, but this will allow tinkering beyond that of MT-32 (old) digital volume clipping avoidance I wanted it for. It turns out to be a RWI-modded MT-32 (old)! And it appears that it has the optional four reverb ports (a reverb send and standard reverb out for each channel) in the back and Robin's third firmware revision (diagnosed by reading his notes and testing for the errors in the first two revisions). It still reports itself as having firmware version 1.07 with the 4 + RHYTHM + MASTER VOLUME buttons held down on startup, though, which makes me very happy. I'm thinking that it should still be fine as an overflow-assigned/assigning MT-32 (old) reference, if I mix the left and right Reverb Out ports with the standard L & R Output ports. Of course, if I'm understanding the mod notes correctly, it should no longer have the digital volume overflow bug at all! Sorry, I'm so giddy. This was a real surprise as there was no picture of the back, so I only asked the seller if it had the Phones port, and they reported it didn't, but that a later model would have one. I obviously wasn't hoping for the later model anyway, so I bought it. The battery even seems to work still!

Thanks a lot, man!
Sorry for the delay in response. I didn't get any notifications to my email, and kinda forgot to come back...

Anyway, great work! I already downloaded most of the stuff.
Also, I'm at home for the next week due to quarantine over the Corona virus (I'm not sick, just as a precautionary measure ), so I have some time to use my CM-64.
BTW, I've tried loading the MIDI files, and at least with the Eco Quest MIDIs, there seems to be something off with the sound. I'm wondering if it's something I'm doing wrong.

Anyway, I'll try uploading at least part of the LSL3 soundtrack this week. I still haven't recorded all of it to digital.

Yeah, so apparently I had the first 2/3s of the soundtrack already recorded and converted to FLAC.
I've uploaded them to my Google Drive here: https://drive.google.com/open?id=1UIPEp ... fVh4bk-pj1
I'll try and get the last part recorded ASAP.

Enjoy!

Ari wrote: ↑Mon Mar 09, 2020 8:42 am Thanks a lot, man!
Sorry for the delay in response. I didn't get any notifications to my email, and kinda forgot to come back...

Anyway, great work! I already downloaded most of the stuff.
Also, I'm at home for the next week due to quarantine over the Corona virus (I'm not sick, just as a precautionary measure ), so I have some time to use my CM-64.
BTW, I've tried loading the MIDI files, and at least with the Eco Quest MIDIs, there seems to be something off with the sound. I'm wondering if it's something I'm doing wrong.

Anyway, I'll try uploading at least part of the LSL3 soundtrack this week. I still haven't recorded all of it to digital.

You're welcome! I'm glad you're free to enjoy yourself and that it's just precautionary. Assuming my recording of Eco Quest sounds accurate to you (I have the game but haven't played it for a couple years), it's probably something to do with the SysEx, as usual. This is obvious, but if something else was played before Eco Quest, it would be a good idea to switch the CM-64 off temporarily to reset it. Also be sure that your player isn't sending an MT-32 reset between each song. Similarly, if the mt-32-reset.mid file I uploaded previously (but not as part of this set) is played anytime after ECO-000-Initial-SysEx.mid, it would mess up the programming. After ECO-000-Initial-SysEx.mid, I would have played mt-32-cm-32l-cm-64_master-volume-48-only.mid just in case. It turns out, though, that the Eco Quest files include embedded SysEx modifying the master volume (as many songs do) to 100, so it's great that they don't cause digital volume overflow on the CM-64 and CM-32L in this case. Now, each song file should be played. This doesn't matter for the CM-64, but I usually insert 2-seconds-nothing-and-then-gs-reset.mid between SysEx-containing MIDI files since I have the MT-32 (old) which could "Exc. Buffer overflow" otherwise. Listening to it now, I probably wouldn't have needed to resend the ECO-000-Initial-SysEx.mid between each Eco Quest song, but as I did, I also used the 2-seconds-nothing-and-then-gs-reset.mid between it and the start of the next song because it's common for songs to have their own initial SysEx embedded which would, again "Exc. Buffer overflow" the MT-32 (old).

Ari wrote: ↑Mon Mar 09, 2020 8:58 am Yeah, so apparently I had the first 2/3s of the soundtrack already recorded and converted to FLAC.
I've uploaded them to my Google Drive here: https://drive.google.com/open?id=1UIPEp ... fVh4bk-pj1
I'll try and get the last part recorded ASAP.

Enjoy!

Thanks! I haven't listened long, but I can already tell the piano is an improvement in your version.