Timecode over USB-MTC - Midi Time Code

[mungewell]

FujiFilm announced a FW upgrade to introduce compatibility with Ambient Lockit devices, talked about/demonstrated here:
https://youtu.be/C4O3qpItzw0?si=_slQyaDvqQGjLbxZ

Big question is whether this is an Open Standard, and whether 'we' could implement with PicoTimecode.

Micropython on the RP2040 now supports implementing USB devices (apparently):
https://github.com/micropython/micropython/blob/master/examples/usb/usb_simple_device.py

[flummer]

I think it is MIDI time code that is used

https://ambient.de/en/products/acn-cl-lockit-timecode-und-syncgenerator (technical details tab)

[mungewell]

@flummer Thanks for the link, I first saw mention of this in Instagram post - where they seem to say that you can use either USB-HID or MTC. Obviously USB-Midi Class and USB-HID are different things... I know you can convert MTC to TC (afterall my Sync-IO can do that), but I'm not sure how simple it would be for a Pico.
https://www.instagram.com/p/DCpGFQ6sQTD/?igsh=YXhvam1iaGRnYml1

I did find that there is a 'HID Usage' for a 'Time Sensor', and perhaps this is what they use. I'm not clear how one would relate fractional framerates and/or dropframe into that....

[mungewell]

Looks like microPython added the ability to be a Midi-USB client.

https://github.com/micropython/micropython-lib/tree/master/micropython/usb#package-usb-device-midi

[mungewell]

I had a look at how MTC works:
https://en.wikipedia.org/wiki/MIDI_timecode

So we'd need a trigger every 1/4 of the frame, and then output nybles of HHMMSSFF data (which is available from tc_raw).

The PIO StateMachines are all clocked at same rate, and set up for 320 clock per frame (80 * 32).

By happen-stance I've re-written the LED code to save space, which now uses a shift register and clocks out the LED state during parts of the cycle - I had used 10 'parts',representing each byte within the 80bit frame, but that can change.

We also need code to cope with the extra sync (16bits) sent at the start. So a 'part' would have to factor for 16bits and 20bits (80 / 4).... each 'part' could be 4 bits (128 clocks) long, with 20 of them per frame.

For each 'active' part the shift register could output '11110 ->' (nominally '11111->') to a pin, and use this pin to jmp(pin,) over a irq() making it happen (or not). We're very short on PIO code space (like 1 instruction spare at present).

Seems like a workable plan...

[mungewell]

On the downside we'd loose the ability to lightsleep() the processor, as CPU code would have to be active pretty much all the time... or at be very carefully managed.

[mungewell]

Doubled checked that the midi stuff does work, simple script which fakes sending MTC (I think...)
mtc_example.py.zip

Need to install module to Pico from PC console.

$ mpremote mip install usb-device-midi
Install usb-device-midi
Installing usb-device-midi (latest) from https://micropython.org/pi/v2 to /lib
Installing: /lib/usb/device/__init__.mpy
Installing: /lib/usb/device/core.mpy
Installing: /lib/usb/device/midi.mpy        
Done

[mungewell]

Improved test script (don't forget to install the 'usb-device-midi' lib):
mtc_example.py.txt

Here it is sending MTC to 'xjadeo' controlling the playback head. Counts to '00:02:00:00' and then restarts.

Next up porting into project.

[mungewell]

Prototype code running MTC output from Pico-Timecode is here:
https://github.com/mungewell/pico-timecode/tree/mtc_output

Demo video:
https://www.youtube.com/watch?v=kkTFQ0azi5w