What do you guys use to import your music compositions?

I haven't really touched a lot of this stuff for a while, but I recently started messing with it again and started running into limitations with my own approaches I've used in the past. I've relied on 2 methods for music creation, both with mixed results.

Method 1:
Furnace tracker > VGM export > vgm2smps

Issues:
•De-syncing channels
•Absolutely massive filesize

Method 2:
Furnace tracker > VGM export > vgm2mid > FL studio > Anvil Studio > mid2smps

Issues:
•Instrument patches have to be remapped after vgm2mid conversion; corresponding GYB has to be created
•Effects can easily be lost/incorrectly applied somewhere along the conversion
•Sometimes, MIDIs just flat out won't convert correctly with mid2smps (missing notes, tempo difficulties, etc)


So after considering my own methods, I was wondering what other peoples' approaches to music creation were nowadays. Is a DAW+mid2smps largely still used by most? It seems to be a bit broken in Windows 10 at least, as the MIDI input driver doesn't seem to stay installed.

 

I use method 1, it is the easiest. But the bad thing is that sometimes the psg gets out of sync and starts to bug

 

Aside from the timing issue, vgm2smps is generally pretty helpful especially with smpsopt.. though is there any way to have vgm2smps ignore the output filesize? I have quite a few tracks I've been working on which seem to gradually become incompatible with the tool the more elaborate they become.

 

what do you mean with that?

 

VGM2SMPS (and the SMPS driver, I think) haves a size limit, if your SMPS its bigger than 64kb (or 63, I forgot), it isnt going to work.

 

I didn't know that was the limit. I think the maximum I had was 61 or 62 kb and using smps optimized I managed to lower it to 52 kb.
Fun fact: If you pass a file multiple times in smps optimizer it can continue to reduce the size

 

If I shook my head as much as I'd like to after reading this entire discussion, I'd break my neck. "Doing it wrong" sounds like heaven compared to what you guys have been doing.

 

It's what you see when new people try to insert music into Sonic. The only way I know is to use deflemask, use vgm2smps and pray that the psg is not bugged. What I don't understand is, for example, marble zone from sonic 1 has a size of 1 or 2 kb, but the size exported from deflemask is like 19 or 20 kb.

 

Since it sounds like you actually know your way around a tracker (unlike people who prefer MIDI sequencers), look into ModPlugTracker (or anything else that can save modules in XM format), and then give xm3smps or xm4smps a try. There is a learning curve, and you'll need to provide your own instruments, but it will be worth it in the end.

 

Can confirm tracks converted using these methods come out with no unnecessary bulk, so clean you can easily edit them in a hex editor, and you’ll save a ton of ROM space.

 

I use Furnace to write music, and this is the method I use to get it to work with Sonic 1's sound driver. The same method can be done using Deflemask. Remember to save a backup .fur file before doing this because it will be useful for reference. It is recommended that when creating your song, you set Pitch Linearity in the Compatibility Flags window to None in order to emulate how SMPS works.

Step 1) Remove all pitch modulation and detuning. This is almost always the main source of large file sizes because this process involves converting to a VGM, which converts all modulation into individual pitch changes. I recommended removing the detune commands too because detuning by a constant in Furnace often results in frequent changes in the amount of detuning in SMPS, so it's easier to just set that up in SMPS.
Step 2) Set all PSG instruments to have a constant volume. VGMs save PSG envelopes as constant changes in volume, resulting in large file sizes. It's easier to just set the volume envelopes in SMPS.
Step 3) Set the Divider value to 1 and set the speed values to be at their lowest while keeping the same ratio between values, assuming there is more than one speed value. This will increase the maximum speed it could played at in SMPS, which may be useful for speed shoes. You may also need to multiply all the pitch and volume slides by the same number you divided the Speed values by in order for them to end at the intended value. I recommend turning down the Base Tempo value to account for this in order to listen to how the song will sound when you convert it. If the slides sound too choppy, increase the Speed values and then change all the note slide values again to compensate.
Step 4) Save a copy of the .fur file. In this copy, use the "channels" window to move the PSG data to the FM channels. VGM2SMPS has a bug where it incorrectly calculates timing at the loop point, causing the PSG to desync, so converting the PSG data as FM fixes that. In addition, now that the envelopes are removed, two subsequent notes of the same pitch will be treated as one note by the VGM format, which can get problematic for the noise channel, in which it's common to use the same pitch throughout the entire song. Keep the PSG channels in the first .fur file in tact because pitch bends will convert incorrectly when treated as FM. One last thing is that you have to pitch down the data by one octave, which can be done by changing the master tuning from 440 Hz to 220 Hz. If you don't have any instances of two notes playing the same pitch consecutively, I recommend skipping this step and just fixing the desyncing issue in SMPS.
Step 5) Convert both .fur files to VGM and run them through VGM2SMPS using a .bat file that looks something like this:

Code:

vgm2smps input.vgm output.bin -fps=Base Tempo

where "Base Tempo" is the frequency value in Furnace.
Step 6) Run the outputs through SMPSOpt a couple times until the ratios it gives you are all 100%.
Step 7) Run the outputs through SMPS2ASM. It is recommend you use a version of SMPS2ASM with your disassembly so you don't have to assemble the files separately.
Now's when you get into editing the SMPS data. If you're familiar with trackers, it should look somewhat familiar. The main thing to note is that a note will be defined by a pitch value followed by a timing value. If those two values are broken up by other commands or you see two consecutive pitch values or two consecutive timing values, then just know that the pitch or timing value that isn't explicitly set will be carried over from the previous note. If you aren't familiar, I recommend looking up the SCHG music guide. Also, use _smps2asm_inc.asm for more information on individual commands.
Step 8) Open up the ASM file containing the PSG data and use find/replace in your text editor to rename the FM channels to PSG channels. You'll also need to do some edits to change the FM-specific commands to PSG-specific commands. Copy the note data for pitch bends from the main ASM file and make sure the sections you replace have the same timing. Then, replace the PSG data in the main ASM file with the PSG data you just edited.
Step 9) Set the tempo. By default, it will be set to the fastest tempo. I usually just do this using trial and error.
Step 10) Now add back the setting of volume envelopes, modulation, and detuning. Sometimes there may be detuning values already there. If they are very small values (such as $01, $00, $FF) and they aren't part of an existing pitch bend, you should remove those before adding your own detune commands. If you have a noise channel, you'll have to add in the command that makes it a noise channel.

This can be a long and tedious process depending on the complexity of the song, but I think it's rewarding because it gets you a perfect and ROM space-friendly result without having to pretty much recreate everything in a separate program.

 

I'm aware the sound driver has a hard limit in terms of size for music data, but what I meant was kinda really counterintuitive, now that I think about it. Basically, I was wondering if there's anyway to have vgm2smps ignore the size limit and output a binary anyways, so optimization could be attempted via smpsopt. This probably wouldn't actually work how I think it would.

I used to do something like this in the past; I would create samples from FM patches I intended to use. While this isn't a terrible method, a major downside to this approach IMO is that you won't hear an accurate representation of your composition until the conversion process is finished. I also seem to remember one of these programs crashing quite a bit, and I would frequently have to reconfigure everything(?)

Working with MIDI piano roll interface is a bit tedious for me, but one thing I really like about the mid2smps driver for Windows is the fact that it does let you hear your music in realtime. Is there any way this driver could be used as an output device for OpenMPT, or could another FM emulation plugin be used? Something that could give me a more accurate preview of my work while I'm editing.

That sounds kind of scary lol. I've never really understood how to use smps2asm. Like, is it a complete replacement for the sound driver, or is it a tool that lets you convert music data between ASM and binary formats?

 

It's just a set of macros that allow you to use the ASM format to plot out the data for an SMPS track. It's more legible and easier to understand how a track works, easier to directly modify, and pointers are automatically calculated on build.