A MIDI-controller clone of GrandMA3 command wing

By Oscar Halse

1) E - Custom MIDI-controller

1.1) Introduction

The aim of this project long term is to create a clone of the GrandMA3 command wing control surface as a MIDI controller:

The official product also has output for DMX (stage light control protocol) as well as the processing for that output. This MIDI controller will only concern itself with being a control surface, intended for use in at-home programming without physical output.

Within the context of IN5590 the aim is to create functional prototypes of module 1 and 2 as marked in this figure:

Figure text: The pink sections are so called "executors", meaning that they are used for playback. While the green section is the command section, meaning that it is used for programming.

Module 1 and 2 contain the same 3 core components as all the other modules: Buttons, encoders and faders. And should therefore demonstrate the viability of building the remaining 3 at a later time.

All the other modules are functionally equivalent, the only difference being the number of buttons/encodes/faders and the layout. So the prototypes for 1 and 2 are the prototypes of them all.

1.2) Demo of software interraction

This demo was made using off the shelf midi controllers to demonstrate the interraction between the software and midi-controllers.

1.3) Motivation:

The aim of this project within the context of IN5590 is to prototype the 3 modules that form the playback section of the control surface:

This is the cheapest option for any hardware control interface with the "GrandMA3 onPC" lighting programming software. The software itself if free, but with the cheapest controller starting at ~80k NOK it certainly doesn't always feel so free. That is the main motivation of this project: To create a MIDI-controller with the same physical layout as the purpose buildt controller to be able to program lighting shows at home for cheap.

You still need SOME GrandMA3 hardware in order to actually output signals to any physical lights, the cheapest option of which is the GrandMA3 onPC node at ~20k NOK. That's of little concern to us, because any organizer will rent any hardware needed for the event, but at home we are not so lucky. It is the at-home pre-show programming that this product is concerned about.

1.4) Existing implementations

At least two other people have had the same idea in the past. In chronological order (of publication date) we have Nathan I3's implementation published on tingiverse [^1]. Then we also have stagehandshawn's that implements the command section [^2] and the playback section [^3] as two seperate projects.

[^1]: Nathan I3 - DIY: GrandMA3 Command Wing [^2]: EvoCmdWing [^3]: EvoFaderWing

2) Goals

• Demonstrate functionality with hand-soldered prototypes
• Design and iterate RP Pico shield PCB for module 1 and 2
• Have modules appear as standalone MIDI-devices that output sensor readings as MIDI values. Sending a MIDI value to a fader module should set the fader to that value.
• Achieve stepped "notches" on fader (haptic feedback).
• Bonus: Begin on integrating MCU onto sensor PCB

Challenges:

• Tuning the motor to hit specific values
• Tuning the motor to be able to enter a "notch"
• Handling all special cases of setting a fader while something prevents movement
• Bonus challenge: Integrating MCU onto PCB

Of course, the goal of the project as a whole is to create a cheaper and more modular version of the grandma3 control surface. But wihin the context of IN5590 the main goal is to create functional modules that demonstrate the ability to create a MIDI controller with some number of buttons, encoders and motorized faders. I.e. practically demonstrate the same functionality as the end product, without necessarilly creating the entire layout.

Finally, after the controller works as a stand-alone MIDI-controller it will need some custom scrips in GrandMA3 such that the software and the controller can talk to eachother. This has been demoed already using generic MIDI-controllers.

The optimiation will be in tuning the PID controller of the motorized faders such that they are critically damped while still moving as fast as possible between positions.

3) Sketch

3.1) The system architecture

The final system as a whole will utilize a star topology with one centralized controller/SBC repsponsible for communicating with all other controllers and the software. This is because it is very difficult to find one controller with enough I/O to service everything from one microcontroller (80+ buttons, 20+ encoders, 10+ faders). Also it makes it more scaleable.

The communication between the central controller and the daughter boards will be over USB. This is to keep each module as a standalone device such that the individual modules can be combined in any arbitrary configuration with nothing more than a PC, USB-splitter and the modules themselves.

Between the central controller and the software, the controller will present an UDP interface and a MIDI interface. The software can run on both a PC and a purpose buildt lighting console which is why the GMA3 software is portrayed as a cloud and not a specific device.

As for physical positioning of the hardware, that will follow the layout of the real product.

4) Bill of materials (BOM)

Create a table with the most important components for your setup.

Not listed here are the minor components that are hard to plan before actually starting to design the PCBs.

5) Plan

The plan can roughly be divided into the following 10 steps, where only the first 4 are intended to be completed within IN5590.

1. Build and test a breadboard prototype of
   • Button matrix
   • Encoder matrix
   • Readout and control of single motorized fader
2. Design, print and test PCB's for module 1 and 2 as Rasberry Pi Pico (RP Pico) shields. (If crisis with non-functional PCB's, the components will be hand soldered)
3. Design and 3D print a box (one for each) for module 1 and 2
4. Program the microcontrollers such that the modules functions as standalone MIDI-controllers.
   • IN5590 goals end here
5. Introduce LED feedback to the encoders and buttons on the shield prototypes
6. Design, print and test PCB's for module 1 and 2 as standalone PCB's with onboard microcontroller. LED feedback from the start.
7. Design, print and test PCB's for module 3, 4 and 5.
8. Design, print and test PCB for central SBC (RP CM5)
9. Write software for the central SBC such that it connects to all the modules on the inside, while presenting a single unified MIDI-interface to any connecting external PC.
10. Design and build chassis for complete assembly.

Create prototype PCB of the 3 daughter-boards

What seems to be an universal addage amongst PCB-designers: They're like children, you always mess up the first one. Therefore I exepct some revisions here. The design will be done in KiKad.

The first board will be filled with jumpers and redundancies such that many different things can be tested and switched out with minimal effort:

• Seperate power delivery networks that all can be connected to the power networks of the chip using jumpers:
  • Barrel jack for 15V from external PSU
  • Barrel jack for 3.3V from external PSU
  • USB PD with PD controller for negotiation of delivery of 15V at 3A. The 3.3V network will be derived from this one using a buck-converter.
• Every sensor can be jumped between one of two sensing networks:
  • One using a PICO attached directly to a socket on the board in case issues with getting the RP2040 to work correctly arrise
  • One using the RP2040
• The motors can be jumped between two different drivers:
  • One using an external pre-tested motor-driver that can be controlled from the MCU.
  • The other using a motor-driver on the board. Using a H-bridge powered by the 15V network.

The first board will include the faculties needed for all the sensors. Later revisions will break out the relevant components into seperate boards and then compacted.

Tuning motor controllers

• Faders should be able to move to a set target value sent to the controller
• Faders should be able to have a notched setting where it will notch to specific values and a somewhat signifficant amount of fource is needed to move it to the next notch

The slide potentiometers are supposed to be given a command about a target position then reach it. For this a PID loop will be utilized and tuned. For the tuning the software shall initiate a tuning mode, in this mode the fader jumps between targets while the user can watch it and tune each parameter of the PID controller using the encoders.

Completing the software

In the final version the CM will be responsible for presenting a common interface to the PC over IP. The CM will coordinate a distributed state between all of the different sub-modules which it communicates with over USB. The methodology will be a simple priority loop of:

• Read digital state
• If digital state changed: Update physical state
• If digital state unchanged: Read physical state
• If physical state changed, transmitt to GrandMA3 software.

The GrandMA3 onPC software needs some simple scrips for reading the state of a playback unit on the mixer before transmitting to the controller (the physical controller must update according to changes done directly in the software), as well as writing to it on physical actuation of the corresponding button/encoder/fader.