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

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

#48

I haven't tried throttling but it makes sense to.
Not at home now but will try it later.
Thank you for the help.

#49

Hi All,
I know this thread has been doing the rounds for a while, connected directly to the Axo, I have found a way to use 2 rotary encoders to control every parameter, or at least those you want to control.
Basically it has one encoder to select the value of the parameter, this can be an unlimited number count of parameters to adjust. Then the parameter itself is given a number that connects to the selected value which can be adjusted and or the built in momentary switch (if it has one) when it is selected. The objects to support this can just be added further as more parameters for control are added etc... Works very well in the GUI environment. I will have some right ups when I tidy it all up, as I have some tailored for my foot controller I built. Am also trying to modify an Encoder to be adjusted by a wheel I turn by foot.
If any one is interested, for my setup, the data is displayed on a recycled VGA monitor controlled by Arduino Due communicated via UART.
Sorry I don't have anything solid to offer yet. but it is coming..:slight_smile:
I can post a few things on the thread if you like, I haven't learnt to add to GITHUB yet, I just haven't had the time yet.

#50

OK, finally have a video of one of several working prototypes I have.
It shows controlling 5 parameters controlled via the Axo shown on the left monitor, sent via uart to Arduino due, then sent to VGA screen where I have setup to show 64 parameters.

Little image to show the hardware.. (yes I removed the Midi)
Arduino due on the left with VGA connection, 3 rotary encoders, the left one connected only to the due does nothing, (planning to use this for patch selection), middle connected directly to axo selects the parameter number, right also connected directly to the axo changes the value of the selected parameter and momentary switch. Then of course the Axo, I have a pined board with wires hard wired going to 3 different destinations, controls, arduino due, and a foot controller not shown that has an arduino nano. (that's another story entirely)

rotaaxodue.PNG783x167 201 KB

The 5 para's controlled within the axo on the left monitor are spread out over the 64 as you will see it selected on the right monitor, it also shows changing of the values, the numbers in green, and the pressing of the momentary action of the rotary switch which changes a red square to yellow on the VGA screen. You will also notice that some action has no change, this proves that unless there is a match between the selected value and the nominated value in the axo patch, there will be no change. You may also notice a few small bugs on the vga side to iron out.

I think this somehow meets the subject title...:grin:
Apologies for the shacking video, forgot to take my meds... LOL :laughing:

Hardware interface concept question
#51

I should probably also state,
If anyone is interested in any aspects of my setup, just add to this post and I will happily assist where I can, there is extra than explained in my other Rotary Encoder posts because of the UART communications, and connecting to a VGA monitor. And to be honest even though I had to learn a lot, I do think it is quite basic for anyone with simple level C programming and soldering skills.
The most difficult part was changing an integer to a char, I didn't know what a char is.
The most time consuming was getting the positioning of the characters etc on the VGA screen, this is done mostly with just simple (x,y) positioning controls.
But you would need to buy an arduino due, VGA connecter and some resistors. about $35.
A VGA screen, well lost of these are throwaways, but it won't run on 5v battery power so you will need to power it as you would normally. But there a lots of breakdown info on the web about VGA screens so getting a big one, small one, mounting it into some unit for your axo standalone setup, its a lot cheaper then spending $100 or more on some small fancy LCD module that would need to be connected to a micro controller anyway. This is why I chose this direction. On a side note, this setup also works on NTCS and PAL televisions with RCA Video inputs, so any screen like this you have can be recycled too, the wiring is mostly the same as VGA, with only some small differences. In fact I am looking at changing to a small PAL unit powered by a separate power supply unit.

:slight_smile:

#52

Great job. Sounds like an impressive setup and certainly has my interest. Did you ever switch over to the smaller PAL screen?

#53

No strictly VGA. That setup was some time ago now, but good proof of concept. Not using the rotary encoders for now. After that point I decided I needed a different setup that was more controllable with my feet.
This sort of highlights the direction I have gone in, due for some more updates as soon as I can iron out some kinks.

#55

This looks cool Gavin, I had in mind a similar idea for control with only a couple of encoders but hadn't considered using VGA for a display, I'd be interested to know how you did it and how much of the system resources it takes up.

#56

It takes up no resources on the Axo, it requires and Arduino Due, pretty simple really, instructions and library, the only resources on the Axo will be how you decide to interface between the Arduino Due and the Axo.

The link for you to check out is as follows..
https://stimmer.github.io/DueVGA/

Resolution isn't the best, but I built a smaller font set and was able to create quite a bit of extra space to fit everything in.
And the instructions are supper simple to follow.

The main reason why I went with this setup, is because it is very cheap, monitors are being thrown out all the time, or you can pick them up super cheap at vinnies.

We have an e-waste throw out coming up in north Sydney, its going to be like Christmas. :grinning:

#57

Cool, will check it out. I have a few spare monitors already, don't have a Duo though, will it run on a Uno? easy enough to get a Duo if not, I also have an STM8 discovery and that might also do it, I'd have to write or modifiy the software though.

#58

You can get due's off ebay from china for less than $20.
There are VGA shields you can get for the Uno, but this is different setup.
As far as know, the Stimmer VGA library only works on an Arduino due, from my knowledge there is no reason why it can't be ported to other M3 32bit dev boards, but I have never done anything like this, so wouldn't know where to start.
$20 or so for an Arduino Due dev board and a few small components is pretty cheap, I have even thought of chaining 3 of these across 3 monitors for a more elaborate display setup. But its so easy to do, I can consider this anytime.

#59

A resistor DAC is pretty simple, you could actually do the same thing directly from Axoloti though it would use a lot of system resources. 320*200 is about a 25Mhz pixel clock, so at a rough guess that would be between 15-25% of available clock cycles.

I have an FPGA board that has a VGA chip and plug on it, I could use that even.

Got 2 Axo projects I want to get some work done on and upload some beta versions of then I will be working on adding controls, a display and various types of buffered I/O, will try a couple of different approaches to the display.

I'll keep you posted.