Hmm. Well it kinda works. I can receive MIDI events in my Reaper DAW and the board appears as a MIDI output device but the code reports no incoming MIDI events when I send them from Reaper.
For some reason the downloaded usb.device library uses compiled .mpy files and I'm still trying to figure out how to replace these with normal source files (which I *assume* would be the equivalently-named core.py and midi.py files in the github repo) but putting these in the same folder tree /usb/device results in an error 'module' object has no attribute 'get' on the line
usb.device.get().init(m, builtin_driver=True)
which is undoubtedly due to a stupid oversight on my part, no doubt. I'm not remotely an expert on Python module name resolution unfortunately. (obvs I'd like to be able to add more debug print logic to try and track down what's going on)
However the overall implementation does seem quite fragile. It's possible to easily get into a state where the COM3 port is permanently in use and only a reboot will recover (i.e power cycling the Pico won't get you out of it); also, I can get things into a state where Reaper is no longer able to enumerate outbound MIDI devices and truncates the list it shows for reasons unclear at this stage. Still, this is a new and complex feature, I'll have to continue investigating.
I do have wireless midi fairly stable (as a fallback) using a small implementation of rtpmidi on the Pico W and this works rock solid with Reaper, but the show-stopper I hit previously is that the WLAN functionality doesn't work on core 1, which meant my plan of offloading all MIDI to that core failed. It's possible, I guess, that 1.23 addresses some of the core 1 issues (there were problems with IRQ handling as well causing rotary encoder read code to fail), I haven't looked at that yet. Fingers crossed....
For some reason the downloaded usb.device library uses compiled .mpy files and I'm still trying to figure out how to replace these with normal source files (which I *assume* would be the equivalently-named core.py and midi.py files in the github repo) but putting these in the same folder tree /usb/device results in an error 'module' object has no attribute 'get' on the line
usb.device.get().init(m, builtin_driver=True)
which is undoubtedly due to a stupid oversight on my part, no doubt. I'm not remotely an expert on Python module name resolution unfortunately. (obvs I'd like to be able to add more debug print logic to try and track down what's going on)
However the overall implementation does seem quite fragile. It's possible to easily get into a state where the COM3 port is permanently in use and only a reboot will recover (i.e power cycling the Pico won't get you out of it); also, I can get things into a state where Reaper is no longer able to enumerate outbound MIDI devices and truncates the list it shows for reasons unclear at this stage. Still, this is a new and complex feature, I'll have to continue investigating.
I do have wireless midi fairly stable (as a fallback) using a small implementation of rtpmidi on the Pico W and this works rock solid with Reaper, but the show-stopper I hit previously is that the WLAN functionality doesn't work on core 1, which meant my plan of offloading all MIDI to that core failed. It's possible, I guess, that 1.23 addresses some of the core 1 issues (there were problems with IRQ handling as well causing rotary encoder read code to fail), I haven't looked at that yet. Fingers crossed....
Statistics: Posted by ajay_m — Sun Jun 16, 2024 11:00 am