Using just a few rotary encoders to control almost every parameter of axoloti?

#28

They haven't stopped at 8 :smiley:

Midibox thread

#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.

arduino & axoloti files

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
#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
#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.

#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.

#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
#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.

#35

awesome i will look into that today.
thenkyou for the heads up.

#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.

#37

if you're talking about midi/in/bend hr it's 14bits by the looks of it, 16383.

#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 )

#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?

#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.

#41

Yes, they are 2 MIDI data bytes (ie with 7 bits) else they would be status bytes (full 8 bits).

#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;
}

#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 :slight_smile:

#44

Some more info here.

https://forum.pjrc.com/threads/25940-14-bit-MIDI-over-USB

#45

note: as i mentioned, we don't currently support 14 bit velocity.
(also in that implementation, Id have thought it should be velocity < 127 , not 256)

it would be trivial to add, but frankly, its really hard to strike a key with the same force every time, and so I found 14 bit velocity didn't anything even with hi-res controllers.
( I tested with an Eigenharp and Pianoteq which both support it)

of course, Im sure, concert trained pianists would strongly disagree, and say correctly, its insufficient skill :slight_smile:

however, in contrast 14 bit CC/PB (and channel pressure though only defined in MPE) really can be felt and utilised, due to its continuously nature.

heres a list of the 'official' 14 bit CC messages: (as i said with 32 offset)
https://www.midi.org/specifications/item/table-3-control-change-messages-data-bytes-2

#46

It's all working very nicely now, big thank yous to @paul and @thetechnobear.

tho I am having a weird issue when I want to send lots of cc's.

This for when I switch patch , which I am doing on the arduino side.

once I load my values in to an array, I am using a for loop to step thru the array and send each value to the axo one after the other.

I am using the same code to send each message as I am for when I turn a dial, but for some reason the axo isn't receiving it correctly.

Any suggestions as to why this might be?

#47

Does what your doing have flow control?
If not a tight loop will probably exceed the speed it can be written to/read from - try throttling the messages your sendng. ( initially real slow , then speed up to the point it's reliable)