Interfacing multiple axoloti on one midi input


#21

haven't been tested between axoloti's, but I've got sort of a bundle of modules working together in this patch (see below for patch).
It consists of 3 parts:
1- control/note encoding modules (2 modules for controls: 8x 16 bit single and 8x 8bit dual X/Y controls into a 32bit single pulse message)
2- data combiner combines the 32bit single pulse message of up to 8 encoder modules into one serial stream to be connected to a GPIO.
3- serial decoding receive modules for notes and controls (all listen to a single data stream, multiple streams can be used to divide up the data to reduce latency. eg. seperate the note and control messages over two seperate GPIO's)

1
the control encoding modules come in two options.
-the first one excepts 8 controls and encodes these in 16 bits resolution, each having their own controller CC, all having the same channel
the second one excepts 8 controls and encodes these as 8bit XY pairs, each pair having their own controller CC, all having the same channel

the note encoding module comes in one option, just a single "mono" trigger. To play polyphonic, just add multiple of these as the normal cv2midi module and connect them all to the same datacombiner.

all this encoded data is being send as single 32bit pulses whenever a control changes. This pulse contains all the channel, type, control and value data in 32bits.

2
The data combiner takes in the 32bit pulses of the connected control/note modules, put them in a buffer and play the bits of the buffer serially until the buffer is empty again. Up to 64 pulses can go into the memory, if this is not enough, it could be set higher inside the code (enlarge the buffer array and change the values of the "wp" and "rp" (write and read position) where it says "&63"->use powers of two and use the lengthmask to keep read and write positions between the boundries.
The output of this module should be connected to a GPIO.
As the data of the controller module can "run a bit out of hand", it's recommended to use seperate modules for note and control data.

3
All the receive modules just listen to the same data stream.
Whenever the input goes high for the first time, it starts reading out the message, which will always be 32bit, and send it to one of the outputs in case the channel, type and control number correspond with the selected channel/control number set on the module and whether the module is of the same type (note/16b control/dual 8bit control)

The control receive modules have 8 outputs that output the last decoded values from the serial stream.
An attribute spinner sets which channel the module will listen to. 2 modules to decode the 16bit and dual 8bit codes.

For the note receiving, I've got 3 modules:
-a simple mono receiver, it was my first try to get the values out of the stream
-a simple 4 voice receiver with a top to bottom note priority: it will always try to fill the first outputs, last one only gets filled when there are actually 4 notes playinh

-a converter module to decode the stream into data and then encode it into midi, so it can be internally used in the normal sense.

and a nice pattern generator to test the polyphony :slight_smile:

serial data connection.axp (115.0 KB)


#22

oh, as for the syncing... this is a first try.
I will probably need a second trigger signal running alongside to sync things. At the moment I did it simple by just sending one high bit to start the stream. From that first trigger, the receiving modules will start reading until they've read 32bits (whatever the sending axoloti does, so this might get out of sync). Then they start waiting on the next incoming stream.


#23

whahahahhahahahahahahahaha
it works over GPIO LOLOLOLOLOL

too soon.. got hanging notes every once in a while
though controls seem to work ok..


#24

No offense intended, but do you understand the meanings of synchronous, asynchronous and isochronous?

There’s a good reason for the existence of UARTs and USARTs. Even if you get something working, it’s likely to be slow, and CPU-intensive, at least on the receiving side.

Again, no offense intended, but this is tricky stuff.


#25

I understand, it's my first try out.
it's kinda working, though not optimal.
It's also the first time I've hooked up those gpio's of two axoloti together.
Gonna test some more this week, I guess . As I'm not using those gpio's anyways, I might as well just abuse them for communication between axoloti's, to have one control module and the rest for drums, synths and fx


#26

fwiw yesterday i finally got around to testing the GPIO serial comm with @Hugo's extra midi io project, and it works like a charm. just connected one axos TX to the others RX. i was able to change the baudrate to 250000 and it still was working fine. now i just have to get my midibox to send at high rates too...

now, a rather general question, can i just split serial data wires physically? ie. one TX pin to 3 RX pins? or do i need to involve voltage buffers? i read up on that a million times but still fail to understand it, i guess it depends on the GPIO RX pins impedance? if they don't draw a lot, it could work w/o buffers? anybody with experience here? put a small R infront of every RX? edit: according to arduino forum posts it should be no issues this way. one rx to several TX needs resistors, but this way around just conenct and go. i'll report.

also, quick forum search didn't yield anything, can i just open several serial conenctions on unique pins?

__
update:
i managed to forward/channel split midi data incoming from one "control" axoloti's DIN input to two "slave" axolotis with a serial connection, using only the control boards TX pin and both slaves RX pin, with some objects based around hugos work. it runs nice on 250000 baud but i think i do lose some packets or get the LSB MSB shuffled... working with a lot of NRPN 4x cc messages to be deserialized, so its either my parsing being shit or the unprotocolled bitbanging. same parsing algos on the control board yield much better results than on the slave ones. but i think so far the rate of value skips/jumps is not high enough for me to look into it any further...


#27

Where can I find details on 'extra midi io project'?
Are you literally bitbanging - or is a UART being used?

edit: ahh, I found it. Not bitbanging. Nevermind.


#28

yeah no bits involved i just used that term carelessly for describing i am sending single bytes via uart..