Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_midi (Read 81860 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_midi

Reply #50
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.

Re: foo_midi

Reply #51
Same OS here, works as expected. Check your configuration.

Re: foo_midi

Reply #52
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.

Re: foo_midi

Reply #53
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.


Re: foo_midi

Reply #55
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.

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

Reply #58
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:



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.

Re: foo_midi

Reply #59
EF BB BF is the byte order mark for Unicode. Apparently the new SFList parser is choking on that...

And I have yet to make the SFList JSON editor...
¡Se habla español! Also available in purple and orange.

Re: foo_midi

Reply #60
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.

Re: foo_midi

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


Re: foo_midi

Reply #63
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.


Re: foo_midi

Reply #64
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.

Re: foo_midi

Reply #65
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...

Re: foo_midi

Reply #66
Nuclear option?  This all of sudden showed up.

Re: foo_midi

Reply #67
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.

Re: foo_midi

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

Re: foo_midi

Reply #69
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.

Re: foo_midi

Reply #70
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.

Re: foo_midi

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


Re: foo_midi

Reply #73
BassMidi VSTi doesn't work. Will you support for this? thanks.

Re: foo_midi

Reply #74
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.