Using Midi-Keyboard with MusE

[Tutorius]

Hi,
i have got a new keyboard today. It is a Arturia Keylab 49 Essential. It has nine turn-knobs and nine sliders that are sending some midi controls.
The controllers work well with synthesizers i have added, i can use them to alter filters and so on.
I have tried to use the controllers for conrolling the mixing-sliders in Mixer1. I klick to add a controler and learn it, it is learned.
When i then use the slider or knob, the mixer-slider on the screen disapears and it is not possible to get it back again.
Just a restart works, as far i can see it.
Any hints or is there an other way to get this connection working?

Thanks for your answers...

[Impostor]

That's a bug. Assigning volume automation to a controller leads to NAN when you move it. Other parameters seem to work OK.

This can be found in the .med file when saved with two automation points on the volume graph:

Code: Select all

controller id="0" cur="-nan" color="#ffffff" visible="1">
        576000 -nan 5,         1632000 -nan 5,         

(to get a graph in the first place you have to manually draw a point first, otherwise it just disappears)
EDIT: It seems to be locale independent at least :)

[Tim E. Real]

Observed. Thanks.
Seems to be only with volume sliders.
Not locale related.
I will dig deeper later...

[Tim E. Real]

Hi. This should be fixed in github master now.
All logarithmic controllers including certain log plugin controllers and our built-in volume had this problem.

It was an oversight with recent 'minimum logarithmic controller decibel value' reworking.
Ha! I could be making that up and you wouldn't know it, eh?

Thanks very much for the report.

[Tim E. Real]

This should be something in the manual. I'll try to add it but I wanted to state it here.

A quick word about logarithmic audio controllers:

With the exception of our built-in audio logarithmic volume controllers (for which we have the luxury of
having a minimum slider decibel Global Setting), some logarithmic plugin controllers specify a minimum value of 0.0.

This presents a problem: When we want to display or manipulate (increment, adjust) the value in units of decibels,
there is no specification of what a reasonable minimum decibel value would be.
No plugin architecture has such a specification for this value.
A minimum decibel value MUST be chosen before any math can be performed in units of decibels.
It cannot be -inifinte decibels as the stated 0.0 minimum log value suggests.
Otherwise you end up with NAN infinite values and so on.

When a plugin's minimum log value states it is 0.0, it implies that it is up to the user (or the app) to choose a minimum decibel value.
Unfortunately MusE doesn't have per-controller user-settable decibel minimums and maximums.
And, well, it would be a lot of user micro-management. Without an 'overview' window, the user might be lost, unsure of
how many of the potentially hundreds of controllers available have what particular settings.

So I had no choice but to 'compose' or 'educated guess' pick a minimum decibel value based on the overall value range of the controller.

What this means is that a logarithmic native UI control might jump to -infinite dB a bit too soon when its corresponding generic UI control
is moved towards zero.

Try it with LSP plugins for example. Some of their plugin native UIs have 'level' controls which, when rotated clockwise,
jump from -infinite dB to -80 dB, and then smoothly rise to say, 60 dB.
But our generic UI version of that control has no way of knowing that the plugin's minimum dB value is -80 dB
before it jumps down to -infinite dB. There is no specification of that value in any plugin architecture (LV2, VST etc.).
Therefore the semi-educated minimum dB value that I pick in my code might be somewhat higher than -80dB.
This means the native control might jump a bit too soon from a minimum value that I pick of say, -60dB, down to -infinite dB,
as the corresponding generic UI control is lowered.

The exact same rules apply to midi-to-audio controller assignment discussed in this thread.
You may see the native UI control jump a bit too soon to -infinite dB as the the external midi controller is lowered.

Hope you can understand that.
I need to explain it a bit more in the manual.
Tricks, traps, and gotchas for sure.

[Tim E. Real]

I have added some info to the wiki at:
https://muse-sequencer.github.io/docs/automation.html

I discussed midi control to audio control assignment.
And I talked about this minimum dB stuff.

And there is more info.
I present it here for completeness.
If you are wondering why a plugin native UI's logarithmic control such as 'level' is clearly displayed in decibels
but our corresponding generic UI control is displayed in pure log, here is the answer:

Quote:

There is another problem with logarithmic plugin controls: There is no way to know whether a logarithmic control should be
displayed in decibels, frequency (Hertz), pure log, or some other units.
Even when the plugin's own native UI displays the control in units of decibels for example, there is no reliable mechanism
by which we can know that we too, in our generic UI, should also show it in decibel units.
Logarithmic controls whose units are of frequency (Hertz) face a similar problem.

[ Side note: If you are thinking that I could look at the LV2 units, which include pre-defined "dB" and "Hertz", to determine
how exactly to display a control, forget it. They are not reliable. LSP for example uses mysterious custom units like "G" for gain, not "dB".
So LV2 units are out of the question. ]

Once again, it would be up to the user (or the app) to choose how to display every available logarithmic control in
our generic plugin UIs - as decibels, frequency (Hertz), pure log, or some other unit. It would be yet more user micro-management.

[ Side note: I was actually shocked and dismayed to learn all of this! It's a baaaad situation. ]

In future releases this level of manipulation might be possible to add to MusE.
But for now, you will see a plugin's native UI logarithmic controls in decibels, Hertz or other units,
while our corresponding generic UI controls will always be shown in pure logarithmic units.

[Impostor]

I have added some info to the wiki at:
https://muse-sequencer.github.io/docs/automation.html

Just wondering: Are you the sole active developer of MusE? Or are you simply the only active one here?

[j_e_f_f_g]

Are you the sole active developer of MusE? Or are you simply the only active one here?

There's definitely at least one other developer. And he does occasionally post here (although I've forgotten his handle), although not nearly as often as Tim. Tim just happens to be the only one who can fit into the hazmat suit before logging in here.

[j_e_f_f_g]

look at the LV2 units, which include pre-defined "dB" and "Hertz", to determine
how exactly to display a control, forget it. They are not reliable.

But they should be reliable. I can't imagine why a plugin dev would not use the dB units tuplet if his value is expressed in dB. Can you ask sadko4u to change it? He's usually quite cooperative. And if not, Dave Healey tells me he's easily bribed.

[merlyn]

... But for now, you will see a plugin's native UI logarithmic controls in decibels, Hertz or other units,
while our corresponding generic UI controls will always be shown in pure logarithmic units. ...

What base is the logarithm to? If it's base 10, then you pretty much have dB. I don't know about the specifics of LV2, but I do know about dB.

dB = 20*log₁₀ (V2/V1)

So if you have log to the base 10, going to dB is simply multiplying by 20. If it's only log to the base e (natural log or ln) that's available it's possible to change the base with

log_b (x) = log_a (x)/log_a (b)

or with a concrete example log₁₀ (x) = ln (x)/ln (10)

[Impostor]

... But for now, you will see a plugin's native UI logarithmic controls in decibels, Hertz or other units,
while our corresponding generic UI controls will always be shown in pure logarithmic units. ...

What base is the logarithm to? If it's base 10, then you pretty much have dB. I don't know about the specifics of LV2, but I do know about dB.

dB = 20*log₁₀ (V2/V1)

Note your use of a reference value, the absence (or lack of specification) of which is exactly the problem, if I understand Tim's point correctly.

Edit: I see that was Tim's first point, not his second, to which you were replying. But again, it's lack of specification what's the problem: what do "g" units stand for? Gravitational acceleration? Gain? Pleasure?

[Impostor]

Are you the sole active developer of MusE? Or are you simply the only active one here?

There's definitely at least one other developer. And he does occasionally post here (although I've forgotten his handle), although not nearly as often as Tim. Tim just happens to be the only one who can fit into the hazmat suit before logging in here.

Yes, spamatica is another MusE dev, indeed.

[merlyn]

... Note your use of a reference value, the absence (or lack of specification) of which is exactly the problem, if I understand Tim's point correctly. ...

There is a reference as correctly the units are dBFS, dB relative to full scale which could be taken as plus or minus 1, or 2²³ as a 24 bit signed integer.

[Impostor]

... Note your use of a reference value, the absence (or lack of specification) of which is exactly the problem, if I understand Tim's point correctly. ...

There is a reference as correctly the units are dBFS, dB relative to full scale which could be taken as plus or minus 1, or 2²³ as a 24 bit signed integer.

Ah. Then I guess I didn't understand Tim's point after all:)

[Tim E. Real]

Heh. I was afraid I might have caused confusion.

To clarify: This is not a fault with any plugin, either LSP or other brands, or any LV2 or LADSPA or VST plugin.
It is a shortcoming of the plugin specifications and architectures.

The plugins did the right thing - the only thing that they could do.
Which was to specify a log controller with a minimum value of 0.0.

The problem lies with displaying and manipulating such a log range that starts at 0.0.
For example, when you try to adapt a standard integer value slider widget to adjust a log value within such a log range,
you run into a problem. You cannot simply apply the slider's integer values to this log range. Otherwise all of the useful range of values
will become compressed into one small section of the slider.
So you have to first convert the log range into a linear decibel range (or some similar linear range - it doesn't have to be dBs)
and then you can apply the linear integers from the slider, then convert back to a log value (with exp10 for example) and store this value
in the plugin's controller.
But there is a problem with that conversion from log to linear range: A minimum log value of 0.0 converts to -inifinity dB.
This value cannot be used in the scaling calculations as it gives an infinite dB range.
One must arbitrarily pick (or be given) a reasonable minimum dB value in order to reasonably limit the low-end of the linear dB range.
At the very first slider integer setting of '0', a special exception is made to make the resulting log value jump to 0.0 thus
cutting off the sound completely.
At the next slider integer setting of '1', that minimum dB value kicks in and its log equivalent is returned.
At all successive slider values from '1' to the slider's maximum value, normal log-to-dB-to-log conversions can be done.

If the plugin maker had specified that a 'gain' or 'level' control had a linear decibel range, then the maker would
be forced to impose their own lower dB limit in the plugin's range specs.
The specified range would have to look something like: Minimum: -80, Maximum +60 (in the case of LSP plugins).
The maker cannot specify a minimum value of -infinity because that's not a friendly value to pass around.
You can see there is a problem there: A linear minimum of -80 would mean the sound could not be completely cut off !
So you see the plugin does the 'correct' thing by specifying a logarithmic range which starts at 0.0 (sound completely cut off).
They essentially leave it up to the app or the user to decide what is a reasonable minimum dB value if dBs are what is desired.
Which is fine - except that we don't know what they are using in their native UI control.
We don't know what that minimum dB value is before their control suddenly jumps down to - infinity.
In the case of LSP, we don't know how to obtain that lower limit -80 dB value before it jumps to -infinity.
That value is useful to us.

And that is where the shortcoming lies in the plugin architecture specs. There is a lack of information.

To muddy the water a bit, some plugins and architectures actually do specify 'gain' in a linear range !
VST plugins for example usually do that IIRC. Some LADSPA plugins do it. How do they get away with it?
I believe that when presented with a value equal to the specified minimum, they simply make a special exception
for this one value and interpret it as -infinity dB.
This way the user sees a nice easy-to-use linear dB range but the very first value in the range is interpreted as -infinity.

Hope that made sense. I just woke up...