▲

[CaitSith2]

Would it be possible to allow for a single soundfont file to be loaded automatically if present in the same directory as the midi files.         (This would be handy, for cases where a good set of midi files in one directory require a specific soundfont, besides the default loaded creative one, and that specific soundfont is common to all of the midi files.)

[raina]

I believe this already works for MIDI files and SoundFonts with the same file name. But yeah, it's not exactly the same and would require duplicates of the SF.

[Ian @ un4seen]

I'm not sure loading any old SF2 that's in the same directory would be a good idea, as you'd have to be careful about where you keep your MIDI files to avoid using an unwanted SF2. But here's an update to try, with a "partial matches" option...

   www.un4seen.com/stuff/xmp-midi.dll

For example, if you have "blah.sf2", any MIDI file (in the same directory) starting with "blah" will use it.

[Knurek]

I'm not sure loading any old SF2 that's in the same directory would be a good idea, as you'd have to be careful about where you keep your MIDI files to avoid using an unwanted SF2. But here's an update to try, with a "partial matches" option...

   www.un4seen.com/stuff/xmp-midi.dll

For example, if you have "blah.sf2", any MIDI file (in the same directory) starting with "blah" will use it.

Works like a charm, thank you for that (I do have a feeling that I know what CaitSith2's had in mind with his request ).

I take it that native DLS support is rather out of the question, considering the fileformat (at least for the level 2 specs) isn't free?

[CaitSith2]

Not working for me at all.

[Knurek]

Not working for me at all.

It's disabled at default, most probably you need to enable it in the plugin configuration.

[CaitSith2]

Found something strange.  If the directory name is "blah something", and you have a sound font named "blah.sf2" in the directory containing the "blah something" directory,  All midis within that directory use that sound font, provided there is no overriding soundfont for the midi in that directory.  Was this intentional?  Kind of handy if it is.  (I came across this by accident, from not deleting a soundfont named "ma.sf2",  when I was trying to create a specific "BGM.sf2" in a directory contained within "magical starsign".)

(This should actually apply for full matches as well.  If directory is named "blah", and the sound font in the directory containing it is "blah.sf2",  then it should be considered an exact match in this case, rather than a partial match.)

[Ian @ un4seen]

Found something strange.  If the directory name is "blah something", and you have a sound font named "blah.sf2" in the directory containing the "blah something" directory,  All midis within that directory use that sound font, provided there is no overriding soundfont for the midi in that directory.  Was this intentional?

Nope, that wasn't intentional - it's a bug

[CaitSith2]

Here is an example of the "bug" being utilized.  http://ds.caitsith2.net/Club%20House%20Games.7z (Several mid sets, each in their own directories, and accessing a soundfont named the same as the directory.

[Ian @ un4seen]

Here's a fixed version...

   www.un4seen.com/stuff/xmp-midi.dll

I left in the ability to have an SF2 file of the same name as the directory containg the MIDI, but stopped it regressing any further than that.

Btw, I noticed that your example files are pretty slow to load, due to it being a solid archive. So I've tweaked that a bit, and here's an updated 7-Zip plugin to try...

   www.un4seen.com/stuff/xmp-7z.dll

[Knurek]

Btw, I noticed that your example files are pretty slow to load, due to it being a solid archive. So I've tweaked that a bit, and here's an updated 7-Zip plugin to try...

   www.un4seen.com/stuff/xmp-7z.dll

Works much, much faster, thank you. What's with the speed increase, do you unpack the whole archive at once and keep the files in the temp folder/RAM or something?

BTW, I've found a bug with MIDI looping. Here's an example:

www.snesmusic.org/hoot/midiloop.rar

ToT.mid has the looping section doubled in the MIDI file, so you can check how the loop switching should sound.

ToT-DNloop.mid uses Duke Nukem's format loop markers (0x74 and 0x75 I believe). XMPlay doesn't detect that now.

ToT-FF7loop.mid uses FF7 PC loop markers (loopStart, loopEnd). While XMPlay does detect the loop in this file, the loop switch isn't seamless. Not sure if it's xmp-midi or the file itself to blame (but if the MIDI is to blame, then the doubled file should exhibit the same behaviour, right?).

Also, the file doesn't fade-out at the end, would be nice if looped MIDIs would fade as MODs do.

[Ian @ un4seen]

Btw, I noticed that your example files are pretty slow to load, due to it being a solid archive. So I've tweaked that a bit, and here's an updated 7-Zip plugin to try...

   www.un4seen.com/stuff/xmp-7z.dll

Works much, much faster, thank you. What's with the speed increase, do you unpack the whole archive at once and keep the files in the temp folder/RAM or something?

Yep, solid archives are unpacked to memory, and then automatically freed when not accessed for a while.

ToT-DNloop.mid uses Duke Nukem's format loop markers (0x74 and 0x75 I believe). XMPlay doesn't detect that now.

There doesn't appear to be any markers (or other special meta-events) in this file. Do you have any details of the looping system used, eg. what's 0x74 and 0x75?

ToT-FF7loop.mid uses FF7 PC loop markers (loopStart, loopEnd). While XMPlay does detect the loop in this file, the loop switch isn't seamless.

Oops! When the loop position is the start of the file, it was skipping past any notes on the first tick. Should be sorted now...

   www.un4seen.com/stuff/xmp-midi.dll

Also, the file doesn't fade-out at the end, would be nice if looped MIDIs would fade as MODs do.

That's strange, fading seems to have been disabled for anything but MODs. I'm not sure exactly when/why that happened, but here's an update to try...

   www.un4seen.com/stuff/xmplay.exe

[Knurek]

Yep, solid archives are unpacked to memory, and then automatically freed when not accessed for a while.

I just hope it won't bug out with a 512 MB solid archive on a 512 MB system.

There doesn't appear to be any markers (or other special meta-events) in this file. Do you have any details of the looping system used, eg. what's 0x74 and 0x75?

I can only paste you the sourcecode of the converting program (both FF7 and Duke Nukem loops inserting). Hope that helps.

  case 1:
       if(!loopPointUsed)
      {
      smfInsertControl(smf, sseq2mid->track[trackIndex].offsetToAbsTime[offsetToJump], midiCh, midiCh, 0x74, 0);
      smfInsertControl(smf, absTime, midiCh, midiCh, 0x75, 0);
      loopPointUsed = true;
      }
      loopCount = 0;
      break;

  case 2:
       if(!loopPointUsed)
      {
      smfInsertMetaEvent(smf, sseq2mid->track[trackIndex].offsetToAbsTime[offsetToJump], midiCh, 6, "loopStart", 9);
      smfInsertMetaEvent(smf, absTime, midiCh, 6, "loopEnd", 7);
      loopPointUsed = true;
      }
      loopCount = 0;
      break;

The loopchanges work quite fine, thank you! Now to reprocess all those midi files... Argh...

[CaitSith2]

ToT-FF7loop.mid uses FF7 PC loop markers (loopStart, loopEnd). While XMPlay does detect the loop in this file, the loop switch isn't seamless.

Oops! When the loop position is the start of the file, it was skipping past any notes on the first tick. Should be sorted now...

   www.un4seen.com/stuff/xmp-midi.dll

Seems the loop point code is still incomplete.  When it hits the "loopEnd" marker,  it should go back to the "loopStart" marker, rather than play past the "loopEnd" marker.  For an example of a midi with the "loopEnd" marker, in the middle of data beyond the marker, look at http://ds.caitsith2.net/magical%20starsign.rar.

[Ian @ un4seen]

Yep, solid archives are unpacked to memory, and then automatically freed when not accessed for a while.

I just hope it won't bug out with a 512 MB solid archive on a 512 MB system.

If people want to use solid archives and still open/play individual files from them, they gotta face the consequences

I can only paste you the sourcecode of the converting program (both FF7 and Duke Nukem loops inserting). Hope that helps.

I see, it's using a controller rather than a meta-event. Here's an update to try...

   www.un4seen.com/stuff/xmp-midi.dll

Seems the loop point code is still incomplete.  When it hits the "loopEnd" marker,  it should go back to the "loopStart" marker, rather than play past the "loopEnd" marker.  For an example of a midi with the "loopEnd" marker, in the middle of data beyond the marker, look at http://ds.caitsith2.net/magical%20starsign.rar.

Yep, "loopEnd" markers were ignored as it assumed they would just be at the end, but the update above includes an option to use the loop end point.

[CaitSith2]

Seems I found that most video game system music formats do not have the limitation of midi/module formats.   Specifically,  that limitation is that all tracks in the formats have to be the same length.

More or less,  I have encountered several games that use varied track lengths.  (In one case, Track 0 is 30 seconds, Track 1, 34 seconds, Track 2 & 3, 40 seconds. (These tracks loop at those lengths)).  Unfortunately, midi loops at Track 0s loop length, cutting Track 1-3 short, and repeating them early.

I truely wished there were a PC side format that I could convert to, that did not suffer this limitation.

[Knurek]

More or less,  I have encountered several games that use varied track lengths.  (In one case, Track 0 is 30 seconds, Track 1, 34 seconds, Track 2 & 3, 40 seconds. (These tracks loop at those lengths)).  Unfortunately, midi loops at Track 0s loop length, cutting Track 1-3 short, and repeating them early.

Wouldn't it be possible to fill all tracks shorter than the longest one to it's length? I mean, it still sounds like something doable to me...

[Torkell]

A better approach would be to extend all tracks until the loop points meet. E.g. if you have track 1 is 40 seconds long and track 2 is 30 seconds, then create a file with track 1 repeated three times and track 2 four times to give a total length of 120 seconds.

'course, this isn't particularly optimal for non-simple ratios (as in CatSith2's example).


Edit: eek, when did I pass 1000 posts?

[Knurek]

A better approach would be to extend all tracks until the loop points meet. E.g. if you have track 1 is 40 seconds long and track 2 is 30 seconds, then create a file with track 1 repeated three times and track 2 four times to give a total length of 120 seconds.

That's what I had in mind actually.

Edit: eek, when did I pass 1000 posts?

I'd say about 90 posts ago.

[CaitSith2]

Im working on doing something,  to make an option for doing 2 pass looping.  (First pass finds out all of the loop point lengths, and figure out how many times each track should loop, and the second pass then creates the midi file, using the info gleaned from the first pass.

A game that is bad for differing track lengths, is Magical Starsign.  (ambience effects are often on the longer track, and doesn't sound right as a result of the looping, unless the midi was converted using the 2 loops option, rather than the loop point options.)