If possible , please do 32 bit float point in OPL3 GM synth ) beause this synth create noise about -63 dB. This not good and I wantin what would this noise no was be.

As you may have noticed OPL3VSTi is a VST plugin that uses either DosBox or Nuked OPL3 libraries for rendering. None of them supports native 32-bit floating point currently.
So you should convince either the DosBox team or Nukeykt to support it:
Nuked OPL3 emulator
Just a reminder: The primary goal of Nukeykt's OPL3 library was/is to be a bit perfect emulation library of YMF262. So supporting features that the original hardware did not support (like 32-bit floating point rendering) maybe is not something that he is willing to add.

In MUNT also was be only channels 2-10 or if reconfigure , will be 1-9 and absent channels 1,11-16 or if reconfigure 9,11-16 ) but this now have ) also I offer do with 32 render mode ) check box on/off if this possible )

In MUNT also was be only channels 2-10 or if reconfigure , will be 1-9 and absent channels 1,11-16 or if reconfigure 9,11-16 ) but this now have ) also I offer do with 32 render mode ) check box on/off if this possible )

I do not understand even a single word from the above 😀. Please be more precise, or at least try again with Google translate.

I say about , what in MUNT also was be only 16 bit int renderer and was be only 8 channel parts , but you extended this from 16 bit int renderer to 32 bit float pont renderer optional , and next you extended MUNT from 8 MIDI channels to 16 MIDI channels in dual synth mode.
I offer do also and with OPL3GM synth ) if possible - add mode 32 bit render )
Switch as use 16 bit render or 32 bit FP render leave.

but you extended this from 16 bit int renderer to 32 bit float pont renderer

Ahh OK, now I understand what you mean, but you are wrong 😀. It was not me, but Serg who 'extended' the base Munt library to handle 32-bit float rendering:
Request for floating point arithmetic version
Request for floating point arithmetic version

Without this modification to core Munt emulation library by Serg I could not have done it in MuntVSTi plugin. The relation between emulation library and plugin is exactly the same in case of OPL3VSTi: without support in the base library (DosBox/Nuked OPL3) I can not add native 32-bit floating point rendering to OPL3VSTi plugin.

(To be clear what 'supporting floating point' could mean from my VSTi plugin's point of view: Without native support by the emulation library I could only add converted/emulated floating point support since supporting floating point is a required feature in case of VSTi plugins.
That's why you can see 2 different labels on MuntVSTi's user interface like 'VST: 32-bit', 'Munt: 16-bit'. The 1st one refers to the plugin to host interface that is mandatory to be floating point. This is also present in OPL3VSTi. It can be either 32-bit float or 64-bit float. The 2nd one refers to the native rendering mode of the emulation library itself. It can be either 16-bit int or 32-bit float in case of Munt. This 2nd option is the one that requires explicit support from the emulation library. And this is what is currently missing from both DosBox and Nuked OPL3 libraries. More precisely it is always 16-bit int)

next you extended MUNT from 8 MIDI channels to 16 MIDI channels in dual synth mode.

This is a completely different story since 'extending' supported channels or using 2 instances of the synth does not require special support from the base library. That's why there is a kind of 'dual synth mode' also in OPL3VSTi.
I hope it's clear for you now why you should first try to convince the library authors (DosBox team, Nukeykt) to add support for 32-bit float processing. So once again:
Nuked OPL3 emulator

> Solved. Sorry. Aldo <

Just another question: I'm recording some midi files using for each midi a different soundfont (and now this works great). Now, when i'm recording tracks i've selected form the microphone button the option: "What you Hear", because I was trying to record music, enabling and disabling hardware DSP of my soundblaster SB-X, but while what i'm hearing changes... files generated are identical with and without hardware DSP...

Thank you.

Aldo

I very recomended use for write sound this cables https://www.vb-audio.com/Cable/ ) this correctly write without disortion of Creative DSP-s)

RetroGC wrote:

> Solved. Sorry. Aldo < […]
Show full quote

> Solved. Sorry. Aldo <

Just another question: I'm recording some midi files using for each midi a different soundfont (and now this works great). Now, when i'm recording tracks i've selected form the microphone button the option: "What you Hear", because I was trying to record music, enabling and disabling hardware DSP of my soundblaster SB-X, but while what i'm hearing changes... files generated are identical with and without hardware DSP...

Thank you.

Aldo

Hi,
1. In the WinXP era in case of SB Live/Audigy hardware SF2 synths 'What You Hear' always meant the 'wet' recording source and 'Midi' was the 'dry' counterpart. But since Vista independent hardware recording sources are not available anymore so 'What You Hear' only means some kind of loopback source/device (mainly for recording Wave) and it's completely driver dependent whether it provides wet or dry signal. Anyway FSMP has nothing to do with this, it can only record what the driver provides be it wet or dry signal.
2. If you use the 'internal' recording through Bassmidi soft synth then of course hardware DSP effects are missing since Bassmidi records its own internal signal before it reaches the hardware DSP/mixer. In this 2nd case recording does not use any real recording sources such as 'What You Hear' but internal infrastructure of Bass. Actually there is a hint about this behavior on the Microphone button saying:

Select Midi or Stereo Mix (XP)
Set recording level (Vista+)
Not relevant for BassMidi/VSTi!

You can also find details about this in the 'FAQ/How-to' document:
http://falcosoft.hu/midiplayer_howto.html#a8

Instead in internal Bassmidi recording mode you can use VST effects and/or the internal Bass/Treble sliders.

Roland User wrote:

If possible , please do 32 bit float point in OPL3 GM synth ) beause this synth create noise about -63 dB.

I have just tested and only Nuked OPL3 is affected by this high noise floor phenomenon. DosBox OPL3 core is absolutely noiseless (-Inf) in idle state. In this respect DosBox OPL3 is even better than SC-VA. So you simply should not check 'Use Nuked OPL3 library' on the interface. The advantage of Nuked OPL3 is bit perfect emulation but in this case it's exactly what you want to avoid. In Nuked OPL3 noise seems to be added deliberately. See OPL3_NoiseGenerate() in Nuked OPL3 library. So this phenomenon actually has nothing to do with 16-bit int vs. 32-bit float rendering.

I presume the noise is emulating a deficiency in how a real OPL3 typically sounds on a real soundcard equipped with one.

Falcosoft
Thank you ) now I understand causin this noise )

Hey, I noticed a few bugs when it comes to using Sound Canvas devices:

1. The Roland SC-D70 and SC-8850 inofficially supports XG Lite and the SD-90 supports it officially. Whenever I play a song with an XG Reset, neither of the devices will be properly set into XG mode and will often only go into GM mode instead. I even set the "Reset Type" to XG within Midi Player, but that didn't help either. I can send the XG On manually, but when starting the song, it will go back to GM. When I play those files in Winamp, it works as intended.
I also do have a Korg NX5R (which has a proper XG daughterboard) and there it works properly with Midi Player, so it must be an issue with the Sound Canvas devices.

2. This is kinda an odd one, because only the SC-8850 has issues here. When I open a song with Midi Player everything works, however, after changing the song ("Reset Type" is set to GS or GM) the percussion track will not be played at all. The SC-8850 doesn't receive any data whatsover from what I can tell there. All other tracks are playing fine. The only solution is to manually send a GS or GM Reset SYSEx and then play the song again. In Winamp this works properly, even when I do not send resets between songs, so I think it must be an issue with Midi Player. All other devices work fine however.

I would be happy if you could take a look at these issues. If you need further assistance from me, just let me know.

Hi,
For both of your problem first let's try the following:
1. In Main menu -> Compatibility Setting make sure 'Set Missing Default Patches' is disabled.
2. In Playlist's right click context menu make sure 'Play from First Note' is disabled.
3. In right click context menu of the reset button select 'Select/Send Custom SysEx' then choose the appropriate SysEx message (XG_ON, GM_ON, GS_ON) and make sure that it is selected as the active Reset option. I'm talking about this:

This is different to setting simply XG/GS/GM since custom SysEx sends only the selected message and nothing more. You can also select to send 'nothing' by specifying 'Use Hex String' and typing 'F0 F7'. More about this:
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

Then repeat your tests. The above could help since I think this is a buffering problem because of too many sent messages and slow processing of your HW.
In case of problem 1 it would be helpful if you can tell what mode Midi Player displays as actual Midi System (XG or GM). I'm talking about this:

Or even better you could attach your problematic XG Midi files.

1. I disabled it now, but it didn't fix the issues described above.
2. This was already disabled.
3. This is what I meant by "sending XG On Manually" and setting Reset Type to "XG On" and the latter was what I mean with "Reset Type", this is also set to XG On.

After testing I noticed that only the SC-D70 and the SC-8850 are affected (inofficial XG Lite support). The SD-90 works fine (official XG Lite Support). And I also noticed that it doesn't only change to XG when using MIDI Files, but already when using "Select/Send Custom SysEx":

When I use "Select/Send Custom SysEx" and send over a GM On, the SC-D70 will properly change to GM.

However, when I send the XG On, it will change to GS instead:

If I use Cakewalk and send the XG On.sys it will properly set it to XG (since it doesn't officially support XG all lamps will be off instead):

So it aren't actually the MIDIs but something else. I also tried "Use Hex String" and put in the XG On SysEx command (F0 43 10 4C 00 00 7E 00 F7 ), but when sending that with Midi Player the SC-D70 will go back to GS instead. In Cakewalk and Winamp it works as intended.

Since only the SC-D70 and the 8850 are affected it might have something to do with that their implementation might not be complete, as they do not officially support it? However, why does it still work in Cakewalk and Winamp?

Hi,
OK, let's continue our investigation. I have an idea what can cause this strange behavior. So make sure in 'Device Settings' dialog:
1. 'Use SysEx for Voulume/Balance' is NOT selected.
2. The 'SysEx Effects' controls are set to Default and exactly at the middle position (64). You can do this by double clicking on the slider controls.
3. Repeat your test sequence and report back.

It's because when a Reset message is detected, Midi Player tries to set you predefined effects/volume/balance level since a reset overrides these values. And since supported commands are not known by the player it tries to do this all known ways (e.g. XG spec does not mention specific balance SysEx messages but XG synths can also support GM/GS balance SysEx messages). This usually should not change the Midi system/mode but maybe your synth reacts to any GM/GS like SysEx this way.

1.
"Use SysEx for Volume/Balance" is the cause. If disabled, it will properly change to XG.
The "SysEx Effects" can be set to anything, even if I do set a custom reverb/hall/value, it will still change to XG as long as "Use SysEx for Volume/Balance" is disabled.

After doing that I obviously cannot alter the volume within Midi Player, but since they are external devices I can still change the volume on them directly. However, if you know an easy fix for this whole issue, I would still appreciate it.

2.
I also found what caused the error that the SC-8850 doesn't play any percussion tracks after the first song:
For "SysEx Effects" I had an XG Reverb and Chorus selected (Hall 2 XG / Chorus 2 XG). If that is the case the error will be present. If I set it to any GS Reverb/Chorus it will play the percussion just fine when switching between songs. I doubt there's anything you can do about that, as it seems to be an error specific to the SC-8850.

Thanks for helping me out to finding the cause of the issues!

XxMiltenXx wrote:

1. "Use SysEx for Volume/Balance" is the cause. If disabled, it will properly change to XG. The "SysEx Effects" can be set to an […]
Show full quote

1.
"Use SysEx for Volume/Balance" is the cause. If disabled, it will properly change to XG.
The "SysEx Effects" can be set to anything, even if I do set a custom reverb/hall/value, it will still change to XG as long as "Use SysEx for Volume/Balance" is disabled.

After doing that I obviously cannot alter the volume within Midi Player, but since they are external devices I can still change the volume on them directly. However, if you know an easy fix for this whole issue, I would still appreciate it.

I'm glad this mysterious problem is solved. I have an idea about how this could be mitigated without affecting other devices, but most likely it will require some trial and error steps so your further assistance is needed.

XxMiltenXx wrote:

2. I also found what caused the error that the SC-8850 doesn't play any percussion tracks after the first song: For "SysEx Effec […]
Show full quote

2.
I also found what caused the error that the SC-8850 doesn't play any percussion tracks after the first song:
For "SysEx Effects" I had an XG Reverb and Chorus selected (Hall 2 XG / Chorus 2 XG). If that is the case the error will be present. If I set it to any GS Reverb/Chorus it will play the percussion just fine when switching between songs. I doubt there's anything you can do about that, as it seems to be an error specific to the SC-8850.

Thanks for helping me out to finding the cause of the issues!

So much for 'unofficial' XG support on Roland devices... This behavior reinforces my guess that not only XG Reset but any other/random XG SysEx messages can switch your HW into XG mode (just like non-Reset GM/GS SysEx messages can switch it out of XG mode, causing problem 1). Most likely on your device in XG mode channel 10 is only a drum/percussion channel if Bank MSB is set to 127. Without this Channel 10 remains a melodic channel. You can test this hypothesis if you set Channel 10 into solo mode and listen if you can hear wrong Piano like sounds instead of drums. If I'm right the problem was not 'The SC-8850 doesn't receive any data whatsoever ' but it fails to handle Channel 10 as drum channel because it implicitly switches itself into XG mode by detecting XG style Reverb/Chorus SysEx messages. It's stupid, no sane devices should behave this way.
Anyway if I'm right you could also correct this problem (if you still want to use XG Reverb/Chorus presets) by selecting 'Main menu -> Compatibility Settings -> Fix SFZ Drum Bug (Force XG Drums)' option.

Falcosoft wrote:

I'm glad this mysterious problem is solved. I have an idea about how this could be mitigated without affecting other devices, but most likely it will require some trial and error steps so your further assistance is needed.

Sure, just let me know If you want me to test something.

Falcosoft wrote:

So much for 'unofficial' XG support on Roland devices... This behavior reinforces my guess that not only XG Reset but any other/random XG SysEx messages can switch your HW into XG mode (just like non-Reset GM/GS SysEx messages can switch it out of XG mode, causing problem 1). Most likely on your device in XG mode channel 10 is only a drum/percussion channel if Bank MSB is set to 127. Without this Channel 10 remains a melodic channel. You can test this hypothesis if you set Channel 10 into solo mode and listen if you can hear wrong Piano like sounds instead of drums. If I'm right the problem was not 'The SC-8850 doesn't receive any data whatsoever ' but it fails to handle Channel 10 as drum channel because it implicitly switches itself into XG mode by detecting XG style Reverb/Chorus SysEx messages. It's stupid, no sane devices should behave this way.

So, first off after further testing I noticed that only the Reverb SysEx Effect cause this issue and only "Hall 1 XG" and "Hall 2 XG". Neither Chorus nor any other Reverb make issues. (I even doubt that the Roland Devices support any of these effects as I do not hear any differences when chaning them.)
It does not go into XG Mode when receiving those XG Reverbs and it doesn't receive any data on Channel 10 whatsoever. The SC-8850 has a proper display where I can cycle through all the parts and see if something is happening there. The Drum kit is selected properly (otherwise it would say something like "No Instrument") but I had another hunch and it's really stupid - the SC-8850 is misinterpreting the SysEx it receives...
The SC-8850 has 2 MIDI In Ports at the back. I was using MIDI Port 1 for now. So just now I got the idea to test MIDI Port 2, and well ... what do you know. Sending one of these XG Reverbs causes the percussion track to be played via MIDI Port 2 (Part-B as it is called in the SC-8850) but ALSO on (Part-A), which would normally be MIDI Port 1, which isn't even connected then. So I guess it copies the percussion data to another part for some particular reason. The only odd thing is: How come for MIDI Port 2 (Part-B) it plays there as intended but also on Part-A, but when MIDI Port 1 is used (Part-A) it doesn't play on any Part? My only guess it that it tries to apply it to the previous Part. But since Part-A is already the first, it tries to send it to an invalid part and so it doesn't get played at all I guess.
So I guess this is a device bug that is beyond your control. Unless you have any other ideas to what might be the cause.

Falcosoft wrote:

Anyway if I'm right you could also correct this problem (if you still want to use XG Reverb/Chorus presets) by selecting 'Main menu -> Compatibility Settings -> Fix SFZ Drum Bug (Force XG Drums)' option.

I only left it on because I was testing the reverbs on the Korg NX5R. And since all Roland devices seem to ignore XG Reverbs/Chorus I never noticed it afterwards that I didn't change it back... well, until I got the SC-8850 and that odd bug xD

Please, try this:
http://falcosoft.hu/midiplayer_58_test.zip
In this version when 'Use SysEx for Volume/Balance' is enabled and Midi Player is in XG mode only GM Master Volume/Balance SysEx messages are sent.

Now both devices will go into XG and the volume slider is working for all types (GS, GM and XG), thanks a lot for the quick fix! 😁