Trampa v3 - DIY MIDI Controller

[SamIAm]

 

Here she goes again!

 

I've built a couple of DIY MIDI Foot controllers in the past, sadly now resigned to a slag of melted bits due to my fire.

 

The time has come ... to build another!

 

I've 'sorta' settled (at least as much as anyone can) on a pedalboard setup.

A MOD Dwarf is at the heart, an insanely powerful audio processer providing multi-fx, audio synth, IR and AI Neural modelling.

I've an expression pedal for those ... times!

And some bits and bobs to link these elements together.

 

I  initally had a setup with a MVave Foot Controller, a very cost effective device, nice and small ... but not very sophisticated in MIDI configurability ... thus Trampa v3.  This diary is to share my progress, seek ideas and feedback and keep a record of my progress.

 

Features:

• Four footswitches (due to pedalboard size constraints) , each with a scribblestrip display so I know which does what.
• Expression pedal with TRS input (Which will be translated to MIDI).
• USB to connect to my Dwarf (To carry MIDI and supply power).
• Ultra flexible MIDI configuration (Think Morningstar!) eventually via a web based editor.
• Inexpensive - Totaly hardware costs are likely to be under £50.

  

This is my current prototype (A bit Heath Robinson at present as my 3D printer is not yet operational). Once operational I will look to getting a more ... robust ... enclosure sorted.

 

Warning - Geekspeak ahead

 

Hardware:

• Raspberry PICO W microcontroller. Cheap, powerful, readily available and with WiFi connectivity.
• 4 OLED SSD1306,I2C Displays (driven using a TCA9548A I2C Multiplexer)
• 1 Adafruit 24LC32 I2C EEPROM (For holding configuration data)
• Switches, wires, housing, etc

 

Software:

I started off using platformio/c++ to prove out the concept; this allowed multiple displays (with scrolling), button action detection (Tap, Double Tap, Long Tap, Repeat and multiple button tap), expression pedal reading (With automatic calibration, this converts the pedal position to a MIDI CC message)and MIDI messaging over USB.  All these basic elements worked, but performance/responsiveness was poor when I started to use them all together, as a result I've switched to using the PICO C++ SDK, heavier lifting ... but it is very fast and also allows me to more readily use both input interrupts and multicore (The PICO has two cores) to ensure this wee beast will run like lighting.

 

Operation:

Press a footswitch and it will send MIDI message(s), release the footswitch and it will send MIDI message(s) (This is the toggle mode).

Tap, Double Tap or Long Tap a footswitch and it will send ... MIDI message(s). 

Press the left or right pair of footswitches and it will shift banks (A Trampa bank is a set of MIDI messages assigned to each footswitch and the info that will be displayed on the scribblestrip).

The ultimate goal is to have all configuration carried out using a web browser connected over WiFi.

 

My aim is to have a tightly integrated setup between my Dwarf and Trampa.  The Dwarf has the ability to use its footswitches to select a pedalboard (a configuration of plugins and interconnections) or snapshots (A set of parameter setting for a particular pedalboard) and it is possible to get it to send a MIDI message when this happens, this MIDI message will be recognised by Trampa and used to select the Trampa bank appropriate to the pedalboard/snapshot, for example if I load a pedalboard with a looper, Trampa will be configured to load (among other things) a looper configuration bank.

 

Conversely, Trampa will be able to send MIDI messages to select pedalboard/snapshots on the Dwarf.

 

Whilst aimed at my Dwarf, Trampa should be suitable for any MIDI controlled system.

 

More developments as they occur.

 

S'manth x

 

Edited April 25, 2023 by Smanth

[tauzero]

Looking forward to this with interest.

[Woodinblack]

Why did you decide on midi vs control channel, was this so you could use it on other things?

Also is your expression pedal USB or Midi, or are you processing that in the pedalboard too?

[SamIAm]

1 hour ago, Woodinblack said:

Why did you decide on midi vs control channel, was this so you could use it on other things?

Also is your expression pedal USB or Midi, or are you processing that in the pedalboard too?

I went for MIDI as the MOD Control Channel is not as mainstream, in theory I could use Trampa to control a Zoom pedal (Tho the USB hookup is quite different and the Pico needs to run in USB Host mode, which I believe the TinyUSB library I'm using supports), when I get Trampa working I may see if the control channel is easy to add.

My expression pedal is analogue (A foot operated potentiometer). The pico has 3 onboard ADCs and I'm using one to read the value from the pedal (It comes back as a value from 0 to 1023) and then mapping this onto the 0 to 127 range for a MIDI CC message.

S'manth x

Edited April 26, 2023 by Smanth

[Random Guitarist]

This looks very interesting, lots of possibilities, and tantalisingly cost effective.

 

 

[Woodinblack]

Certainly more work that I am going for - if I decide to do the upgrade, I will just use the MVave case and stick a Pico or a bluetooth feather (only because I have one!), but looks like you will have a very versatile pedal!

 

Might just go for these though:

http://www.timetravelaudio.co.uk/shop/components/switches/foot-switches/3pdt-foot-switch-illuminated-type-with-led-ring-colour-options-on-led-cap/

 

[Richard R]

9 hours ago, Random Guitarist said:

... tantalisingly cost effective.

 

Assuming you are a genius who has some time to invest and isn't costing it 😁

 

Sadly us mere mortals can only watch in awe from the cabbage fields.

[SamIAm]

2 hours ago, Richard R said:

 

Assuming you are a genius who has some time to invest and isn't costing it 😁

 

Sadly us mere mortals can only watch in awe from the cabbage fields.

Just a geek with some software and electronics experience and a love of gadgets. Hope to produce (eventually) a build guide for those who might want to do similar.

S’manth x

[RichardH]

This looks really interesting. I have a Dwarf on the way - as a super early bird adopter, I chose to be in the last tier for delivery, so got caught in the collapse.... haven't stumped up the extra to get it sooner as yet...

 

However, with all these multi FX devices like the Dwarf and HX stomp, all I really want it is a way to be able to jump between a few set "sounds" - so an additional controller like this looks like just the job for gigging use. Watching with great interest!

[Random Guitarist]

Looking at this a bit more I think it's probably possible to do something similar with an Arduino Nano plus the multiplexer and displays?

It would need to be configured via USB, not web, and would be limited in terms of capabilities, but might suit the kind of device I need more closely.

 

Thank you, very thought provoking

[Woodinblack]

38 minutes ago, RichardH said:

However, with all these multi FX devices like the Dwarf and HX stomp, all I really want it is a way to be able to jump between a few set "sounds" - so an additional controller like this looks like just the job for gigging use. Watching with great interest!

 

If all you want is to jump between a few set sounds, you don't even need additional buttons, you can just have a pedalboard with a number of snapshots, and move between them.  Obviously the pedalboard becomes more useful if you want to randomly switch between several sounds

[Woodinblack]

One thing I have found really irritating in the past that affects this with the oled displays, is that while the cheap ones are very cheap and very easy to use (<£5 each), the commonly available ones are all fixed to one I2C address, and the slightly more expensive or bigger ones have a choice of 2. Why can't they just expose a number of pins so you can pick at the minimum one of 4 or 8 addreses?

[tauzero]

You can multiplex OLEDs: https://www.instructables.com/Arduino-on-I2c-Multiplexer-Tca9548a-1/ which looks quite simple.

[Woodinblack]

8 minutes ago, tauzero said:

You can multiplex OLEDs: https://www.instructables.com/Arduino-on-I2c-Multiplexer-Tca9548a-1/ which looks quite simple.

 

Indeed you can, but if they just exposed the pins you would't have to, just assign them a different address then they would all work.

But yes, it is a workround.

[SamIAm]

 

1 hour ago, tauzero said:

You can multiplex OLEDs: https://www.instructables.com/Arduino-on-I2c-Multiplexer-Tca9548a-1/ which looks quite simple.

 

57 minutes ago, Woodinblack said:

 

Indeed you can, but if they just exposed the pins you would't have to, just assign them a different address then they would all work.

But yes, it is a workround.

Your are right @Woodinblack, I've cheap OLEDs which have a fixed address.  I gather that it is possible to bitbang I2C to allow the use of non h/w I2C pins, which would allow for more displays, but I took the approach @tauzeromentions ... it is not difficult to use and allows up to 8 devices (I'm unlikely to need more than 5 at the moment).  I did however find an odd issue when using the Arduino OLED libraries (during my proving out stage) that there was what appeard to be some ... 'crosstalk' between the 128x32 (4 of these) and the 128x64 (1 of these) that caused the 128x64 to expand fonts vertically by a factor of 2!  I combed thru the code several times to ensure I was using totally seperate variables/objects but I could not resolve it (the actual text displayed on each OLED was unique as intended).  When I get to driving them from c++ I may have to figure out what was actually going on.

 

S'manth x

Edited April 27, 2023 by Smanth

[3below]

I have also experienced unexpected font size problems with OLEDs. From memory (it was a while ago) my kludge solution was to keep the text messages short and use println(), not ideal but it sufficied. Good luck with tracking your issue down.

[SamIAm]

There are some things that are pretty much a given when developing software, a couple of them are:

 

1) Theft - OK, so we call it reuse! (In the open source world this is encouraged, generally all one needs to do is acknowledge the original genius who's work you are stealing reusing.  It is actually a practical example of the quote “If I have seen further, it is by standing on the shoulders of giants.” - Isaac Newton.

 

2) Debugging - Once a section of code is written, compiled and run ... it goes off and does what you have told it to do, very occasionally this is what you actually intended ... but more often than not it isn't!  When faced with the near certainty of impropriety it is useful to be able to observe what the code is actually doing.  With the development environment I'm using for Trampa, there is a rather sophisticated debugger (A tool that lets you progress through a program one line at a time, examine and change the values of variables, etc) available, but I've yet to have a good play with it (It actually consists of a second PICO running some special software and wired in a special way to the PICO that the software being developed runs on).  For now I'm doing some simple debugging by scattering print commands throughout my code, this will display messages like "You are here", "This is is the Nth time we have reached this point", "I have just received a MIDI message [CC 0xed]" or "You really don't know what you are doing ... do you!?".

 

Applying these two "principles" I have reached a minor milestone. 🥳

 

I was able to find a good example of how to send MIDI messages from Trampa to my laptop (Over a USB connection).  When I run this example, I can see (Using a MIDI monitor on my laptop) the MIDI messages coming in the USB port and if I fire up a DAW (Logix Pro in my case) I can hear notes being played.

 

I have also found some examples of how to print messages via the USB connection such that they appear to come in via a serial connection on the laptop and can be displayed in a terminal emulation program, this will let me keep an eye on things.

 

But ... both the MIDI and the Serial run over the same USB connection and ... darn it ... I searched high and low but I just could not find an example that showed how to use them both together (I knew it was possible as I have done it using a different programming environment) using C++ and TinyUSB (Which is what I'm using).

 

Over the course of several hours I have tried one approach after another ... without any joy, I could get MIDI to work but the Serial would remain sullenly inoperative ... or vice versa.  When Trampa is running for real I won't need the serial print capability, but whilst I'm developing it ... it will be essential to allow me to see what the system is doing with respect to reading incomming MIDI messages or detecting the different types of button presses for instance.

 

And then I stumbled across an example that seemed promising, it had a name that was in no way connected to what I was trying to achieve, I had found no handy "Here is how I did it" articles on the web, I just knuckled down and poured over the source code of several dozen different examples and tried tweaking some of them ... but it eventually bore fruit!

 

I now have a very simple example program which can send MIDI message to the laptop and send the output of my print commands to a terminal emulator!  (I have to admit I did a little dance of joy when it worked ... yes I've a sad life 🤣)

 

Next in the ever growing list of things to bite off, is the ability to detect the different types of button presses (Press/Release/Single Tap/Double Tap/Long Tap).  There are a few really elegant libraries that provide these sort of features, but I've yet to find a good one using the C++/PICO_SDK setup that I have chosen ... I cannot believe I'll not find one, but haven't yet.

 

Once I can detect the button presses I can then generate different MIDI messages based on which button is pressed (and the type of press) and even tho the displays won't be working I will have actually have a basic MIDI controller!

 

More developments as they occur ...

 

S'manth x 

 

 

[Richard R]

Further to my previous comment:

 

 

Edited April 27, 2023 by Richard R

[SamIAm]

I was sorta hoping for something more like ...

🤣

S'manth x

[3below]

Not that long ago I wrote a  page turner Blue Tooth app for ESP32 to drive my tablet with music tabs etc.  This involved short and long button detection, debounce etc.  I tried several libraries and eventually reached a simple approach adapted from somewhere that I can not now remember / find.  I have pmd you some code that is straightforward and seemed effective. HTH.

Edited April 27, 2023 by 3below

[SamIAm]

27 minutes ago, 3below said:

Not that long ago I wrote a  page turner Blue Tooth app for ESP32 to drive my tablet with music tabs etc.  This involved short and long button detection, debounce etc.  I tried several libraries and eventually reached a simple approach adapted from somewhere that I can not now remember / find.  I have pmd you some code that is straightforward and seemed effective. HTH.

Cool! I'm taking an interrupt driven approach to IO (buttons/expression pedal/midi/http) driving fifo queues to try to improve responsiveness and hopefully allow easy(ish) multicore division of labour (well, that's my hope!) ... I'll have a look at the code you kindly sent to see how I can adapt it to this approach.

S'manth x

[Woodinblack]

6 hours ago, Smanth said:

Your are right @Woodinblack, I've cheap OLEDs which have a fixed address.  I gather that it is possible to bitbang I2C to allow the use of non h/w I2C pins, which would allow for more displays, but I took the approach @tauzeromentions ... it is not difficult to use and allows up to 8 devices (I'm unlikely to need more than 5 at the moment).  I did however find an odd issue when using the Arduino OLED libraries (during my proving out stage) that there was what appeard to be some ... 'crosstalk' between the 128x32 (4 of these) and the 128x64 (1 of these) that caused the 128x64 to expand fonts vertically by a factor of 2! 

 

If you are using the same 128x64 devices that I use, you can actually change the hardware ID of those, so you don't need to mutiplex it at all. 

Sounds very much like the 64 high device is using the same setup as the 32 so trying to be a 32, but obviously could be any number of things, something there is sitting there laughing at you

 

2 hours ago, Smanth said:

Next in the ever growing list of things to bite off, is the ability to detect the different types of button presses (Press/Release/Single Tap/Double Tap/Long Tap).  There are a few really elegant libraries that provide these sort of features, but I've yet to find a good one using the C++/PICO_SDK setup that I have chosen ... I cannot believe I'll not find one, but haven't yet.

 

What sort of library do you need for those? I must admit that something like that I wouldn't even think of looking for a library for it. Obviously there are issues with differentiating between double tap and long tap, if you want the single tap to be as responsive as possible - there is a compromise there where your single tap is going to be delayed for a bit. 

[SamIAm]

1 hour ago, Woodinblack said:

 

If you are using the same 128x64 devices that I use, you can actually change the hardware ID of those, so you don't need to mutiplex it at all. 

Sounds very much like the 64 high device is using the same setup as the 32 so trying to be a 32, but obviously could be any number of things, something there is sitting there laughing at you

Yes, something in the OLED code was mocking me! 🤣

 

1 hour ago, Woodinblack said:

What sort of library do you need for those? I must admit that something like that I wouldn't even think of looking for a library for it. Obviously there are issues with differentiating between double tap and long tap, if you want the single tap to be as responsive as possible - there is a compromise there where your single tap is going to be delayed for a bit. 

There are a few button libraries I came across for the Arduino environment, my favorite was https://github.com/bxparks/AceButton#readme tho http://www.mathertel.de/Arduino/OneButtonLibrary.aspx has a rather nice FSM flow I'll probably end up adapting (as I want to drive the button detection system using H/W interrupts and I also would like to be able to detect when two buttons are held down together). There are also some inspiring ideas in the app I used for my first MIDI controller build https://github.com/alf45tar/PedalinoMini#pedals

 

 

You are spot on about the inherent delay when a button is configured to be able to detect single/double/long tap.

 

In some use cases (like toggling on/off an effect or loading snapshots) I'm not sure if it will be long enough to be a problem ... I'll need to have a play with the timings, but I've seen values ranging from 250 to 500ms used to determine if one is double tapping and perhaps 1,000 to 1,500ms to detect a long tap.

 

For looper control (or tap tempo) type situations where this is an unacceptably long latency, I envisage that a button can be configured to be single press only, if configured for single-press-latching, it will send a MIDI-ON or MIDI-OFF message on alternate taps; if configured for single-press-momentary it will (optionally) send a MIDI-ON message when pressed and (optionally) a MIDI-OFF message when released. I would guess that this could drop the latency to double digit ms (Tho this is just a stick my finger in the air kind of guesstimate 🤣) tho I will need to consider how to ensure any debounce logic does not delay this.

** MIDI-ON & MIDI-OFF will be configurable to be any MIDI message the user desires (or even sequence of MIDI messages). **

 

I'm scouring the Morningstar user guide as they have some nice ways of representing the different event types that can be generated https://morningstarengineering.atlassian.net/wiki/spaces/MMS/pages/181698574/Action+Type+List tho I'm also looking at the stuff by https://piratemidi.com/ for inspiration.

 

 

S'manth x

Edited April 27, 2023 by Smanth

[Woodinblack]

Sounds like you are well into it, but as always the programming is actually fairly trivial compared to actually deciding what it is that you want, which is always the tricky bit to stop feature creep from taking over (and ending up never happy!)

 

[SamIAm]

Just now, Woodinblack said:

Sounds like you are well into it, but as always the programming is actually fairly trivial compared to actually deciding what it is that you want, which is always the tricky bit to stop feature creep from taking over (and ending up never happy!)

 

The wise wise words of one who has been there and done that!

S'manth x