MIDI-based instruments play an octave too low by default

[softrabbit]

Left: TripleOscillator, one sine wave, coarse tuning 0, 440 Hz
Right: ZynAddSubFX, one sine wave, coarse tuning 0 AFAIK, 220 Hz

Same root note, same note played as the image shows. Both do output the correct note 69 through MIDI out.

(For further evidence, this is how I had to compensate in OpulenZ: https://github.com/LMMS/lmms/blob/master/plugins/opl2/opl2instrument.cpp#L306 )

[badosu]

@softrabbit This is weird, A4 should always be 440hz right?

[eagles051387]

Yes as per http://www.phy.mtu.edu/~suits/notefreqs.html A4 is 440hz.

On Wed, Mar 11, 2015 at 3:57 PM, Amadeus Folego notifications@github.com
wrote:

@softrabbit https://github.com/softrabbit This is weird, A4 should
always be 440hz right?

—
Reply to this email directly or view it on GitHub
#1857 (comment).

Jonathan Aquilina

[Sti2nd]

A4 should always be 440hz right?

Maybe, but the world doesn't agree. 442 is also highly accepted for orchestras. We can only assume LMMS uses 440? The frequncy on the right image is far lower than 440Hz, though, so it is definitely not an A.

[badosu]

Well 220 is half 440, so it's A, just one octave below :-).

[Sti2nd]

Lol, I was too fast there, yes, of course it could be a lower A!

I don't know where the Zyn's inbuilt keyboard starts from, but if it starts from C1 Zyn is indeed playing A3, marked with 3.

[badosu]

Yeah, if we had an integration layer before touching Zyn, this would probably be not an issue.

@softrabbit @Sti2nd Can you make a list of intruments that you have found that present this problem for when someone takes this task the person already has something to work with?

[softrabbit]

Grepping the plugin sources for IsMidiBased finds these possible victims: Carla, Vestige, ZynAddSubFX (confirmed), OpulenZ (fixed internally).

I don't see any code to adjust the octave in Carla or Vestige, both seem to pass on the key number they get, so I'd say they are almost certainly affected. Actual testing to confirm wouldn't hurt, of course.

This all comes from LMMS numbering notes internally in a different way from MIDI, look in e.g. src/core/midi/MidiAlsaSeq.cpp how every incoming and outgoing key event gets adjusted by KeysPerOctave.

[badosu]

@softrabbit thanks for the feedback! 👍

[curlymorphic]

Just a note for when this is implemented

If we change this, It would mean that all existing projects would play an octave different on the effected instruments. This could be worked around, by checking the version when loading the project files.

[badosu]

@curlymorphic Well remembered, we already present a warning when using older projects on newer versions.

The release notes emphasizing this can be helpful.

[PhysSong]

LMMS have note range C0~B8 (0~107), but most of MIDI based instruments have note range C-1~G9(0~127). I think the note range should be extended, when this issue is fixed.

[geckolinux]

Unfortunately this still prevents me from using LMMS (now testing with version 1.2.0). Using my M-AUDIO Keystation 88es, it still interprets it as an octave too low. I was playing around with moving the base note down 12 steps, which makes the lowest note on my 88 key keyboard playable, but on the other hand the highest note is silent.

[telepriest]

unfortunately that renders this otherwise great software almost useless. what a shame.
a simple option switch in the settings could fix that.

[michaelgregorius]

Here are some results that I have found while investigating #5139. I repeat them here because this issue is a good fit for them.

Mapping/manipulation of MIDI note values

I found that several MIDI values, e.g. for "Note On" and "Note Off", are manipulated in MidiAlsaSeq::run where a value of KeysPerOctave is subtracted. If I play an A4 on my MIDI keyboard I can see in the debugger that the struct ev has a correct note value of 69 (see here). This value is then changed to 69 - 12 = 57 before being passed into the MidiEvent that is processed by MidiPort::processInEvent.

What's surprising is that for example Triple Oscillator still plays an A4 = 440 Hz (69) instead of an A3 = 220 Hz (57). This means that somewhere the whole thing has to be corrected again.

I found out that this more or less happens in the constructor of InstrumentTrack where the following line is executed:

m_baseNoteModel.setInitValue( DefaultKey );

The value of DefaultKey is 57 which corresponds to the value that an A4 is mapped to. So the base note of the Instrument Track is set to 57. The Triple Oscillator takes the frequency that it should play from the NotePlayHandle that's passed into TripleOscillator::playNote. This frequency is calculated in NotePlayHandle::updateFrequency and one of the factors that determines the frequency is the value of the base note. If we don't take master pitch and detune into account the frequency is calculated as something that looks similar to the following:

m_frequency = BaseFreq * powf( 2.0f, key - baseNoteModel)

In the case of the pressed A4 key and baseNoteModel both have a value of 57 so we multiply BaseFreq by 2^0 = 1. BaseFreq has a value of 440 and thus we play A4.

LMMS can't handle the full note range of MIDI devices

In MidiPort::processInEvent the following checking code can be found:

if( inEvent.key() < 0 || inEvent.key() >= NumKeys )
{
    return;
}

If I trigger the lowest note on my MIDI keyboard this corresponds to a "Note On" with a value of 0. Because LMMS subtracts a value of 12 in MidiAlsaSeq::run before passing the value to MidiPort::processInEvent the aforementioned check returns because it sees a value of -12.

Put differently: if you had a keyboard with 128 keys for each MIDI value then LMMS would ignore some of them and would likely also not forward them to VSTs which might be interested in the full range.

I think LMMS should not manipulate the raw MIDI data and instead should just forward it. It should be left to consumers to decide how to deal with them, i.e. if they want to ignore some of the values.

[he29-net]

For reference, this is how all the instruments I have available in my build (skipping a few which I have no loadable content for) currently respond:

VST, Vibed and Zyn seem to be definitely broken; TripleOsc appears broken but is just detuned down by default so it works as intended, sfxr is somewhat weirdly out of tune so it is hard to tell, Organic is probably all right as the harmonic series suggests the correct A4 is supposed to be the main note, and OpulenZ I'm not sure about, because it starts on the right note and then adds many harmonics that suggest the A3 is the main note.

EDIT: So it appears only VSTs and Zyn were affected. Vibed apparently works as intended and OpulenZ corrected the offset internally, as mentioned in this discussion. I'm not sure about Carla as I never used it, but given the discussion and bug reports mentioning it, it is probably safe to say it was affected as well.

[geckolinux]

@Veratil Nice! What release will this fix appear in? Thanks a lot!

[qnebra]

It will be in 1.3, this mean currently developed release.

[Veratil]

We'll be building a new alpha version this week as well.