At first glance there's really a problem. The matching pattern is too permissive. If you load MI2_1.MID these syx files all match:
MI2_1.syx
MI2_13.syx
MI2_14.syx
MI2_16.syx
MI2_17.syx
So I think a good solution would be if the postfix has to be started with '_' for example.
Edit:
But that would also kill the same name match...
So the question is what the pattern should be? This is the function I call: https://msdn.microsoft.com/en-us/library/wind … v=vs.85%29.aspx
Essentially you can have only 2 kind of wildcards in the pattern: '*' and '?'.
I sill cannot reproduce the long waiting you have described. What should I load?
@Edit:
Have you ever met a situation when more than one syx file has to be loaded by a midi file?
If not, maybe the exact name match only would solve the problem.
I sill cannot reproduce the long waiting you have described. What should I load?
Load MI2_1.MID to the playlist.
Set FSMP to MT-32 and "Autoload at Startup".
Set Delay between SysEx to 20ms.
Close FSMP and open it again.
Now watch the MT-32 window.
If I use the standalone MUNT MT-32 (not the VST plugin) or just another Midi-Out port, opening FSMP with MI2_1.MID in the playlist will freeze FSMP till the SYX sending sequence is done.
Have you ever met a situation when more than one syx file has to be loaded by a midi file?
If not, maybe the exact name match only would solve the problem.
No.
Usually an MT-32 game (or per track) rip contains only one external SYX, where all other in-between syx are in the midi file.
That would be a good choice to load a single SYX per single MID, with both having the same name.
The previous naming scheme has been cancelled. Only syx files with the same name as the midi files are loaded. The old 'Autoload Soundfont' option in Main menu -> Instrument has been renamed to 'Autoload Soundfont/SysEx' and can be used to enable/disable this autoload feature. If there is a detected autoloadable syx file, it is listed in the Soundfont/SysEx columin of the playlist.
I think this is a good compromise. In the rare cases of multiple syx files the drag&drop feature can be used.
Please, test it.
Yet again, starting FSMP will send the (first?) SYX in the playlist at startup, and may take a long time with a big SYX and long SysEx delay value, till then FSMP is frozen.
This is not desired behavior, it should send the SYX (or load SF2) only when double-clicked, song change, or MID/SYX dropping into FSMP.
Also, adding a MID to the playlist will send its SYX, this is not desirable.
1. FSMP loads the last used/ selected song at startup. It always did this.
Also, adding a MID to the playlist will send its SYX, this is not desirable.
This is not the first time you write this, but this is still not true. I do not know what is happening and causing problems on your side, but definitely not this.
I have made a video about actually what happens and when FSMP sends the syx file. Please, use Midi-ox or some other tool so we can find out what is happening on your side.
When you have an empty playlist and you load a file of course it loads it (and even starts to play it). I think it is desirable, and always worked this way.
Yes, I failed to mention that I add the MID file into an empty playlist; in that case, everything is correct.
FSMP preloads the last used/selected song? I see, I haven't noticed till now because I didn't test with MT-32 midi so never noticed the startup delay.
Are you sure it is desirable? Even if an MT-32 MID/SYX contain large amount of SysEx?
Hi,
New test version uploaded.
GUI always shows up at start up regardless of chosen output and possible associated syx file. Also somewhat faster preload at start up if associated syx file found.
Great!
Now I feel the responsiveness and bug free operation.
I think you have a 4.7 RC.
Cosmetic-wise, I would move Midi-text and Even-viewer to the right side.
For my needs, all four buttons will not be used often, so I personally wouldn't mind them being in a sub-menu (edit: they already are), because the title bar starting to looks cluttered.
This is of course my personal opinion.
According to feedbacks the real 'hidden gem' for new users was the main menu (and so VST submenu). I have added a dedicated main menu button to this new design. Unfortunately loading VST(i) would not works in the Device Settings dialog, since Bass infrastructure is not ready until you enable Bass output and press OK. But I will add a 'VST(i) Info' button that explains VST(i) plugins are available in Main menu after Bass output is enabled. Moreover I think I will prioritize the order of submenus of main menu so VST(i) setting will be upper in the structure.
Last edited by Falcosoft on 2017-05-17, 15:32. Edited 1 time in total.
At first it feels strange, but at the long run it may prove to be more comfortable. I have added an 'Exit' command to the main menu to help the transition while we recalibrate our minds 😀.
Looks and feels great, much more intuitive for new users.
I really like how the VST menu is first in the list,, much more comfortable (for me) to reach it by mouse.
Although I would put the VST Instrument before Effect 1, simply because how often it is used compared to the Effect slots.
Don't remove the Exit from the main menu, it also quite intuitive to go there.
I have notice that the VSTi MT-32 is much louder than standalone MUNT.
VST MT-32 has much less headroom than standalone MUNT, because of that it distorts much sooner.
You can also see the meters peaking red most of the time, that's not a good sign.
For them to match, FSMP volume should be set to middle, but for other plugins like SC-VA the Volume slider has to be set to maximum to be as loud as SAVIHost for example.
In other words:
SC-VA in FSMP will be equal in volume as SC-VA in SAVIHost, only when Volume slider is set to maximum.
But VST MT-32 will be twice as loud as the standalone MUNT if volume slider is at maximum, they match when the slider is in the middle.
I remember you explained the the Volume slider is Gain and 0.0 is in the middle; alright, but it still doesn't deny that VST MT-32 is much too loud compared to standalone MUNT.
This is not that case with SC-VA.
EDIT:
Found the problem.
Standalone MUNT has default Output Gain and Reverb Output Gain at 50, whether VST MT-32 has them on 100.
VST MT-32 is way too loud at default and loses much headroom because of this.
IMO, double clicking the Gains in VST MT-32 should bring them to 50, not 100.
James,
I recommend to take a look at Munt's source (especially Enumerations.h). You can see that the phenomenon you have faced caused by the DAC Input method you use and not the 100% gain factor.
quote form DAC Input mode Nice (High quality):
/**
* Produces samples at double the volume, without tricks.
* Nicer overdrive characteristics than the DAC hacks (it simply […] Show full quote
/**
* Produces samples at double the volume, without tricks.
* Nicer overdrive characteristics than the DAC hacks (it simply clips samples within range)
* Higher quality than the real devices
**/
I do not know why Pure mode cannot be selected in the qt client of Munt (you can select it in MuntVsti just because I noticed this phenomenon myself), but it seems counter-intuitive for me to choose double volume DAC modes and then attenuate it with 50% gain (as in mt32emu-qt.exe).
So the solution for you is rather to use DAC Input mode 'Pure'.
quote from DAC input mode Pure:
/**
* Produces samples that exactly match the bits output from the emulated LA32.
* Nicer overdrive characteristics than the […] Show full quote
/**
* Produces samples that exactly match the bits output from the emulated LA32.
* Nicer overdrive characteristics than the DAC hacks (it simply clips samples within range)
* Much less likely to overdrive than any other mode.
* Half the volume of any of the other modes.
* Output gain is ignored for both LA32 and reverb output.
* Perfect for developers while debugging 😀
*/
I remember you explained the the Volume slider is Gain and 0.0 is in the middle;
No, this was in an absolutely different context. I said that the slider has 200% (and not 100%) as maximum since it is a gain control and not the volume slider that can be found on MT-32 hardware. That can be set by Sysex messages e.g. by setting FSMP to use SysEx for Volume/Balance. But of course reset/volume SysEx messages in midi files can set it to default 100% (or any other value).
Edit: The wide variation in volume output level between VSTi instruments (e.g. SC-VA and SYXG-50) gave me the idea to add a default simple gain VST effect plugin to FSMP's package.
So the solution for you is rather to use DAC Input mode 'Pure'.
Thank you Falco, it definitely should be on 'Pure' in my book as an audio enthusiast.
A lot of MT-32 games have high velocity midis and reach the red zone often, in my opinion there is nothing 'nice' or 'high quality' in clipped audio.
It is definitely dumb to push the audio into clipping then attenuate it (like modern music 😐 ), I too wonder why mt32emu-qt.exe has omitted the 'Pure' option.
I have noticed that FSMP has some final compression on top of the output audio.
Can you please elaborate on that?
EDIT: Ah found it, "Use 32bit Sample Rate" compresses the sound instead of clipping it.
I prefer not to use this option because I love understanding and controlling the gain stages myself. 😀
Also, the compression kicks in slightly before peak volume (it has a knee), therefor 'deforms' the sound in the last 3-6db.
I like it as pure as possible, so no compression for me.
The further I understand FSMP the better I love it. 😊
Falcosoft wrote:
I said that the slider has 200% (and not 100%) as maximum since it is a gain control and not the volume slider that can be found on MT-32 hardware.
Yes, this is exactly what I understood.
0.0db gain is 100% volume, which is in the middle of the slider.
Although, at a closer look FSMP Volume is indeed a volume slider and not a gain control.
It only attenuates, so in the middle it cuts 6db, where at 100% it is bypassed.
This is exactly what I experienced with SC-VA in FSMP and SAVIHost SC-VA, they match when the volume slider is at 100%, so it is indeed a volume control because there is no boosting only cutting.
BTW, I quoted your [original topic starter post] in the second post of this thread, so you can delete it from the first post to make it cleaner.
Also, the new FSMP design deserves a new photo in the first post. 😀
