Share your DIY controller project based on MIDI for 3rd Party Devices | AXE3 | FM3 | FM9 | VP4 |

sean.e said:
VP4 as well... And anything else that ever comes along.
Click to expand...
Good point.

Currently it does say this:

The messages documented here are compatible between Axe-Fx II, Axe-Fx II XL, Axe-Fx II XL+ and AX8. FX8 messages are not documented.
Click to expand...

Maybe the sysex for those devices should be a new page that is linked via a subsection here called Axe Fx II and AX8:

AC1B0E7F-C9B1-44D6-B28B-562A81837FB0.jpeg
So there would be a short sub-section for each generation of devices, each with a link to the sysex documentation.

I am not sure how to create a separate page or if that makes sense. I will defer to yek on that.
 
So I've been taking time to optimize code etc and finally got around to timing drawing with and without a sprite/framebuffer.

without screenbuffer.png

with screenbuffer.png

The screenshots show the timings for various drawing operations with the timings displayed in the terminal at the bottom. The short of it is, when doing individual operations without using a sprite each screen takes @38ms. When using a sprite it is closer to 20ms.

That's a lot when you have 18 screens. The sprite saves about 320ms when I have to do a total update. The trade-off is about 40k of memory for my ST7735s. On the Teensy 4.1 that isn't a lot, so I will go with the faster speed...
 
Axelman8 said:
Just installed the 1uf ceramic capacitors and the screens are all even bright now. Had some little brightness difference on the bottom and top row, now not anymore. Have to get a 10uf for the main VCC and ground.

Thank you @mavriq for the tips 🤘

View attachment 149644
Click to expand...
If the brightness was being pulled down you can bet the signal was messier too. If you can I would get a 50uf Electrolytic cap (10v or so) and put it on each board across the power coming in. And something around 100uf at the start of the supply if there are none in the existing power supply.
 
unix-guy said:
Good point.

Currently it does say this:



Maybe the sysex for those devices should be a new page that is linked via a subsection here called Axe Fx II and AX8:

View attachment 149671
So there would be a short sub-section for each generation of devices, each with a link to the sysex documentation.

I am not sure how to create a separate page or if that makes sense. I will defer to yek on that.
Click to expand...
Ok, I figured out how to create a new page and did what I proposed above.

The main page here is now trimmed down: https://wiki.fractalaudio.com/wiki/index.php?title=MIDI_SysEx

It references the new page for Axe Fx II and AX8 SysEx Functions here:
https://wiki.fractalaudio.com/wiki/index.php?title=MIDI_SysEx_Functions_AxeFxII

@yek - let me know if you have any input.
 
mavriq said:
Short of it is, when doing individual operations without using a sprite each screen takes @38ms. When using a sprite it is closer to 20ms.

That's a lot when you have 18 screens. The sprite saves about 320ms when I have to do a total update. The trade-off is about 40k of memory for my ST7735s. On the Teensy 4.1 that isn't a lot, so I will go with the faster speed...
Click to expand...
It is the library of the font that is slow. The standard font is blazing fast.

Other thing:
I'm using this font from my function without creating a sprite. I write every screen in one function, that saves some ms too, But its much slower than with the standard font. The teensy is fast enough, so its hardly noticable.

Other thing:
Are you using digitalWriteFast()? to set the screens low and high? Saves some ms too

Waiting for your vid on the full functional working mockup 🤘😁

Cheers 🍻
 
Hmm, never even considered digitalWriteFast(). I will add that for sure.

I just spent 2 days refactoring my code so there are separations of concerns. This should make doing display changes easier. I wonder why the font makes it slower. On load I can see it, but it never gets sent to the screen, just pixels AFAIK. So that shouldn't be slower. I'm going to take a quick look at the code and see what it shows.

Now that my code is maintainable, I should be able to add a bunch of stuff over the next few days. Going to fire up the large screen and get some stuff happening there too. I'll post a vid once I have some things to show. :)

I also wrote a programmer for it. I thought I posted a pic a few days ago, but it didn't post for some reason:
1735605128775.png

Eventually I'm hoping to get it working on Android, Mac, and IOS as well. It's flutter so it hopefully shouldn't be too big a job.
 
Holy shiiiit, even an editor that is super cool 🤘
What interface/development tools are you using? I Would like to investigate/ learn how to etc. Having a holiday in Thailand so plenty of time to read and learn.
Nevermind, you mentioned Flutter. Found it 👍


Happy New Year to all readers 🥂
 
Last edited:
So I looked into digitalWriteFast after looking athttps://forum.pjrc.com/index.php?threads/digitalwrite-and-digitalwritefast.76305/#post-353515 thread. I ran the test on mine and its about 10X as fast... wow.

1735606421981.png
 
The latest issue I've come across is that TFT_eSPI only supports one driver at a time. I think I'm going to have to refactor it from compile time to run time to make this work. I could not find any other way to 2 or more. I tried several experiments to work around the issue, but so far have come up empty.
 
mavriq said:
The latest issue I've come across is that TFT_eSPI only supports one driver at a time. I think I'm going to have to refactor it from compile time to run time to make this work. I could not find any other way to 2 or more. I tried several experiments to work around the issue, but so far have come up empty.
Click to expand...
I use tft-espi tft. for the standard font.
For the new font I declare the font at the beginning of the function and then build the screens and on the end of the function I unload the font again. You can use all the fonds you need with this method
 
Not it's the driver that is the issue. I have an ILI9488 and the ST7735's. There is no way to use them both with the current version of TFT_eSPI as it is all preprocessor directives and trying to use 2 drivers results in name collisions
 
Are
mavriq said:
Not it's the driver that is the issue. I have an ILI9488 and the ST7735's. There is no way to use them both with the current version of TFT_eSPI as it is all preprocessor directives and trying to use 2 drivers results in name collisions
Click to expand...
Are You using spi0 and spi1?
 
That isn't the issue. You can't use more than one driver with TFT_eSPI at once. If you use 2 drivers you need 2 usersetup.h files which will have the some defines named the same but with different information. So drivers won't work together
 
Last edited:
I spent about 2 days mucking around with TFT_espi and slowly tried to convert it to something that could have the driver defined at runtime rather than compile time. The short of it is I learned a lot, but never did get it going.

The good news is, that I decided to look at st7735_t3. From staring at the guts of TFT_eSPI I can say there is no support for teensy optimizations except for spi transactions. st7735_t3 on the other hand was written by Paul Stoffregen the creator of the Teensy and KurtE, Teensy wizard... It has many optimizations and a framebuffer as well. It looked to be less jerky updating (to my eyes), and it executes on average about 5ms faster per screen update:

1735877600916.png

It also has DMA built in, but I didn't get that working correctly yet. That would make it even faster. From what I learned, I can likely get it to work with other displays and add parallel support for screens that support it. Also FLEXIO for Teensy 4 which would be much faster as well.

I will spend a short while trying to get DMA working and then back to getting my ILI9488 working. There is an ILI9488_t3 for that as well and CAN be initialized at run time.

As a side note, I also had to get OpenFontRender working as it would not take the new class as an argument without throwing errors. The issue was that under the hood OpenFontRender wanted to lock things into an SPI transaction. Under the covers, it called TFT_eSPIs strartWrite and endWrite. At first, I thought I would have to make a custom version of OpenFontRender but then had an idea. If I inherited from st7735_t3 and provided implementations of those methods it just might work. In fact it did. So the fix was only this code:

C++: 
#include <ST7735_t3.h>

class ST7735_mav : public ST7735_t3 {
    public:
        ST7735_mav() : ST7735_t3(-1, TFT_DC, TFT_RST) {}
        void startWrite() {}
        void endWrite() {}
};

Not bad for 2mins work.
 
I'm away for one month in Thailand, so unable to assist or test. To bad I didnt update my github with my latest .ino, so I'm unable to check my code.
DMA is running in my version. I have sent you a copy some weeks ago, in the .ino tab on the bottom is the initialization of the DMA. I think that I'm using the _T3 lib too, but not sure

Amazing stuff you are doing.. thanx for sharing

Cheers 🍻
 
Axelman8 said:
To bad I didnt update my github with my latest .ino, so I'm unable to check my code.
Click to expand...

I use VS Code and have git integrated with it. It takes less than a minute to create a repository, then less than 10 seconds to commit and sync each time.
Intellisense is SO much nicer than Arduino IDE, I couldn't live without it.
 
Well, that was a waste of a day. I couldn't get my ILI9488 to work with any driver software. Was ready to throw it through it against the wall. I had it going before using st7735s so it was functional. Now I can see the backlight on, but the display stays black even at startup. I did some pixel writing and readPixel, and everything is working, just not the TFT. So the display is apparently now no good. At least I know it isn't a software or hook-up issue. I guess I'll have to get something of AliExpress and wait a couple of weeks for it...

In the meantime, I'm going to work on new versions of the pcbs.
 
You must log in or register to reply here.
Back
Top Bottom