Add support for i2c2midi to firmware about crow

[mreid]

I’d love to see this too. I have a more memory efficient and fully featured version of that script you linked to on my machine. I’m traveling at the moment but will push an update once I’m home next week.

[eethann]

I've started merging the i2c2midi code into the firmware here, currently compiles but untested: https://github.com/eethann/crow/tree/i2c2midi_support

[eethann]

I just uploaded a compile of the first rough implementation and it seems to be working. Yay. I'll work on smoothing it out a bit and maybe getting more coverage of the i2c2midi commands.

[mreid]

Nice work! I've just pushed the version I mentioned above to my repo: https://github.com/mreid/crow-i2c2midi/blob/main/i2c2midi-compact.lua

From memory, it gets rid of the range checking of the original to save memory and adds some extra commands. It also has a simple example usage at the top.

[eethann]

Awesome. I just tried with the added CC out ops and they work. So fun!

I also tried adding a MIDI IN CC getter, but it's not working immediately. I'll push and provide more info.

[eethann]

I figured out the CC getter (have to pass both channel and control number as args) and got the midi getters basically working. I've published a release so others can try it out here: https://github.com/eethann/crow/releases/tag/4.1.0-i2c2midi-rc1

I haven't gotten to any documentation yet. There's one problem that might require a change to some deeper code in the crow firmware: the second arg is used to pass the control number to query, but the event callback function is only passed the first argument. This makes it impossible to handle a specific controller number in the callback. The solutions I can see are either

1. Generate separate getters for every CC controller number, so you only pass the channel (seems less than ideal, but would follow the fader implementation)
2. Update the callback handler to pass an args table or an arg2 property back to the controller so we can check the specific controller that is being reported on (I think this would be preferable if not prohibitive)

Interested in any thoughts or recommendations about those two.

[trentgill]

hey folks! apologies for the long delay here - i didn't realize this was sitting here waiting!

i took a quick look at the linked forks & the core ii descriptors look good. if i understand correctly, the big block of commented out code is the example of how to incorporate it into a crow script. i assume the runtime-memory usage comes from generating function stubs for every command.

could someone link me to (or explain):
a) example of a crow setter & getter using this
b) the transmitted bytes that match to the above

my hope is we can find a way to use the "pickle"/"unpickle" C-extensions of the ii description file, to avoid needing to create stub-functions for every command.

if that fails, we could look into a metatable solution so all the commands can share the same function. i'd prefer to avoid this and keep everything within the automated ii code generation land!