#include "qmk_midi.h" always results in compile error[Bug]

[xbong360]

Describe the Bug

I've spent the past few days working on a keymap for the BDN9 that includes midi functionality on separate layers. Everything works great, but I wanted to include midi sends for the encoders like

        if (clockwise) {
            midi_send_cc(&midi_device, 0, 0x14, 1);
        } else {
            midi_send_cc(&midi_device, 0, 0x15, 1);

However, in order to do that I need to put #include "qmk_midi.h" within the keymap and no matter what I do it always results in the same error if qmk_midi.h is included. Here's the error

tmk_core/protocol/midi/qmk_midi.h:7:36: error: unknown type name 'MIDI_EventPacket_t'
 void              send_midi_packet(MIDI_EventPacket_t* event);
                                    ^~~~~~~~~~~~~~~~~~
tmk_core/protocol/midi/qmk_midi.h:8:36: error: unknown type name 'MIDI_EventPacket_t'
 bool              recv_midi_packet(MIDI_EventPacket_t* const event);

I've gotten pretty obsesive about it because I can't for the life of me figure it out. I have midi enabled in the rules and have # define MIDI_ADVANCED in the config. I'd really appreciate if anyone has any suggestion. Thanks

System Information

• Keyboard:
  BDN9 REV 1 (Pro Micro)
• Operating system: Windows 10
• AVR GCC version: 8.3.0
• ARM GCC version: 8.3.1
• QMK Firmware version: 0.9.10

[AlexOConnorHub]

See Pull request #9466. I was having similar trouble. Try adding#include "protocol/usb_descriptor.h" to tmk_core/protocol/midi/qmk_midi.h inside the if statement.

[AlexOConnorHub]

@xbong360 have you been able to try this?

[xbong360]

@AlexOConnorHub YES I had tried a few inclusions within qmk_midi.h with no luck, but usb_descriptor.h was finally the thing that got it compiling.

Sorry for the late response. as soon as it compiled I got distracted by trying to setup rotary encoders to function in a more conventional decreasing/increasing 0-127 value way like a potentiometer. Thanks again though, the lack of similar issues online had been driving me crazy.

[AlexOConnorHub]

No problem! Do you have your code on git somewhere? I was hoping to do something similar with an encoder, and would like to see someone else's idea on how to do it, since MIDI is a rather new territory for QMK.

[xbong360]

@AlexOConnorHub I hadn't quite figured out how to get an encoder working the way I wanted until just barely. My entire keymap is still a mess and I haven't got multiple encoder layers working quite yet, but I'm starting to understand midi functions a bit better. I don't know what your use case is, but as for me I wanted to be able to map an encoder to a min/max parameter in Ableton (gain, sends, dry/wet fx, etc). Here's what my send function for that use case looks like at the moment.

            if (clockwise) {
                midi_send_cc(&midi_device, 0, 0x20, 117);
            } else {
                midi_send_cc(&midi_device, 0, 0x20, 10);
            }`

So the only difference between clockwise and counterclockwise is the value. Those values are absolute, but in Ableton (along with other daws) you can creating mappings using a relative midi cc mode. Basically this makes endless rotary controls possible. So instead of values just being a set number between 0-127, it's more like 0-63 goes in one direction and 127-64 in the other. The way I think about it is like "if 1 = +1 then 127= -1". I might have that backwards, but regardless smaller increments were going too slow and that's why I set the values to 10.

Again I barely understand this as it is, but that's where I'm at right now. Hopefully I'll have a fully functional keymap that I can share soon and it actually make sense.