Falcosoft wrote:

Then you must be doing something wrong in Audacity since the original 0 dB gain recording amplified by Audacity by +12dB should […]
Show full quote

3. Yes. Because then I will get sample with distortion

Then you must be doing something wrong in Audacity since the original 0 dB gain recording amplified by Audacity by +12dB should give the same result as recording with Simple Gain VSTi by +12dB.
Also you should only hear distortion/clipping when you use integer formats. 32-bit floating point data should never clip/distort.
Also I have noticed that you use 44100 Hz sample rate in Audacity. Maybe you also used this sample rate when recording SC-VA sounds. This is a bad choice. The native sample rate of SC-VA is 32000 Hz. There is no problem free conversion between 32000 and 44100 Hz. So you should set the sample rate of Midi Player before recording to 32000 Hz. But even 48000 Hz is a better choice. Also in Audacity you should also use 32000 or 48000 Hz for your project and also select 32-bit float format everywhere (quality and output settings). Also select Windows WASAPI as output device instead of MME. And also make sure in your Windows audio playback device's control panel the Default Format is also set to 48000 Hz.

Note: I didn't record entire sample. I layed out square wave samples and united them in soundfont. But layed-out samples were too silent. And this is the reason why samples in recording have noises. If these samples were more louder by using Simple Gain VST, it would be fine.

Please be a little bit more specific. Instead of writing down what you did NOT do you could describe the exact steps you had done. And also some details about:
1. What software you used for recording?
2. What exactly you recorded from SC-VA itself?
3. How simple gain VST is a part of your process?
4. What sample rate and bit depth you recorded at?

And this is the reason why samples in recording have noises. If these samples were more louder by using Simple Gain VST, it would be fine.

I'm really sorry that after more than 10 posts you still do not understand why this is nonsense...
And even if it could be true some way tell me a reason why the same cannot be done exactly the same way in Audacity as the plugin does... The plugin can only post process the rendered samples the same way Adacity can post process the recorded samples. There is no theory that can explain why this is not the case.

Falcosoft wrote:

Please be a little bit more specific. Instead of writing down what you did NOT do you could describe the exact steps you had don […]
Show full quote

Please be a little bit more specific. Instead of writing down what you did NOT do you could describe the exact steps you had done. And also some details about:
1. What software you used for recording?
2. What exactly you recorded from SC-VA itself?
3. How simple gain VST is a part of your process?
4. What sample rate and bit depth you recorded at?

And this is the reason why samples in recording have noises. If these samples were more louder by using Simple Gain VST, it would be fine.

I'm really sorry that after more than 10 posts you still do not understand why this is nonsense...

1. For recording I used SCVA and Soundfont MidiPlayer.
2. I recorded instruments with stereo sounding. For this I maximally panned nesessary samples to receive source samples.
3. Simple Gain VST helps me make recording samples louder (Gained samples have little less noises than without gain).
4. 44100 Hz. My favorite. I checked 32000 and 48000. Both are awkward. First have squeak, second, in my opinion, is too soapy.
There's new recording. First sample used parametres:
SCVA Pan: L63
SCVA Level 127
SGVST Gain: 0 dB.
SGVST Balance: R10.
Second sample used parametres:
SCVA Pan: L63
SCVA Level 127
SGVST Gain: +12 dB.
SGVST Balance: R10.
https://drive.google.com/open?id=1--V5fjuxDa_ … 7Sn9uuD9x91nyNi

EmperorGrieferus wrote:

4. 44100 Hz. My favorite. I checked 32000 and 48000. Both are awkward. First have squeak, second, in my opinion, is too soapy.

Taste is one thing but facts are another. You can have 44100 Hz as 'favorite' but in this case it's simply the worst choice. I'm not talking about your final end result master mix. It can be rendered at 44100 Hz as a last step if you want. But during processing the resampling artifacts of your 44100 Hz recordings can add up resulting in unwanted noise. Try to repeat your process with 32000 Hz recordings. Just for your consideration...
Instead of hoping that increasing gain can kill noise some mysterious way (please, send me reference literature about how it can be possible even in theory) using the native sample rate of the synth's samples actually can make a difference.

Falcosoft wrote:

EmperorGrieferus wrote:

4. 44100 Hz. My favorite. I checked 32000 and 48000. Both are awkward. First have squeak, second, in my opinion, is too soapy.

Taste is one thing but facts are another. You can have 44100 Hz as 'favorite' but in this case it's simply the worst choice. I'm not talking about your final end result master mix. It can be rendered at 44100 Hz as a last step if you want. But during processing the resampling artifacts of your 44100 Hz recordings can add up resulting in unwanted noise. Try to repeat your process with 32000 Hz recordings. Just for your consideration...

Okay, I will record. But something says to me that the result will be same.
32000 Hz: https://drive.google.com/open?id=1PR0mOiHQm3N … g6o5JYwAWtj7nTg

SCVA Pan: L63 SCVA Level 127 SGVST Gain: 0 dB. SGVST Balance: R10. Second sample used parametres: SCVA Pan: L63 SCVA Level 127 S […]
Show full quote

SCVA Pan: L63
SCVA Level 127
SGVST Gain: 0 dB.
SGVST Balance: R10.
Second sample used parametres:
SCVA Pan: L63
SCVA Level 127
SGVST Gain: +12 dB.
SGVST Balance: R10.

You wrote that the 1st sample was recorded at 0 dB and the 2nd at +12 dB. Yet both samples in your recording have the same peak and seem to be normalized. Should not you upload the raw, not normalized samples instead?

Falcosoft wrote:

SCVA Pan: L63 SCVA Level 127 SGVST Gain: 0 dB. SGVST Balance: R10. Second sample used parametres: SCVA Pan: L63 SCVA Level 127 S […]
Show full quote

SCVA Pan: L63
SCVA Level 127
SGVST Gain: 0 dB.
SGVST Balance: R10.
Second sample used parametres:
SCVA Pan: L63
SCVA Level 127
SGVST Gain: +12 dB.
SGVST Balance: R10.

Image2.jpg

You wrote that the 1st sample was recorded at 0 dB and the 2nd at +12 dB. Yet both samples in your recording have the same peak and seem to be normalized. Should not you upload the raw, not normalized samples instead?

Here. But sample rate is 44100 Hz. Sorry.
https://drive.google.com/open?id=13ug6t1SBdAl … PwXYK-H_bAWBSUj
Edit: You can make an easy experiment.
Take any mono instrument (For example: Acoustic Grand Piano), set level to 50 and record it. Still recording, change level to 127 and press same key. You will be surprised.

OK, now I think I understand what your problem is. When you use simple gain VST it works with 32-bit floating point data since in VST world everything is floating point. But your recordings are all 16-bit integer ones. So they have smaller dynamic range and when you normalize them or add 12 dB gain in Audacity you also raise the noise since the original dynamic range has already lost at the 32-bit float -> 16-bit integer conversion made by Midi Player. Somehow I believed that you always use 32-bit floating point data at recording since your first images showed 32-bit floating point samples in Audacity. So you should check the the '32 bit float' checkbox at the right hand side of Midi Player's file select dialog after you press the recording button. This way audacity will have the same headroom with your 32-bit floating point recordings than simple gain VST has with the real-time 32-bit floating point data.

Falcosoft wrote:

OK, now I think I understand what your problem is. When you use simple gain VST it works with 32-bit floating point data since in VST world everything is floating point. But your recordings are all 16-bit integer ones. So they have smaller dynamic range and when you normalize them or add 12 dB gain in Audacity you also raise the noise since the original dynamic range has already lost at the 32-bit float -> 16-bit integer conversion made by Midi Player. Somehow I believed that you always use 32-bit floating point data at recording since your first images showed 32-bit floating point. So you should check the the '32 bit float' checkbox at the right hand side of Midi Player's file select dialog after you press the recording button. This way audacity will have the same headroom with your 32-bit floating point recording than simple gain VST has with the real-time 32-bit floating point data.

Please, look at experiment. And in Audacity normalize both samples.

Please read again. I have just tried and in case of 32-bit floating point recordings I get the exact same noise level If I record with Simple Gain Vst +12dB option or with 0 dB option and amplify +12 dB in Audacity afterwards.

Falcosoft wrote:

Please read again. I have just tried and in case of 32-bit floating point recordings I get the exact same noise level If I record with Simple Gain Vst +12dB option or with 0 dB option and amplify +12 dB in Audacity afterwards.

I understood. But the problem is in gain: less gain (In synthesizer, not recording) - more noise in recording. More gain (In synthesizer, not recording) - less noise in recording. This is why Simple Gain VST requires 24 dB as gain range max value.

I understood. But the problem is in gain: less gain - more noise. More gain - less noise. This is why Simple Gain VST requires 24 dB as gain range max value.

NO, you do not understand. The problem is you used 16-bit recordings, thus decreasing the dynamic range and then you tried manipulating the already 16-bit integer data. While you stay in 32-bit floating point domain (also in your recordings) the equation is: less gain - SAME noise. More gain - SAME noise (proportionally)
That's why there is absolutely nothing requires more Gain, even +12 dB is absolutely unnecessary at real-time.
You can do the same at post processing in your wave editor.

Falcosoft wrote:

NO, you do not understand. The problem is you used 16-bit recordings, thus decreasing the dynamic range and then you tried manip […]
Show full quote

I understood. But the problem is in gain: less gain - more noise. More gain - less noise. This is why Simple Gain VST requires 24 dB as gain range max value.

NO, you do not understand. The problem is you used 16-bit recordings, thus decreasing the dynamic range and then you tried manipulating the already 16-bit integer data. While you stay in 32-bit floating point domain (also in your recordings) the equation is: less gain - SAME noise. More gain - SAME noise (proportionally)
That's why there is absolutely nothing requires more Gain, even +12 dB is absolutely unnecessary at real-time.
You can do the same at post processing in your wave editor.

What a bloody magic? I can't believe my ears.
Well, I'm very sorry for wasting your time in vain.

EmperorGrieferus wrote:

Well, I'm very sorry for wasting your time in vain.

Already happened before 😀

Falcosoft wrote:

EmperorGrieferus wrote:

Well, I'm very sorry for wasting your time in vain.

Already happened before 😀

I had a crazier idea.
Edit some files in SCVA to increase bend range max value.
Result: Fail.

I had a crazier idea.
Edit some files in SCVA to increase bend range max value.
Result: Fail.

The crazy idea is that it requires editing files. Setting pitch bend range has been a part of Midi specification for a long time. In GM specification you can find how to set pitch bend range under the RPN section:

The Pitch Bend Sensitivity RPN (0,0) is also known as Pitch Bend Range. The high order adjustment uses Controller 6 (Data Entry MSB) to set the range in semitones. The low order adjustment uses Controller 38 (Data Entry LSB) to set the range in cents (that is hundredths of a semitone.

Also if you right click the first aid like 'Reset' button of Midi Player you can select custom SysEx messages. If you choose GS_MT32_Mode.syx and send it to SC-VA it sets the Pitch bend Range to 12 semitones from 2 semitones GM default (among others).

Falcosoft wrote:

The crazy idea is that it requires editing files. Setting pitch bend range has been a part of Midi specification for a long time […]
Show full quote

I had a crazier idea.
Edit some files in SCVA to increase bend range max value.
Result: Fail.

The crazy idea is that it requires editing files. Setting pitch bend range has been a part of Midi specification for a long time. In GM specification you can find how to set pitch bend range under the RPN section:

The Pitch Bend Sensitivity RPN (0,0) is also known as Pitch Bend Range. The high order adjustment uses Controller 6 (Data Entry MSB) to set the range in semitones. The low order adjustment uses Controller 38 (Data Entry LSB) to set the range in cents (that is hundredths of a semitone.

Also if you right click the first aid like 'Reset' button of Midi Player you can select custom SysEx messages. If you choose GS_MT32_Mode.syx and send it to SC-VA it sets the Pitch bend Range to 12 semitones from 2 semitones GM default (among others).

I will try when I will finish rewriting organ samples (Accordion and Bandoneon).

Hi,
A new test version is available together with a new version of Munt VSTi:
http://falcosoft.hu/midiplayer_57_test.zip

In case of Midi player the only addition is the support of real time sync Midi messages together with Midi Timing Clock. It's added only for the fun factor. This way FSMP can be used as a Master together with devices/software that can support real time sync messages as a Slave. I have made a short test video with AutoDrum and Midi files that have somewhat interesting tempo changes:
https://youtu.be/bnTbNi6yPaE

The bigger additions are related to Mint VSTi:
1. I have convinced Serg to add an option to disable the weird LA-32 behavior that can result in attenuated or completely missing notes in case of GM files that are not intended to be played on LA-32. It can happen because of this (quote from Serg):

LA-32 is known to mix partials either in-phase (so that they are added) or in counter-phase (so that they are subtracted instead).
In some cases, this quirk isn't highly desired because a pair of closely sounding partials may occasionally cancel out.
In the NicePartialMixing mode, the mixing is always performed in-phase, thus making the behavior more predictable.

The new option is called Nice Partial Mixing and by default it's disabled in MT-32 mode but enabled in GM mode.
(@Roland User: you should try this option since it can give much better results e.g. with your earlier uploaded 'dibigc20-sc88.mid' file).
On the interface the checkbox controlling this option has 3 states. The default is the above described Auto mode but you can also force both the ON and the OFF states. In MT-32 mode it's recommended to be disabled/set to Auto since some MT-32 Midis could rely on this feature.

2. For the sake of coherency the Reverse Stereo setting now also has 3 states and behaves the same. Namely in Auto mode it's enabled in GM mode but disabled in MT-32 mode, but both ON and OFF states can be forced.

3. An Auto option also added to 'Midi delay mode' that follows the same above described logic.

4. The added Multi-threaded rendering seems to be rock solid now but it has to be enabled manually.

5. Also fixed some minor issues regarding GM compatibility.

I hate to ask but, is there any chance the MIDI sequencing code for the OPL3 VSTi plugin could be used to improve/fix the one in ALSA for Linux systems?

The OPL MIDI usage on Linux currently suffers from these bugs:
Notes can get stuck "on" if polyphony is exhausted and many, many notes are rapidly being instructed to play.
Controller events (except for pitch wheel) are ignored for active voices and only considered for a new voice.
The polyphony managing is not very conservative at all. (Many songs with long notes end up getting shafted by repetitive short sounds being prioritized first for whatever reason)

DracoNihil wrote:

I hate to ask but, is there any chance the MIDI sequencing code for the OPL3 VSTi plugin could be used to improve/fix the one in […]
Show full quote

I hate to ask but, is there any chance the MIDI sequencing code for the OPL3 VSTi plugin could be used to improve/fix the one in ALSA for Linux systems?

The OPL MIDI usage on Linux currently suffers from these bugs:
Notes can get stuck "on" if polyphony is exhausted and many, many notes are rapidly being instructed to play.
Controller events (except for pitch wheel) are ignored for active voices and only considered for a new voice.
The polyphony managing is not very conservative at all. (Many songs with long notes end up getting shafted by repetitive short sounds being prioritized first for whatever reason)

Hi,
If you ask 'my permission' to use the source code of the Midi sequencing process then the answer is of course: yes, you can use it. But as you may have noticed in the source (available in FSMP's package) some code parts are from Microsoft that are not (L)GPL ones. And my modifications are based on these code parts. I do not think code parts licensed under the Microsoft Limited Public License can be used in ALSA's code to improve it. The most problematic part of this license is the '3. F' section:

F.Platform Limitation - The licenses granted in sections 2(A) and 2(B) extend only to the software or derivative works that you create that run on a Microsoft Windows operating system product.

So while MS-LPL is basically a permissive/free license that is similar to BSD in this sense, but only as far as Windows is concerned.