Skip to main content
Topic: foo_midi (Read 18201 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_midi

Reply #75
Okay, I understand. I guess it's better not to change anything. Thank you. :)

Re: foo_midi

Reply #76
Hi all, just a quick question: what is the maximum polyphony of the BASSMIDI option in foo_midi?

Re: foo_midi

Reply #77
Hey,

I'm trying to get MIDIs from the DOS game Gateway 1 to play with adlib emulation.  It works, but the instrumentation is way off.  Here is what it should sound like (from Dosbox)
https://www.youtube.com/watch?v=9ct5aJFl30M

Is it possible to extract instruments from the game somehow?  I got the MIDIs from here:
http://www.mirsoft.info/gmb/music_info.php?id_ele=MTM0MTE=

I thought at first it makes more sense to play from the original game files using foo_adplug but the .mus files in the game folder won't be accepted by the plugin.  Any ideas?

Re: foo_midi

Reply #78
The .MUS files included with the game are just multi-file banks containing standard MIDI files. The instrument data is presumably in one of the game's data files or executables.

Re: foo_midi

Reply #79
hi, kode54
Does foo_midi actually support midi type 2? I just happened to know this type of midi from here.
Regards.

Re: foo_midi

Reply #80
It separates type 2 files into individual sub-songs.

Re: foo_midi

Reply #81
Hi kode54,

Does foo_midi support multi-port MIDI files? Those files have 0x21 port info already and can be correctly played by TMIDI Player with my SC-D70 for example.

BTW before I post this I did google for the solution, and accidentally I saw you mentioned SC-VA in another forum, but I can say it doesn't always sound like the real thing. Maybe they should hire you to fix those pathetic bugs.

https://forum.cockos.com/showpost.php?p=1861656&postcount=12

Re: foo_midi

Reply #82
Yes, multiple ports are supported, up to three ports at this time. Ports are allocated not by port number, since some files use port names and have a unique port name on each track. Rather, they are allocated by each unique track using the same channel as another track that has a different port identifier.

Re: foo_midi

Reply #83
bassopus.dll, basswv.dll, bass_mpc.dll, bassflac.dll
Why does foo_midi include all these files? It seems that they are not required for playing MIDI.

Re: foo_midi

Reply #84
They're used if you have soundfonts with audio compression.
Nazi punks, f*** off!
--
¡Se habla español!

 

Re: foo_midi

Reply #85
Can someone please help me understand what I need in order to play these files?

https://drive.google.com/file/d/0B2uObEBH_jRHUGRXZFRQSHIzd3M/view

There are two folders - it's the CM-32L files that I'm struggling with. They generate an "Invalid MIDI File" error when I try to play them. I have CM-32L PCM and Control ROMs referenced under the MUNT data path in the foo_midi settings.

Thanks!

Re: foo_midi

Reply #86
Sorry I took so long to respond to that one report, it's a weird one though. Running status for SysEx commands. Basically, a F0 command, length, and unterminated sequence (no F7), then a delay, then an F7 command, with the rest of the SysEx sequence following it, terminated by another F7. Apparently, this was sort of normal in some MIDI files? Anyway, it's now supported.

Re: foo_midi

Reply #87
Apparently, this was sort of normal in some MIDI files?
The files are definitely abnormal. I am not familiar with pre-GM stuff but it could be caused by real time recording through physical MIDI interfaces and cables, or some buggy ripping software.

Sometimes buggy MIDI files can hang my synthesizer and I needed to power cycle it.

Re: foo_midi

Reply #88
My library will read those sort of files, but will automatically normalize the SysEx messages into single whole message blocks.

Re: foo_midi

Reply #89
My library will read those sort of files, but will automatically normalize the SysEx messages into single whole message blocks.
Can you elaborate a bit more? I read some of your codes but I am not sure if I understand them correctly.

Take the attached song as example. myTool.txt is an incomplete tool I wrote to extract SysEx data. It simply gets the bytes according to the reported length after "F0". As you can see, there are some illegal values in delta time 2040.

sonar.txt: the stuff that Sonar read from that SysEx entry.

reaper.txt: Reaper gave up and stopped to parse the file just before that entry.

How do you use the logic of running status to read SysEx? What SysEx values did you get from foo_midi? Thanks.

Re: foo_midi

Reply #90
F0 <running length, in this case, 255> <255 bytes follow> <another delta tick count> F7 <running length, remainder of SysEx> <specified length follows, ends with F7>

If you use my tomid/2mid tool linked with this latest version of midi_processing, it can normalize these split up SysEx messages, padding them on the end with the extra tick counts that surrounded the continuation blocks.

Re: foo_midi

Reply #91
Thanks for the explanation.

Re: foo_midi

Reply #92
Hi kode54, I updated my tool so that it supports multi-part SysEx messages, but I found foo_midi cannot read some files (attached).

These files are totally fine in other MIDI players and sequencers. I think I found a foo_midi bug.

Re: foo_midi

Reply #93
Those are either encoded incorrectly, or SysEx is even weirder than I thought. MF2T decodes those SysEx sequences as "Arb" arbitrary data. They are encoded with a 0xF7 <length> header for the only block of data, with the 0xF0 inside the data sequence.

My library only handles sequences that start with a 0xF0 <length> sequence, followed by 0xF7 <length> sequences. I suppose I can change it to accept 0xF7 started sequences that are missing a 0xF0 started sequence, so long as they start with 0xF0 in the data. But then they'll have to separate the sequences by checking for a 0xF7 on the end of any arbitrary block. Or worse, in the middle of a block, followed by another 0xF0. Ugh.

Re: foo_midi

Reply #94
Both Sonar and Reaper don't show any SysEx in their event list, but they don't show any error and simply treat them as MIDI files without SysEx data.  MPC-HC and vanBasco also play the files and all of them have the same duration and timecode so they just ignore the offending messages and proceed to the next delta tick.

Re: foo_midi

Reply #95
Hey Kode54, any chance you could update this plugin to use the latest Nuked OPL version?

Re: foo_midi

Reply #96
Done. And I also slip in my own modifications, which are published in the foo_midi repository. Only one simple modification: A special register to allow panning of the (up to) 18 channels of the chip.

Re: foo_midi

Reply #97
Awesome, that was quick, thank you.

Why is it that extracted dos midi music sounds a bit off compared to Dosbox ECE, which uses the same Nuked emulation? I guess there's more to it than just emulating the chip accurately? I'm out of my depth with this stuff.

Re: foo_midi

Reply #98
Dosbox resamples it from 49716Hz to whatever rate you have set, using a running average resampler. I resample using a sinc resampler.

It also depends on which Adlib emulator you're using. The "Nuclear Option" drivers use Nuked OPL3, while AdPlug uses the Dosbox "fast" emulator, mainly because it defaults to using 10 instances at once.

 
SimplePortal 1.0.0 RC1 © 2008-2018