Closed zewelor closed 1 year 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?
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.
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
@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?
Thanks for looking into midi_bridge.
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.
I think its ready for review. Did some testing and couldn't find any more errors for now.
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?
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.
Great; thanks for the quick feedback. I'll look to merge the code soon, and thanks for working on it!
Thanks for review. I've applied your suggestions. I hope now its all good ?
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!
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.