DJ-TechTools / Midi_Fighter_Twister_Open_Source

95 stars 25 forks source link

source for the midifighter utility? #4

Open armadillu opened 6 years ago

armadillu commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.