LambdaTon

LambdaControl - MIDI Controller for Ableton Live

7 posts in this topic

lambdacontrol-dark.thumb.jpg.54a4aa65311

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

lambdacontrol.thumb.jpg.40b813c3dec833e8

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.

DSC00852.thumb.jpg.03453177d1ef0dbeade7f

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.

ableton-lambdacontrol-settings.thumb.PNGlambdacontrol-clip-view.thumb.PNG.7fdc1b

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:

I hope this information can help other people with their projects.

Edited by LambdaTon
1 person likes this

Share this post


Link to post
Share on other sites

Hello

That's a nice first post !

Bravo

Zam

Share this post


Link to post
Share on other sites

Very nice!
Welcome to the forums!

Many greets,
Peter

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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:
large.5a1b571dd4afe_Fichier27-11-2017002
The wiki but I did not refresh it. The interfacing logic circuit is now on CPLD.

Best.
Bruno

And great work with your controller!
 

Edited by Antichambre

Share this post


Link to post
Share on other sites
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 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now