openAVproductions / openAV-Ctlra

A plain C library to program with hardware controllers.
BSD 3-Clause "New" or "Revised" License
78 stars 16 forks source link

Initial mikro mk3 support #107

Closed zewelor closed 1 year ago

zewelor commented 2 years ago

Hi

thanks for great project. After some work I can finally use my Maschine Mikro MK3 in linux ! I've based code on Maschine MK3 code and Maschine Mikro MK2. Midi changes are from: https://github.com/openAVproductions/openAV-Ctlra/pull/95, which was merged but not into master. I hope those changes are ok ? Also some update in daemon.c.

So far looks like buttons / slider / encoder / pads are working. After connection display is draw half black half white, to indicate that there is connection. Maybe in some future I will get how to write / draw some stuff there. I think now only missing is leds control, for now ?

EDIT: Added pads leds, and seems to work in daemon. Commented this daemon code, because I'm not sure how it works, it comments about pads/grid but its handled above. Also it just starts with button id = 0.

harryhaaren commented 2 years ago

Hey @zewelor, generally, thanks for adding MikroMK3 support! As I don't have HW to test, I'll have to just assume things just work!

I had hoped that the "Mikro" MK3 would be the "normal" MK3 but just with some things disabled - you've taken the approach of duplicating all the code & reworking for the device itself.. that's fine too. I expect there is some code-duplication, but that's also present in the other device support.

Generally code looks good, haven't done an in depth review. Keep the "update commits" coming, and let me know when you think its good to merge?

zewelor commented 2 years ago

Hi

I will test it for some more days, but looks like everything is working so far. As for code duplication, maybe we could DRY it a bit ? There are differences in usb communication / buttons idx / layout etc. RGB color to hsv could be extracted to some common code ( Could you provide guidance where and how ? ). Also pad decoding code is the same.

Also I've started to make Maschine midi mode, somehow similar as its in windows. https://github.com/zewelor/openAV-Ctlra/blob/mc-customizations/examples/midi_bridge/midi_bridge.c . For example its possible to change octave using groups. Same as in windows midi mode.

harryhaaren commented 2 years ago

DRY is a good idea, less duplicate == a win. However, to really refactor Ctlra "device drivers" properly would require large effort & testing. As you can see from the commit-history, I do not currently spend much time on the library/OpenAV projects (due to real-life things). I'd like to refactor & redo things, but lets be pragmatic/realistic too - and just merge this when it works :)

I like the idea of emulating the MIDI-mode: I haven't used the Maschine/Kontrol on Windows, so don't know what it does, but I think some users had requested such feature/functionality before (perhaps for better Mixxx bindings? Although I had a Mixxx/Ctlra native integration branch for a while which I felt was a better solution to tight-integration).

Good work - keep me posted if you need my help for specific things and I can try make some time. Cheers -Harry

harryhaaren commented 2 years ago

@zewelor; I cannot comment or review your code for midi_bridge because its in your repo. If you create a PR for it, I can comment inline.

A few small things I see from a quick scan (https://github.com/zewelor/openAV-Ctlra/blob/mc-customizations/examples/midi_bridge/midi_bridge.c#L36):

1) Watch out for tabs/spaces: the indentation is inconsistent. 2) The daemon_t for passing around to callbacks can allocate (or just contain a member variable) to a mm_static. That way the mm_static doesn't have to be static. For e.g. LV2 plugins, removing static state is a very good habit - unless there's a reason it must be static that I'm missing?

zewelor commented 2 years ago

Thanks for looking into midi_bridge.

  1. Formatting should be fixed now.
  2. I have very little C experience, most work I've done copying other code and making little adjustments. Static struct for mm_t was taken from: https://github.com/openAVproductions/openAV-Ctlra/blob/master/examples/sequencer/seq.c#L64 without thinking much about it. Thanks for pointing this. Already fixed.

I think it would be good to have somehow similar midi mode, like in official drivers. This code emulates this a bit. Group and Shift ( on mikro mk3 ) are special buttons, that cannot have assigned midi code, in official software. Group is used to change pads midi codes mapping. On MK3 looks like only shift is special ( https://www.native-instruments.com/forum/attachments/screen-shot-2017-09-23-at-16-19-48-png.52558/ ).

In my version, group allows to change octaves, send by pads. Added also possibility to change midi channel via shift + pad ( current channel highlighted ).

I think logic can differ per device, also currently there are hardcoded buttons for mikro mk3 ( https://github.com/zewelor/openAV-Ctlra/blob/mc-customizations/examples/midi_bridge/midi_bridge.c#L132 ). Maybe it would need some per device config. Like which buttons are special and some callbacks to handle then or per device function to handle each event type ? I think it would be good to have high level framework written once with per device customizations.

As you've added Maschine MK3, maybe you will find this interesting. I've added new message type parsing: https://github.com/openAVproductions/openAV-Ctlra/pull/107/commits/f2008f29ddd594dfef68ef4e12bd8e05081dfadd#diff-edf488ad803513400fb966b89935c333d77ec81efed04c6a2e26917f35f1d166R462 . I've only seen it when using pads, and then pressing some button, but not always, like 20% of time. Looks like it had half of pads data + buttons data ( 64 + 14 [ mikro mk3 buttons message size ] ).

EDIT: Midi emulation open a lot of doors, in terms of software integration. One benefit vs some native integration is that you can for example use it in Mixxx and on the same time use it on some other software ( both software reacts to the same midi not, for example some music sample + fire light using qlc+ etc ). Or some other crazy ideas, and integration with a lot of software, which can use any midi controller, via midi learning.

zewelor commented 2 years ago

I think its ready for review. Did some testing and couldn't find any more errors for now.

harryhaaren commented 1 year ago

Hi @zewelor; any changes/progress since? I have little time, but hoping to do a Ctlra lib release sometime to incorperate some compilation fixes... and I'm OK with merging this as "experimental" for now if you're happy with it?

zewelor commented 1 year ago

Hi

Recently i was not using mikro mk3. As far as I remember it worked fine, at least stuff that I've tested. If you want to merge I think its a good base at least. For me it was game changer to use mikro mk3 on linux as normal midi controller. Maybe would be useful for more people.

harryhaaren commented 1 year ago

Great; thanks for the quick feedback. I'll look to merge the code soon, and thanks for working on it!

zewelor commented 1 year ago

Thanks for review. I've applied your suggestions. I hope now its all good ?

harryhaaren commented 1 year ago

I've had to do a manual rebase of this patchset as there were (true) conflicts in the midi.c code. I've rebased it onto lastest master and pushed... that brings Ctlra library to > 1000 commits! https://github.com/openAVproductions/openAV-Ctlra/commit/8b6cf95712c0e67c92b93fa270c3ee094f870d28

Thanks @zewelor for working on Mikro MK3 support, and the quick rework to fixup some minor style things!