Falcosoft
Thank you ) MUNT 2.1 very good )

Hi James,

I think you should lower the defaults to 50% like in standalone MUNT, or tweak the code so it matches.
Yes, even though it is actually 0-200% Gains and not 0-400%, maybe it is just a typo in the commentary?
...To my ears FSMP sounds exactly like standalone Munt but has the 0-200% vs 0-400% Gains labeling wrong.

No, it's not a typo in the documentation, it's actually in the very code.

Munt driver/Qt uses 100% (1.0f) as default for Gain and Reverb Gain:

1synthProfile.outputGain = settings->value("outputGain", 1.0f).toFloat();
2synthProfile.reverbOutputGain = settings->value("reverbOutputGain", 1.0f).toFloat();

Both the Gain and Reverb Gain slider in Munt Qt has a range of 0-400% with default 100% and ticks at every '100' units:

1<item row="9" column="0">
2      <widget class="QLabel" name="label_5">
3       <property name="text">
4        <string>Output Gain</string>
5       </property>
6      </widget>
7     </item>
8     <item row="9" column="1">
9      <widget class="QSlider" name="outputGainSlider">
10       <property name="maximum">
11        <number>400</number>
12       </property>
13       <property name="orientation">
14        <enum>Qt::Horizontal</enum>
15       </property>
16       <property name="tickPosition">
17        <enum>QSlider::TicksAbove</enum>
18       </property>
19       <property name="tickInterval">
20        <number>100</number>
21       </property>
22      </widget>
23</item> 

So at the end of the Gain slider Munt qt sets the Gain parameter to 4.0f (400%).

Munt VSTi uses 100% (1.0f) as default for Gain and Reverb Gain and has a range of 0-200%.
So at the end of the Gain slider Munt Vsti sets the Gain parameter to 2.0f.

As I said before and Serge confirmed the volume level difference comes from the fact that the built in integer-> floating point conversion in Munt uses 16384 as conversion constant instead of the VST expected 32768.
It seems like Serge would like to change the conversion behavior so I will wait a while:
Munt Reloaded - Development

As a backup plan I have already implemented integer -> floating point conversion in my code with conversion constant 32768 and this way the plugin produces the same volume level
as the driver/Qt app. But I definitely wait for Serge's solution before publishing next version .

Testing the "32bit internal rendering" produces even Less emulated DAC digital distortion with HQ and 'Pure'.
But there is something terribly wrong with Gen1/2 DACs in 32bit , they are extremely distorted even more than in 16bit.
You can test this with my headroom.mid and "Output Gain" at 20.

Falco, I think this is relevant information to the MT-32 Dev thread but I don't want to duply-post on various boards.

Ok, I have duplicated your post myself 😀

Falcosoft wrote:

2. There are 2 functions in Munt's C API to get the rendered samples (note: the 2nd one is not the same as the newly introduced […]
Show full quote

2. There are 2 functions in Munt's C API to get the rendered samples (note: the 2nd one is not the same as the newly introduced floating point rendering path) :
a. mt32emu_render_bit16s()
b. mt32emu_render_float()
For a VSTi plugin mt32emu_render_float is the natural choice since VST plugins always use floating point data(32 or 64 bit).

?
So what "32bit internal rendering" does in the VST?
Is it related to the DAC to fix the "digital overflows" issue or the final rendering path, or both?

When both MT-32 VST set to "32bit internal rendering" and FSMP set to "Use 32bit Sample data", there is ZERO clipping with 200 Gain in HQ setting and headrrom.mid, but the final output is dynamically normalized by FSMP, exactly like SC-VA.
So to my ears Floating point operation works correctly, and far beyond what the real hw MT-32 can do.

Falcosoft wrote:

The 2 functions give different results regarding volume level. The floating point one results in twice the volume.

This statement is not true regrading the VST.
There is no difference in volume between 16bit and 32bit in the VST.

Hi James,

There are 2 functions in Munt's C API to get the rendered samples (note: the 2nd one is not the same as the newly introduced floating point rendering path)
a. mt32emu_render_bit16s()
b. mt32emu_render_float()

The bold statement was an important one.
There are 2 conceptually different 'floating point modes' in Munt:

1. You can get floating point samples from Munt by using mt32emu_render_float(). It works even if Munt uses 16 bit integer rendering internally. This was in Munt long before the "runtime adjustable" internal floating point engine.
The volume problem is related to this function and its integer->floating point conversion as described before *. MuntVsti always uses this function to get data, since in VST world there is no integer mode. (Actually you can use mt32emu_render_bit16s() and do the conversion yourself, but why if there's a dedicated function to do it? -> That's what I thought 😀 ).

2. From version 2.01 of Munt you can set the internal rendering mode of Munt to use floating point data internally. This is what '32bit internal rendering" refers to. Here is the topic about it:
Request for floating point arithmetic version.
Originally it was a compile time directive whether you want to use the integer or the floating point engine. Obviously the default was the integer one.

I hope this will make things clear.

Ps:
* There seems to be a problem also with mt32emu_render_float() float to float conversion regarding volume level since it produces the same level as its integer to float algorithm.
I have not tried yet what happens when you use the 'Internal floating point rendering path' but you use mt32emu_render_bit16s() to get integer sample data. I will test it later.
May be that's what Serge referred to as

'After more thinking about it I became to a conclusion that the current behavior is actually a mess.'

Yes, much clearer, Thanks.
Lets' see if I understand correctly;
There is 32bit float Samples which is the default in the VST, but distortion can still occur if the digital output of the VST reaches full scale, this option has minimal audible affect on sound.
And Internal Rendering which actually enables "true" 32bit floating point wave output, this one doesn't clip at all if used in a VST Host that supports Floating Point.
Am I correct?

But what if you use 16bit Samples and 32Bit Rendering?
There should be almost no perceivable difference between 16+32 and 32+32.. no?
It is just like playing a 16bit WAV file in a 32bit Float media player.. the quality of the samples doesn't affect distortion behavior only noise floor.
16bit has -96db RMS noise floor which is more than enough, but I assume VST standard demands 32bit Float.

Yes, exactly.

I have not tried yet what happens when you use the 'Internal floating point rendering path' but you use mt32emu_render_bit16s() to get integer sample data. I will test it later.
....
But what if you use 16bit Samples and 32Bit Rendering?

Your question and my question are equivalent.

A will test it ASAP. Currently I'm at my working place.

Edit:

this one doesn't clip at all if used in a VST Host that supports Floating Point.
...
VST standard demands 32bit Float

'Supporting' floating point is not optional. If you are a VST Host it's mandatory. Only 64 bit floating point support is optional. VST 2.4 standard requires both the Host and the plugins to support at least 32 bit float. But if both the Host and the plugin support 64 bit double they are allowed to use it.
FSMP is a 32 bit float only VST Host since Bass does not support 64 bit floating point samples currently. But MunstVsti can do 64 bit doubles if the Host requests this. This way it can be placed in an audio pipeline where other effects can do real 64 bit double processing.

Hi,
I have made a test version that always use mt32emu_render_bit16s() to get sample data and make the integer -> floating point conversion by itself (multiplying by constant 1/32768).
This should not make a difference (except the volume level) when using internal integer rendering mode of Munt.
In case of the floating point internal rendering path there's an additional conversion step (namely float -> integer-> float). So there could be some differences compared to the previous mt32emu_render_float() version. I have checked and the volume level is the same as in the integer rendering mode! So the conclusion is the double volume phenomenon is caused by fully the
mt32emu_render_float() function and it has nothing to do with the internal floating point rendering.
http://falcosoft.hu/muntvsti_test.zip

Please, test it.

Falcosoft wrote:

namely float -> integer-> float
Please, test it.

I believe that destroyed the "true" floating operation.
Now it distorts/clips in 32bit rendering and 32bit in FSMP, whether in 2.1 it was true floating and there was no distortion at 200% gains.

I know it.
This was the question:

But what if you use 16bit Samples and 32Bit Rendering?

It is just a test to demonstrate the volume level situation and the 2 completely separate forms of Munt's floating point modes.
You can get float samples from both float and integer internal rendering and you can get integer samples from both float and integer internal rendering.
The volume level between the integer and float sample modes are different and independent from the used internal rendering mode.

Oh, I see, it was an experimental version together with a beta version..
So did you manage to fix the volume difference and keep the floating operation?

Theoretically it's nothing more than multiplying the result given back by mt32emu_render_float() with 0.5f at the moment. (Since both rendering path produces the same volume level).
But I would like to wait for Serg's solution to this problem as I said before. So no new version will be released at the moment.

Falcosoft:

I should mention that when producing recordings from FSMP, I found myself opening Audacity to get a more useful line-in level monitor implementation. In particular:

• Audacity's monitor provides some transient and permanent high water mark bars that greatly aid in getting good input levels.
• Audacity uses a logarithmic dB scale, which makes it easier to see changes at quieter levels but harder at higher levels. This actually hurt more than helped in my case, because I was trying to see what was going on at the top end.
• FSMP's level monitor has horizontal separators at regular intervals, instead of using every pixel for maximum accuracy.
• Audacity has level labels/indicators. I realize there isn't room for anything detailed on FSMP's interface, but maybe some marks between the two bars at 10%, 25%, or dB intervals might be useful.

Falcosoft
If long used SaviHost with this settings :
Samplerate = 44.1/48
Sample buffer = 2533 samples
Then we have delay.
Why is as ?

Please pardon the non FSMP related talk.

No problem, but maybe this discussion would deserve its own thread.

@Roland User: If long used SaviHost with this settings : Samplerate = 44.1/48 Sample buffer = 2533 samples Then we have delay. W […]
Show full quote

@Roland User:
If long used SaviHost with this settings :
Samplerate = 44.1/48
Sample buffer = 2533 samples
Then we have delay.
Why is as ?

I have already made my recommendations for Roland User, but maybe I have not explained the whys/reasons behind them.
I have also noticed in the comments section of Phil's Ultimate Midi Emulator Project video that he does not actually know why he recommended the 32000 Hz sample rate for MuntVsti.
The following explanation can be useful for anyone using MuntVsti.

So here are the facts:
Munt internally always use 32000 Hz sample rate.
The timestamp of Munt is linked to this 32000 Hz sample rate.
from documentation: 'The timestamp is measured as the global rendered sample count since the synth was created (at the native sample rate 32000 Hz).'
So absolutely rounding(so timing) problem free operation in VST environment can only be achieved using this 32000 Hz sample rate.

In the VSTi plugin there are 2 possible areas rounding can cause problems:
1. Counting the globally played sample frames.
2. Playing back the samples within a block at the required block offset position.

Problem 1 can be solved almost perfectly by using an appropriate sample rate and good block size (I will use SAVIHost terminology):
The run time calculation of the global timestamp can be expressed in the following form (it's when you process the sample frames contained in a block):

1 timestamp = timestamp + ( VST sampleFrames * (munt internal sample rate / VST sample rate ))  

Based on this you can conclude that e.g. at 48000 Hz and with 300 samples (160 b/s) you get exactly 200 sample frames in Munt's internal unit.
300 * (32000 / 48000) = 200
Another perfect case is 96000 Hz with 600 samlpes (160 b/s)
600 * (32000 / 96000) = 200
But e.g. in case of 44100 Hz you actually cannot get a perfect rounding problem free result
300 * (32000 / 44100) = 217.687... It has to be rounded to 218 but it's actually not true so you will get a little time drift.
So the conclusion is there are not so many proper combinations and Roland user's choice of 2533 samples is wrong with every sample rate.
2533 * (32000 / 48000) = 1688.666..

Problem 2 can only be entirely solved by using 32000 Hz since within a block you can get arbitrary sample offsets and you have to give Munt the offset in Munt's unit.

1mt32emu_play_short_message_at(midiStream, midiData, timestamp + (VST deltaFrames * (munt internal sample rate / VST sample rate )))

So e.g in case of deltaFrames 11 you cannot set the offset in Munt's unit perfectly.
The only way to mitigate this problem is to use as little buffer (less samples, more blocks/s) as possible since this way the solving of problem 1 will be more and more significant than problem 2.

So the recommendation:
1. If you can, use 32000 Hz. This is preferable not particularly because of audio quality, but because of the rigid timestamps of Munt linked to 32000 Hz.
2. If you cannot use 32000 Hz use 48000 Hz, 96000 Hz etc. with a block size that gives exact integer samples count in '32000 Hz units'.
3. Avoid 44100 Hz since it's impossible to get rounding problem free operation.
3. Use as little buffer as possible.

In SaviHost this means 160 b/s or 200 b/s buffer with 48000 or 96000 Hz.
FSMP makes the optimizations itself and 32000 Hz is also available.

FYI, I have moved the later posts regarding Line-In recording to a new topic: Recording MIDI synthesizers via PC Line-In

Hi
Serg has made 2 important modifications to Munt's core:
1. https://github.com/munt/munt/commit/db2c53e49 … 860da66de0c5681
This one cures the volume/normalization problems of mt32emu_render_float();
I have only experienced one drawback. Namely when the internal floating point rendering is NOT enabled the new version is much more distorted at higher gains than the previous one.
Munt Reloaded - Development (following the link there's also a video about the issue).
The fully floating-point path seems to be perfect.

2. https://github.com/munt/munt/commit/909717e7d … 37e9b9a306ff6a5
This one provides direct access to Munt's internal timestamp so no 'guessing' is necessary anymore. Thus the above described rounding/timing problems are greatly mitigated.

I have made a new test version for you to try. In the plugin nothing has changed related to mt32emu_render_float() handling so the decreased volume level is due to the new Munt's library.
(So the new mt32emu4v.dll can be tested even with the old MuntVsti.dll, but not the other way around.)
The slider range has been changed to 0 - 400%.
Also the new mt32emu_get_internal_rendered_sample_count() is used now to get proper timestamp instead of calculations by code.
Munt Reloaded - Development

http://falcosoft.hu/munt_vsti_test.zip

All is functioning well.

Thanks, but I have not been satisfied so far because I hate breaking changes. If you have an implementation for many versions that's not OK that in the next one you could not reproduce the output/sound of the previous ones in any way. (E.g. imagine a Reaper project with MuntVsti and other tracks/instruments already fine tuned.)
I have checked and the old version of the library produces the same level of distortion if you use 4.0f Gain and multiply the sample results given back by mt32emu_render_float() with 0.5f (to get the same volume level as the new version). So there is nothing Serg should fix. Simply the current half level float samples on 100, 200, 400% gain are not the same as the old ones on 50, 100, 200% gain.
So I have added a compatibility option 'Emulate v2.1 FP Conversion (Double Volume)'.
New test version uploaded.