Based on several sources, and especially @PierterP numerous posts, i was able to build a midi control surface on a arduino nano, with few buttons and encoders + SPI TFT screen which purpose was to simply test if i was able to
I worked great in a minimal implementation, with a single midi output port.
it had limitations: too few inputs, unability to act as a midi class device (mandatory), to few power to handle a MUX connecting buttons and directly attached rotary encoders as fast as required to operate DAW plugins.
So i bought a STM32 clone which was recommanded from a friend.
As a noob, i thought the code would be directly portable from the nano to the STM32, but it's not.
As far as i understand, the current issue i meet is that some "known" values like NUM_DIGITAL_PINS, NUM_ANALOG_PINS, etc are not known on STM32 platform, as it is not built the same.
(I also had issues due to usage of PORTD in another library, same platform dependant value i guess.)
As compiling raises many other errors, i suppose i may not lose to much time trying to solve the unsolvable (according to my poor knowledge), i wanted to know id someone has already used Control_Surface.h on a STM32?
If @pieterP can confirm it won't be compatible, or if i forgot a major step, i would be pleased that you inform me.
In case the Control_Surface.h library wouldn't be usable on STM32, what workaround would be available?
I thank you in advance,
First a disclaimer: while I have some experience with the official ST tools for STM32, I have zero experience with the STM32 Arduino Core/port.
I don't have the hardware or the time to add official STM32 support to Control Surface any time soon.
That being said, just getting the library to compile shouldn't be an issue at all. There are only a handful of places where platform-specific changes are necessary.
I've pushed the minimal changes necessary to compile the examples to the [
stm32
](GitHub - tttapa/Control-Surface at stm32) feature branch.
I used stm32duino/Arduino_Core_STM32 v1.9.0.
This branch is a 2.0 development branch, some things have changed from the previous stable release. There's an overview of the “breaking changes” from the 1.x releases to the 2.0 development branch at the bottom of the README. You should use the documentation of the [
One significant feature that probably won't work out of the box is MIDI over USB. Like I said, I have no experience with STM32 on Arduino, and I have no idea what MIDI USB libraries are available for the STM32. If you find one that works, adding support for it in the library is easy, you just have to implement a function to read a MIDI USB packet and a function to write a MIDI USB packet. If the MIDI library you use doesn't send the packets asynchronously or not quickly enough, you also have to provide a sendNow function that sends the packets, and a preferImmediateSend function to let Control Surface know to always flush immediately after sending. See https://github.com/tttapa/Control-Surface/blob/stm32/src/MIDI_Interfaces/USBMIDI/USBMIDI_MIDIUSB.ipp for an example. You can add a STM32-specific file in the same directory (e.g. USBMIDI_STM32.ipp) and then use an #ifdef ARDUINO_ARCH_STM32 in https://github.com/tttapa/Control-Surface/blob/stm32/src/MIDI_Interfaces/USBMIDI/USBMIDI.cpp to include your USBMIDI_STM32.ipp implementation file when compiling for STM32. This might also help: support for STM32 devices? · Issue #230 · tttapa/Control-Surface · GitHub
Thank you both for your answers. @aarg, it's really new, i received the STM32 board yesterday, so i didn't have time to read documentation and forums yet. @PieterP, i'm gonna try to catch all you wrote, i'm really new to this world
@PieterP: loaded the framework you mentioned and also got the specific STM32 library you targetted, and now it compiles correctly! Thank you!
Now, i have to understand why it won't upload to the board (** OpenOCD init failed ** )
this is what i just tried out... and it blinks only in my dreams...
I was able to get it blink yesterday, with the previous framework, bu ti suspect i screwed everything up today trying to solve my previous issue.
my last few code transfer were successful, maybe my stlink has an issue.
but even a simple blink sequence won't work ^^
 digitalWrite(PC13, HIGH); // turn the LED on (HIGH is the voltage level)
 delay(1000);       // wait for a second
 digitalWrite(PC13, LOW);  // turn the LED off by making the voltage LOW
 delay(1000);       // wait for a second
Hello!
FYI, at the moment, i abandonned using Control_Surface library: there are to many complex dependancies i can't manage by myself because of my poor skills.
I'm currently trying to get a decent functionnality with a basic rotary encoder library but the behavior is still dodgy.
Anyway, even if i wasted a considerable amount of hours (days) i also learn a lot.
PieterP, considering your library seems to be correctly managed by Teensy, which model would you recommand?
I thank you in advance!
Ronan.
Ronerone:
FYI, at the moment, i abandonned using Control_Surface library: there are to many complex dependancies i can't manage by myself because of my poor skills.
I'm currently trying to get a decent functionnality with a basic rotary encoder library but the behavior is still dodgy.
Anyway, even if i wasted a considerable amount of hours (days) i also learn a lot.
Feel free to ask questions if you have any, it might be more efficient if I can interpret the error message or point you to the correct file.
PieterP, considering your library seems to be correctly managed by Teensy, which model would you recommand?
I thank you in advance!
Control Surface supports pretty much all modern Teensies (2.x, LC, 3.x, 4.x), but I haven't personally tested 2.x and LC, these were reported to be working by other users.
I do most of my development on a T3.2 and a T4.0, so the 3.x and 4.x series are well supported. The 3.2, 3.5, 3.6, 4.0 and 4.1 should all work without any issues, so it's just a matter of finding one that has enough pins for your project. The Teensy 4.x boards are ridiculously fast so that might be overkill for a simple MIDI controller, but considering the price, there's not really a reason not to use them.
Thank you aarg, yeah, i discovered that later
Thank you also PieterP, in fact, my controller will contain 6 rotary encoders + push and 3 switches/button, which means 21 signal PINs.
i had to tweak my code with some interrupts + clickencoder library usage, but even if it will work for basic usage, i'm still limited at all other MCU features implementation, so a teensy usage would be appropriated.
EDIT/ oups, i had written a real book here, seems most of it was removed when posting... not serious, i was writing my life story... i tried to rewrite the essential. the most important is the last part. Sorry for that.
PieterP:
Like I said, I've never used any STM32 boards with the Arduino IDE, I cannot help you with upload issues.
Hello Pieter!
I've made some progress on my controller and basics correctly work. This simple remote with 6 encoders and 3 buttons/switch allow me to control some plugin effets in a DAW (Studio One). I still have to implement hardware debounce anyway as changes sent are quite dodgy.
I'm currently working on a function mode selection between absolute and relative value transmission.
in absolute mode: all works quite well but moving from a plugin effect to another causes "jumps" when moving an encoder, as the plugin and the encoders all have their own values. I probably have to be able to handle received midi messages to force the encoders to sync with the values already set on the plugin.
in relative mode: it also works after modifying a surface definition XML file in studio one and the encoders progression seems more reliable than in absolute mode, but the encoders speed progression is very low and i would have to understand how i can handle the relative values to make them faster).
This appart, i would still love to be able to implement your Control_surface library on the STM32.
I know you don't own one and that it's impossible for you to make any dev regarding this.
Anyway, would it be useful that i send you my compilation log file after just having written "#include<Control_Surface.h>" in order to figure out if there would be a easy workaround to the 106 errors generated?
In fact, that wouldn't be useful as many errors are generated because of concurrent MIDI libraries (i suppose). But maybe i could set a simple code and help you evaluate the complexity?
I thank you in advance for your consideration.
Ronan.
Ronerone:
the encoders speed progression is very low and i would have to understand how i can handle the relative values to make them faster
You can just multiply the delta of the encoder position by a certain factor. That's how Control Surface does it, see the speedMultiply argument and the implementation here.
Anyway, would it be useful that i send you my compilation log file after just having written "#include<Control_Surface.h>" in order to figure out if there would be a easy workaround to the 106 errors generated?
Not without seeing the changes you made. The stm32 branch I linked to above should compile without issues, if you get errors by adding a MIDI USB library, you'll have to post your changes. Preferably, use git so it's easy to see what's changed. You can fork the stm32 branch on GitHub.
Before trying to integrate a MIDI library with Control Surface though, you'll have to make sure that you can get the examples to compile. If you can't get MIDI USB to work in a simple sketch without Control Surface, it won't work with Control Surface either. If you send me a working MIDI USB sketch for STM32, integrating it with Control Surface is relatively easy.
However, unless it's a 2 minute fix, I'm afraid I can't really help you for at least another month because I have some exams coming up.
EDIT/ oups, i had written a real book here, seems most of it was removed when posting... not serious, i was writing my life story... i tried to rewrite the essential. the most important is the last part. Sorry for that.
If you're lucky, it autosaved in the “drafts” section of your profile. I got into the habit of always copying my post to my clipboard before submitting it. It really is a shame that the forum forum does this, although I thought they'd fixed it.
In fact Pieter, most of the errors come from some values that are not included in the framework and which are refered to in the control surface library.
Maybe a veteran dev would be able to recreate these values (some tables refering to Pins for example), but i'm not good enough at the moment.
So, removing my whole code and replacing it with an example has no success.
Good luck for your exams! (and merry Christmas)
Ronerone:
In fact Pieter, most of the errors come from some values that are not included in the framework and which are refered to in the control surface library.
Maybe a veteran dev would be able to recreate these values (some tables refering to Pins for example), but i'm not good enough at the moment.
stm32duino/Arduino_Core_STM32 seems to be the “official” core, supported by an STMicroelectronics employee. rogerclarkmelbourne/Arduino_STM32 seems less actively maintained, uses an ancient toolchain, lacks some necessary parts of the Arduino Core API, and doesn't have the backing of STMicroelectronics, so I don't feel inclined to maintain compatibility with this core.
oh! excellent. I'm gonna do some more tests.
I know i had tested the official core, but i can't remember why i had changed to the maple one (it was advised by a friend, but as a workaround to an issue i had).
As i said, i'm very new to this, and starting from zero, i'm constantly doing some progress and understanding some more things So, i may have done a bad choice one day.
Thanks for this info Pieter and appologize my lack of pro approach, i simply can't!
EDIT: testing a little bit, the issue was the unability to integrate USBComposite.
Hi PieterP, as i still wasn't able to compile control surface with the official core (i'm sure i was able to do it one time, but can't figure out why it won't work right now), i kept working on my current setup (usb composite, roger clarck's core) and was wondering about one point.
As i know you have been working on your project for years now (2016?) you probably have digged in the same aspects and maybe you'll be able to answer me.
I use studio one as a DAW.
If my controller is declared as a "noname" control surface, it will be able to control some plugin settings in the DAW, as expected, thanks to the studio one's midi learning included feature (you touch a button in the plugin, you touch a button on your controller and you tell studio one to associate both). BUT, in that case, studio one won't send any midi data to the controller.
If my controller is declared as a Mackie control or Mackie HUI surface, Studio one will send midi datas to the controller which i'm trying to handle (but at the moment it causes DAW freeze) but my own midi commands won't work.
My question is: what makes difference, seen from the DAW, between the "noname" surface and the Mackie surface which would explain that it sends MIDI datas to one and not to the other?
I tried to find that in the surface .xml files used by studio one, but i wasn't able to find out.
I thank you in advance,
Ronan.
it's now blinking and compile/transfer seems ok each time.