#`synthio.Note` should default to
gloomy niche
I haven't tried running the samples yet (thanks for the link!). I'm very curious about what effect the WS pin might have because the WS and MCLK pins got swapped between board revision B (the one I have) and revision D (the one that's reflected in the current board.I2S_* pin definitions)
pulsar dagger
Oh yeah, that could definitely be the problem. If you have an oscilloscope or logic probe of some sort, I'd recommend probing that pin. If it's stuck on GND, all you'll get is left channel.
gloomy niche
hmm... it's soldered onto the board rather than a separate breakout, so probing that signal would be pretty tricky. I'll take a closer look at how I'm calling I2SOut. Currently I do audiobusio.I2SOut(bit_clock=I2S_BCLK, word_select=I2S_MCLK, data=I2S_DIN), so it's using I2S_MCLK instead of I2S_WS. But, it's possible I've messed that up somehow by missreading the commit that changed the pin definition.
Thanks! I'll go try this stuff now.
gloomy niche
Never figured out what the deal was with the missing right channel audio. But, based on the things I've ruled out, a hardware issue on the prototype board seems reasonably possible. I'll just try again once the real boards are up in the shop. Also, in case you're curious, I wrote this project up as a Playground guide: https://adafruit-playground.com/u/SamBlenny/pages/fruit-jam-portable-midi-synth
pulsar dagger
I've never dealt with USB Host MIDI myself, but is there a particular reason you're using your own implementation rather than the adafruit_usb_host_midi library? https://github.com/adafruit/Adafruit_CircuitPython_USB_Host_MIDI
gloomy niche
yes, there is. Long story short, I got started on doing my own USB descriptor parsing because I was hitting problems and bugs using the CIrcuitPython usb_host API stuff to handle descriptor parsing.
Based on the behaviors I've observed, I think there may be some combination of buffer overflows, race conditions, use after free, or whatever in the normal descriptor parsing code.
After a lot of trial and error for USB host gamepad support, I came up with the basic structure of the stuff that I've adapted for USB host MIDI.
Another thing about my USB code is that its designed to use the MicroPython performance boost tricks described at Maximising MicroPython speed
pulsar dagger
Sounds like you know a lot more than me on the topic. If there's any way to improve the adafruit library, I'm sure they'd appreciate a PR.
gloomy niche
Yeah... I've not really gotten up to speed on digging into CircuitPython and TinyUSB internals. Tried a few times, but it's a major commitment to learn. Kinda hoping that by building and documenting various example projects, maybe that will inspire some other folks to dig into what's causing the glitches.
for some of it, you'd probably need a Beagle USB analyzer in combination with a logic analyzer (to watch C level GPIO pin wiggling to trace functions for interrupt handling in the core, etc)
gloomy niche
Sounds like you know a lot more than me on the topic. If there's any way to impr...
In case the context for my last two comments wasn't obvious... Some of the problems I hit gave me the impression that the Python functions were tickling C-level bugs. So, I think the fixing would need to happen in the core.
But, also, for performance, using an implementation that's based on class methods and properties (i.e. the normal adafruit midi stuff) adds kind of a lot of heap allocation and dictionary lookups. So, I'd rather just use a whole different approach.
The code I've been writing is just on the edge of too many dropped and stuck notes to be useable, so I'm trying to do all the performance boosting stuff I can