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 81871 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: foo_midi

Reply #275
Should be fixed now, I hope.

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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


Re: foo_midi

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

Re: foo_midi

Reply #282
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:
Code: [Select]
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.

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

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

 

Re: foo_midi

Reply #289
@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).

Re: foo_midi

Reply #290
What are your settings? I cannot reproduce this issue.

Re: foo_midi

Reply #291
What are your settings? I cannot reproduce this issue.
I'm using foo_midi's BASSMIDI output with the following settings:



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.

Re: foo_midi

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

Re: foo_midi

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

Re: foo_midi

Reply #294
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 in the related XMPlay forum thread.

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

Re: foo_midi

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

Re: foo_midi

Reply #296
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
Code: [Select]
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. 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.

Re: foo_midi

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

Re: foo_midi

Reply #298
I think you may have perceived that incorrectly:

Quoted post from the Bass forum
Code: [Select]
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 from the Bass forum
Code: [Select]
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. :)

Re: foo_midi

Reply #299
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