LambdaTon Posted December 22, 2017 Report Posted December 22, 2017 (edited) Hey MIDIbox community, first of all I want to thanks everybody participating in this project, since utilizing from the MIDIbox project really saved me a lot of time. In 2014 I started working on my DIY MIDI controller LambdaControl and can now proudly say that it is finished. I designed and build LambdaControl to support me during my upcoming live performances. Therefore, the controller consists of 10 channel that are fully integrated into Ableton Live. Each channel consists of a volume fader, six buttons for clip selection, four rotary potentiometers for effects, and an encoder with switch button functionality (could be used to control a looping mechanism). The normal components like the potentiometers or encoders are simply scanned by using the AINSER64 and DIN modules with a custom MIOS32 firmware. However, the special part of LambdaControl is the custom 10x6 RGB button matrix (based on button pads from Sparkfun), which is completely integrated into Ableton Live like a Novation Launchpad. For this purpose I connected a separate micro controller unit (MCU) via I2C to the MIDIbox core, which drives the RGB leds and reads the button inputs. The matrix MCU (16MHz Arduino Nano) can produce up to 4096 different colors by driving the matrix with a combination of multiplexing and Bit Angle Modulation (BAM). The matrix MCU still uses the shift registers of the DIN and DOUT modules to connect to the matrix rows and columns. This works really stable in the given scenario, but my implementation has some drawbacks like a low refresh rate or a relatively high input lag for the buttons (more in the documentation). This problems can be easily solved by using a MCU with more power or using a specialized IC like a TLC5958. However, it was a nice challenge to do everything in software on a limited hardware. Moreover, the parts used for the matrix MCU were with around 4€ really cheap. Additionally, I written a so called MIDI Remote Script, which integrates the by MIDI messages controllable RGB button matrix into Ableton Live. The MIDI Remote Scripts are python scripts that Live internally uses to integrate the different commercial MIDI controllers. The following picture shows that LambdaControl can be selected as every other control surface inside Live's preferences. The other screenshot shows the red rectangle that Live is rendering to visualize the position of LambdaControl's clip launcher that can be moved up and down by using the encoder on the master channel. I decided to release all files under open source licenses, such that other people can make us of my work. First of all you can find a complete documentation with more information and pictures on my website. Then I created four repositories on github for the different parts: Repository for the hardware related files like the faceplate or the 3D printable case MIOS32 firmware for the MIDIbox core Matrix MCU Firmware for the separate micro controller that drives the RGB matrix MIDI Remote Script for Ableton Live that integrates LambdaControl into the DAW I hope this information can help other people with their projects. Edited December 22, 2017 by LambdaTon 1 Quote
Zam Posted December 22, 2017 Report Posted December 22, 2017 Hello That's a nice first post ! Bravo Zam Quote
Hawkeye Posted December 22, 2017 Report Posted December 22, 2017 Very nice! Welcome to the forums! Many greets, Peter Quote
TK. Posted December 22, 2017 Report Posted December 22, 2017 Congratulation, really good work! :) I would like to give some feedback on the MCU usage: I don't think that it's really required, the STM32F4 core has more than enough bandwidth to handle this as a "background task". According to your documentation you decided to use a separate MCU for this task due to limitations in MBNG. But this limitation only exists since I preferred less latency and universal usage (SRIO can be used for multiple purposes, not only for controlling RGB LEDs). If these design constraints wouldn't exist, we could simply control the SRIO on a similar way like you did in the MCU code. MIOS32 provides a MIOS32_DONT_SERVICE_SRIO_SCAN switch which can be defined in mios32_config.h to disable the common SRIO scan approach. With this switch you are able to initiate the scan in your app MBNG works this way meanwhile, but a more simple example can be found in the Keyboard tutorial: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F029_keyboard_velocity%2F The first transfer is initiated with MIOS32_Init(): // limit the number of DIN/DOUT SRs which will be scanned for faster scan rate MIOS32_SRIO_ScanNumSet(2); // speed up SPI transfer rate (was MIOS32_SPI_PRESCALER_128, initialized by MIOS32_SRIO_Init()) MIOS32_SPI_TransferModeInit(MIOS32_SRIO_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_64); // prescaler 64 results into a transfer rate of 0.64 uS per bit // when 2 SRs are transfered, we are able to scan the whole 16x8 matrix in 300 uS // standard SRIO scan has been disabled in programming_models/traditional/main.c via MIOS32_DONT_SERVICE_SRIO_SCAN in mios32_config.h // start the scan here - and retrigger it whenever it's finished APP_SRIO_ServicePrepare(); MIOS32_SRIO_ScanStart(APP_SRIO_ServiceFinish); See APP_SRIO_ServicePrepare() and APP_SRIO_ServiceFinish() how to prepare and process a scan. Since the STM32F4 is pretty fast, there is no need to use a timer in your case. Just start the next scan once the last has been finished and buttons have been checked like shown in the tutorial. This results into back-to-back scan, where the update speed is a result of the number of SRs and the SPI transfer rate - both values are set in the example above. This way you could also store new RGB values in the DOUT registers. BAM should be possible by updating the DOUT register only each 2nd, 4th, 8th, 16th time. Pseudo code: iteration_ctr = (iteraction_ctr + 1) % 16; if( iteration_ctr == 0 || iteration_ctr == 2 || iteration_ctr == 4 || iteration_ctr == 8 ) { bam_ctr = (bam_ctr + 1) % 4; DOUT = color_value[bam_ctr]; } Best Regards, Thorsten. Quote
LambdaTon Posted December 30, 2017 Author Report Posted December 30, 2017 Thanks for the nice feedback. Actually, I first tried to implement it exactly like you proposed, but my BAM implementation always suffered from "randomly" appearing flickering. With my sketchy knowledge about MIOS32 and FreeRTOS, I were not able to solve this problem within an acceptable amount of time, such that I went the lazy way and used a separate Arduino Nano for the task, which I already had here lie around. But you are absolutely right, it should in general not be a problem to implement all of this with just the MIDIbox core. I think in my next project, I will go another way and use directly a specific LED driver like the TLC5958, since the feature set of this chip is really interesting. Sadly, they are just available in a SMT package, such that they could be a challenge for MIDIbox beginners. Best regards, Sascha Quote
Antichambre Posted December 30, 2017 Report Posted December 30, 2017 (edited) On 30/12/2017 at 5:47 PM, LambdaTon said: I think in my next project, I will go another way and use directly a specific LED driver like the TLC5958, since the feature set of this chip is really interesting. Sadly, they are just available in a SMT package, such that they could be a challenge for MIDIbox beginners. Hi, driving the TLC5958 with the Core is not an easy way, features are amazing but it will require some more electronic as interface for the GSCLK. I wrote a software driver for it, it works without too much process. ButI added a CPLD between the two. See my OLRE16 project: The wiki but I did not refresh it. The interfacing logic circuit is now on CPLD. Best. BrunoAnd great work with your controller! Edited January 1, 2018 by Antichambre Quote
LambdaTon Posted January 13, 2018 Author Report Posted January 13, 2018 On 12/30/2017 at 7:56 PM, Antichambre said: Hi, driving the TLC5958 with the Core is not an easy way, features are amazing but it will require some more electronic as interface for the GSCLK. I wrote a software driver for it, it works without too much process. ButI added a CPLD between the two. Hey Antichambre, your project looks really great. I just looked briefly over the datasheet of the TLC5958 and now understand your problem with the multiplexing. Using a CPLD to achieve a precise timing is an interesting solution. At the moment I am thinking about building a dedicated step sequencer that is fully integrated into the DAW, but I am just in the concept phase. When things get more precise, I will definitely take a deeper look at your solution. Best regards, Sascha 1 Quote
Adimari Posted April 3, 2022 Report Posted April 3, 2022 Hi ! this is amazing! can I build one for myself? or do you sell them? Im from Argentina. Great work! Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.