apollo-studio
apollo-studio copied to clipboard
mat1jaczyyy
MIDI Fighter 64 support
DJTT has responded, and the MF64 does not support any sort of direct RGB update message which is the only thing preventing us from getting MF64 support. They did say it's planned though, waiting for the potential firmware update to drop.
A year in and I got bored, so I checked on this issue as it got me curious to ask if DJTT has any update on the potential new firmware? (despite not owning an MF64)
The latest MF64 firmware is still labelled 64_0006000120170620.hex, implying it's from 06/20/2017.
Funnily enough, one might just disassemble the firmware and add the functionality themselves, as the binary itself is not too large. This wasn't considered at the time of this issue being made, but it can definitely be done this way. MF Utility already supports loading custom firmwares, for whatever reason.
As I don't physically own a MF64 however, I will definitely not be the one doing this though.
A year in and I got bored, so I checked on this issue as it got me curious to ask if DJTT has any update on the potential new firmware? (despite not owning an MF64)
9 months later, managed to get my hands on an MF64.
I will be spending some parts of my summer understanding Ghidra and HxD to probably help.
If there is still interest in support for rgb in the MF64 firmware, I can maybe help out. I just compiled a hacky version witch supports rgb, utilizing 3 midi channels for the respective color values.
I had to get rid of the sleep animation, because it freezes the device after startup. Have to further investigate, but I think the controller runs out of memory and can not allocate the grid for the animation.
Furthermore it currently breaks compatibility with the mf utility. I can still use it to flash the firmware when I set the device in bootloader mode manually, but that is pretty much it.
If there is still interest in support for rgb in the MF64 firmware, I can maybe help out. I just compiled a hacky version witch supports rgb, utilizing 3 midi channels for the respective color values.
I had to get rid of the sleep animation, because it freezes the device after startup. Have to further investigate, but I think the controller runs out of memory and can not allocate the grid for the animation.
Furthermore it currently breaks compatibility with the mf utility. I can still use it to flash the firmware when I set the device in bootloader mode manually, but that is pretty much it.
Looks like there's hope for the 4 people (me included) to have MF64 support on Apollo. This is promising.
Hey @FunkM0nk, thanks for the interest, was this done by hacking on the disassembly of the official firmware or implemented using this HAL?
Glad to hear you got things working, the only reason stopping me from hacking this in myself is not owning a physical unit lol, I'm definitely interested in seeing where this goes.
Unfortunately I can't add support for the implementation you propose (via MIDI channels) to Apollo, but if you could borrow the implementation used in Pro CFW or the one MK2/X/MiniMK3 hack (along with a unique version change in the device inquiry response), that would be enough to get official support in Apollo. The reason for the LED set code being this specialized is to minimize MIDI driver overhead, especially on Windows.
For official support, I'd personally prefer a disassembly hack, or at least that a HAL-based implementation nearly fully reimplements the stock firmware. I don't want to force users to constantly switch between two firmwares depending on their use cases, however this is up for debate...
thanks for the interest, was this done by hacking on the disassembly of the official firmware or implemented using this HAL?
It was done with the HAL you linked.
Unfortunately I can't add support for the implementation you propose (via MIDI channels) to Apollo, but if you could borrow the implementation used in Pro CFW or the one MK2/X/MiniMK3 hack (along with a unique version change in the device inquiry response), that would be enough to get official support in Apollo
Was going with MIDI Channels because I intended to use it with existing software, witch only allows for this kind of mapping( at least as far as I know). I just stumbled about this issue while researching things regarding the firmware and didn't had the chance to look at how Apollo handled things, yet.
Thanks for pointing to the implementations for the launchpads. Was going to take a look anyways and this will shorten my research quite a bit I think :)
For official support, I'd personally prefer a disassembly hack, or at least that a HAL-based implementation nearly fully reimplements the stock firmware. I don't want to force users to constantly switch between two firmwares
Absolutely understandable. I just crosschecked the repo with the changelog of the stock firmware and it looks to me, that all of the features of the current stock firmware are implemented. Looking at the licensing terms in the source files, this could indeed be the source of the original firmware.
I will have a go at implementing support for Apollo on the firmware side after some code cleanup.
@FunkM0nk from my brief viewing of it, I took it as either just a HAL or the earliest version. There have been numerous official stock firmware updates that I don't think that repo provides the source for.
When you build their repo unedited, does the hex file outputted match the official firmware?
When you build their repo unedited, does the hex file outputted match the official firmware?
I am not sure if it will be able to produce a matching output, since I had to edit some includes of missing source files. accel_gyro.c(most likely related to MF3D) and circular_buffer.c. Those were included in other source files, but never referenced.
The source has a some legacy code for older MF models and a lot of testing, but I suspect it actually is the latest firmware. Reasons being:
- Changelog provided here mentions the expanded color map. This matches what is present in the repo. Also 2 bank mode and combos are available.
- in the releases folder you can find midifighter64_20170724_production.hex, witch would match the release date of the last official firmware.
- I can not make out any different behavior flashing the latest stock fw vs. an unedited (minus the includes) fw.
I honestly think they just said "good enough" and stopped developing at that point.
To represent the "generic" MF64 user, here's a couple things that can be focused on the equation:
-
99.9% of the time, you'd be running the MF64 with no default lights on and letting Ableton handle light effects
-
Channel wise, it stays at 3. I haven't seen a reason why to change it because it doesn't cause conflict.
-
Super combos are a neat concept, but only works well for the 3D + Spectra since on the 64... well.. you have 64 buttons. (and the super combos only work on the bottom left set of buttons, I think.) You can very well replicate this with M4L
-
Think of the bank change as a hardware-included page swapper, I like it but other people have it off. Personal preference.
-
We don't need the utility AT ALL. You'd mess with it once and never be touched ever again. For flashing, maybe it could be a LP Utility thing? :D
tl;dr: Strip the MF64 from supercombos, default lighting, maybe even the bank switcher and utility features.
The MF64 is literally a blank canvas, a 500$ blank canvas mind you, waiting for someone to hack it open. Unlike the LP, it only has one mode. No velocity sensitivity and aftertouch too.
@FunkM0nk cool stuff. I'm going abroad for a week now, but I'm interested in collaborating on getting official Apollo MF64 support if you're up for the task
mat has gotten the funds to buy a (second hand) MF64, apollo release expected to be around late January/early February
wow, this is actually happening.