Max for Live: crow + i2c can present instability

[dndrks]

this has been a pretty big white whale (no micro-pun intended) since the beginning -- when crow's Max for Live devices are used to convert MIDI to i2c messages for Just Friends, the entire i2c bus will unpredictably crash. often, it is tied to a density of note data or instantiating another Live device in the chain while notes are being played simultaneously. this has been reported with Just Friends as well as w/.

over the years, I have tried to repro the 'density of note data' issue with Max with no effect -- there seems to be some type of issue happening exclusively in the Live -> Max -> crow -> i2c chain. as I've iterated the devices trying to chase down stable scenarios, i've found myself wondering if the data is just being throttled between Live and Max and something is clogging the serial messages and crow is getting hit with multiple conflicting messages at once. eg. when another device [say, Random MIDI] is loaded while an arpeggio [via Arpeggiator] is running, Live's UI noticeably hits a small lag -- Live will always prioritize the audio thread over any other data, so maybe that's introducing a kink?

anyway, logging here and on the M4L repo for centralized visibility!

[trentgill]

agreed this seems like a limitation of Live's handling of the underlying Serial port in max patches. it may be ameliorated by dramatically increasing the i2c queue length (

crow/lib/ii.c

Line 21 in 4ca8b7d

#define II_QUEUE_LENGTH 16

) to 128 or something like that.

still very unclear to me how this crashes the i2c bus, but perhaps this could help. otherwise it might require further buffering/throttling of the outgoing i2c messages. or maybe the mechanism we use to detect when an i2c transfer has completed returns too early?