[sm_jamieson]

I mentioned before that the code paths in JUCE are:

[keypress on GUI] – noteOn(chan,note,vel) – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)
and
processNextMidiEvent – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)

Regarding the current ctrlr code:
Since noteOnInternal sets the note state that is used when drawing the keyboard (in MidiKeyboardComponent::paint) I am note sure why the incoming midi is not being indicated on the keyboard in ctrlr. Something in ctrlr must be bypassing a part of the process. This will need investigating in ctrlr. It should not be necessary to call NoteOn from handleNoteOn in order to get the GUI to update ( thus generating a duplicate midi event – which I believe was the original problem).

Due to the move of ctrlr to GitHub, I cannot see the original code from the time when the GUI did indicate incoming midi but was seeing duplicate midi events, so I could not investigate further.

Thanks,
Simon.

[sm_jamieson]

Thanks, I had tried that before but I had not clicked “Refresh property lists”.
Simon.

[sm_jamieson]

My requirement for linear slider touch screen behaviour is slightly different. I would like the slider to only start moving after my finger has moved through the current location, preventing any jumps at all. In practice this means you can start off slightly below/above the slider to avoid any sudden jumps. This is a standard type of behaviour in some music applications.
Obviously it would need to be an option since sometimes you want an immediate jump.
I have no idea if JUCE supports this.
Simon.

[sm_jamieson]

Regarding the item (1) comment “if it is not possible to have it working as an indicator and live keyboard at the same time, could we have a ctrlr option to choose which mode ?”.

I suggest a compromise.
Since the JUCE midi keyboard component keypresses produce output on only one channel, you can safely display incoming midi for the other channels (whilst being able to suppress duplicate messages) since you know those can only have come from midi input and not the GUI !

Simon.

[sm_jamieson]

On a previous post it was mentioned that the main requirement to fix item (1) is to know the source of the change in keyboard state, whether from a midi event or a gui key press. I’ve looked at the code in JUCE and the code paths are as follows:

keypress – noteOn – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)
and
processNextMidiEvent – noteOnInternal(chan,note,vel) – handleNoteOn(chan,note,vel)

It should be simple for JUCE to pass the source (midi or GUI) through as an extra parameter in a variant of handleNoteOn. The comment on the JUCE forum about requiring two midi sources to the component seemed to kill the discussion dead, when what is actually required is much simpler.

Simon.

[sm_jamieson]

I had an old version. I have now installed version 5.3.54 and it is all working, including full lua runtime errors.
Simon.

[Author]

Posts