expertsleepersltd / issues

Public facing feature request and bug tracker for Expert Sleepers modules
7 stars 0 forks source link

MIDI to I2C (follower) #642

Open Ysum opened 1 year ago

Ysum commented 1 year ago

I hate to ask for more shortly after you gave us Midi to I2C, targetting ER-301 (thank you so much for that!)

Any chance on exposing MIDI over I2C, DistingEx acting as a follower?

My use case is polling MIDI signals from Teletype (for further processing of midi note numbers/gates especially)

Surely with all the functionality present it's a low hanging fruit (I obviously have no idea what I'm talking about, hehe)

I would be more than happy to help testing

expertsleepers commented 1 year ago

The EX already implements I2C commands to output MIDI.

Or do you mean you want to query (from the Teletype) MIDI input to the EX?

Ysum commented 1 year ago

Yes exactly. And I just realised this is more involved than I initially thought. it would require some work on teletype firmware to be in line with the other disting ex ops. I guess I'd need to ask scannerdarkly or someone else familiar with the code base if willing to put in the work. alternatively there are the generic teletype ops we could use out of the box now. they support setting the i2c address and use any i2c device using a generic command api.

To give you an idea what use case I had in mind:

there are midi in ops on teletype, you might ask why not use these? the answer is: using a monome grid at the same time is not possible.

so as it stands, to use grid alongside midi in, we would need to (periodically or not) poll/query values. this works well with faderbank (16n). (seems maybe a bit odd for discrete signals, in contrast to continuous).

teletype generic ops synthax is:

IIQ1 cmd value1 (Execute the specified query with 1 parameters and get a value back)

IIQ2 cmd value1 value2 (Execute the specified query with 2 parameters and get a value back)

IIQ3 cmd value1 value2 value3 (Execute the specified query with 3 parameters and get a value back)

so querying could look something like this: (inspired by usb-midi-in commands https://monome.org/docs/teletype/manual/#midi-in)

// query note value IIQ1 EX.MI.N noteIndexNr // query velocity IIQ1 EX.MI.V noteIndexNr // query CC IIQ1 EX.MI.CC ccNr

or with specifiying channel as argument:

// query note value IIQ2 EX.MI.N channelNr noteIndexNr // query velocity IIQ2 EX.MI.V channelNr noteIndexNr // query CC IIQ2 EX.MI.CC channelNr ccNr

(unfortunately I don't know if "cmd" can be an arbitraty identifier or if it is a command code, i'm not familiar with the protocol)

of course it would be nicer to have dedicated ops. but would require a collaborator on the teletype side.

the i2c2midi project also implemented something along the lines, but seems to be doing some overly fancy stuff. https://github.com/attowatt/i2c2midi#teletype-ops

expertsleepers commented 1 year ago

This seems like a very odd way of dealing with MIDI, which is fundamentally an event-based protocol. It would require the disting to track the status of every note (with velocity) and CC across all 16 MIDI channels, on the off chance something was going to query it.

I could perhaps see putting this in the CVM-8, which has plenty of spare memory, but I wouldn't want to devote that much space to it in the disting - unless this was a dedicated algorithm, where MIDI-to-I2C was all the disting was doing.

Ysum commented 1 year ago

you know what, I kind of agree. with my request I am very much in the current-state-of-teletype mindset (with its limitation).

I guess the right thing to do would be making teletype also act as a I2C follower (easier said than done I guess). I'll start a discussion over at lines when the dust of the new teletype v5 release settles a bit.

distingEX is so versatile, can't blame you at all on using its (and your) resources carefully. I had imagined maybe there is already some kind of buffer in place.

edit: that said, I could see myself buying a cvm-8 if you were to implement such a thing there. More CV ins sounds tempting.

thanks! and sorry for the noise.