@MrBim and @bafonso what about and ILI9341 touchdisplay…at the moment they're cheaper then oled displays.
edit1 maybe this pcb is 8 encoders and led rings would be interesting for.
Using just a few rotary encoders to control almost every parameter of axoloti?
bafonso
#26
In my DMX light controller I used a capacitive touch screen based on the ILI9341. It works well and is FAST w/ the teensy, not sure about other platforms. You need to pick a screen that has libraries available or then it becomes a project just to use that particular display. The multiple small OLED display will be a pain to use, it is much simpler to use a single bigger display.
You mean the 16 monster encoder PCB? 
It seems like that there's no middle ground between 1 encoder breakout and 16 I looked and could not find 3, 4, 6 or even 8. I panel mounted them last time but all the wires, it's a mess, oy vey
paul
#27
yes, I looked up the U8glib library for my oled…it has a lot of function but to complex to edit it to work with stm32f1…the adafruit libraries are much easier to understand.
I used an I2C oled display and I can set up different I2C addresses by resistors…so I think it's possible to drive 4 oled display by one i2C bus. a maple mini has two hardware I2C buses and with fast clock speed and it's also possible to use software I2C with any GPIO but slower speed (~100MHz)
YES 
…the module use 4 74hc165 shift in registers + SPI (4 wires, VDD, GND) to read out the encoders states. I don't know how there doing it, but it working great with their MIOS fw. Maybe someone which is more skilled in programming can to a look at their source code and find out how it's done.
There is also 8 encoder pcb 
paul
#29
thanks @mongrol . I have searched for this control board but didn't found it. I love the ways some oled display are mount between the rings and encoders.
Can you explain how they're are reading the 24 increment state of each encoder?
here is a one example how to transmit datas by uart between an arduino and axoloti. The axoloti part needs some improvements. If I have tried to comment each step so everyone knows, what's going on.
message to be send to arduino are:
l/ value1 value2 value3 value4 ("l/" at the beginning signals a message for leds section followed by 4 bytes value.
x/ HELLO WORLD!; ("x/" at the beginning signals a string message. ";" marks ending of a string message. Everything between will be printed by arduino serial…
the arduino sketch needs two serial ports but you can edit it to work with only one arduino serial port. I have tested this sketch with stm32f1 based board running as stm32duino.
Sometimes the serial communication got stocked and it seems that serial messages are printed out in four pack sequence. So something is wrong with byte handling or storing…
Using UART to connect to arduino for UI controls
Serial Data Output
Bug after trying to open patch from dropbox
mongrol
#30
The MBProgramma board is still in development. I think the one in the video was a one off and that version of the project appears to have went silent. If you read from this post you'll see Latigid On is working on a 4x4 matrix board that can be combined up to 64 way and uses RGB encoders. Looks nice.
Arduino to axoloti thru serial
paul
#31
ah cool, hope this will be continued. I have two 16enc. edition pcbs from the first run somewhere. I haven't assembled them because I was irritated by the LED brightness problem and my whole midi box project went out of money and time.
going with a mios based midi controller (e.g. midibox128) in combination axoloti should be the easiest and interesting way to go with a lot of encoders, buttons, displays etc.
MrBim
#32
sooooooo i am at the point where i am able to think about this properly now.
i have looked at the code kindly provided.
the arduino side looks like it makes sense but i am struggling to get the axolotl side to play ball.
if i download the file from git and remove the .html tag (leaving it as a .axp) i get a whole bunch of errors from the axoloti console if i try to load it.
am i being dumb? can you clear this up a little for me. i think i am probably being an idiot but i don't know where to start.
MrBim
#33
I have Made some definite progress.
This is axoloti with just a 4pole filter.
Using Paul's second midi input on PA2 and PA3 (plus gnd)
Might look at NRPN's to reduce the jumps.
More to follow as it materialises.
Arduino to axoloti thru serial
mongrol
#34
I can't view the video here but if its filter stepping you mean then the hi-res Midi objects could help. Arduino also supports this.
MrBim
#36
Does any one know what format the hirez midi object expects?
I seem to remember I can't count on directly from 127 as I think the last bit is reserved as 0.
thetechnobear
#38
Hi res midi is 14 bit, as 2 7bit numbers.
pitchbend is always 14 bit , cc optional
There is also support for 14 bit velocity iirc but this is not implemented ( and rarely supported )
MrBim
#39
But is it just a 14 bit number?
Normal messages are 7 but with the 8th as zero.
Does that mean hi Rez is two 8 bit messages with each of their 8th bits as zero?
thetechnobear
#40
by the time its out of the transport layers its 2 (8bit) bytes, each with 7bits of data.
at the transport level, you need to check the protocol, e.g. usb midi uses 3 bytes, serial 8n1 , not sure that they are using for ethernet... but all expose to app as 2 bytes.
hellcore
#41
Yes, they are 2 MIDI data bytes (ie with 7 bits) else they would be status bytes (full 8 bits).
MrBim
#42
I am sending the messages from an arduino over UART.
So I am trying to work out what I need to send from the arduino in order for the midi/in/cc hr object to understand it.
Currently I am just sending a number from 0-127 and it works with the standard midi/in.cc object.
does this mean that i need to jump from 127 to 256 in order to account for the status byte?
something long the lines of
if ( value > 127)
{
value += 256;
}
thetechnobear
#43
14bit protocol for CC, are sent as 2 independent CC values, the default is the LSB is MSB CC+32.
e.g. for mod wheel , you send CC 1 (MSB) and CC 33. (LSB)
so for CC1 14 bit, 129 , send CC33 = 2, CC 1 = 1 (1*127+2)
(also, it is best to send the LSB before the MSB... to avoid 'bumps' on MSB boundaries.)
PB is always 14 bit, and is a 3 byte midi message.
so there is an overhead for 14 bits, and you are sending 2 bytes for each, CC, so 4 bytes, gets you 14 bits... (even worst over USB, which is 6 bytes!), hence the push for a proper HD midi spec