HydrogenAudio

Hi Kode54,

I was checking out the newly introduced ADLmidi emulator lately and I have a few comments/suggestions:

1. Suggestion to rearrange the foo_midi decoder configuration page in order gain more space for the FM patch drop down list, thus the entire FM patch strings are readable.
    I.e. exchange the location of the BASSMIDI and MUNT options with ADLmidi options. This way the width of the FM patch drop down list can be greatly increased.

2. Shouldn't the ADLmidi options be grayed out unless ADLmidi is the selected output plug-in?

3. Suggestion to sort the FM patch entries in alphabetical order, i.e. sort first by AIL, OP3, SB, TMB, Bisqwit, then by the game titles.
    Even better would be to have a list made of the game titles only, omitting the leading AIL, OP3, SB etc.. This list would be alphabetical sorted, showing only one game title per row which makes it quite easier to find a particular game entry.

4. Could an logic be implemented to predefine which FM patch is to be used for certain MIDI files? Like via an optional setting stored to the foobar playlist, or a config file (like <soundfont>.sflist) stored with the MIDI files.

5 AIL (Star Control 3, Albion, Empire 2, Sensible Soccer, Settlers 2, many others) = standard bank: This was the default patch file used in the AIL/MSI setup distributions (Fatman.opl).
   I suggest to add "default" in front of the game titles (default, Albion, Empire 2, ...). Also was used for the game Time Commando (developer of Little Big Adventure).

6. AIL (Kasparov's Gambit) = file15: This was also used for the game GateWorld.


Q1: Shall I provide you with additional FM patches currently not available in Foo_MIDI?
Q2: What is the file programs.txt used for? Does it belong to the recently added FMmidi emulator?

BTW, the Foo_MIDI component download page still holds a reference for FluidSynth to be built-in. And the link to the GIT hub is missing.

1. Suggestion to rearrange the foo_midi decoder configuration page in order gain more space for the FM patch drop down list, thus the entire FM patch strings are readable.
    I.e. exchange the location of the BASSMIDI and MUNT options with ADLmidi options. This way the width of the FM patch drop down list can be greatly increased.

I'll look into this.

2. Shouldn't the ADLmidi options be grayed out unless ADLmidi is the selected output plug-in?

And this.

3. Suggestion to sort the FM patch entries in alphabetical order, i.e. sort first by AIL, OP3, SB, TMB, Bisqwit, then by the game titles.
    Even better would be to have a list made of the game titles only, omitting the leading AIL, OP3, SB etc.. This list would be alphabetical sorted, showing only one game title per row which makes it quite easier to find a particular game entry.

And this. You can take a look at my adlmidi repository (https://github.com/kode54/adlmidi) and poke around in gen_adldata.cc, to see how to reorder the banks. Please do note that the Bisqwit 51 bank is hard coded to assume the instrument numbers that come from inserting all 51 of the previous banks in the exact order they're already in. The instruments are pruned for duplicates as they are inserted.

4. Could an logic be implemented to predefine which FM patch is to be used for certain MIDI files? Like via an optional setting stored to the foobar playlist, or a config file (like <soundfont>.sflist) stored with the MIDI files.

I can look into this, but it does sound complicated, like I would need to define how certain settings can be stored in tag presets. I would probably implement it as something that is inserted into the tag database and read back on file open, and provide context menu options to save the current playback settings to the file, load settings from the file, and also clear the tagged settings.

5 AIL (Star Control 3, Albion, Empire 2, Sensible Soccer, Settlers 2, many others) = standard bank: This was the default patch file used in the AIL/MSI setup distributions (Fatman.opl).
   I suggest to add "default" in front of the game titles (default, Albion, Empire 2, ...). Also was used for the game Time Commando (developer of Little Big Adventure).

Yes, and I also included another copy of the Fat Man set, both 2 and 4 operator versions, as bundled with Skunny 32-bit, among those OP3 sets. Yes, the generator does label that bank as a "standard" GM bank.

6. AIL (Kasparov's Gambit) = file15: This was also used for the game GateWorld.

You're welcome to add that to the generator, or I can add it.

Q1: Shall I provide you with additional FM patches currently not available in Foo_MIDI?

That would be great. If they're in formats already supported by the gen_adldata.cc in that repository, you only need to supply the bank files and information about them. If they're in different formats, it would be helpful if you could supply the format information so I can more easily write translators for them. Or you can write your own translators.

The preferred data order a translator needs to load to is, first, 11 bytes of instrument data per 2 operator voice, in this register order:

{0x20,0x23,0x60,0x63,0x80,0x83,0xE0,0xE3,0x40,0x43,0xC0};

Optionally, a semitone finetune offset per 2 operator voice.

Then, applying to the whole instrument, be it two operator, coupled two operator, or four operator, an optional note number. Per Miles banks, the note number is treated as a positive offset if in the range of 0 - 19, a fixed note if 20 - 127, or a negative offset of 128 or greater. (Negative is applied as wanted note - offset - 128.)

It is best that the banks be supplied in their original format, or at least the smallest extracted files that contain them, with instructions or C++ code for extracting them from those files as necessary. See gen_adldata.cc, it contains a bunch of LoadSomeFormat() functions, which take relative paths to the bank files, bank numbers, and bank name prefixes, and load the data into the big table of instruments and instrument map.

Q2: What is the file programs.txt used for? Does it belong to the recently added FMmidi emulator?

Yes, it's for fmmidi, which was lifted with very little modification from this program (http://milkpot.sakura.ne.jp/fmmidi/). The synthesizer does not actually appear to be designed after any particular FM chip, but rather implements a high level four operator sine wave based FM synthesizer, which is designed around a synthesizer class, containing instances of a channel class, which creates FM note generators from a note generator factory class. At initialization, the synthesizers are assigned a single note generator, and the instrument presets are loaded into the note generator.

BTW, the Foo_MIDI component download page still holds a reference for FluidSynth to be built-in. And the link to the GIT hub is missing.

Fixed.

Thank you for the update and taking my suggestions into account.

You can take a look at my adlmidi repository (https://github.com/kode54/adlmidi) and poke around in gen_adldata.cc

I already looked into bisqwit's adlmidi source before raising this thread, mainly to be able to read the entire FM patch strings.

I can look into this, but it does sound complicated, like I would need to define how certain settings can be stored in tag presets. I would probably implement it as something that is inserted into the tag database and read back on file open, and provide context menu options to save the current playback settings to the file, load settings from the file, and also clear the tagged settings.

1. I understand this is not trivial to implement, thus my alternative suggestion was to just use a simple text file. Upon loading a MIDI file foo_midi would need to check if such an text file, e.g. by the (hardcoded?) file name foo_mid.fmlst, does exist and load a predefined FM patch accordingly overriding current Foo_MIDI preferences. Each entry simply would look like this:

descent.mid, intmelo.bnk
credits.mid, rickmelo.bnk
...

2. In order to derive the internal FM patch filenames a meta field containing the currently used FM patch could be made available, which would be accessible from the file properties dialog upon playback . And/or simply provide the FM patch filenames in a documentation for the foo_midi plug-in.

3. Speaking of documentation I created one myself which I include in the foo_midi archive made available on MODLAND. Please have a look and let me know your thoughts, corrections, rejections and what not.
If you think it is good enough to be included with your main distribution please fell free to do so.

MIDI Synthesizer Host, for Foobar2000 v1.1x
(c) Chris Moeller, http://kode54.foobar2000.org
https://github.com/kode54/foo_midi/commits/master
https://github.com/kode54/adlmidi
Emu de MIDI alpha by Mitsutaka Okazaki, VST Plug-in Technology by Steinberg.


Adds decoding support for General MIDI files and RIFF MIDI files as well as several
proprietary MIDI formats.


Plays through either one of the following:

 · Emu de MIDI, a built-in "Chip tune"-like synthesizer (default).
   Does not require any soundfont.

 · BASSMIDI, a BASS.DLL extension included with the plugin.
   Supports SF2 soundfonts. Additional soundfonts may be defined with a text file
   named <filename>.SFLIST, to be stored in the soundfonts folder. The text file
   is assumed to be UTF-8 encoded unless it contains an UTF-16LE byte order marker.
   You may copy the soundfont file names from Explorer and paste them into any
   unicode capable text editor (e.g. Notepad). The first defined soundfont is the
   base font, any following soundfonts add or replace instruments of the base font.

 · Super MUNT GM, a built-in MT-32 emulator.
   Requires the PCM and control ROMs for either MT-32 or CM-32L to be located in
   the directory configured in preferences. The emulator will automatically be used
   to play any MIDI file containing MT-32 system exclusive messages, you don't need
   to select MUNT from the synthesizer list. Selecting MUNT only has an effect when
   playing non-MT-32 files in which case it automatically uploads a General MIDI
   emulation instrument set and enables an extended channel and polyphony mode to
   support the full 16 MIDI channels as well as 256 voices worth of polyphony.

 · ADL MIDI, a built-in OPL3 emulator.
   Supports four-operator mode (FM synthesis) for playback of the proprietary MIDI
   formats AIL = Miles Sound System (MSI), DMX (Doom MIDI Extension), HMI (Human
   Machine Interfaces) and Creative IBK. Several built-in FM patches from a number
   of known PC games are selectable from the MIDI decoder configuration page.

 · FM MIDI, a built-in Frequency Modulation emulator.
   Does not require any soundfont.

 · VST instrument host.
   Plays through VST instruments installed to %programfiles%\Steinberg\VstPlugins,
   e.g. Edirol Hyper Canvas DXi VSTi. VST Instrument support requires a path to be
   configured in the Advanced section of Foobar2000's preferences before opening
   the regular MIDI decoder configuration page. It is recommended to only include
   instruments you may wish to use in this directory.


Supported formats:
.GMF .HMI, .HMP, .KAR, .LDS, .MDS, .MID, .MIDS, .MUS, .RMI, .XMI

Q1: Btw, the drop down list still isn't wide enough preventing several strings from being fully visible, so why not use the full width of the MIDI preferences screen?

Q2: What does the adlmidi setting Chips exactly do?

Q3: What do you think of my suggestion to omit leading text AIL, OP3, SB etc from the drop down list and provide an alphabetical sorted list just made of the game titles, showing one title per row/entry only? Each entry would be linked internally to the appropriate FM patch. Do you think it is feasible and convenient? If so I could edit the file gen_adldata.cc accordingly and send it to you.

Q4: Thankfully you often provide the latest release of bassmidi.dll with foo_midi (where do you get it from?). Then again included bass.dll is rather old, v2.4.7 from 2012-10-02. Is this for a reason? Btw, latest release of bass.dll I could get hold of is v2.4.9.16 from 2012-12-18.

1. I understand this is not trivial to implement, thus my alternative suggestion was to just use a simple text file.

I actually find the tag database easier to work with than searching for settings files on disk. The hard part is actually going to be interfacing a settings preset into the input. It would probably just involve either translating the global settings into a preset of variables, with overrides read from a binary tag structure.

You may be right that it would be a good idea to store a string or substring name for the bank, as the bank names and order could change. Well, maybe not. I was thinking that any bank additions would simply be appended to the existing list. Names could change, but bank numbers will not.

The new sorted bank list stuffs the bank numbers and their names into a list, then sorts it by the names. The configuration stores the internal bank number, not the sorted bank number.

3. Speaking of documentation I created one myself which I include in the foo_midi archive made available on MODLAND. Please have a look and let me know your thoughts, corrections, rejections and what not.
If you think it is good enough to be included with your main distribution please fell free to do so.

Cool, let's see here.

· FM MIDI, a built-in Frequency Modulation emulator.
  Does not require any soundfont.

Currently requires the programs.txt file, which is bundled. I may add an option to configure an alternate presets file, or even include an editor based on the one in fmmidi.

· VST instrument host.
  Plays through VST instruments installed to %programfiles%\Steinberg\VstPlugins,
  e.g. Edirol Hyper Canvas DXi VSTi. VST Instrument support requires a path to be
  configured in the Advanced section of Foobar2000's preferences before opening
  the regular MIDI decoder configuration page. It is recommended to only include
  instruments you may wish to use in this directory.

The program files path is misleading, as it no longer supports automatically reading VST instruments from that path. It explicitly requires a path to be configured before it will search for any instruments. It is not advised to use a path which will include too many DLL files, as it searches the entire path recursively, and a path containing a lot of files could take a long time to process.

Q1: Btw, the drop down list still isn't wide enough preventing several strings from being fully visible, so why not use the full width of the MIDI preferences screen?

Sure, I could do that.

Q2: What does the adlmidi setting Chips exactly do?

That controls how many emulated OPL3 chips are used per instance of the synthesizer. Each OPL3 chip supports 18 voices in 2 operator mode, but are actually configured for 4 voices in 4 operator mode and 10 voices in 2 operator mode. This limits the total polyphony of the synthesizer, depending on the types of instruments used.

4 operator instruments use 4 operator voices. 2 operator instruments use 2 operator voices. Pseudo 4 operator instruments (really pairs of 2 operator voices) like DMX banks use pairs of 2 operator voices.

And then full panning mode doubles the chip count and uses one set of chips for the left channel and another for the right channel.

Q3: What do you think of my suggestion to omit leading text AIL, OP3, SB etc from the drop down list and provide an alphabetical sorted list just made of the game titles, showing one title per row/entry only? Each entry would be linked internally to the appropriate FM patch. Do you think it is feasible and convenient? If so I could edit the file gen_adldata.cc accordingly and send it to you.

Actually, separate/multiple individual titles per bank should probably be handled separate from gen_adldata.cc, or at least separately from the original bank list. It should be handled as a separate list, indexed with bank numbers and game/bank titles. It could also be pre-sorted in some arbitrary order.

I think the original bank list should remain as it is, or at least in the same order, so that Bisqwit 51 still works without modification. Or you can reorder things and remake that bank.

Q4: Thankfully you often provide the latest release of bassmidi.dll with foo_midi (where do you get it from?). Then again included bass.dll is rather old, v2.4.7 from 2012-10-02. Is this for a reason? Btw, latest release of bass.dll I could get hold of is v2.4.9.16 from 2012-12-18.

I usually get it from http://un4seen.com/stuff/bassmidi.zip (http://un4seen.com/stuff/bassmidi.zip). As for BASS itself, I don't actually use many of the features of BASS, and I hadn't known there was a new version to update to.

The program files path is misleading, as it no longer supports automatically reading VST instruments from that path.

Right, I understand. I got that bit of information from the foo_midi component download page here on Hydrogenaudio. Looks like that page requires some more maintenance.
Here's the updated documentation for your convenience.

MIDI Synthesizer Host, for Foobar2000 v1.1x
(c) Chris Moeller, http://kode54.foobar2000.org
https://github.com/kode54/foo_midi/commits/master
https://github.com/kode54/adlmidi
Emu de MIDI alpha by Mitsutaka Okazaki, VST Plug-in Technology by Steinberg.


Adds decoding support for General MIDI files and RIFF MIDI files as well as several
proprietary MIDI formats.


Plays through either one of the following:

 · Emu de MIDI, a built-in "Chip tune"-like synthesizer (default).
   Does not require any soundfont.

 · BASSMIDI, a BASS.DLL extension included with the plugin.
   Supports SF2 soundfonts. Additional soundfonts may be defined with a text file
   named <filename>.SFLIST, to be stored in the soundfonts folder. The text file
   is assumed to be UTF-8 encoded unless it contains an UTF-16LE byte order marker.
   You may copy the soundfont file names from Explorer and paste them into any
   unicode capable text editor (e.g. Notepad). The first defined soundfont is the
   base font, any following soundfonts add or replace instruments of the base font.

 · Super MUNT GM, a built-in MT-32 emulator.
   Requires the PCM and control ROMs for either MT-32 or CM-32L to be located in
   the directory configured in preferences. The emulator will automatically be used
   to play any MIDI file containing MT-32 system exclusive messages, you don't need
   to select MUNT from the synthesizer list. Selecting MUNT only has an effect when
   playing non-MT-32 files in which case it automatically uploads a General MIDI
   emulation instrument set and enables an extended channel and polyphony mode to
   support the full 16 MIDI channels as well as 256 voices worth of polyphony.

 · ADL MIDI, a built-in OPL3 emulator.
   Supports four-operator mode (FM synthesis) for playback of the proprietary MIDI
   formats AIL = Miles Sound System (MSI), DMX (Doom MIDI Extension), HMI (Human
   Machine Interfaces) and Creative IBK. Several built-in FM patches from a number
   of known PC games are selectable from the MIDI decoder configuration page.

 · FM MIDI, a built-in Frequency Modulation emulator.
   Requires the file programs.txt, included with the plugin.

 · VST instrument host.
   Plays through VST instruments, e.g. Edirol Hyper Canvas DXi VSTi. Requires a
   path to be configured in the Advanced section of Foobar2000's preferences BEFORE
   opening the regular MIDI decoder configuration page. Because the entire path is
   searched recursively it is recommended to only include instruments you may wish 
   to use in this directory. A path containing a lot of files may take a long time
   to process.


Supported formats:
.GMF .HMI, .HMP, .KAR, .LDS, .MDS, .MID, .MIDS, .MUS, .RMI, .XMI

I usually get it from http://un4seen.com/stuff/bassmidi.zip (http://un4seen.com/stuff/bassmidi.zip)

Ah, I see. I didn't have this ZIP file on my radar, I was only checking for updates of the EXE/DLL files in Ian's stuff folder. Bassmidi.dll was updated recently (2012-12-28), too.

And here (http://www.hydrogenaudio.org/forums/index.php?showtopic=98935&view=findpost&p=821059) is a small archive containing a few FM patches currently not available in adlmidi.

Hi kode54!

I'd like to request such a thing:


If midi file is detected as XG then (if available) use Yamaha S-YXG50 .dll for playback (as in case with MT-32 midi files).

It's quite a hassle to switch between different player plugins as for now.

I'm sorry, Dave, I'm afraid I can't do that.

Perhaps you can be satisfied with preset saving. Configure the synthesizer you want to use, select all the MIDI files you want it to be used with, then right click and select Save synthesizer preset, under the Utilities submenu. Remove preset will restore the selected files to using the configured default synthesizer.

I'm sorry, Dave, I'm afraid I can't do that.

Perhaps you can be satisfied with preset saving. Configure the synthesizer you want to use, select all the MIDI files you want it to be used with, then right click and select Save synthesizer preset, under the Utilities submenu. Remove preset will restore the selected files to using the configured default synthesizer.

That's even better in my case  Thanks a bunch!

Hello.

I just installed and trying to use this plugin.
When I try to open *.kar file I get "Unable to open item for playback (Unsupported file format):" message.
Am I missing anything? Could you please direct me to more information about this plugin?

Thanks in advance.

Yeah, I fixed that. Stupid of me to amend the change log without actually applying the necessary changes.

After updating to 1.209 automatically through foobar (1.2.6), I get: Failed to load DLL: foo_midi.dll, reason: The specified procedure could not be found. 

The same appears after trying to manually install the plugin again.

It would help if you could use this (http://www.dependencywalker.com/) to indicate which libraries it is missing. Besides shared.dll and apparently ieshims.dll. It should be located under %appdata%\foobar2000\user-components\foo_midi, or under the same user-components directory inside the foobar2000 directory if you are using a portable installation.

According to Dependency Walker, only SHARED.DLL and IESHIMS.DLL are missing for me.

I want to report a bug with new foo_midi 1.215.
In nearly all of my midi files the last seconds were cut off during playback.
foobar2000 1.2.9, Win7

This should be fixed with 1.216.

Hello.

I just installed and trying to use this plugin.
When I try to open *.kar file I get "Unable to open item for playback (Unsupported file format):" message.
Am I missing anything? Could you please direct me to more information about this plugin?

Thanks in advance.

Kode54, is this really fixed, as I get error while playing karaoke midis, with latest to date, and prior version of foo_midi?
MidiBar and everything else that supports midis, plays them fine

This is the error I get in console:

Opening track for playback: "G:\income\media\karaoke\Necu_Necu_Dijamante.kar"
on_endofplayback
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"G:\income\media\karaoke\Necu_Necu_Dijamante.kar"

Then it is obviously not just a renamed .MID file.

for example: http://freemidis.net/midi/Ekv/Krug.rar (http://freemidis.net/midi/Ekv/Krug.rar)

That file works here.

Are you sure you even have basic MIDI support working? If you have BASSMIDI selected but no working SoundFonts configured, it will pop that decode error on file start. The same goes for using MUNT or an MT-32 MIDI file without the MT-32 or CM32-L patches configured.

That was it. I use Windows bassmidi driver that you and mudlord prepare and wasn't aware that it has no impact on foo_midi settings, where bassmidi groupbox was set in the past to now non-existing soundfont. So, not even regular midis were playable, which I assumed it's not the case.

Sorry

Yeah, foobar2000 components can't really use system synthesizers, because they usually direct their own audio output to the system in real-time. foobar2000 inputs need to be able to generate sample data internally, and on demand.

Actually, foo_midi came out before the drivers did.

Tip: If you want to keep foo_midi in sync with the SoundFont settings you use with the driver, point it to C:\Windows\bassmidi.sflist for port A, or C:\Windows\bassmidi_b.sflist for port B.

Huge error in the latest update. I guess you changed the bass DLL and triggered its inbuilt anti-tampering mechanism.

It now gives this message: "This file has been tampered with and MAY BE INFECTED BY A VIRUS!"

This stops foobar2000 from working.

Update it again.

Just want to report ver 1.223 still have some MID file report as invalid, they can be played in my last version (should be 3 months ago).

I had a little problem with my new range checking code. I repeatedly made backwards range comparisons of if ((end - it) > the_size) return fail;, instead of checking < the_size. I caught most of them before committing the final work, but missed one in the Standard MIDI track processor, where it handles System Exclusive messages. Fixed now.

johnsonlam's post me too...
I can not play MIDI files of some v1.223 update later
(http://imgz.co.za/images/2013/10/27/foomidibug.png)

You just missed the post where I said I fixed that with v1.224.

You just missed the post where I said I fixed that with v1.224.

ThankYou! Kode54

Hey Kode is the VSTi search path:
{Preferences-->Advanced-->Midi Decoder-->VSTi search path:}

Is that Absolute or relative path or will it take either?
loi  =D

I am having no luck with quick Google searches for MUNT or BASSMIDI...
I found forum posts...  but what am I looking for...

The search path is absolute. I can try to make it relative to the profile path later, if you insist.

MUNT: MT-32 / CM-32L simulator library.
BASSMIDI: Ian Luck's SoundFont MIDI synthesizer library, an extension to his existing BASS sound library.

The search path is absolute. I can try to make it relative to the profile path later, if you insist.

MUNT: MT-32 / CM-32L simulator library.
BASSMIDI: Ian Luck's SoundFont MIDI synthesizer library, an extension to his existing BASS sound library.

Thanks for the Info Kode54  =D 

well it could hurt to have it function both ways as an added improvement to your already amazing extensions ;D

are there packages of either type that don't require install.... loi I kinda already have a installed Midi Player called

- Yamaha soft-synthesizer s-yxg50 (http://img97.echo.cx/img97/1341/softsynth14or.png)

the college I was at had it on all the PCs and I grabbed a copy years later...
I never was able to find out where the wave tables were stored though..... anyway I have been following your work with foo_midi so I can listen to the hand full of midi files I have from those college days (2001-2002, lol only had floppy discs back then so no way I could do MP3s lol) from within  Foobar2000 =D

If you locate a handy copy of the S-YXG50 VSTi, hopefully modified to support non-Yamaha VSTi hosts, you can use it with this component.

If you locate a handy copy of the S-YXG50 VSTi, hopefully modified to support non-Yamaha VSTi hosts, you can use it with this component.

ooh O_o Cool hopeful there is some out there somewhere...

I had a little problem with my new range checking code. I repeatedly made backwards range comparisons of if ((end - it) > the_size) return fail;, instead of checking < the_size. I caught most of them before committing the final work, but missed one in the Standard MIDI track processor, where it handles System Exclusive messages. Fixed now.

I've double checked, problem gone, thank you!

foobar2000 says this MIDI file is corrupted, but it plays fine in other players (MPC-HC for example): http://keygenmusic.net/music/phrozencrew/P...izerXP1.0nfo.7z (http://keygenmusic.net/music/phrozencrew/PHROZENCREW-CustomizerXP1.0nfo.7z)

Contains a bunch of MT-32 SysEx messages that claim it's an MT-32 file, so you'll need to install some MT-32 control/PCM ROMs (or CM32-L).

Hello kode54,

Foo-Midi 1.245

SYSEX dumps for MUNT is now broken.
External dump  &  for mt32 MIDI files that already include SYSEX dump

(Crash location:
Module: foo_midi
Offset: 3CA48h)


foo-midi 1.243 works fine


Greetings

EDIT:
PS
At your Git, I just saw that there was some MUNT changes within 1.244.
I do not have this version, so i can´t test this.
Maybe the error refers at these changes!?

- Version is now 1.244
- Fix MUNT by updating to the latest version and correcting how its API is used

-         _synth->playSysex( start, sequence_end - start + 1 );
+         _synth->playSysexNow( start, sequence_end - start + 1 );

etc.pp

As i said, foo-midi 1.243 MUNT and SYSEX dumps works fine.

Please let me know if this build fixes it for you:

http://kode54.foobar2000.org/foo_midi.fb2k-component (http://kode54.foobar2000.org/foo_midi.fb2k-component)

Please let me know if this build fixes it for you:

http://kode54.foobar2000.org/foo_midi.fb2k-component (http://kode54.foobar2000.org/foo_midi.fb2k-component)

No it doesn´t, kode54

No matter which of my many mt32 MIDI files.

If i load an mt32 file that dont include any Lib. SYSEX Dump and or without dump external it plays normal but then of course over BASSMIDI and not with the MUNT Emu.

Illegal operation:
Code: C0000005h, flags: 00000000h, address: 0159C9A8h
Access violation, operation: read, address: 00000000h
Last win32 error: 38
(ERROR_HANDLE_EOF
    38 (0x26)
    Reached the end of the file.
(

Call path:
playback_process entry=>input_decoder::run

Registers:
EAX: 061F9A58, EBX: 061F9A58, ECX: 00000000, EDX: 017CD630
ESI: 00000004, EDI: 00000000, EBP: 0612F4D0, ESP: 0612F4A8

Crash location:
Module: foo_midi
Offset: 3C9A8h

------

V-1.243 MUNT works fine
x86(XP) and with x64 WIN7

Greetings

EDIT:

is has really to do with the MUNT Synth and not only with SYSEX because

if i force SUPER MUNT to play any MIDI File it (V1.245/46) instantly crash and always with the same error code 38.
with all other synth Emu´s like adl,fm, opl, bass and emu de- no problem.

I have to add that i test this with the older XP x86 audio/midi machine.

And I expect you to submit your crash reports to the tracker so that I can see them, including the minidump (.dmp) that is generated. I don't see any recent crashes, except for one from July from someone running a foo_midi release from 2012.

And I expect you to submit your crash reports to the tracker so that I can see them, including the minidump (.dmp) that is generated. I don't see any recent crashes, except for one from July from someone running a foo_midi release from 2012.

It is the same with an fresh portable 1.38 with minimal needed third components(only foomidi and Asio support) installation.
I send the report to the foo tracker. The Super-MUNT mode / foo_midi 1.245 & 1.246 crash foobar 1.3.8 ; Super-MUNT 1.243  do not crash.

I have added also an link to my dropbox with the foobar Report and the Mini Dump

Crash-Report (https://www.dropbox.com/s/2psca3xfy761b5z/crash%20reports.7z?dl=0)


Greetings

I can't reproduce it on anything newer than Windows XP. Looks like I'm downgrading Visual Studio to 2010 and dropping this whole XP SDK nonsense.

Try now, from http://kode54.foobar2000.org/foo_mid.fb2k-component (http://kode54.foobar2000.org/foo_mid.fb2k-component)

I feel like such a dunce for not fixing this issue I'm having by myself, but I exported an .sflist from XMplay's MIDI decoder and it isn't loading any instruments from other .sf2 files other than the latest instrument I assigned a soundfont to.

It's behaving as if I just popped an .sf2 file in regularly and I want it to load instruments from other soundfonts like it does in XMplay. Mind giving me any hints on how to resolve this?

While I'm here, I love your work kode54. Until I started browsing that Japanese f2k .dll library, I used to have ALL your plugins. Still do have most of 'em. Thanks for all you've done.

1.247, released on 2015-10-06

Now, the mt32 mode works again, kode54.
No problems anymore, great.
 



BTW nothing special but i wonder why you use the older bass wavpack version 2.4.4.0 within foo-midi, if there is an newer official
BASSWV 2.4.5.1

Because there is no update notifier to tell me there are newer releases, and I never bother to check for them manually.

Hi,

I just want to report that the S-YXG50 VSTi does not work well with the newest version of foo_midi.

For some reason, it runs the S-YXG50 in default setting every time I play a midi file. The default setting puts the S-YXG50 at 32-Note polyphony meaning that most of my MIDI files are not playing properly (dropped notes, frequent muting, silent tracks).

I tried using the configuration option in the preferences menu to increase it to 128 Note Polyphony, but it is still causing the same problem.

It used to work fine before, but it started happening when I reinstalled the foobar2000 program + foo_midi plugin. Is there any way to fix it or get the vsthost32.exe to accept VST settings?

I've been playing around with the Super MUNT GM and I've been noticing a couple problems.

1)The sierra/kings quest 6 set doesn't seem to be made for GM that well. Some instruments are getting replaced by REALLY annoying noises or just don't play at all.

(although when compatible, I usually prefer how it sounds over the Roland set, but not always.)

Not sure how difficult it is to (if you can) edit the set to replace said instruments with working ones from the Roland set?

2)Some of the MIDI files I own are making a bunch of crackling sounds like a corrupted audio file when I play them with MUNT, but with a roland Hyper Canvas VST for example, it sounds fine on the other output plug-ins.

It also sounds fine if I render it to WAV with another Foobar plugin.

Not sure why it's doing that when I have a pretty capable CPU and all...

Ok nvrm about the crackling, apparently my buffer was set really low.

still though, I understand if the sounds are sound effects or something to be compatible with the sierra midis, but if there could be a 3rd mixed option it would be great.

(Still have no idea how feasible that is though, so its okay if you can't.)

Hi Kode54,

I hope you are doing well. Today I tried your most recent release of foo_midi v2.0, only to find that it won't load any MIDI file at all, throwing the error message "Unsupported format or corrupted file". Going back to v1.256 I found that version to behave all the same. Going further back to the then previous release v1.254 everything is working well again. Perhaps this issue is related to the switch from MSVC 2015 in v1.254 to MSVC 2010 with release v1.256? Using Windows 10 Pro 64-bit here.

Same OS here, works as expected. Check your configuration.

Same OS here, works as expected. Check your configuration.

I did that, I also tried with a fresh setup. Every output plug-in (Emu de MIDI, adlmidi, fmmidi, etc.) of MIDI player  is working, except for BASSMIDI. The bass.dll appears to get not loaded although all required files are available in the folder of the plugin. Simply overwriting foo_midi.dll, vsthost32.exe and vsthost64.exe with the files from the v1.254 release fixes the issue, BASSMIDI is working fine again.

EDIT:
I just tried with a vanilla installation of foobar2000 v1.3.13 and foo_midi v1.2.56 as the only additional plug-in. Again all output options of foo_midi work, except for BASSMIDI. Replacing the foo_midi files with the v1.254 versions BASSMIDI is working again.

I didn't even change anything BASS/BASSMIDI related. Well, except for the new SFLIST parser. I'll need to see your sflist files, even if only privately.

Hi Kode54,

please find my SoundFonts.sflist enclosed in a RAR archive attached below.

I realize it's not very helpful, but have you tried adding the files back to the sflist one at a time until it stops working? I do eventually need to add error reporting for the sflist parser, down to the line number where it fails. Of course, this won't be terribly useful, as it'll be parsed into JSON first.

So maybe a report of exact failure file instead.

@kode54 any reason why all of your components removed from foobar2000 site?

Drama that I'd rather not get into here. I'm taking a break from things.

Drama that I'd rather not get into here. I'm taking a break from things.

I'm really sorry to hear that. I hope you and the related person(s) can sort out the issue and you can find an agreement that allows you to continue where you left off. You have my gratitude for all the valuable content you have contributed over the many years, without asking for anything in return.

I still owe you an answer regarding the following:

I realize it's not very helpful, but have you tried adding the files back to the sflist one at a time until it stops working?

Thank you for the hint! I did that and managed to get the MIDI player to fully work again as expected. The issue was not related to any of the Soundfonts or MIDI files, but to the SoundFont.sflist itself. Recreating this list Soundfont by Soundfont from scratch and then comparing the final working result to the old one I found the following difference:

(http://i.imgur.com/ifIrVxi.png)

The hexadecimal representation of the difference is EF BB BF. This additional content is not visible when viewing or editing the file in text mode, and I have no idea how it ended up in the file. Anyway, your new Soundfont.sflist parser obviously chocked on it while the old one ignored these extra values.

EF BB BF is the byte order mark (https://en.wikipedia.org/wiki/Byte_order_mark) for Unicode. Apparently the new SFList parser is choking on that...

And I have yet to make the SFList JSON editor...

Hi KDDLB,

thanks for the clarification. Yes indeed my SoundFont.sflist file is saved in Unicode format, so is the one I just recreated. Yet the new one does not carry that extra values. Probably my text editor Notepad++ or the then used plug-in NppTextFX added the value at a  certain occasion without me recognizing it.

This is fixed in source now, as well as the sflist public gist.

I'm taking a break from things.

Not a good reason to punish us by removing all of your components IMHO.
We have done nothing wrong.

Quote from: kode54 on 2016-11-25 19:29:39

I'm taking a break from things.

Not a good reason to punish us by removing all of your components IMHO.
We have done nothing wrong.

The way you are quoting Kode54 puts his message out of context. His full post was:

Drama that I'd rather not get into here.  I'm taking a break from things.

Which means we do not know the reason for his motivation at all, so we have no basis to judge upon.

It has everything to do with IRC drama, and nothing to do with my user base. Guess who gets hurt by it? Unfortunately, it's my user base.

I'll probably restore things back to the way they were, and get rid of this uniquely identified download system.

It has everything to do with IRC drama, and nothing to do with my user base. Guess who gets hurt by it? Unfortunately, it's my user base.

I'll probably restore things back to the way they were, and get rid of this uniquely identified download system.

I'm sorry to hear you are having IRC trouble... :(
I hope it all works out some how..
I was worried when all your work disappeared...

Nuclear option?  This all of sudden showed up.

Nuclear Option = Nuked emu opl coupled with the two MIDI players that were otherwise only available as Windows drivers. One of them is the DMX / Doom / etc sound system with every bank set I could find, and the other is a port or recreation of the MSOPL.DRV, down to the flaws. (See: pitch wheel underflows/wraps on D_OPENIN.MUS and ROBOCREP.MID, etc.)

I chose to enable the "extended" mode for both of these drivers, which I created myself. An inaccuracy in the most accurate OPL3 emulator: Sinusoidal panning control over any of the running channels, through a proprietary register switch to activate it, and another register to control the panning position of a given channel, which is activated and controlled by the two drivers when extp is set enabled. Otherwise, they both hard pan according to their original panning dead zones.

I'm wondering how close the OPL3 emulation comes to that Windows 95 driver.  Dusts off S&K Collection MIDIs.

I'll probably restore things back to the way they were, and get rid of this uniquely identified download system.

I am relieved to see that you made all your plug-ins publicly available again. Thank you for the turn-around.

Sinusoidal panning control over any of the running channels, through a proprietary register switch to activate it, and another register to control the panning position of a given channel, which is activated and controlled by the two drivers when extp is set enabled. Otherwise, they both hard pan according to their original panning dead zones.

An option to turn it off would be nice.  Can't seem to find it.

You want hard panned stereo? OK, I'll add a checkbox for that. Done.

You want hard panned stereo? OK, I'll add a checkbox for that. Done.

Thank you!

BassMidi VSTi (http://falcosoft.hu/softwares.html#bassmidi_vsti) doesn't work. Will you support for this? thanks.

BassMidi VSTi (http://falcosoft.hu/softwares.html#bassmidi_vsti) doesn't work. Will you support for this? thanks.

This is unlikely to ever work unless I remove my own BASSMIDI support from the component, since we're both importing conflicting versions of the BASS and BASSMIDI libraries. Not like you're seeing any benefit to using it as a VSTi under this player, since you can't access the real time editor of any playing instance.

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

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

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?

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.

hi, kode54
Does foo_midi actually support midi type 2? I just happened to know this type of midi from here (http://www.vogons.org/viewtopic.php?f=24&t=48207&sid=03bbc61fad10c6aad3e4ebd892139cc5&start=460#p591941).
Regards.

It separates type 2 files into individual sub-songs.

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

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.

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.

They're used if you have soundfonts with audio compression.

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!

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.

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.

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

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.

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.

Thanks for the explanation.

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.

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.

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.

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

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.

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.

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.

Hi kode54,

The latest version of foo_midi (2.1.3) has garbled/choppy playback of MIDI files when using the fmmidi plug-in.  All of the other plug-ins play files just fine, and fmmidi playback was fine in previous versions (as far as I can remember).  This is using foobar2000 1.4 on Windows 10 version 1803, for what it's worth.

This should be fixed now. It was due to some synthesis crap I added that didn't really have much benefit, and was apparently super slow.

version 2.1.4, won't open midi preference page once vsti is set

Cannot reproduce. It has to enumerate the plugins installed first before it can display the preferences page, so you'll have to wait for it to finish, assuming you have a lot of VST plugins. It has to scan them all, to determine which ones are instruments.

I have only one VSTi plugin, with just a dll atm. I also try with fresh portable, foobar2000 becomes not responding when open midis page.

That was fast. Another update, to undo something I was told to fix. Apparently, I really do need a message pump within the VSTi enumerator, or else the whole process deadlocks. foobar2000 1.4.1 is also supposed to include a fix for preferences pages including their own message pump, so that users can't swap prefpanes while one is still loading, causing a bug reported earlier.

Guess what? Neither of these things causes bugs in Wine. Isn't FOSS wonderful?

the component is still listed as 2.1.4 on website, the file itself is correct. thanks for fix it. :)

Fixed that version listing, too.

adlmidi uses a lot of cpu power. I use default settings. Is there kind of midi that I should not play with it? I try with some classic musics.

Fixed that version listing, too.

Not yet on your site :P
(JSON's listing (https://kode54.net/fb2k/json.php) is obsolete?)

The JSON doesn't contain version numbers. Also, the indexes for the web site are server side generated now, so they'll populate search engines.

adlmidi uses a lot of cpu power. I use default settings. Is there kind of midi that I should not play with it? I try with some classic musics.

I made an account to ask about this exact issue. I don't know the exact cause (Because I'm not a programmer), but the CPU usage does drop dramatically if you lower the number of emulated chips from 10 to 5. Of course, this causes some other problems. What's odd is that before now, adlmidi worked fine with 10 emulated chips, so this must be a new issue.

The new issue is that the new library defaults to using Nuked OPL3 emulator instead of the much faster and mostly as accurate Dosbox OPL3 core. I should add an option, but the preferences dialog is already crammed, so I'll just make Dosbox the default and add an Advanced Preferences option to change it to either of the other Nuked versions provided.

I see you have uploaded the new version (2.1.7) on your website and that resolve this issue. Now its much faster with Dosbox OPL3 as emulator core. Thanks :)

Sorry if this is an old topic, but I'd really love foo_midi to provide a separate volume control for MIDI output - at least a volume slider on the Preferences page.

There are two reasons: 1) the various MIDI playback methods can be drastically different in volume, which means our MIDI playback may be significantly louder or quieter than normal, and we may want to adjust the volume at the same time we select our MIDI options. 2) Unlike PCM audio, we can't batch-adjust gains on MIDI files.

Personally, I find Secret Sauce (my main playback option) so extremely quiet I need to turn up the system volume for certain songs to be sufficiently loud. I would prefer being able to mix MIDI and non-MIDI files in a playlist without having to worry about volume.

Hello. I joined Hydrogenaudio because I need help partaining to this plugin.

I have MUNT fully installed and working, but I can't seem to get foobar to recognize the data path for some reason. I can play midi straight from MUNTs own frontend just fine, but when I use Super MUNT GS, foobar gives me an error saying the file is unsupported or corrupt.

I previously used BASSMIDI and soundfonts to play MIDI music, but I always did want an authentic Roland MT-32 playback.

You need to configure the data path in Preferences->Playback->Decoding->MIDI Player. Hope that helps.

[EDIT]: And you don't need to select Super MUNT GM as an output plugin, for MT-32 midi automatically plays using MUNT, once correctly configured.

Also, this plugin does not use external installations of MUNT, so any paths you have configured there will not be used. You must configure your ROM path manually in the Advanced section of Preferences.

You need to configure the data path in Preferences->Playback->Decoding->MIDI Player. Hope that helps.

[EDIT]: And you don't need to select Super MUNT GM as an output plugin, for MT-32 midi automatically plays using MUNT, once correctly configured.

Also, this plugin does not use external installations of MUNT, so any paths you have configured there will not be used. You must configure your ROM path manually in the Advanced section of Preferences.

So the data path must point directly to the folder containing the ROMs, correct?

Also, if I don't have to select Super MUNT GM, what it the default option to utilize MT-32 midi? Will the plug-in be fmmidi or something else?

So the data path must point directly to the folder containing the ROMs, correct?

Yes, That's correct.

Also, if I don't have to select Super MUNT GM, what it the default option to utilize MT-32 midi? Will the plug-in be fmmidi or something else?

What you've selected (fmmidi or other) will be used for everything other than MT-32 midi. MUNT will be used automatically for MT-32 midi only. MT-32 midi must contain corresponding reset message at the beginning of the file. In that case it will contain the following string in the Properties->Details of the file: "MIDI_TYPE: MT-32"

Speaking of the MT-32, here is a MIDI that I found that seems to be silent, even though it's apparently an MT-32 MIDI. I believe this file played in previous foo_midi versions. https://www.dropbox.com/s/vrf69c3vi1udfpk/PHROZEN%20CREW%20-%20Customizer%20XP%201.0%20nfo.mid?dl=1

It's silent in my Foobar, MUNT and Falcosoft Midi Player using MUNT as output too.

the silent with file above started from 2.0.23

According to the SysEx messages in that file, it's an MT-32 file. And that's Wrong.

So it's falsely stating that it's an MT-32 file but there's nothing specific to the MT-32 in it?

The only thing specific to the MT-32 which is in it is an MT-32 reset message. The entire file occupies channels which, upon reset, do not route anywhere.

Your recent release is listed as 2.1.6 on foobar2000 component page, component version is 2.1.8 now. :)

Again, oops.

Is there a program to create sfogg soundfont? Is it faster than using sf2pack FLAC?

It is no faster, and in fact possibly slower, than using sf2pack FLAC. I only enabled it because there is a published SoundFont bank that uses it. It is in fact the sf2pack format, using Ogg Vorbis. And the author who employed it said that it sounds possibly broken if you use anything less than quality level 10 when compressing the SoundFont bank. It figures, since Ogg Vorbis is meant to be gapless only on the ends of the whole stream, and sf2pack requires the entire block of sample data to be compressed as one long stream.

Update: Secret Sauce now works with 64 bit cores. Please be sure to report your core version and MD5 sum if it isn't recognized.

this midi (http://usahakujualanku.weebly.com/uploads/5/4/0/8/5408510/48canon-rock-in-d104825.mid) has an error when converting to FLAC, no problem when trying with WavPack, ALAC, MP3. Tried with BASSMIDI

Message on console
Writing tags to encoded file failed: Unsupported format or corrupted file
An error occurred while finalizing the encoding process (Unsupported format or corrupted file)

I'm curious what happens here as other midi seems fine.

The encoding doesn't fail but transferring tags does. There's something weird with the metadata in TRACK_NAME_01 field, it's invisible in foobar properties but when converted to for example WAV it shows up as some binary mess.

Thanks for reporting.

Added a fix in fb2k 1.4.3b5 so converting such file to FLAC no longer fails, problematic metadata fields will simply not be transferred.

In Secret Sauce preferences, is 885 in the flavor list the SC-8820?

I guess? Also don't forget those are overrides. otherwise, it just passes on all supported reset commands to the core.

Hi kode54. I'm wondering where the sflist JSON format for loading SFZ files in to foo_midi is documented? I remember you saying that there was info about it on GitHub somewhere, but I can't quite seem to find anything so far.

https://gist.github.com/kode54/a7bb01a0db3f2e996145b77f0ca510d5

Thanks for that. :)

Is there a way to see any errors in the JSON syntax? I've been trying to figure out how to prioritize soundfonts and SFZs but I'm having issues doing that at the moment, and I can't seem to find any errors in the console.

Update. It seems that I was making things needlessly complicated, I realized that I could just add the SFZ name to an sflist and edit the SFZ to reflect the new path for the instrument samples, since I have SFZ instruments stored as a separate subfolder in my soundfont collection.

I found an odd glitch when using Secret Sauce with some 64-bit cores. It seems that it does recognize that the core is 64-bit and scpipe64.exe runs, but the Secret Sauce option does not appear in the plugins list when the 64-bit core is selected. Using core version 1.03, MD5 F16B5EB9C7E204DE7F9B3A829D2D5500.

That's because the preferences page only appears if the configured path points to a folder containing a whitelisted MD5. I've only whitelisted the few that I've personally encountered. I'll add this MD5 to my list, since I never needed to add 64 bit versions back when I had 1.03.

I added 64 bit support and container/piping, because it solves two issues. One, that the Roland rental service store only offers 64 bit versions as far as I can tell. Two, that I can create multiple instances without duping the file around to the temp folder like the official plugin does, and thus also start up way faster as a result. Three, if it ever finds a crash bug, those crashes won't take out the main player, they'll just kill playback.

E: I'll need the file size, too. For now, I can only add 1.0.7 64 bit, since that's another version I have available.

E2: Never mind, that's the other 64 bit version I do have on hand.

E3: Added, enjoy.

Works now, thanks for the quick fix :).

Another foo_midi question. How exactly is EMIDI device track exclusion implemented? Does the component always mute the FM tracks, or does it exclude and add them as needed? For example, say I choose adlmidi with the Duke Nukem 3D bank, will it then play the FM tracks and exclude the normal ones, or will it just let the bank handle the instruments?

The EMIDI FM tracks are the same channels as the GM tracks of the same name, only they have different instruments. And usually, these instruments are hand tailored to exactly the Duke Nukem 3D bank. You should disable that override option, as usually the FM tracks will take effect first.

Which override option? EMIDI device track exclusion when playing EMIDI files with FM?

Yes, that one. I'd have to specially modify the filter to support filtering to just the FM tracks specifically for FM output, since it requires manual configuration to use the Duke Nukem 3D bank anyway.

Hi, I noticed an issue in the new Secret Sauce flavor preferences. In the newest foo_midi, when I select default in the GS flavor options, it seems to choose GM, even if a MIDI is specifically detected as GS, most noticeable when playing the GS version of the Grabbag theme. http://leejacksonaudio.lbjackson.com/html/download.html. If you play the file using the GS option, it will play normally, but a lot of the instruments will break when choosing the default GS flavor.

Yeah, that was an oops on my part. It should be fixed now.

Also, just FYI, that track should be played in the 88 Pro mode or better, or Default, for the GS type. Synth mode should be either Default or GS.

Meanwhile, most or all of the actual soundtrack shipping with the game should be played in SC-55 mode, especially Water World.

Working now, thanks for the fix. Unfortunately I noticed that XG is broken as well. If you try to play this MIDI using either the default or x flavors, it won't play using the incomplete XG implementation when a main flavor other than default is selected.

How i do that S-YXG50 switch into GS mode? Why foo_midi don't have a option to change to GS/XG/GM2 modes?

Your MIDI files should be doing this automatically. It also has the ability to attach System Exclusive message dumps to your files, which are added on playback.

Yes, but only the GS midi files with the SysEx patch, i know how work it, but i have various GS midi files without the SysEx, and when play them with the S-YXG50 sounds bad (muted variation sounds and a different drum sound, e.g the Metronome Bell sounds as a Open Rimshot instead of the mentioned sound). I tried the sysex dump with my GS reset syx file, but don't work properly, the instruments break and sounds as piano (all program changes reset to 0). You have no thought to made a option to reset the S-YXG50 to GS that works like the Super MUNT GM? I like how sounds GS mode in it.

The only thing I can do to make the S-YXG50 work like a GS instrument is to send a GS reset myself. And that's obviously not working for you.

Works, but in patched midi files. The feature that i say is, to be more specific, e.g Vanbasco and FSMP have a feature that can reset the S-YXG50 to GS, GM2 and by default XG, and the same player send a sysex message to the device. It will be possible that the plugin have that feature? That the plugin send a sysex to the synth as do it Vanbasco and FSMP? Is a feature that i have wished for years for my fav player... foo_midi is awesome but only missing that feature... specially for the S-YXG50 compatibility for play midi files. I hope I don't ask too much ...

I'll look into it. Eventually. But as you said, you sent a reset command to the synthesizer, and it broke all the instrument mappings.

Yes, when tried the sysex dump, but i fixed it removing the dump. How is it done to the sysex dump send a reset message to the midi file instead the synthesizer and play it correctly? I made the GS Reset .syx file myself in a hex editor and i made sure copy well the sysex message.

And I'm telling you, sending that SysEx message before the file plays is the only thing any GS/XG mode switch I add will do. The "Secret Sauce" already does this, but also feeds a delay to the synthesizer and disposes of the output, before starting the file.

And how it is used the Secret Sauce? I viewed it recently in the Advanced settings and ask me for a path (like the VST path configuration), but i don't know what is there to do exactly. Works for S-YXG50?

No, it only works with Sound Canvas VA, and only whitelisted versions.

I set the path for SC-VA and in the plugin window it appears the Secret Sauce options, but is disabled. For what versions works? I have the 1.0.3. The secret sauce is for the SC-VA don't be delayed in the loading when change the song?

You need to set the Secret Sauce path, not the VSTi path. Then you need to close preferences and reopen them.

I done it. Is fantastic! now i can play midi files with the SC-55 mode in foobar. And has XG mode, great! I didn't know that SC-VA had a XG mode. Thanks for that.

Sorry my insistence, but should to consider the idea of a "secret sauce" for S-YXG50... it will be so useful as the SC-VA's "sauce". If you can't, never mind, i settle for the SC-VA's sauce :)

There is no point. The "Secret Sauce" is for using an internal library directly. The S-YXG50 is only available as a VST instrument, so it must be used through the VST interface.

I could make the SysEx initialization a global thing, but it would only benefit VST instruments, the Roland synthesizer, and BASSMIDI. And BASSMIDI's handling of the various standards is very limited.

SysEx initialization refers to the GM(2)/GS/XG selection mode of which i have spoken previously?

Yes. There aren't a whole lot of VST instruments that support more than basic General MIDI, and a whole lot that don't even support that.

I know. Well, in my case i have various VST instruments with GM/GM2 support and additionally GS/XG, besides they are of light size. GM standards is my favorite thing. So, it will be possible that in a next update add that feature?

I don't know if some another user has informed you, but there's another problem with foo_midi to play some midis. When i play the "After Burner - Super Stripe" midi file for example, the instrument mappings breaks (similary thing when the sysex dump is applied) and occurs with VST instruments and BASSMIDI. I will put the midi files for you to check it.

I wish I could just disable multi-port MIDI support, it's been nothing but trouble. Sorry, it's just due to how these MIDI files use port number meta commands.

Hello, i'm using newest version 2.2.11 and try to use Yamaha S-YXG50
I have extract syxg50.dll to foo_midi folder, is foo_midi now support relative path?
I tried
%profile_dir%\user-components\foo_midi\
.\user-components\foo_midi\

Both seems not work, or what's wrong in my type? Thank you.

I'm pretty sure you still have to use absolute paths, and doesn't the SYXG50 depend on some other files? If it supports relative paths it might be relative to foobar2000.exe, I saw something like that when getting the yrw801.rom file for foo_input_vgm.

Oh that's so sad, my foobar is portable so i don't want to paste absolute path.
BTW syxg50.dll is only one dll file and work fine is i use absolute path.
Thanks for your reply.

I was waiting for the new version, and i downloaded it when was launched. But there's a problem... the X flavour on the "Secret Sauce" is now broken (the drums sounds as GS with some pianos). Besides, you didn't add the global SysEx initialization as i expected  :(

2kode54 Hello! help me please, I'm trying to load HALion Sonic 3 but your midi plugin does not see it. HALion Sonic 3 is one of the best advanced VST for playing midi file. and i am very sad about this issue.  thank you for your work.

I already tried, HyperCanvas, Hypersonic, SOUNDCanvas and syxg50, they all works fine.

You can try a quick dirty hacky component http://www.saunalahti.fi/~cse/temp/foo_dyndec.fb2k-component (http://www.saunalahti.fi/~cse/temp/foo_dyndec.fb2k-component). It exposes the dynamically changing fields you need in %dartist% and %dtitle%. Probably best to use with some if function wrapping, something like $if2(%dtitle%,%title%).

Hi there!
@kode54, @Case,
if the foo_dyndec component is installed, then playing any midi file will crash of fb2k if the syxg50.dll VST-plugin is set.
Please see how this can be fixed?

The crashing is probably my fault. I noticed in the documentation that the function rendering the string can be called from multiple threads and I had not taken that into account. New version with appropriate protections uploaded to http://www.foobar2000.org/components/view/foo_dyndec (http://www.foobar2000.org/components/view/foo_dyndec).

Edit: changed the link.

Hi kode54, is it possible to add a never looping mode with adjustable decay time or lowest volume threshold after the last note ended? 1s decay time still chops off a lot of MIDI files.

I can make it do an auto decay search pattern once the file has ended, but I'll have to do this a bit later, as I need to set up my dev environment again.

Thanks!

"MIDI Player 2.2.12" has a new error which upon opening the respective Options page for foo_midi it just stalls and crashes Foobar2000 entirely.
No error popup either, just the generic (Not Responding) text above most Windows titlebars.

EDIT: Upon removing my respective VSTi path it now works, It would be nice to still have that VSTi support though.
Furthermore with these tests, it seems any VSTi will crash the options page now, as I have singled out many of them from 3 to 1 different VSTi's within the respective folder of choice.

VSTi will crash the options page now

same

I was advised to remove a message pump from my pipe processing loops, which were in place for both VST instruments and the Secret Sauce. This message pump was causing one of Case's input wrapper components to crash.

I need further input from Peter for what to do, since this message pump is 100% necessary when the pipe interaction happens in the main thread.

Edit: I've fixed at least a possible cause for indefinite hangs. It will still hang while scanning, and while displaying an instrument's configuration/editor dialog, but it won't hang indefinitely like it did for that brief release. Still waiting on a proper solution.

Edit: I've fixed at least a possible cause for indefinite hangs. It will still hang while scanning, and while displaying an instrument's configuration/editor dialog, but it won't hang indefinitely like it did for that brief release. Still waiting on a proper solution.

Completely fixed thank you very much, amazing work as always!
It's doesn't even "still hang while scanning, and while displaying an instrument's configuration/editor dialog".

Another note: "Skip to first note" option actually changes the VSTi instruments of certain songs.
Although I like this change, I understand if you wish to fix this.

thank you Kode54, how about supporting Steinberg HALion Sonic 3, foo_midi doesn't want to see that marvelous VSTi plugin. Belive me HALion Sonic is the best of the best. I tried many of them and I know that for sure.
I recently discovered it for myself and was simply amazed how my midi files sounded now. It allows you to customize any instrument as you wish and assign any effects you want for each of them separately.
You can also download tons of different professional instrument or create them by yourself and assign them status of general midi, and they will be loaded automatically when midi plays.
You can achieve sound comparable to professional soundtracks if you spend enough time and tune them all.

thank you! please don't ignore my message.

You need the VSTi 2 version of it to work. I'm not adding support for VST 3. Also, I thought that was one of those programmable and configurable synthesizers that you basically need to hand tune for every sequencing job you put it through, similar to Kontakt Player, so I don't really see that as too useful for this. The whole purpose of adding VST instrument support was to support the Yamaha S-YXG50 synthesizer, and everything else was an afterthought.

Hi kode54, thank you for your response, Steinberg HALion Sonic 3 already support VSTi 2. It can also work as it is by default without any additional settings. no need to hand tune if you don’t want it.

Yes, and what I'm trying to tell you is that the VST 2 plugin should work already. If it doesn't, I can't exactly test it without a license.

there is a free version steinberg halion sonic 3 se
https://www.steinberg.net/en/support/downloads/downloads_halion_sonic_se_3.html

"The free HALion Sonic SE download version does not contain any content."

How am I supposed to test this, then?

it should contain the standard General MIDI instruments.

Looks like a .NET hulking monstrosity. I don't think that will ever work in my host.

Why are you trying to use HALion in foo_midi anyway? HALion isn't well-suited for General MIDI playback.

I just checked anyway, even if I wanted to get the free version, it does not include any instrument content whatsoever, and still requires an eLicensor dongle to activate the free license code they gave me.

E: I figured it out. Their stupid library uses the VST 2 export "MAIN" instead of "main", I have added this as a fallback. It loads, it's configurable, but I have no idea how to make it produce sound. Good luck, whatever.

Thank you for your efforts, now it is loading. but there is no sound.

Why are you trying to use HALion in foo_midi anyway? HALion isn't well-suited for General MIDI playback.

halion sonic 3 specifically designed for General MIDI playback.

I have attempted to load Halion 6, but I guess I need to try Halion Sonic instead. I still can't figure out how to configure this thing from Preferences so it will eventually play GM sound. I've tried various things, I don't know why it's not producing sound.

It's also not helpful that I can't use any of this crap in Wine.

I made a picture for you. 5 easy steps to enable general midi constantly.

(http://imglink.ru/pictures/03-02-20/9b3ffd7d6939a68b20b4da6c5425d7e1.jpg)

my thoughts about the lack of sound. halion sonic 3 cannot detect asio driver inside foobar environment

It can't use ASIO output. It's supposed to be outputting through foobar2000, not the system.

Having an issue configuring loop settings. In previous versions of foo_midi, I configured the component to play indefinitely but only when loop info is detected in the MIDI file. However, with newer foo_midi versions, I can't seem to replicate this, and the play indefinitely option seems to play all MIDI files forever rather than just files with loop info.

Any comment on these alarming number of "malware" detection's from the recent midi plugin uploads? Like I get false positives, but with these many different sources, you never know if something might be a foot...

https://www.reddit.com/r/foobar2000/comments/f3qzq8/foobar2000_midi_component_2214_20200202_malware/
(https://funkyimg.com/i/32gM9.png)

Absolutely bullshit. Half of those files haven't even changed since the last time I updated, and they're still setting it off now.

I'm dying to see these files from before January 28th that somehow magically don't set off any scanners. Files containing modules that currently set off the scanner. Files that haven't changed in six or more months, and have verifiable PGP signatures.

Spent hours doing a rebuild, now it only sets off one major scanner. This scanner only accepts reports of false positive or negative from their customers, damn. Anyone want to help out?

Sorry for the problems. :(

I would never fathom that you would do something malicious, but sites can get highjacked and links get swapped out for fake ones, etc.

But thanks for looking into it and fixing it up/clarifying, I can sleep a little easier now. (Not that you really fixed anything, AV's are still random BS special snowflakes, lol, they probably all just copy each others "homework", change it a little and go, yup looks good, so if one says BAD!, a ton will too...)

Sorta off-topic now, but for whatever reason foobar2000.org is still not HTTPS in 2020, has Peter given any reason why it is the way it is? Can he not change it to HTTPS?

(https://i.imgur.com/ZlOUzxP.png)

I don't control foobar2000.org completely. It's HTTPS, but the HTTP doesn't force redirect to HTTPS, except on certain admin paths. I should bug Peter to change that, since he's really the one in charge of that server.

New Secret Sauce hashes. It appears that the trial version on Roland's website is now at version 1.06.
1.06 32-bit: 6588E6AA17A57BA874E8B675114214F0.
1.06 64-bit: 6ABFBF61869FC436D76C93D1BC7E2735.

Got your email. Your files will need meta indicators on the duplicate channel tracks.

It will need either:

Meta 4 or 9 on all tracks, with different device/port strings for each port track that is on the same channel. It doesn't really matter what the strings are, as it will simply detect two overlapping channels with different strings between the two (or three).

Or.

Meta 0x21, with the number of a port, on each channel track. The number needs to be different between different tracks that are on the same channel and need to go to different ports.

Currently, my code just detects unique instances of a name or number on a given channel. It "makes sense" to make them just port 0 for port 0, 1 for port 1, in that order. But I've seen files that have unique identifiers across the entire file, so I had to just dedup instead.

Oh, and I don't properly handle SysEx message splitting, so you'll need to do that yourself. Port 0 sysex will be sent to all three virtual ports, while port 1 and 2 will be sent to only their virtual ports.

Any comment on these alarming number of "malware" detection's from the recent midi plugin uploads? Like I get false positives, but with these many different sources, you never know if something might be a foot...

https://www.reddit.com/r/foobar2000/comments/f3qzq8/foobar2000_midi_component_2214_20200202_malware/
(https://funkyimg.com/i/32gM9.png)

I got the same virus/trojan warning when I updated foo_midi today. Avast flagged vsthost32.exe. Virustotal says that 18 different scanners identify it as carrying a trojan. Attached is a screen grab.

This is  vsthost32.exe version 1.0.0.12, dated 2/16/2020.

Where can I get the previous version of foo_midi until this is resolved?

Virustotal also finds funny business in file scpipe32.dll (screengrab attached.) I submitted all other exe and dll files, but these are the only two that were flagged.

false positives... I updated and haven't had any issues.... of course I do not bother with the insanity that is anti-virus... I just keep my PC locked down hard.. with top of the line firewall etc...

False positives. Please report them to your antivirus vendors as such. Previous versions are not retained anywhere, and it wouldn't matter anyway, because they're not specially whitelisted, either. You'll find versions from a year ago are now setting off "all new" detections for viruses that have just been invented.

Anyone want to pay me $500 for one year worth of automatic whitelist, the technology known as code signing?

false positives... I updated and haven't had any issues.... of course I do not bother with the insanity that is anti-virus... I just keep my PC locked down hard.. with top of the line firewall etc...

That strikes me as false bravado. The fact that you have allowed a program to update itself means that your computer is not really "locked down" - you have permitted outside files onto the local computer, and you have no practical way of knowing what those files are doing. Anti-virus is flawed, but unless you can view and fully understand the source code, you have little else to rely on. A positive alarm may not be a definitive last word, but it seems to me to be a valid reason to find out why the alarm was sounded.

False positives. Please report them to your antivirus vendors as such. Previous versions are not retained anywhere, and it wouldn't matter anyway, because they're not specially whitelisted, either. You'll find versions from a year ago are now setting off "all new" detections for viruses that have just been invented.

My previous version didn't set off any alarms, and I do full scans every once in a while. So, why did this one set it off? And 18 scanners suddenly going off seems like more than mere coincidence.

For example, I have a backup of the complete foo_midi component dated 11/27/17 (ver 1.0.0.11), and it scans clean with Avast (local) and Virustotal online. I also found another version of 1.0.0.11 from an 1/3/2018 update, and it doesn't ring any Avast or Virustotal alarms, either. It's only the 1.0.0.12 version.

Upload your file here, then. I'll make it my official version for now until forever, since I obviously can't use a clean virtual machine to develop any more, without "introducing" "viruses" into the mix.

The last two people who made this claim never bothered to upload their file to me. Maybe you'll be different?

E: Also, make your own VirusTotal upload and link to it here. That way, nobody can claim I "infected" "your" file in the process of uploading it.

Upload your file here, then. I'll make it my official version for now until forever, since I obviously can't use a clean virtual machine to develop any more, without "introducing" "viruses" into the mix.

The last two people who made this claim never bothered to upload their file to me. Maybe you'll be different?

E: Also, make your own VirusTotal upload and link to it here. That way, nobody can claim I "infected" "your" file in the process of uploading it.

OK. But it's not my claim, it's Ad-Aware, ALYac, Arcabit, Avast, AVG, BitDefender, Cyren, eScan, F-Prot, FireEye, GData, MAX, Sangfor Engine Zero, and TrendMicro-HouseCall's claim. And since two people here have noticed the issue, there are sure to be plenty more people out there who just haven't reported it.

Attached is foo_midi-files.zip, which has these files in it. They are renamed so as to not be easily executable. The first one is reported to be clean. The other two may not be. The newest files are from a freshly downloaded copy of foo_midi.fb2k-component.

vsthost32.exe (ver 1.0.0.1)

https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection (https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection)

scpipe32.exe (ver 1.0.0.1)

https://www.virustotal.com/gui/file/b39c95d47a270b3f3c629188e48fa878474d369b2f6ab79bc9e87be22a8771d0/detection (https://www.virustotal.com/gui/file/b39c95d47a270b3f3c629188e48fa878474d369b2f6ab79bc9e87be22a8771d0/detection)

vsthost32.exe (ver 1.0.0.2)

https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection (https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection)

I've downgraded foo_midi to the 2017 version until this is resolved.

edit: Attachment removed per request of poster.

Fine. I'm pulling all binaries for my components. You fuckers can compile your own goddamn shit.

E: Here, have a VirusTotal entry (https://www.virustotal.com/gui/file/ae61073f4603b6fab47cd940413a1345a61030f64f2df869a6b0110b11657a50/detection) on what would have been an update to foo_midi. See, one engine, based on a stupid AI, finds it "Malicious". Chances are, because of that, it's been submitted to all the other vendors for flagging as malicious as well, and it will have 17+ engines detecting it in short order. I'm done with this shit.

Quote from: kode54 on 2020-02-24 02:37:00

Upload your file here, then. I'll make it my official version for now until forever, since I obviously can't use a clean virtual machine to develop any more, without "introducing" "viruses" into the mix.

The last two people who made this claim never bothered to upload their file to me. Maybe you'll be different?

E: Also, make your own VirusTotal upload and link to it here. That way, nobody can claim I "infected" "your" file in the process of uploading it.

OK. But it's not my claim, it's Ad-Aware, ALYac, Arcabit, Avast, AVG, BitDefender, Cyren, eScan, F-Prot, FireEye, GData, MAX, Sangfor Engine Zero, and TrendMicro-HouseCall's claim. And since two people here have noticed the issue, there are sure to be plenty more people out there who just haven't reported it.

Attached is foo_midi-files.zip, which has these files in it. They are renamed so as to not be easily executable. The first one is reported to be clean. The other two may not be. The newest files are from a freshly downloaded copy of foo_midi.fb2k-component.

vsthost32.exe (ver 1.0.0.1)

https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection (https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection)

scpipe32.exe (ver 1.0.0.1)

https://www.virustotal.com/gui/file/b39c95d47a270b3f3c629188e48fa878474d369b2f6ab79bc9e87be22a8771d0/detection (https://www.virustotal.com/gui/file/b39c95d47a270b3f3c629188e48fa878474d369b2f6ab79bc9e87be22a8771d0/detection)

vsthost32.exe (ver 1.0.0.2)

https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection (https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection)

I've downgraded foo_midi to the 2017 version until this is resolved.

You ought to be banned.

Fine. I'm pulling all binaries for my components. You fuckers can compile your own goddamn shit.

E: Here, have a VirusTotal entry (https://www.virustotal.com/gui/file/ae61073f4603b6fab47cd940413a1345a61030f64f2df869a6b0110b11657a50/detection) on what would have been an update to foo_midi. See, one engine, based on a stupid AI, finds it "Malicious". Chances are, because of that, it's been submitted to all the other vendors for flagging as malicious as well, and it will have 17+ engines detecting it in short order. I'm done with this shit.

I warned you many times that the AV business is a protection cartel.

vsthost32.exe (ver 1.0.0.1)

https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection (https://www.virustotal.com/gui/file/bddb907d7b44ffa942b34cf4311160e0f70f2f45c12bc71c4c662e303f061911/detection)

vsthost32.exe (ver 1.0.0.2)

https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection (https://www.virustotal.com/gui/file/aee2b9707836a4696fe0c0d6c32f2a398b29ec70b257c1df604959eb24410f3a/detection)

Hey. You incredibly thick fuckstick. This is literally the only difference between those two files (https://bitbucket.org/losnoco/foo_midi/commits/8b59fdbb8e6d9d49e30dcd0afa64a35592690460). Oh, and maybe a new compiler, freshly downloaded from Microsoft.

Wow @rednoise all the way back to 2017 for a component that frequently sees several updates in a single month?  Really?  You're a total asshole, no developer at all likes that shit.

You ought to be banned.

If you mean because I uploaded a potentially infected file, you're right. That was a very bad idea. I was just trying to cooperate with the developer. I don't see how to edit or delete my post, so I'll report it myself.

kode54, if you still want the files, I'm happy to send them to you. Please don't take this personally. Nobody is claiming you intentionally  infected any files. Nobody is even claiming the files are definitely infected. The only claim is that something about them is setting off alarms in multiple virus scanning engines from different companies. Seems to me it would be a good thing to know exactly why. You're liable to get more people questioning it as time goes by.

Wow @rednoise all the way back to 2017 for a component that frequently sees several updates in a single month?  Really?  You're a total asshole, no developer at all likes that shit.

It's the most recent one I have besides the latest, and the developer says no others are available.

You are implying that someone, who is well acknowledged in the HA community as a developer, would willingly infect their own files.

Why would they do that?

AVs are a complete blackbox, and if you read the source code, you will see its entirely illogical to infect their own files.


EDIT: Ill use one of my own examples. I wrote an executable compressor. Apparently, anything other than UPX is "bad"

https://www.virustotal.com/gui/file/7aa8c756af59955d12d77788b3b5963add9416d2c220649c8813cb9facc95377/detection

That shows how broken the AV system is. AVs rely on signatures "only". There is no deeper analysis involved. At all.

I said I don't have old binaries. I have the old source code, it's a versioned repository going back at least a decade. Going back to old source and building it again with a new compiler will just result in more false positives. Hell, I'd be willing to bet that rebuilding it with a 2017 compiler will have the same problem, just from having a file build timestamp from this year.

Did I forget to mention that all of the source code is entirely public?

You are implying that someone, who is well acknowledged in the HA community as a developer, would willingly infect their own files.

No, I am not. Please read my post more closely.

Okay then. What exactly are you implying? That Microsoft's 2019 Community compiler is infected by design?

If you can produce builds that aren't detected at all, using the same toolkit and build environment that I use.

Fresh Windows 10 1909 x64 English ISO, downloaded from Microsoft. (size: 5,421,459,456; sha256: 01bf1eb643f7e50d0438f4f74fb91468d35cde2c82b07abc1390d47fc6a356be)

Installed into a fresh Linux Qemu/KVM virtual machine, using Gnome Boxes.

Switched to Virt-Manager for more flexibility post-install.

Install desktop updates to current status.

Install MSVC 2019 Community, and Clang-CL for some things now.

Install Git for Windows from its official site.

Git clone the entire bitbucket.org/losnoco/foobar2000 tree, recursively.

Build the component from the solution at <repository root>/plugins/foobar/foobar2000/plugins.sln

Fine. I'm pulling all binaries for my components. You fuckers can compile your own goddamn shit.
I'm done with this shit.

kode54, please don't let it get to you... :'(
and please don't de-list your components again... it saddens me when u do that...
I rely on your updates to keep Foobar2000 game music plugins working at their best and value your work...


I don't trust AV as far as I can throw them lol..

Kode54 all the componets I use were written by you and I have always considered u a trusted source.. ;^_^;

kode54, v2.3.1 doesn't show Yamaha VSTi to me

Okay then. What exactly are you implying? That Microsoft's 2019 Community compiler is infected by design?

I imply nothing. I state the fact that two files in this component trigger alarms from my AV and apparently with a number of other AVs. I'm not the only one to notice this. That is all.

I'd recommend sending detected files for false positive analysis to your antivirus vendor. That way you wouldn't stress the developer needlessly and you'd quickly hear from the vendor that the files are indeed clean. The false positive flagging won't stop unless paying customers complain loudly.

GDI you guys! This is why we cannot have nice things.

I'm putting them back, soon enough.

There's a new foo_midi, 2.3.2. The VSTi and Secret Sauce components require the MSVC 2015 runtimes, both 32 and 64 bit.

I'm putting them back, soon enough.

ok,  :'(  :'(  :D  :D

I'm putting them back, soon enough.

There's a new foo_midi, 2.3.2. The VSTi and Secret Sauce components require the MSVC 2015 runtimes, both 32 and 64 bit.

It works well and doesn't trigger any local or on-line AVs that I have access to. Thank you.

For the benefit of us many incredibly thick fucksticks (also known as every-day users, the target audience for Foobar2000 and its components,) did you find what was triggering all those AV engines? Or did our false-positive reports just catch up with their virus definition updates?

Sorry, I need to clean up my language. I must apologize for calling you thick like that, I was really mad and in a bad place.

Basically, I had to do the following:

This step may not matter: Create new VM in place of old, install MSVC 2015 Update 3, final.

This step may matter: After getting everything compiled again, submitting my package to VirusTotal myself, and rescanning a few times to make sure it processed everything. It caught a few false positives, including in Microsoft's scanner.

This step matters: I submitted my software, packaged in an encrypted ZIP with the password "infected", as per instructions, to Microsoft, and kindly asked them to verify my assertion that it wasn't infected. Within about 8 hours, they verified that it was clean.

This step also matters: Once the above was completed, I rescanned the original upload at VirusTotal, which now comes out 100% clean. Note that three of the executables still register individually as "Malicious" or something with Cylance, even though the top level package does not.

It seems whenever I make updates to any of the executable subcomponents of foo_midi, or even the main component, I will need to complete the day long process of submitting it to Microsoft for whitelisting, every time. Oh well. Maybe I can convince someone to extend an EV certificate my way...

Oh well. Maybe I can convince someone to extend an EV certificate my way...

I would donate again when I have some $ to spare...
bills are killing me most of the time so its hard when I don't have much food most of the time...
sorry Kode54

Nah, I didn't mean donations. More like another assist from the Mobile team. I'm already using their help to sign my macOS software. It was only an idea floated by Peter, in case it would help him with his false positive issues as well. Only considered since the last time he had a certificate, not EV, it sometimes resulted in worse experience than without a certificate.

ooh ok..

Corrected "with a certificate" to "without", oops. Yeah, there was a time when a "cheap" certificate was actually worse than no certificate.

I am a old user of foo_midi when only can select between Emu de MIDI and FluydSinth (with Foobar2000 1.3.3).
I recently update to last Foobar version and plugins. And I see many changes to configure that plugin.

I am a ignorant about MIDI world and only want play/convert some general midi files with the best quality possible.
I suppose than BASSMIDI is like FluydSinth to use soundfonts and the best option to choice, but there are many, and I don't know the parameters to configure it.

I read this thread entirely and I don't see many info about it.
There are some extensive documentation about foo_midi configuration?
Or you can be so polite to answer my questions here?

There is no need to change most of the defaults with BASSMIDI. You just need to load a SoundFont, or a list of SoundFonts with a priority order by the order they're listed.

Thanks to answer. Only a few questions:

- Resampling: Is better 16pt Sinc interpolation?

- Cached: X MB / 2.62 GB (the 2.62 GB is a limit?, the Soundfont is 4 GB, is a problem?)
Also the Soundfont claim have 24 bits samples but when record to flac (or wav auto) is only 16 bits.

- The MUNT section, what is? Click to set what?

I suposse the rest of default settings are the recommended.

Thanks to answer. Only a few questions:

- Resampling: Is better 16pt Sinc interpolation?

It's really only a placebo effect, but you're welcome to use it if you think it will improve the sound quality.

- Cached: X MB / 2.62 GB (the 2.62 GB is a limit?, the Soundfont is 4 GB, is a problem?)
Also the Soundfont claim have 24 bits samples but when record to flac (or wav auto) is only 16 bits.

BASSMIDI only supports 16 bit SoundFonts anyway, and even if that were not the case, you wouldn't be able to exceed about 3GB anyway, since the whole thing has to fit into a 32 bit process. I'll consider making an external BASSMIDI 64 bit process, maybe, if there's really a demand for hitting the limit of memory there.

(Also, I think I've tried this StGiga soundfont, and I wasn't really that impressed.)

- The MUNT section, what is? Click to set what?

MT-32 emulator, for MT-32 MIDI files. Supply your own MT-32 or CM-32L control and PCM ROM set, and it can play those files. Don't, and it won't.

BASSMIDI only supports 16 bit SoundFonts anyway, and even if that were not the case, you wouldn't be able to exceed about 3GB anyway, since the whole thing has to fit into a 32 bit process. I'll consider making an external BASSMIDI 64 bit process, maybe, if there's really a demand for hitting the limit of memory there.

Don't worry, is enough quality for me. I tested many free soundfonts an this one is the better for me, and seems work fine.

Thanks for all, your plugin and your answers.

Hi, I have a couple of questions/requests regarding foo_midi.

1. I use Yamaha S-YXG50 as my default plug-in, though in many cases I'd prefer to be using Roland SCVA. So far, I have only been invoking SCVA for the purposes of rendering select midis to audio, and then switching back to S-YXG50 for general usage, because of the impracticality imposed by SCVA's exceptionally long initialisation time. Is there any possible workaround for this problem, or is continued case-by-case rendering my best option? I had also been using SCVA with mudlord's VST MIDI driver and using a separate MIDI player so that it isn't initialised on playback of every song, that is until Microsoft decided to horribly break MIDI devices in a recent Windows update...

2. This one's slightly out of left-field - is there any possibility of Ensoniq AudioPCI Wavesets (eapci2m.ecw / eapci4m.ecw / eapci8m.ecw) becoming supported in foo_midi/BASSMIDI? They were also used by some later SoundBlaster cards like Live! and Audigy, where the MIDI device named Creative SW Synth utilised them.
Failing that, are there any other apps I could use to play midis with these soundbanks? There was an ECW to SoundFont conversion utility (ecw2sf2.exe) released around a decade ago, I don't know if it is still online anywhere, though I still have it locally and could share it if it is of interest. Unfortunately it does not work very well, otherwise I'd just use the resulting SoundFonts in BASSMIDI and call it a day. These soundbanks were how I first experienced General MIDI in the late 90s, so I suppose I have a particular fondness for them.

Any pointers would be most welcome, thanks.

For Sound Canvas VA, you might want to try the Secret Sauce option, which uses the Sound Canvas engine directly and as a result runs much faster than the official plugin. Just set the Secret Sauce path in the advanced settings to the location of the VSTi.

Thanks for the reply Slender.

That sounds intriguing, though I'm not having any joy so far. I've copied the directory into the Secret Sauce path and closed/reopened the Preferences window, but I don't see anything about Secret Sauce appearing anywhere in the MIDI Player configuration; I'm assuming it would appear as a new output plug-in?

I read kode54's post earlier in the thread that Secret Sauce only works with whitelisted versions of SCVA, which may possibly be the issue as I'm using v1.00. Is there a list of versions that are known to work?

Yes, it would appear as an output plugin. Make sure there are no quotes around the path as well. If it isn't recognized, you might want to post the MD5 hash of your copy of SCCore.dll.

Ahh, success. I decided to update to v1.16 (S) (Build 1160) for some other reasons, and now this works. Gosh, it is significantly faster and actually usable. Thanks for the tip.

In case this is still useful information, I generated an MD5 of my previous version:

FD2FFC7229042738718278239D4B0EC4

A friend was also having the same problem with a different version, v1.11 (S) - Build 1110. Curiously it was said to be v1.00 when loaded in foobar2000, which could mean mine wasn't v1.00 either, but anyway:

DBD9A30C168EFEF577D40A28D9ADF37D

Enjoy :). As a sidenote, you could actually just copy SCCore.dll somewhere in case the hash changes in the future. From what I can tell, as far as emulation is concerned, the project is basically complete, and any future changes seem to be focusing more on UI improvements and fixes. SCCore.dll is completely independent of the VSTi as well. You don't need to keep around any data files to use it, and in fact you don't even need Sound Canvas VA itself installed, either, just the Visual C++ 2015 redistributables.

FYI, they have made bug fixes to the SCCore module, so newer versions may be different. I should make it so that the hash check is only a warning and can be disabled, as it doesn't look like they're ever going to change the binary interface it implements.

Hello, http://www-personal.umich.edu/~tdkim/midi/tf4-cred.mid doesn't play properly for me using foo_midi, some notes are missing. Timidity under Linux plays the missing notes fine.

Mind investigating? Thanks.

At what point? Using which MIDI synthesizer?

I am using the BASSMIDI plugin, some notes are audibly missing at 13 seconds in, but is there if I manually reseek. After awhile the instrument goes missing again. I am using the Fluidsynth R3 soundfont.

@j34

Please upload recordings (first ~30 seconds) of tf4-cred.mid played in foobar2000 and Timidity under Linux using FluidR3_GM.sf2 which demonstrate the playback issue you are reporting. I played tf4-cred.mid with FluidR3_GM.sf2 in foobar2000 and XMPlay, both played them identically without any missing notes. I verified that with a different SoundFont.

I was able to replicate notes dropping in Cog on macOS Big Sur, but only with the Apple system DLS/SF2 synthesizer, not with BASSMIDI.

Thanks @deus-ex and @kode54 for the clues, I found out what the problem was. Turns out I wasn't using the FluidSynth soundfont at all loaded through an sflist file, it has been a while since I last changed it.
It was an older Timbres of Heaven 3.92 that was a problem, upgrading to 3.94 solved the missing notes.

Sorry for the noise.

@j34

You're welcome, glad you could solve your issue. No need to feel sorry, though. You had a problem, came asking for help, and with our input you could solve it. That (among some other aspects) is the purpose of a support forum, right?

I agree, we helped you to look elsewhere for your problem, and it turned out to be a configuration error, and an outdated sample bank.

is there any possibility of Ensoniq AudioPCI Wavesets (eapci2m.ecw / eapci4m.ecw / eapci8m.ecw) becoming supported in foo_midi/BASSMIDI? They were also used by some later SoundBlaster cards like Live! and Audigy, where the MIDI device named Creative SW Synth utilised them.
Failing that, are there any other apps I could use to play midis with these soundbanks?

Any word on this? (remaining faintly hopeful.)

The format isn't documented anywhere, and I only support SF2 because that's what BASSMIDI implements. If you want, I could forward the request to Ian Luck, the author of BASS and BASSMIDI, but I don't know how well he'd do at it, with no documentation. Also, he hasn't implemented DLS support, either, and that's actually quite well documented, so there's that.

@kode54

Thanks for another fine release of foo_midi (v2.4.5).

Playtesting through my MIDI file collection I found a couple of files where the song titles are not displayed (attached below). The titles of these MIDIs are each stored in the field 'TRACK_MARKER'. Would it make sense to add a check of the TRACK_MARKER field for the title, too? Or do these MIDIs have it wrong and it is an uncommon exception?

Track marker means that it's a position marking metadata event in any possible track. There may be multiple across different tracks, or even multiple in the same track. This could, for example, lead to Final Fantasy VII tracks having a title of "loopStart".

Thanks for taking a look. Although I was almost certain of the outcome, I thought it's better to ask an expert on the subject rather than guessing on my own.

Please find attached a small collection of MIDI files that foo_midi v2.4.5 fails to load. I rechecked them today with the most current XMPlay.exe/Xmp-MIDI.dll, and there all these files do load and play successfully. Perhaps this collection allows you to harden the foo_midi file loader?

I have changed the MIDI processor to be able to play all of these as-is, and attempt to recover any playable tracks from a given file, but they won't be perfect. Probably the best that can be expected, given the damages.

Wow, that's terrific! My huge thanks!

I kept these MIDI files for the sake of testing only, I actually never listened to these files except for the first few seconds. So I just installed foo_midi v2.4.6 and tested the 'load fail' set again. The majority of these files now indeed load and play, yet there are a couple of MIDIs which are still not accepted by foo_midi here. Not that I would mind too much, but I think it's better you are aware since you said they would load fine with the recent changes to the loader.

Here's a list of the files which still won't load:

Here's another set of MIDI files where foo_midi reports a wrong duration. I just retested these with foo_midi v2.4.6 and the most recent XMPlay/Xmp-Midi binaries. I adjusted the timestamp of each file to reflect the duration reported by XMPlay for easy comparison.

The file NATURAL.MID of this set is a special case, therefor I wrote the filename all uppercase. Foo_midi reports a different duration depending on whether the file is currently played or not. Also, a different duration is reported almost every time when the file is played.

The question is whether the duration calculation of foo_midi can be improved, of course with reasonable effort and effect?

Try again.

Also, the files that throw "bad exception" on open, claim to be MT-32 files, and you need to set up the MT-32 emulation to play them. Although for some reason, they don't seem to work with it.

Thank you for further adjustments and improvements to foo_midi.

I do not have the MT-32 emulation (MUNT) configured, it requires the installation of an additional external application and/or drivers. As I do not have any MT-32 files in my collection this would be in vain. These files (load fail/wrong duration) belong to a testbed of MIDIs that cause certain errors or exceptions, but they are not part of my MIDI collection which I like to listen to. So if a few of these still won't load here, then that's fine with me.

It requires nothing more than either the MT-32 or the CM-32L control and PCM ROM dumps, and it will prefer the CM-32L if it finds that first. It will require you to configure a folder in foo_midi's preferences page, under the Munt data path. Just click the edit box to open a folder picker dialog, and navigate to somewhere it can load the above from.

I recommend stuffing them under either your personal or the system shared Music folder, in an MT-32 subfolder. Or anywhere on your main OS drive. They're under 1MB.

You do not need to supply your own copy of Munt, as it is linked into the plugin already, and only needs the ROMs.

Thanks for the details on the required steps for the MUNT setup. This will come in handy when I try this out. Also a good reference for any interested foo_midi user.

So, what's your opinion on the 'wrong duration' file set I uploaded previously? Do you see an opportunity to improve the calculation of the MIDI track duration?

The latest fixes seem to have caused regressions with some files. For example, this file now claims to be over one day long, and sounds broken in Secret Sauce.

Should be all fixed now. I accidentally forgot to recompile the plugin after making major changes.

Confirmed, the update fixed the duration reported for zero88.mid. But the MIDI file set 'wrong duration' I provided remains unchanged in this regard. Have there any changes been made regarding the duration calculation?

EDIT: Correction, NATURAL.MID, and Romeoa.mid no show the correct time. The reported duration of the other MIDIs is still off. This issue seems harder to come by than expected. Don't take this to heart, though, I'm not complaining, just reporting. ;)

There's nothing I can do about that. The files are broken. XMPlay is doing some magic to make them work. There is nothing that can consistently gather duration from broken files.

EDIT: I see what's wrong on most of these files. They have events end well in advance of the actual end of the tracks. I can truncate those too.

Sounds great. I'll stay tuned.

Should be fixed now, I hope.

Yes, that did it, foo_midi can do some magic, too. Congratulations!

Now, if you don't mind, I have one last item left to suggest. Find attached a selection of MIDIs where channel 16 is used as a second drum channel. Due to this, regular playback of these files sounds quite off.

Could you perhaps add a menu toggle to switch channel 16 to play the drums instrument? Another idea I have is to add a marker to the file name, for example '@CH16' or '_(CH16)', which foo_midi checks for and takes appropriate action.

EDIT: The only player I know to be capable of doing this is the good old Open Cubic Player for DOS. There you would enter a letter 'd' at a designated field of the built-in playlist editor, and Open Cubic Player would assign channel 16 to the drums for that MIDI file.

I can make an override that gets saved to the per-file preset, the same way as other MIDI settings, to an internal database. It could handle 11-16 in two different ways:

1) Drop them entirely.
2) Remap them to 1-5 and 10, on a second port.

I have listened to these MIDIs quite often, also tried them with channel 16 toggled off. Certainly, remapping is the way to go, as dropping channel 16 would have these tunes lose too much of their character.

Could you please explain how one would go about saving per-file presets to an internal database, or is this entirely on the developer side? I wouldn't mind, if so, as these are all of the MIDIs with a second drum channel I have encountered so far. Meaning, they are not that common.

You would select one or more MIDI files, right click, then select something from the context menu, under tools.

In other news, I fixed the outstanding random length issue.

I don't see any 'Tools' entry in the context menu (screenshot). There's the known 'Utilities' entry, but that doesn't appear to hold any command allowing me to change the MIDI channel setup.

(https://i.imgur.com/GPhzYta.png)

Remapping channels could be useful for other things as well, for example MIDIs that are multi-port but lack the necessary information.

I just noticed 14 years after I made a request on the XMPlay forum, that Ian (XMPlay author) implemented auto-detection of MIDIs with a second drum channel on Ch16 into the Xmp-Midi plugin back then, in 2007. I thought my request couldn't be realized and I never checked that particular issue again. So I missed this feature for about 14 years. Crazy...

Here's how Ian solved the issue, actually quite simple and elegant:

I have another idea... if channel 16's track name includes "drum", assume it's a drum channel. That works for 19 of your 22 files :)

The original post can be found here: https://www.un4seen.com/forum/?topic=5337.msg45080#msg45080

EDIT:
Actually today Xmp-Midi recognizes 22 out of the 23 MIDIs with a second drum channel on Ch16. The one not detected is Mood.mid.

Sorry, brain fart. I meant Utilities. It doesn't help that I don't run foobar2000 most of the time now. And I haven't implemented the feature yet, anyway.

No harm done, I figured almost as much. Please check my previous post (reply #282) which provides a simple, working solution to the auto-detection of MIDIs with a second drum channel on ch16. It works great in XMPlay. Not only did I forget that I suggested it to Ian in the first place, I even didn't notice its realization for 14 years! Guinness World Records committee, here I come.

Hi, I recently found an odd bug. It seems that this MIDI file is completely silent when played with Secret Sauce or any VSTi, though it seems to contain some data, as BASSMIDI does manage to play it.

It is a bug in Sound Canvas. That MIDI file uses a royal shitload of GS control messages, and I do not know if there is any legitimate GS synthesizer which will play the file. BASSMIDI and all the fm synthesizers in foo midi get by by not supporting most of that crap. Feel free to report the bug to Roland and hope they actually listen.

Actually today Xmp-Midi recognizes 22 out of the 23 MIDIs with a second drum channel on Ch16. The one not detected is Mood.mid.

After further investigation, it turned out that Mood.mid actually doesn't have a second drum channel. So XMPlay accurately detects 22 out of my set of 22 MIDIs using a second drum channel.

I'll look into adding case insensitive detection of "drum" in a track name for the 16th channel, which will require checking which channel(s) a given MIDI track uses.

@kode54

I noticed that each time the last item played in foobar2000 is a MIDI file, the foobar2000 process isn't properly terminated on application shutdown. I then have to terminate the foobar2000 process via task manager to be able to start foobar2000 again. Playing other formats like FLAC, MP3, OPUS, OGG, WAV, and various tracker module formats the issue does not occur. This means I can play any MIDI file and shut down foobar2000 properly, as long as the last played item is NOT a MIDI file. Also, it makes no difference whether the currently played MIDI tune is stopped before shutting down foobar2000.

To verify that this isn't related to any other plugin I use, I ran foobar2000 with foo_midi as the only additional plugin. I checked with the foobar2000 releases v1.6.4, 1.6.5, and 1.6.6 beta as well as various versions of foo_midi ranging from v2.4.5 to 2.4.11. Yet the issue remains reproducible.

I'm running foobar2000 on Windows 10 Pro 64-bit 20H2 (19042.928).

What are your settings? I cannot reproduce this issue.

What are your settings? I cannot reproduce this issue.

I'm using foo_midi's BASSMIDI output with the following settings:

(https://i.imgur.com/uKMf2Wd.png)

Because you wrote you cannot reproduce, I investigated further, now testing through the several output options of foo_midi. The issue would only appear when using the output BASSMIDI. So I edited my soundfont.sflist to reference only one base GM-soundfont instead of my 66 soundfonts that also reference unique instruments, but that didn't help anything.

Finally, I replaced the latest stuff releases of bass.dll (v2.4.15.46) and bassmidi.dll (v2.4.13.14) with the ones included in your foo_midi distribution. It turned out that the issue is related solely to bass.dll (but not bassmidi.dll), replacing it with the official release v2.4.15.00 (included in foo_midi distribution) fixes the issue.

Apparently, Ian made some changes to the stuff release of bass.dll that is causing the issue with foo_midi. If those changes find their way into the official release of bass.dll, this potentially could lead to similar issues later.

I'll report the issue to him, then. If necessary, it may require a minidump to be made of the hung process, hopefully compressed. I can try to reproduce it myself now that I know what causes it.

Edit: Reported on the BASS forum.

Please let me know if I can help with anything on the issue.

I'm happy to report that Ian was able to identify and fix the issue. For a more detailed insight on the root cause and solution please check his post (https://www.un4seen.com/forum/?topic=19348.msg135340#msg135340) in the related XMPlay forum thread.

Thanks again for your support with the issue, Kode54. :)

I was made aware that any application asking for donations within the app, even if it doesn't provide any extra features, but I do (adding your name in the credits if you have been a Patreon subscriber), then I would need to seek at least a Shareware license of BASS for each product that I offer, and at most ever accept €40 from a given person. I have already violated these terms enough times, yet never managed to hold on to a minimum of €125 for Cog, and another €125 for foo_midi.

So, I am now in the process of switching all of my MIDI synthesizers from BASSMIDI to FluidSynth. I will be attempting to support compressed audio streams for sf2pack files as well, but that will come later. The compressed audio support should be simple enough to support, at least in foobar, and probably also in Cog.

There is no donation option or request found in the foo_midi plugin or the component download page. I wasn't aware you are optionally asking for donations somewhere. As far as I can see on Ian's page the bass license terms do not restrict/forbid donations. It limits the amount of money to be charged per product using the bass library if you are actively selling the product, which you clearly do not.

Quote from the Bass license found on http://www.un4seen.com/bass.html

BASS is free for non-commercial use. If you are a non-commercial entity (eg. an individual) and you are not making any money from your product (through sales, advertising, etc), then you can use BASS in it for free.

You are not making any money with foo_midi nor is any advertising involved. You are providing an option to make a donation for your services in general on the Cog homepage (https://cog.losno.co/). The donation is clearly optional and not related or required for the access/usage of the product.

Even if Ian would have any concerns regarding donations, which I doubt, I'm sure you both are able to find a mutual agreement. You should definitely seek Ian out and discuss your situation, before jumping to drastic changes like exchanging the BASS midi synthesizer with FluidSynth.

I have posted on his forums. Someone else is welcome to maintain a fork of the plugin which uses BASSMIDI, and never ask for donations.

I think you may have perceived that incorrectly:

Quoted post (http://www.un4seen.com/forum/?topic=18153.msg127427#msg127427) from the Bass forum

Yes, if your software includes a donation button then a Shareware licence would be needed to use BASS in it,
as you would be making money from it. The occasional donation above 40 Euro will be OK.

EDIT:
Ian also provided a simple solution, in case your product does include a donation button.

Quoted post (http://www.un4seen.com/forum/?topic=15285.msg105940#msg105940) from the Bass forum

A Shareware licence would indeed be required for that arrangement, as you would be making money from the game.
You could perhaps get around that by asking for donations for hosting costs/etc rather than the game, but that would
need to be unconnected to the game, eg. there would be no requests for donations in the game itself and the donations
wouldn't buy the user any extra features/downloads/support/etc for the game.

/EDIT

You are good to continue without a license if your product does not include a donation button. Also, an occasional donation above 40 Euro will be OK.

Perhaps you are (understandably) a bit pissed off right now about the issue. On the Bass forum, you went straight ahead and shut the door waving goodbye WITHOUT awaiting a reply from Ian. You should at least wait for his response. I think the chances are not too bad the issue will be resolved positively in your interest. Oh, and ours, of course. :)

If I perceived it correctly, only the app Cog currently includes a donation button. Cog is available for the MAC platform only. You could either isolate the issue by removing BASS from Cog only or by removing the donation button from the application

Apparently, you couldn't wait to create facts? I don't understand why you don't seek dialog first. I was trying to help and build some bridges...

Well, while you are at it you overlooked removing this from the foo_midi component page:

It also supports Ian Luck's wonderful BASSMIDI SoundFont (.sf2) based synthesizer, including bundled support
for his .sf2pack format, which is nearly identical to the basic .sf2 format, except the file identifier is "sfpk"
instead of "sfbk", and the audio section of the file is a compressed format supported by BASS that also supports
seeking, as it decodes the samples as they are referenced by the MIDI files. The compressed format is identified
only by its bitstream properties. BASS includes support for MP3 and Ogg Vorbis samples, while plugins are bundled
to support FLAC, WavPack, Musepack, and Opus format samples.

Bring us back in_midi by Peter  :))

Keep calm!

I was made aware that any application asking for donations within the app, even if it doesn't provide any extra features, but I do (adding your name in the credits if you have been a Patreon subscriber), then I would need to seek at least a Shareware license of BASS for each product that I offer, and at most ever accept €40 from a given person. I have already violated these terms enough times, yet never managed to hold on to a minimum of €125 for Cog, and another €125 for foo_midi.

So, I am now in the process of switching all of my MIDI synthesizers from BASSMIDI to FluidSynth. I will be attempting to support compressed audio streams for sf2pack files as well, but that will come later. The compressed audio support should be simple enough to support, at least in foobar, and probably also in Cog.

That's truly a sad news. Now non-GM MIDI files are completely screwed up. Even with GM files the 7-point interpolation is producing horrible artifacts or obvious frequency response change in some files. I think I will stay with the previous version of foo_midi forever, just like I am still using your old version of BASSMIDI driver.

Good. I don't really maintain foobar plugins that much any more anyway. Maybe someone else should take over, and remove all traces of the Patreon credits.

Anyway, reading from many previous posts complained about virus, limitations of sf2 standard (e.g. MSB and LSB patches cannot coexist), malformed MIDI files... I did post some files but that's because the issues were specific to foo_midi, and I did not report files which are also problemtic for some other popular sequencers like Cakewalk, Reaper and such.

And secret sauce. I have an SC-D70 and I must say Roland sucked, and sucks, you rock. That SC-VA is piece of crap.

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

I am totally impressed that you even took that HALion request seriously, and added non-standard loop point support though I have no use of them.

Basically, I was totally happy with foo_midi, especially when 16 point interpolation was added and some GS/XG specific commands were added. These are not supported in your old BASSMIDI driver. I did try OmniMIDI but it just can't replace your stuff. A big "thank you" I must say, and respect your decisions.

Perhaps this is in vain. I attempted to get some answers regarding the terms of the BASS shareware license and Ian replied to my questions: https://www.un4seen.com/forum/?topic=19365.msg135429#msg135429

Basically, Ian confirmed that there was no need to remove BASS from the foo_midi plugin.

Oh well. Kind of too late now, since I don't think I'll be reversing this decision.

Edit: The source still supports it, so if someone wants to make a fork that supports it, the license permits that.

Oh well, you kinda seemed rushed when you went ahead removing BASS altogether. I strongly doubt anyone is going to pick it up and reinstate BASS into a fork of foo_midi. So I hope you will reconsider your decision. It would be sad to see BASS be gone forever.

Anyway, I would suggest keeping FluidSynth implemented as is and add back BASS so that you have two independent MIDI synthesizer solutions to choose from. Maybe put each synthesizer into its own subfolder, so the files are structurally more organized and distinguishable. This layout would provide you with flexibility and freedom, should any future circumstances require you to make a similar decision again, which of course I hope will not happen.

I cannot make folders for the dependencies, as they're loaded on component load, so they have to be in the same folder as it.

Hi. A couple questions about the switch to FluidSynth...

1) Will sf3 be the only supported soundfont compression method or will sf2pack
support be added? Some sf2 files refuse to convert to sf3 using MuseScore sf3convert utility.

2) What about SFlist functionality? Loading a sflist and playing a file crashes foobar now.

These issues could easily be sorted out by returning BASS to the plugin. Or, if that's kinda impracticable, let two solutions co-exist: foo_BASSMIDI and foo_FluidSynth. Here's hoping...

No.

Would it be possible to add a gain multiplier for FluidSynth mode similar to what VLC has (admittedly, buried in their advanced options)? I use a high quality soundfont (http://midkar.com/soundfonts/) that also has ridiculously loud base gain, which gives me literal headaches when listening to a mixed-media playlist since apparently nobody makes in-line volume controls on headphones any more. A Gain Multiplier would let me set 0.15x as the multiplier, which would put MIDIs back in line with my other music.

The gain is already set to 0.2, so you'd need to set it to 0.03 for that soundfont.

Oh cool, so the option already exists and I just can't find it.

Where do I set the soundfont gain?

I don't have an option for it. I'll have to add one.

Hello,

I'm trying to play the MIDI files provided for The 7th Guest. They came with my purchase on GOG, but the same files are also available on Mirsoft: http://www.mirsoft.info/gmb/music_info.php?id_ele=MTI3NQ==

As per description, tracks 1 through 6 ("converted from the game by unknown method") work fine, but all the others ("converted from XMI using Winamp") aren't even recognized as a supported file format. I just get an error "Invalid MIDI file".

Is there something I can do to make them work with foo_midi? I'm not knowledgeable about MIDI at all, I can only say that they work in Windows Media Player.

I've fixed that bug now. It was an issue with there being tracks with zero duration. Now it checks only if there is at least one track with a duration.

Wow, that was really quick! Thanks a lot, I can confirm all tracks work with the new version.

I was curious and tried to set RG for a midi file. It worked. But I cannot find the database where that info is stored in. Where does it hide?

Foobar2000 profile folder, under the "indexes" subfolder.

Thank you, I found an index-data folder which seems to have the tags looking at it in a hex editor. Is there a way to clean up these extraneous indices? Mine is full of random data from ages ago.

Also do you know why some midis fail with foo_verifier with 'reported length inaccurate', while others don't? Being midis I suppose there is no length specified in the file at all, but the synthesizer has to report. I was curious what would happen if I ran it on the midis as well.

Don't bother using foo_verifier with any synthesized or sequenced format. The length reported doesn't include configurations for playing an extra second at the end if enabled, or for loops, which are also not reported as total length.

I see, thank you for the explanation. And thank you very much for foo_midi, it's a lot of fun to try different soundfonts. I'd be curious to know what format that database is in, but it seems to be proprietary stuff from Peter. Open source fb2k would be so great - deadbeef doesn't come close, even if it looks similar.

The file format is proprietary, but the database only stores an APEv2 tag of the metadata.

I see with Fluidsynth, it uses bit more CPU and memory usage compared to BASSMIDI when starts new playback. I wonder if its because of this lib or you could fix it in plugin. Cached always display no info, is it because not being used? Anyway just found this sf2convert (https://github.com/KKQ-KKQ/sf2convert/) to convert soundfont to sf3 if anyone need :)

For anyone that had the same problem as me, with their default Windows soundfont for BASSMIDI not working anymore, this version of the default Windows soundfont seems to work with the new version with FluidSynth:
https://musical-artifacts.com/artifacts/713

Ever since the last version 2.6.0, when I rapidly search a midi track clicking the progress bar, it makes foobar crash.

Edit: Confirmed regression, just tested and 2.5.7 doesn't have this issue for me.

Ever since the last version 2.6.0, when I rapidly search a midi track clicking the progress bar, it makes foobar crash.

Edit: Confirmed regression, just tested and 2.5.7 doesn't have this issue for me.

Happened to me as well.

Should be fixed by 2.6.1.

I can still reproduce the issue as of 2.6.1.

Yes, still happens unfortunately. Happens a bit less, maybe?

Send me files. Tell me what drivers or plugins you're using.

If they're bundled with Windows, I already have them.

This is my setup. I use the "GeneralUser GS 1.471 - for use with FluidSynth 1.0.9 or later" soundfont.
The DSP list is empty so Effect DSP, Headphone EQ, SoX Resampler etc. don't really matter I think.
foobar2000 set to "Primary Sound Driver", non-exclusive, and in Windows Sound panel I have ticked "all enhancements disabled".

Did I miss anything?

I don't have any problems with VSTis at all before the last update that fixed problems that the previous one before that caused, playback would simply stop if I seeked while it's playing, now it works normally.  It's the built-in stuff like the Nuclear Option, Emu de MIDI, etc. and the FluidSynth that can cause problems with any MIDI I try to seek while it's playing resulting in infinite hangs or crashes.  Before the last update I couldn't even load a different MIDI sometimes without crashes or infinite hangs.

Ah yes, also, I use "FluidSynth" with that mentioned soundfont obviously.

Edit: Also confirmed that it happens not just with FluidSynth but all the other plugins I was able to test, too.

Meh, I just rebuilt that, too. I may need to set vcpkg to retarget it for Windows 7.

Thanks, I tried something new. Let me know how it works.

Still got crashes on my end.  Even trying a portable clean install to only experience the same as before.  One improvement is unlike before is the crash dumps seem to have more useful data in them instead of being empty files and the crash report dialog box does show up.

This is a crash report for 2.6.2. Foobar doesn't seem to always dump after crash, in fact I had to make it crash like 10 times for a report to appear. Thanks for your efforts so far.

I guess I'll ditch FluidSynth and go back to BASSMIDI then.

Just in case you missed my earlier edit, I had the same thing happen with all plugins except for MUNT (just because I don't have it set up) so it seems to be a general issue.

I found a more likely way to cause it: Setting the mixing sample rate to 192 kHz. I'll try to debug it.

Oh, my god. You're going to hate this.

In my play function, it has a block at the start that renders any time left over from the previous call. It's supposed to repeatedly loop sometimes, if we're doing blocked rendering. It's supposed to scope the sample count to how many the caller requested, minus how many have been rendered already.

It was scoping against how many have been rendered, minus how many are requested. Subtracting to an unsigned type, with what would otherwise be a negative result. This resulted in the comparison always failing.

Fixing that, then the while() loop was never escaping if the loop rendered less than the leftover samples, because the loop condition didn't check that state either.

A two-fer! Everything should be lovely now.

Well I'm glad it was a sufficiently crazy bug and that it's gone now. Cheers! ;)

Tested. Yep, it's all working now.

No crashes to report here.  Works great now.

I can also confirm that the crashes are gone, thanks for the fix! :) However, I found an issue with Secret Sauce. It seems that the map isn't updating properly when set from the MIDI filter preferences, for example when I set the flavor to GS SC-88 Pro or GS SC-55, it continues to use the SC-8820 instruments. Disabling reverb and chorus isn't working as well.

Filtering should work properly now.

Indeed it does, thanks.

@kode54

I haven't posted here for a long time. Well, i decided to update foo_midi, to test if the "CoInitialize" error would be fix (always i get that error every time that i play a song again, after stopped it for the first time, and mainly happens with midi files), when i was going to set it up, i found an option called "MIDI Filter" that replace the "Secret Sauce" option, but that it worked only with SC-VA, i tested it with the S-YXG50 with the GS flavour (there's four options, but i chose SC-55 because it is the closest) and works!, works with S-YXG2006LE too, now i don't listen a "melodic" drum channel anymore!

I just came back to thank you. I don't know in which version was added because i don't updated it since 2020, but i like that new feature, it's exactly what i wanted! Thanks!

Hi @kode54
Just want to say thanks for creating & maintaining foo_midi - it has been one of my essential plugins for all of my foobar2000 installs over the years.
I'm not sure if you would be willing to accept any feature suggestions (and if not, that's fine), but if possible it'd be great to have a strictly MT32 mode in Super MUNT GM.
I'm in the minority who grew up with only an MT32 and wasn't aware of the GM Reset utility, and as such all of the MIDI music I have listened to back in the day was in MT32 mode - so that's the sound that I know and love (I'm a weirdo, I know).
I'm using one of the MT32 soundfonts for nostalgia purposes, but it would be amazing to be able to listen to GM midis in MT32 mode through Super MUNT.
Thanks again!

MT-32 mode swaps in automatically for any file with MT-32 SysEx commands in it. It's also possible to right click on a MT-32 reset .syx file and a .MID at the same time and force it to apply that .SYX to the .MID, using a context menu action. This state is stored in a database, and doesn't modify the files.

MT-32 mode swaps in automatically for any file with MT-32 SysEx commands in it. It's also possible to right click on a MT-32 reset .syx file and a .MID at the same time and force it to apply that .SYX to the .MID, using a context menu action. This state is stored in a database, and doesn't modify the files.

Thanks, I've figured it out!

For anyone else with the same request:
1. Grab the MT-32 Reset zip file from here: https://www.midimusicadventures.com/queststudios/mt32-resource/utilities/ and unpack the .syx file anywhere you can easily find (preferably in your MIDI folder)
2. Select the midis you want to listen to in strict MT-32 mode and drag them into the foobar2000 playlist
3. Drag reset.syx into the playlist
4. Select everything in the playlist from inside foobar2000, reset.syx included, right-click, choose Utilities -> Assign SysEx dumps
And you're good to go. If you need to clear the sysex assignment, just right-click and choose Utilities -> Clear SysEx dumps.

kode54!
Hi, I am a MIDI lover.
I am using DeepL translation and it may be incomplete.
I have an SC-88Pro and would like to use Foobar2000.
I have been using a Japanese software "KbMediaPlayer" to play MIDI, but I would like to move on.
However, foo_midi.dll does not have a MIDI output function.
I would strongly like to add the ability to output MIDI externally.
If I am worried about the operation of VU meter or Spectrum, the average user would send the audio output from the sound source to the PC.
Then, wouldn't the VU meter and spectrum work by sending the sound from the microphone (input) for hardware MIDI such as SC-88Pro, or the speaker (output) for VirtualMIDISynth, Timidity, etc., to Foobar2000?
Since there is no problem without visual effects, can't you at least support MIDI output?

Hello, just here to make an interesting suggestion, since i love this foobar plugin.

Is possible to implement miniBAE in foo_midi? miniBAE was a midi synthesizer for embedded tiny devices such as dumbphones in the year 2000s (for example, Nokia phones), years ago the source code was released as BSD license, and fans made a fork which is a modern implementation of this engine, you can take a look: https://github.com/zefie/miniBAE

It works very similar to SF2, for example, instead of SF2, it's .hsb (or .gm in some cases) format soundbanks, the same ones used in dumbphones from that decade. The point of this suggestion is to have a convenient way to reproduce midi files with this engine, and make audio renders of these in WAV/FLAC/MP3.

That's my suggestion, thanks for the plugin :)

Hello,
Cisco Secure Endpoint reports component file as being infected with W32.3C0B1B053C-90SBX.TG. Any option to fix it?

Hello,
Cisco Secure Endpoint reports component file as being infected with W32.3C0B1B053C-90SBX.TG. Any option to fix it?

Yes, report as false positive:
https://hydrogenaud.io/index.php/topic,120969.html
Also...
https://hydrogenaud.io/index.php/topic,98907.msg980128.html#msg980128

Any chance for a fb2k v2 compilation of the plugin?

Any chance for a fb2k v2 compilation of the plugin?

Since kode54 have stopped all his work on foobar components etc so won't there be any up date from him.

You could always give a try yourself and make a new release using his source
https://gitlab.com/kode54/foo_midi

Quote from: grimes on 2022-10-13 15:10:48

Any chance for a fb2k v2 compilation of the plugin?

Since kode54 have stopped all his work on foobar components etc so won't there be any up date from him.

You could always give a try yourself and make a new release using his source
https://gitlab.com/kode54/foo_midi

I really appreciate his work, to bad that he quit coding, hopefully someone else that can code can update to be supported by the new fb2k v2 x64 compatible.

I don't like to use WMP, wish I could use Foobar2000 for MIDI too!


Regards
/e33et

In case anyone is interested, I have a x64 version that builds and that plays MIDI files on foobar2000 2.0 beta 12 using the Emu de MIDI plugin.

Sounds awful but hey, it works!

The other plugins either complain about a corrupt file or don't produce any sound.

Automatic update to foo_midi / MIDI Player / 2.8.0.0 doesn't work:

Component update: Checking for: foo_midi / MIDI Player / 2.8.0.0
Component update: No release to serve

Should be:

Component update: Checking for: foo_midi / MIDI Player / 2.8.0.0
Component update: Found a match - 2.8.0.0 vs 2.8.0.0

Automatic update to foo_midi / MIDI Player / 2.8.0.0 doesn't work:

Can this be a problem with the Components page? I tried every combination of numbering and deleting releases. Perhaps because the previous releases didn't have a binary attached to it?

Had the same problem with my components. I supposed, Peter fixed that.

Can this be a problem with the Components page?

Yes.

Perhaps because the previous releases didn't have a binary attached to it?

I don't think so, should show (after manual update):

Component update: Found a match - 2.8.0.0 vs 2.8.0.0

Wasn't MIDI flavor and filter effects only for Secret Sauce? I see now it's also available for BASSMIDI and VSTi
Secret Sauce checkbox now to enable filter effect, does it mean now reverb and chorus disabled by default?
Maybe also notif user to reopen preferences after directory of VSTi or Secret is changed to take effect, also the possibility when selected plugins unavailable.
Seems there is a glitch where Secret Sauce listed in plugins list when directory was cleared.
Regards :)

Glitch in Preferences. Opening Preferences: "BASS not loaded" is active, blurry and white (1st screenshot). Switching to another menu item in Preferences and back: "BASS not loaded" is inactive, not blurry and grey (2nd screenshot).

Wasn't MIDI flavor and filter effects only for Secret Sauce? I see now it's also available for BASSMIDI and VSTi
Secret Sauce checkbox now to enable filter effect, does it mean now reverb and chorus disabled by default?
Maybe also notif user to reopen preferences after directory of VSTi or Secret is changed to take effect, also the possibility when selected plugins unavailable.
Seems there is a glitch where Secret Sauce listed in plugins list when directory was cleared.
Regards :)

Thx for the feedback. I'll look in to it. The preferences code was... challenging. It showed a long history of adding features. Obviously I didn't retest all paths.

Tried VSTi, doesn't work with MIDI, just freezes and/or crashes foobar.
I attempted adding all VST's, then just a single VST folder. No matter which VST I chose, same result.

Tried VSTi, doesn't work with MIDI, just freezes and/or crashes foobar.
I attempted adding all VST's, then just a single VST folder. No matter which VST I chose, same result.

x86 or x64? Which VSTi? I have several from simple analog synths to complex digital synths, no problem with them.

Hi kode54!
Is it possible to add a simple MIDI THRU output option to plug-ins menu making it possible to control some midi device? To play MIDIs with windows softsynth midi driver or some external tone generator or midi contolled synth connected by the cable? I didn't find such an option. I've googled a lot and found some free midi thru vst and tried using it, but it doesn't seem to have time sync or something, so it doesn't follow tempo and sounds glitchy. Since foo_midi is the only option available in foobar, I see no other way playing midi without vsti synths and emulators than adding some midi output plug-in working as a proxy to external device

Hi kode54!
Is it possible to add a simple MIDI THRU output option to plug-ins menu making it possible to control some midi device? To play MIDIs with windows softsynth midi driver or some external tone generator or midi contolled synth connected by the cable? I didn't find such an option. I've googled a lot and found some free midi thru vst and tried using it, but it doesn't seem to have time sync or something, so it doesn't follow tempo and sounds glitchy. Since foo_midi is the only option available in foobar, I see no other way playing midi without vsti synths and emulators than adding some midi output plug-in working as a proxy to external device

kode54 doesn't work on foobar2000 plugins anymore: https://kode54.net/fb2k-unfold

Please head over to the follow-up thread raised by pqyt, the new maintainer of the foo_midi plugin, here (https://hydrogenaud.io/index.php/topic,123301.0.html). :)

Automatic update to foo_midi / MIDI Player / 2.8.0.0 doesn't work.

I think, its a problem with the short name of the component. foo_midi is already in use (by kode54). Please consider to rename the component (in foo_midi2). Thanks.

Quote from: grimes on 2023-05-01 13:47:42

Automatic update to foo_midi / MIDI Player / 2.8.0.0 doesn't work.

I think, its a problem with the short name of the component. foo_midi is already in use (by kode54). Please consider to rename the component (in foo_midi2). Thanks.

The internal key is already different ("foo_midi (x64)") because it must be unique (and can not be changed). The display name is also different ("MIDI Player"). I think it's because I have the habit of copying information from the GitHub manifest and I forget to remove the 'v' from 'v2.8.0.0'. The Components repository accepts the 'v' but the update mechanism is confused by it.

When I release an update with the reported bugs I'll pay specific attention to the automatic update process.

Wasn't MIDI flavor and filter effects only for Secret Sauce? I see now it's also available for BASSMIDI and VSTi

MIDI flavor and Filter Effects were available for most players, as mentioned in the original code.

Secret Sauce checkbox now to enable filter effect, does it mean now reverb and chorus disabled by default?

That too is in the original code.

Maybe also notif user to reopen preferences after directory of VSTi or Secret is changed to take effect,

Done.

also the possibility when selected plugins unavailable.

What do you mean by that?

Seems there is a glitch where Secret Sauce listed in plugins list when directory was cleared.

That got solved by asking the user to re-open the Preferences dialog.