source for the midifighter utility?

[armadillu]

Hi! First off, thx so much for sharing the source on this. I've been missing higher res on the midi fighter (127 vals is often not enough) and having access to the source allowed me to increase the res of the knobs by sending encoder values not through regular midi packets, but through sysex msgs. (See https://github.com/armadillu/Midi_Fighter_Twister_Open_Source/tree/feature/14BitEncoder).

The current midifighter utility allows you to set the encoder action behavior, letting you chose between CC and SEND_NOTE. I would like to add a 3rd mode wich sends data through sysEx (I currently hijacked the SEND_NOTE mode to send sysEX). I would also like to add one extra global setting to be able to set how much higher the res is in the encoders when in this HIGH_RES mode (ie how many turns of the knob it takes to travel the whole value spectrum). To do so, I think I would also need access to the source of the midi fighter utility.

Have you guys thought about sharing that too?

[leehu]

Nice work - interested to take a look at this, but MIDI does offer 32, 14-bit controllers so do you need to use sysex for this?

[armadillu]

I don't know much about the MIDI protocol, but having a quick look, the only way I found to send 14 bits per knob was to send two separate packets. I saw the "Pitch Bend" packet which does take 14bits but it seemed to only work on whole channels (ie not possible to ID each individual knob).

Sending two separate packets as LSB and MSB while also handling packets from standard midi devices would have required adding much more logic on the other side for my case, so going for sysEx seemed a good quick & dirty way to get this up quickly. I'm using the midifighter for a very particular use - (to control parameters on realtime software https://github.com/armadillu/ofxRemoteUI ), so I'm ok with a more flexible interpretation of the midi protocols.

At he very end its just bytes going through the bus, and a sysex command with a specific sequence of commands that will be ignored by most devices seemed quite harmless anyway.

I'm happy to change strategy if I find a better option tough.

[natcl]

Implementing 14 bits over 2 CCs would have the advantage of making it compatible with midi software and hardware that supports it. Would be nice to see this implemented in the main firmware.