[posted] AMC8 - Automated midi controller (Hui Protocol)

R

rotabox

Well-known member
hello
after about 1 year i can say that project is done. automated midi controller for protools DAW HUI protocol. the goal was to get 8 motor faders to control protools and to control faders from protools
for writing and reading DAW mixer automations. the controller contain 31 push buttons 8 solo and 8 mute buttons allso 4 buttons for scrolling 1 or 8 Channels to left or right.
7 buttons for transection panel and 4 buttons for read write touch and latch actions.
all so the controller have 8 OLED screens for channel names DB and solo mute channels symbols.
thats the place to thanks GERRIT and Pual for for the knowledge and the help. i used the slave teensy code of gerrit zeus midi controller project as a reference, and i modified it for my needs.
for this project i write custom pcb for easy and safety connections and for easy parts replacements.
the project contain:
2X teensy 3.6
2X Multiplexer 16
1X TCA9548A Multiplexer
4X l9110s Dual Hbrige
8X OLED screens 128X64
31X silicon push buttons.
2X DC TO DC stepdown
1X 12v 4A PSU
enclosure and panel is a custom made by me
i still have some minor bugs like: when i scroll 8 faders right i get solo symbol in the first channel screen. thats behavior related to the hui protocol data action and my code. still trying to fix it but allso i can live with it for now.
the second issue is some problem of buffering screen to get realy fast response on screen with out delay the system for fast faders action.
i used u8g2 lib for my screens but the best i could get from all of my experiments is half top screen to get work with fast fader response . any other full buffer u8g2 constructor i used cuse my system delay in action and looks like overflowing.
all so in this case i can live with it by putting all parameters on top of the screen to see them all.
from my discussions with olikraus the U8g2 lib writer on this issue the problem its about overflowing the ram. im still looking for a ways to solve it .


55719296_10218778452037219_8499328305520967680_n.jpg
57540090_10218894539179325_2161808609472675840_o.jpg
56293829_10218778452277225_3046638246873268224_n.jpg

Rota
 
Last edited:
storing an 128x64 display buffer takes about 1 kB of RAM. The teensy 3.6 has 256 kB, so you could have a buffer for each display without any problems. That way you only have to redraw the display you are updating.
Do you use i2c or SPI for display communication?
I realized that the u8g2 library is way to slow and bulky for fast displays in my experiments.
 
cinhcet said:
storing an 128x64 display buffer takes about 1 kB of RAM. The teensy 3.6 has 256 kB, so you could have a buffer for each display without any problems. That way you only have to redraw the display you are updating.
Do you use i2c or SPI for display communication?
I realized that the u8g2 library is way to slow and bulky for fast displays in my experiments.
Click to expand...

thanks for your replay cinhcet
im using i2c for display communication and for another slaved teensy. for my needs u8g2 working fast enuf the constructer is the problem i guess.
i know that coz i tryed to run u8x8 lib with u8x8 constructor and i get 8 full screens to work in high speed but u8x8 not got any graphic commend only basic printing data commends (im now trying to write test code with U8x8 but i did not finish it yet i just tested the system speed response)
do u know any better lib for oled screens ?
 
rotabox said:
do u know any better lib for oled screens ?
Click to expand...
I really depends on how much you want to dig into the code.

Depending on the actual device speeds and how long your wires are, you might be able to bump up the I2C speed. The default speed is 100 kbit/s. There are faster i2c speeds (400 kbit/s, 1 mbit/s, and 3.2 mbit/s).

The standard Wire library has a function setClock that sets the speed. I see that Teensy supports the call, but whether it supports all of the values, I dunno. The standard values are:

There is an improved i2c library (i2c_t3) that is also shipped. It has more control, and it may have additional speed ups. However, the downside is you have to copy each of the libraries that use Wire.h and change the Wire.h include file to i2c_t3.h. There may be additional changes you will have to make, since while it is mostly compatible, some of the advanced features have different names:

One alternative is to use screens that have their own microprocessor and frame buffer. There you are not sending the whole screen, but just a high level command (i.e. a text string, commands to draw a box, etc.). Obviously, these screens are a little bit more expensive than the i2c OLED displays. The one I have used in the past is digi-ole. You can communicate to these displays via i2c, spi, or via a UART, depending on a solder jumper (for i2c there is a command to change the screen address so you can have multiple displays on the same i2c bus). I tended to use my display with a UART rather than i2c or spi. When I last used them a few years ago, I had to make one change to the *.h file to get it to compile on Teensy. They also have color LCD and OLED displays, some of the color LCD displays are much larger than 128x64:

There are various color OLED displays that use SPI instead of i2c. Instead of having 2 pins and an address, SPI has a separate chip select wire for each display, plus three shared wires (and possibly another pin to distinguish between data/commands). There are a few advanced Teensy drivers for certain OLED displays (ST7735_t3 and ILI9341_t3), that if you pick the right pins you can really speed things up. This is because behind the scenes the Teensy uses DMA to transfer the bits, rather than doing it the slow way. However, there are only 5 special pins, which might mean you can only do 2 per processor since each display would need a CS pin and a DC pin. You might be able to share the DC pin between displays if you are careful to let one display finish before beginning the next display. To make things even harder to understand, while there are actually 9 pins you can choose, 4 of the pins overlap with other pins, so you only have 5 unique pins available:
  • Github library (this is included in the Teensy release): https://github.com/PaulStoffregen/ST7735_t3
  • Either pin 10 or pin 2;
  • Either pin 9 or pin 6;
  • Either pin 23/A9 or pin 20/A6;
  • Either pin 22/A8 or pin 21/A7;
  • Pin 15/A1.
 
rotabox said:
do u know any better lib for oled screens ?
Click to expand...

I use the adafruit library, which I have modified quite a bit (the important difference is that the display buffer is now a member variable of each display object).
If this has enough features for you (u8g2 has more features), then you might give it a try.



You are writing that you are using silicon buttons. What kind of buttons exactly? Can you share details?
 
cinhcet said:
I use the adafruit library, which I have modified quite a bit (the important difference is that the display buffer is now a member variable of each display object).
If this has enough features for you (u8g2 has more features), then you might give it a try.



You are writing that you are using silicon buttons. What kind of buttons exactly? Can you share details?
Click to expand...

i start the project with those buttons:
https://www.ebay.com/itm/Clear-Black-Tact-Tactile-Push-Button-Switch-Cap-Silicone-for-6x6mm-Round-Switch-/142866067462
but its makes click sound and its not good for sound studio needs.


so i ordered those small silicon buttons and now its silent without the click sound.
https://www.ebay.com/itm/20X-8x8x5MM-4PIN-Tactile-Push-Button-Micro-Switch-Direct-Self-Reset-Soundless-HI-/153325408716

one thing i must say about those buttons: the resistance is 100 ohm when circuit is closed. thats not normal behavior for button but its working ok with teensy.

Screenshot_2019-04-29-13-30-04.jpg
 
Last edited:
thank for your replay MichaelMeissner
im working with i2c 400000 communication im allso using i2c_t3 lib instead wire lib.
may be 400 kbit/s is not enuf memory to communicate with tca multi slave for 8 screens and teensy slave for 8 motors faders in same time.
thats the only thing i can think of...
to change all screens to spi or change screens type is not somthing i thinking of. that project allready too expensive. the front panel cuts is measured for specific oled screen any other screen not gonna feet to my panel now. (i experienced allready with 8 screen i order and the seller send me not exactly the same oled size (2mm+-) and the oleds not feet to ther place in the panel so i looked for seller with the precise size and i orderd again.
 
rotabox said:
thank for your replay MichaelMeissner
im working with i2c 400000 communication im allso using i2c_t3 lib instead wire lib.
may be 400 kbit/s is not enuf memory to communicate with tca multi slave for 8 screens and teensy slave for 8 motors faders in same time.
thats the only thing i can think of...
to change all screens to spi or change screens type is not somthing i thinking of. that project allready too expensive. the front panel cuts is measured for specific oled screen any other screen not gonna feet to my panel now. (i experienced allready with 8 screen i order and the seller send me not exactly the same oled size (2mm+-) and the oleds not feet to ther place in the panel so i looked for seller with the precise size and i orderd again.
Click to expand...
Well another way is to use cheaper microprocessor (Teensy LC perhaps) to drive a smaller number of screens. You would write a protocol that just puts out the minimum information from the 3.6, and the cheaper processor would just handle screen updates. I suspect that between the motors and 8 i2c displays, interrupts may be locked for a long enough time that you may be losing interrupts.

For this I might think of using serial output instead of either i2c or spi. If the communication is all one way, you could have all of the slave processors on the same line, and the first character indicates which device to use. If you do that, you probably want to use either Serial1 or Serial2, as these have hardware fifo's built-in.
 
MichaelMeissner said:
Well another way is to use cheaper microprocessor (Teensy LC perhaps) to drive a smaller number of screens. You would write a protocol that just puts out the minimum information from the 3.6, and the cheaper processor would just handle screen updates. I suspect that between the motors and 8 i2c displays, interrupts may be locked for a long enough time that you may be losing interrupts.

For this I might think of using serial output instead of either i2c or spi. If the communication is all one way, you could have all of the slave processors on the same line, and the first character indicates which device to use. If you do that, you probably want to use either Serial1 or Serial2, as these have hardware fifo's built-in.
Click to expand...
That's the best solution for sure but I all ready printed PCB for that project maybe in the next one
thanx for your important input.
 
You must log in or register to reply here.
Back
Top