Only I mean wht not need convert MOD / S3M and other trackers formats to MIDI , I wanted say what this can play as standard trackers if you integrate libopenmpt to your player )
Roland User wrote on 2025-06-29, 17:51:Only I mean wht not need convert MOD / S3M and other trackers formats to MIDI , I wanted say what this can play as standard trackers if you integrate libopenmpt to your player )
But I do not want to play mod files as a standard tracker in a dedicated Midi Player 😀
There are many dedicated module players for such a task such as openmpt.
The only reason of supporting module formats in Midi player is because of the Midi+SF2 conversion. Without this Midi+ SF2 conversion supporting module playback would be meaningless.
Just a historical anecdote:
the main reason why I added module support this way was to use the hardware mixing of my SB Live!/ Audigy 2 ZS since Midi + SF2 pairs could be loaded by Midi Player real-time into Creative HW SF2 Midi synths anyway.
I approximately so and thinked , so this linked with production Creative Labs ) , but I understand your position )
By the way I very glad what we more not in conflict and what you not holdin evil on me
And also I close support Synth-pack , because I very do not match on as seen next development main synthesizer in pack , author of Vampire rested and does not want add GS standard SC-8820 as I offer and offer make
At all when I was tester in YAMAHA YMF-New , TyRUS , Vampire , I dreamed recive Roland SoundCanvas 8820 on live insruments , but this so not be )
Roland User wrote on 2025-06-29, 17:51:Only I mean wht not need convert MOD / S3M and other trackers formats to MIDI , I wanted say what this can play as standard trackers if you integrate libopenmpt to your player )
Imho, the great value here, is you can have little differences in rendered audio compared to OpenMPT (the same library integrated will produce the same audio with the disadvantage that inside OpenMPT there's a lot of settings in advanced mode when working with sinc interpolation without lowpass as well as ramping settings).
Often, I prefear the overall rendering here (not always btw and I think this is related to the samples inside MOD) and I think the chance to have different's output really important, at least for me, trying always to figure out how to have best possible results from a low resolution, retro, module file.
Hi Zoltan )
Now I about MOD2MIDI , I remember what was be ulilit for Windows 3.x / Windows 9x MOD2MIDI , there was a feature in this utility save mod to midi per instrument , example I upluad here , if possible , make extend this up to 128 channels and resave to midi , as you can see , this utility convert MOD to MIDI not per channel , but per instrument , if possible , make this method convertation ) OpenMPT this do not good
Roland User wrote on 2025-06-30, 14:05:Hi Zoltan )
Now I about MOD2MIDI , I remember what was be ulilit for Windows 3.x / Windows 9x MOD2MIDI , there was a feature in this utility save mod to midi per instrument , example I upluad here , if possible , make extend this up to 128 channels and resave to midi , as you can see , this utility convert MOD to MIDI not per channel , but per instrument , if possible , make this method convertation ) OpenMPT this do not good
My mod2midi already knows this. But you have to run it from the command line and give the 'by inst' parameter the value of 1.
Usage: mod2midi <source_file> <destination path> <use drum channel[0/1]> <by inst[0/1]> <by track[0/1]>
E.g:
mod2midi.exe watch.mod C:\temp 0 1 0
You can also try
mod2midi.exe watch.mod C:\temp 0 1 1
(If you want to split by track, too).
Thank you ) this is very good ) but maybe you add this function in FSMP , to not do this in command line , and Instead press to tracker file and convert to midi with both variants ) approximately as now made convertation from GM to MT and from MT to GM )
Roland User wrote on 2025-06-30, 16:19:Thank you ) this is very good ) but maybe you add this function in FSMP , to not do this in command line , and Instead press to tracker file and convert to midi with both variants ) approximately as now made convertation from GM to MT and from MT to GM )
FSMP simply works best with the default 'by channel' version. The other versions are inferior in terms of FSMP playback (they are bigger, seeking is harder, they require more tracks etc.) .
So I do not think I should make my life harder this way 😀
I about other ) now simply need use command line , but FSMP can play modules , and because this can use for export to standard MIDI file for edit )
But it looks me need write vbs for easy convert files with your parameters mod2midi.exe watch.mod C:\temp 0 1 1
Roland User wrote on 2025-06-30, 19:05:I about other ) now simply need use command line , but FSMP can play modules , and because this can use for export to standard MIDI file for edit )
But it looks me need write vbs for easy convert files with your parameters mod2midi.exe watch.mod C:\temp 0 1 1
OK, then write a vbs, or any other script to automate the process.
But available problem , now I can not do command mod2midi.exe watch.mod 0 1 1 and get file in same folder , what I do not correctly ?
Understand , If command mod2midi.exe watch.mod 0 1 1 . - I get file in same folder )
Roland User wrote on 2025-06-30, 20:08:But available problem , now I can not do command mod2midi.exe watch.mod 0 1 1 and get file in same folder , what I do not correctly ?
You missed the 2nd argument (destination folder). You have to set the destination folder explicitly even if you want to output to the current folder.
In Windows the sign of the current directory is '.'
So this should work:
mod2midi.exe watch.mod . 0 1 0
Next problem with transmit arguments , if I transmit so *.mod or *.s3m or *. xm , result nothing
I can not transmit command mod2midi.exe c:\1\*.mod . 0 1 0 why ?
Roland User wrote on 2025-06-30, 20:37:Next problem with transmit arguments , if I transmit so *.mod or *.s3m or *. xm , result nothing
I can not transmit command mod2midi.exe c:\1\*.mod . 0 1 0 why ?
Because it is not needed in Midi Player. You have to do the recursion yourself in your script.
Here so as I write
Firstly, just let me say thank you for this amazing program. Very few developers are taking MIDI seriously these days and almost all of the efforts of those who are interested are directed towards pro musicians rather than MIDI playback. You're nearly single-handedly keeping the dream alive.
This might become lengthy, but I assure you I will ramble and waffle my way to an actual point. I use Midiplayer in a VMware guest running Windows 98 to route MIDI over network to a hardware synthesizer connected to the host OS, the setup goes something like this:
MIDI source application -> Hubi's MidiCable -> Falcosoft Midiplayer (on VM guest) -> VMware host to guest network -> Falcosoft Midiplayer (on VM host) -> actual MIDI device
Now this sounds complicated, but in practice seems to be amazingly reliable and fast considering what is happening, I have no complaints about the functionality whatsoever (again, kudos). The most complicated part actually turns out to be setting this up every time I want to use my external modules from VMware.
What would really help is if there were a way to easily start MidiPlayer in a state where it is listening or sending over the network. I have looked through the documentation and Googled a lot to get to the point where I can perform this trick at all, I am now trying to automate the process as much as possible for convenience and to mitigate forgetfulness or mistakes, and have not come across any solutions to starting Midiplayer in a state where it is listening or sending.
Have I missed something? If not, is there any possibility of requesting this as a feature in the future sometime?
Either command line options to specify network sending and listening, or remembering and restoring the network listen and send settings when opening Midiplayer would solve all my problems.
Thanks.
steviant wrote on 2025-07-10, 04:42:Firstly, just let me say thank you for this amazing program. Very few developers are taking MIDI seriously these days and almost […]
Firstly, just let me say thank you for this amazing program. Very few developers are taking MIDI seriously these days and almost all of the efforts of those who are interested are directed towards pro musicians rather than MIDI playback. You're nearly single-handedly keeping the dream alive.
This might become lengthy, but I assure you I will ramble and waffle my way to an actual point. I use Midiplayer in a VMware guest running Windows 98 to route MIDI over network to a hardware synthesizer connected to the host OS, the setup goes something like this:
MIDI source application -> Hubi's MidiCable -> Falcosoft Midiplayer (on VM guest) -> VMware host to guest network -> Falcosoft Midiplayer (on VM host) -> actual MIDI device
Now this sounds complicated, but in practice seems to be amazingly reliable and fast considering what is happening, I have no complaints about the functionality whatsoever (again, kudos). The most complicated part actually turns out to be setting this up every time I want to use my external modules from VMware.
What would really help is if there were a way to easily start MidiPlayer in a state where it is listening or sending over the network. I have looked through the documentation and Googled a lot to get to the point where I can perform this trick at all, I am now trying to automate the process as much as possible for convenience and to mitigate forgetfulness or mistakes, and have not come across any solutions to starting Midiplayer in a state where it is listening or sending.
Have I missed something? If not, is there any possibility of requesting this as a feature in the future sometime?
Either command line options to specify network sending and listening, or remembering and restoring the network listen and send settings when opening Midiplayer would solve all my problems.
Thanks.
Hi,
1. Thanks for your kind words.
Here is a new test version that saves and then restores the state of Midi net send/receive at startup.
2. This new test version also contains a new Bassmidi option in Device settings -> Bassmidi part namely 'Emulate SC-55 drums/cymbals'.
As the name suggests when this option is enabled Bassmidi emulates the drum/cymbal cut logic used by the original SC-55 that is needed to play some Doom/Doom2 Midis properly.
This new feature should work with any SF2 soundfonts. Since this option can cause problems with more modern Midi files and cymbal rolls it's disabled by default.
Here is a test/demo video about this new feature:
https://youtu.be/dLCpNicrEng
You should simply replace the midiplayer.exe and bassmidi.dll files in your existing Midiplayer 6.5 folder with the proper ones (x86 or x64) from the new zip file.
Falcosoft wrote on 2025-07-10, 12:31:Hi, 1. Thanks for your kind words. Here is a new test version that saves and then restores the state of Midi net send/receive at […]
steviant wrote on 2025-07-10, 04:42:Firstly, just let me say thank you for this amazing program. Very few developers are taking MIDI seriously these days and almost […]
Firstly, just let me say thank you for this amazing program. Very few developers are taking MIDI seriously these days and almost all of the efforts of those who are interested are directed towards pro musicians rather than MIDI playback. You're nearly single-handedly keeping the dream alive.
This might become lengthy, but I assure you I will ramble and waffle my way to an actual point. I use Midiplayer in a VMware guest running Windows 98 to route MIDI over network to a hardware synthesizer connected to the host OS, the setup goes something like this:
MIDI source application -> Hubi's MidiCable -> Falcosoft Midiplayer (on VM guest) -> VMware host to guest network -> Falcosoft Midiplayer (on VM host) -> actual MIDI device
Now this sounds complicated, but in practice seems to be amazingly reliable and fast considering what is happening, I have no complaints about the functionality whatsoever (again, kudos). The most complicated part actually turns out to be setting this up every time I want to use my external modules from VMware.
What would really help is if there were a way to easily start MidiPlayer in a state where it is listening or sending over the network. I have looked through the documentation and Googled a lot to get to the point where I can perform this trick at all, I am now trying to automate the process as much as possible for convenience and to mitigate forgetfulness or mistakes, and have not come across any solutions to starting Midiplayer in a state where it is listening or sending.
Have I missed something? If not, is there any possibility of requesting this as a feature in the future sometime?
Either command line options to specify network sending and listening, or remembering and restoring the network listen and send settings when opening Midiplayer would solve all my problems.
Thanks.
Hi,
1. Thanks for your kind words.
Here is a new test version that saves and then restores the state of Midi net send/receive at startup.2. This new test version also contains a new Bassmidi option in Device settings -> Bassmidi part namely 'Emulate SC-55 drums/cymbals'.
As the name suggests when this option is enabled Bassmidi emulates the drum/cymbal cut logic used by the original SC-55 that is needed to play some Doom/Doom2 Midis properly.
This new feature should work with any SF2 soundfonts. Since this option can cause problems with more modern Midi files and cymbal rolls it's disabled by default.
Here is a test/demo video about this new feature:
https://youtu.be/dLCpNicrEngYou should simply replace the midiplayer.exe and bassmidi.dll files in your existing Midiplayer 6.5 folder with the proper ones (x86 or x64) from the new zip file.
Does your midi player support sending GS/GM resets via MIDI files? Because the MIDI player defaults to GS and I was wondering if I have to change the reset type to GM manually when playing say a DOOM MIDI or if it doesn't matter?
