USB driver for SourceAudio C4 Synth pedal

This is one of the most amazing things I’ve seen!
Thank you.

Note that the video does include an added audio adapter board, which isn't actually necessary if only the C4 Synth functionality is desired. The rotary encoder also has turn indents that prevent slippage.
 
Thank you.

Note that the video does include an added audio adapter board, which isn't actually necessary if only the C4 Synth functionality is desired. The rotary encoder also has turn indents that prevent slippage.
I love the idea of a screen with the names, a detected rotary encoder to select patch (and maybe a second to control the output volume)
I shared the video you had made on a uk based bass forum and a few of us got very excited!

I’m new to a lot of this and need to learn more how to program screens and make it work!
 
I love the idea of a screen with the names, a detected rotary encoder to select patch (and maybe a second to control the output volume)
I shared the video you had made on a uk based bass forum and a few of us got very excited!

I’m new to a lot of this and need to learn more how to program screens and make it work!
This morning I saw a new domain, the bass forum, had linked to the github source tree, and then in turn I came across that thread. And you're correct, I'm in Belfast, Ireland.

I'll throw together simplified version without the audio board, but with another rotary encoder (volume) and say, a 480x320 capacitive touch display. This should allow people to flick through and/or edit the patches, in real-time.
 
This morning I saw a new domain, the bass forum, had linked to the github source tree, and then in turn I came across that thread. And you're correct, I'm in Belfast, Ireland.

I'll throw together simplified version without the audio board, but with another rotary encoder (volume) and say, a 480x320 capacitive touch display. This should allow people to flick through and/or edit the patches, in real-time.
That sounds cool - how would you use the touch screen?


I was thinking of trying to work out a tiny 128x64 screen and try and fit it in as small an enclosure as possible! I’m probably just trying to solve my bug bears with the pedal in that it’s super easy to make sounds that sound good, and to have *enough* control live with the 4 knobs … and I can’t imagine it without a switcher… but I can’t ever remember what the presets are! So it’s preset name and master volume that would be cool to have.
I’m now going into designer mode (the day job) and trying to work out how control functions could work … trying to run before I can walk!
 
That sounds cool - how would you use the touch screen?


I was thinking of trying to work out a tiny 128x64 screen and try and fit it in as small an enclosure as possible! I’m probably just trying to solve my bug bears with the pedal in that it’s super easy to make sounds that sound good, and to have *enough* control live with the 4 knobs … and I can’t imagine it without a switcher… but I can’t ever remember what the presets are! So it’s preset name and master volume that would be cool to have.
I’m now going into designer mode (the day job) and trying to work out how control functions could work … trying to run before I can walk!
Touch input could be used to directly modified multiple onscreen controls without having first select focus. Say, a Bargraph. But could also be used in conjunction with physical input control(s) (keys/knob) for the best of both worlds.

If going with multiple rotary encoders, then I would consider implementing an dynamic encoder input configuration, loadable at runtime from SD. For example, config.cfg, which would index each control with its assigned function.
 
Hey Folks

Many thanks to MichaelMC for sharing his work:)

My intention is to build a controller for the c4 with 16ish encoders to modify parameters (depth, frequency, resonance etc) in real time and have them displayed on a LCD (240x320 ili9341spi). When a new preset is selected the parameters would be updated on the lcd.

I have the Source Audio hub connected to the c4 via the 3.5mm "control port" for preset changes and preset saving/management so I don't need those features from the teensy.


My guess is something like the following:

scan of the c4 to ascertain which preset is selected

use util_listCtrlValues when a new preset is selected via the hub.
Store the values so the encoders know where they are and to update the values of the parameters on the lcd.

use util_setCtrlValue to send the values to the c4 when the encoder is moved.
each encoder would be would be tied to a parameter

use util_getCtrlValue to get the updated value


Does anyone have any suggestion or guidance on how to approach this? Should I use the default teensy encoder library or an alternate?
Any insight would be appreciated or perhaps even an example for one parameter/encoder I can extrapolate (I'm much more a musician than programmer)

Thanks
 
Last edited:
Hey Folks

Many thanks to MichaelMC for sharing his work:)

My intention is to build a controller for the c4 with 16ish encoders to modify parameters (depth, frequency, resonance etc) in real time and have them displayed on a LCD (240x320 ili9341spi). When a new preset is selected the parameters would be updated on the lcd.



Does anyone have any suggestion or guidance on how to approach this? Should I use the default teensy encoder library or an alternate?
Any insight would be appreciated or perhaps even an example for one parameter/encoder I can extrapolate (I'm much more a musician than programmer)

Thanks
I would recommend against the 3.5mm interface as would unnecessarily complicate your design. For example, how could you infer a preset change where it happens external to your software? Polling is one option but not recommended to continuously poll the C4. It has other things to do.

For the encoder question, I threw together a small example of using multiple encoders (3), but using a modified version of the encoder library (added a callback from the isr) included. This is based around a minimalist UI framework which should provide a starting point to build off of.
Attached example is ready to compile as is.
 

Attachments

  • encodertest.zip
    14.3 KB · Views: 7
Thanks for your reply MichaelMC.

I did consider the extra complexity the 3.5mm interface adds, I thought I could maybe get away with polling the c4 at a long interval or maybe add a serial midi in port to connect my current midi controller and have the teensy do preset changes also.

Thanks so much for the code, i'll take a look :)
 
Thanks for your reply MichaelMC.

I did consider the extra complexity the 3.5mm interface adds, I thought I could maybe get away with polling the c4 at a long interval or maybe add a serial midi in port to connect my current midi controller and have the teensy do preset changes also.

Thanks so much for the code, i'll take a look :)
The EncoderTool from MatrixRat above looks promising, and is probably better suited to the task, though I've not tried.

Regarding using util_getCtrlValue(). I wouldn't recommend a user interface design where a read back is perform after each and every adjustment (write). Consider using a delayed approach where, say, after 2 seconds, the read-back is performed after last adjustment occurs. Not immediately. This will help with (prevent) bargraph jumping.

Something also to consider; How many parts (levels) per bargraph per control should there be. Have a look at ctrl_c4.c then controls_c4[]. The forth column states how wide, in bits, each control is. Eg; A control at 2 bits wide indicates a bargraph of 4 levels. 1bit would be either 2 or on/off.
 
The EncoderTool from MatrixRat above looks promising, and is probably better suited to the task, though I've not tried.

Regarding using util_getCtrlValue(). I wouldn't recommend a user interface design where a read back is perform after each and every adjustment (write). Consider using a delayed approach where, say, after 2 seconds, the read-back is performed after last adjustment occurs. Not immediately. This will help with (prevent) bargraph jumping.

Something also to consider; How many parts (levels) per bargraph per control should there be. Have a look at ctrl_c4.c then controls_c4[]. The forth column states how wide, in bits, each control is. Eg; A control at 2 bits wide indicates a bargraph of 4 levels. 1bit would be either 2 or on/off.
I'll take a look at the Encoder tool, thanks MatrixRat.
In regards to using getCtrlValue() I had thought the same thing, a longish interval of perhaps 2 seconds between read-back.
In regards to bargraph, I assume you mean a graph to display the value on the lcd? I would prefer a numerical display 0-254 but a bargraph could be good for touch input if you choose to implement that.
 
Last edited:
Back
Top