c++midijuce

Delay between midi note on and note off message in JUCE framework


Im making a little tool in C++ using the JUCE framework. Its sending out MIDI but I've come to a problem. I'd like to send out chords to my DAW, by sending a note on message followed by a note off message. The noteOn code looks like this:

        void MainContentComponent::handleNoteOn (MidiKeyboardState*, int 
        midiChannel, int midiNoteNumber, float velocity)
        {
            timestamp = (Time::getMillisecondCounterHiRes() * 0.001);
            MidiMessage m (MidiMessage::noteOn  (midiChannel, midiNoteNumber , velocity));
            MidiMessage m2 (MidiMessage::noteOn  (midiChannel, midiNoteNumber + 3, velocity));
            MidiMessage m3 (MidiMessage::noteOn (midiChannel, midiNoteNumber + 7, velocity));
            m.setTimeStamp (timestamp);
            m2.setTimeStamp (timestamp);
            m3.setTimeStamp (timestamp);
            sendToOutputs (m);
            sendToOutputs (m2);
            sendToOutputs (m3);

            handleNoteOff(midiChannel, midiNoteNumber, velocity)
        }

The problem is, that the note off message follows directly after the note on message. I'd like a delay between the note on and note off message. Any idea's on how to do that? I was thinking about delay options, but as far as I know they will freeze the entire program. Does JUCE have anything built in that can help me? I wasn't able to find it online.


Solution

  • JUCE's Tutorial: Create MIDI data shows how to send messages with a delay:

    The MidiBuffer class provides functions for iterating over buffers of MIDI messages based on their timestamps. To illustrate this we will set up a simple scheduling system where we add MidiMessage objects with specific timestamps to a MidiBuffer object. Then we use a Timer object that checks regularly whether any MIDI messages are due to be delivered.

    Warning

    The Timer class is not suitable for high-precision timing. This is used to keep the example simple by keeping all function calls on the message thread. For more robust timing you should use another thread (in most cases the audio thread is appropriate for rendering MidiBuffer objects in to audio).