I’ve been working on a project for Reaper and Electra One users: KnobConnector. It’s a control surface plugin that organizes all parameters of a track’s plugin into a logical hierarchy, making it easier to navigate and control any part of your instrument or effect directly from the Electra One (mkII).
KnobConnector follows your currently focused FX in Reaper and adapts the E1 accordingly.
For example, here’s what the E1 looks like when u-he’s Repro-5 is focused:
This is the first preview version of KnobConnector, which I initially developed for my personal use case. I’d be really interested to see how others might use it or how it could fit into different workflows so I appreciate any feedback, whether it’s about bugs, suggestions for improvements, or new feature ideas.
Version 0.9.0 is here with the following improvements:
v0.9.0 (2024-10-28)
ValueExpressions: Added a workaround for plugins (e.g., VCV Rack or Reason Rack) that only report normalized values (0.0 to 1.0) to the host. This allows defining mathematical expressions that calculate meaningful values for the E1 display.
Before:
After:
DynamicMaps: Added background scanning for parameters when modules are added or removed.
DynamicMaps: Improved the ParameterNames matching mode by detecting split module groups in parameters.
Navigation: Navigation state (selected module, submodule, and parameter view) is now remembered and restored during runtime for each plugin instance. This feature is limited to runtime only due to API constraints.
SteppedParameters: Fixed a bug that caused stepped parameters reported via the REAPER API to be overwritten by default range values in the plugin map.
@martin I cannot edit my initial post anymore. It’d be easier for others if I could continuously add the latest version to my initial post so they don’t have to look through the entire thread to find the latest one. Is it possible to make an exception for this specific thread to allow me to edit my original post?
Hi! Just want to say this is awesome. New to the E1 and picked it up just for Knobconnector. Been trying to set up a different controller for months and this seems be what I wanted the other to be but a whole lot easier. A breath of fresh air, so nice. Thank you!
Fixed a crash when paging through parameters results in a parameter view starting with only hidden parameters for the current submodule
Known Issues:
Wrong submodule shown as selected when paging through parameters results in a parameter view starting with only hidden parameters for the current submodule
Overlapping groups when paging through parameters results in a parameter view starting with only hidden parameters for the current submodule
Paging through parameters sometimes fails to scroll the submodule view
UI : Added keyboard commands for navigating modules, submodules and controlling focus
Use arrow keys to change the currently selected module
Use CTRL and arrow keys to change the currently selected submodule
Use page up/down keys to change the current parameter page
Use Ctrl+Shift+K to switch focus from the UI window to the window focused before
Use the Reaper Action “Toggle controller view” to open or change focus to the UI window
Use Esc key or Ctrl+Q to close the UI
Automatically moves keyboard focus back to UI window when switching to an FX via the FX View using keyboard commands
Navigation: Improve page button behavior by moving the entire view instead of a single element
Navigation: Parameter names and parameter values now utilize the full character length limits of the Electra One
Navigation: Improved opening and focusing floating FX windows via FX View
Navigation: FX View can continue to show all available plugins on a track of the last focused FX even if its window has been closed
Detect adding, moving or removing FX in Reaper and create, reuse or remove corresponding data in memory like dynamic maps or view restore data
Improved several performance aspects of the value to string system (memory management, string deduplication, reuse of math parser instance, minimize query of parameter values via Reaper API)
Added saving and restoring on Reaper exit and startup for FX View, Quantization and UI opened states
Maps:
Allow multiple value expressions per parameter and use math expressions to evaluate at runtime which one to use
Add Audio Damage Quanta 2 map
Reason: Add maps for PH-90, Europa, Grain, BV512 and The Echo
Reason: Add conditional value to string expressions for devices CF-101 (Rate parameter), Thor (LFO1/2 Rate parameter, various Env parameters) and The Echo (Time and Offset parameters)
Sumu: Update map to v1.0 (new parameters on UI)
Fixes
Fixed unnecessary MIDI message flooding when parameter value text exceeded E1’s character length limit
Fixed crash when focusing an FX after an unsuccessful init
Fixed fail during init if a previous control surface plugin failed during init
Fixed crash when closing Reaper with the action view opened showing KnobConnector’s action states
Fixed UI not showing the char %
Fixed button navigation not properly switching back from NoSubmoduleView to normal view
Fixed group slot dimension not updating when parameters positioned at the end would change to hidden
Fixed FX View not updating when FX order changed
Workaround plugins writing parameter values beyond E1’s character limit which caused a stack overflow
Breaking Changes
Changed map data format to allow multiple value to string expressions with conditional activation for single parameter
Thank you so much for your work — this is a brilliant concept! It really looks like Electra One combined with KnobConnector is the ultimate mixing setup.
My goal is to use Electra One to rely more on muscle memory and spend less time dealing with plugin windows and interfaces. I’m not trying to map every single parameter of every plugin, but I do want things to be consistent. For example, I always want input gain on the top-left encoder and output gain on the top-right. That way, no matter which plugin I’m using — whether it’s a compressor, saturator, or anything else — I can quickly adjust gain staging with both hands and avoid being misled by the “louder sounds better” illusion.
Right now, parameters in the Plugin Map are assigned to encoders sequentially. For instance, when using the Kush Audio TWK plugin, I only need three parameters: input gain, output gain, and drive. For my workflow, they need to be on encoders 1, 6, and 7 respectively. At the moment, I’m adding placeholder entries for encoders 2–5 with blank parameters to make this work, but that clutters the interface. Would it be possible to either disable specific encoders or freely assign parameters to exact encoders?
I’d also love to see a “Channel Strip Mode” in the future — something where you don’t need to open plugin UIs at all. I imagine it working like this: when a track is selected, the Electra One screen shows three rows of parameters from all plugins on that track that have Plugin Maps. Instant access to key parameters across multiple plugins without opening any UIs could be the fastest mixing workflow imaginable.
I just received my Electra One today and immediately started diving into KnobConnector. I did notice that sometimes when turning an encoder smoothly, the parameter jumps to its min or max value — I’m not sure if that’s a KnobConnector issue or something related to Electra One’s sensitivity settings?
Thanks a lot! The original concept was developed with synth plugins in mind, but I have been thinking about applying this concept to mixing, latey.
I also thought about having specific functionality appear at specific knobs. Since the idea of plugin maps is to be hardware independent, I’m tending towards another idea: you have a mode where you can define what generic function you want to assign to a specific knob. Things like “Input Volume”, “Ratio” or “Band 1 Frequency”. At runtime, KnobConnector would then try to match these generic functions to specific parameters of the currently focused plugin or the plugins of the currently focused track.
That being said, have you tried declaring the unusedIf property to those workaround placeholder entries? This makes them look a bit less “usable” as it is intended for parameters than can suddenly be greyed out in a plugin UI (like a release parameter becoming disabled when enabling “Auto Release”).
I have been thinking about a channel strip mode as well, also with the goal of not opening the plugin UIs. Not sure what you meant with “three rows of parameters” though, as you can only control two rows of parameters with the E1 and toggle between two other double rows. KnobConnector however locks itself to the lowest double row to have the upper two double rows available for parameter navigation. Maybe you meant to populate the three of the four upper rows with modules from the plugins of the current track?
This is an unfortunate issue with the E1 knob’s touch sensors. Technically, the E1 knob only sends data when the E1 also detected the knob to be touched. This doesn’t work 100%, and can sometimes cause the accelerations derived from the encoder movement to be inaccurately large and even have the wrong direction. The problem will be fixed with the upcoming E1 firmware v4.0.0. It’s in preview atm and if you feel brave enough, you can give it a try: V4.0 testing [was V3.7] - #187 by martin
Thanks so much for the detailed reply — really appreciate the time and thought you put into it!
That’s a great idea and it would be very useful — if only plugin parameter naming weren’t such a mess! Unfortunately, there’s often no consistent logic. For example, Kush Audio uses “Intensity” for drive/saturation, and plugins like Waves CLA MixHub have tons of duplicate parameter names, making it hard to tell which control corresponds to what in the UI. I imagine building a matching system that accounts for each developer’s naming conventions would be a nightmare — so maybe it’s better to leave that pain to the end user
In the past, I tried building a channel strip workflow using Control Surface Integrator and the Softube Console 1. That controller was too limited and the encoders had very low resolution, but it did allow fixed parameter-to-knob assignments. You could define an index file per MIDI controller where each encoder had a name. For example, I’d name one encoder “Drive” and then map that to the saturation parameter in all my saturation plugins. That approach worked well conceptually.
Thanks also for the tip! I’ve gone through the documentation carefully, but I’m still not entirely sure how to activate it for a specific parameter. I’d be super grateful for a small example — I’m not a programmer, but I can usually adapt code snippets if I have something to start from. I think a beginner-friendly intro section with a few practical examples would help other folks like me too!
Yes, you’re absolutely right — I didn’t phrase the “three rows of parameters” part very clearly.
The current layout with submodules works great for synths (I tried your Repro-5 test file) and mastering plugins where you need structured access to multiple sets of parameters. But for a mixing-focused channel strip mode, 12 visible parameters feels a bit too limiting. I think the main goal of this mode should be faster access to key parameters — faster than switching between plugin GUIs — essentially allowing the user to build their own “hardware” channel strip.
For example, the first 4 encoders could control a compressor, the next 12 an EQ, and encoder 13 might adjust saturation. With the current layout, you’d need to flip through pages just to reach that 13th parameter. So for a fast, mixing-oriented channel strip mode, maybe it would make more sense to reserve the top third of the screen for parameter navigation and use the remaining two-thirds (two rows of 12 parameters) for direct control.
For context: a single channel strip on an SSL 4000 desk has 25–29 controls depending on the revision. Having access to a similar number of parameters on E1 — without diving through plugin GUIs — would make mixing so much faster and help keep focus on the sound. Bridging the gap between mouse/keyboard speed and real hardware workflow is no small task, but I honestly think E1 combined with your plugin has the potential to make it happen
Yes, it won’t be based on the name of parameters. So how I think it could be done is this: the plugin maps ship with generic functions tagged to the parameters, e.g. Pro-Q4 would have its frequency parameters tagged with “Frequency Band 1” etc.. Then, users map those tags to specific knobs on the E1, e.g. Knob 1 is “Frequency Band 1”. At runtime, KnobConnector will then check if the current map of the current plugin has a parameter tagged with “Frequency Band 1” and if it finds it, will map that parameter to Knob 1.
Think of it like a tagging system for both, the plugin map and the controller’s encoders.
So how would you map that encoder to all your saturation plugins in CSI? I only understood CSI so far as to those bindings being very specific to your controller, which I want to avoid so all people can share their plugin maps.
The original use case for that is a UI control that is suddenly hidden. That’s why the unusedIf is a math expression. However, in your case, you’d want this to be always on, so you should be fine just setting it to 1 like this:
[plugin]
name = 'SomePlugin'
[[plugin.module]]
name = 'Main'
[[plugin.module.submodule]]
name = 'SomeSubmodule'
[[plugin.module.submodule.parameter]]
index = 0
name = '--'
unusedIf = "1"
This will make the parameter always be unused.
Yeah, I also wondered if users should be able to change all of this. Basically build their own layouts. Actually, this would be a requirement for making KnobConnector support other controllers as the combo of 12 encoders, 36 virtual control slots and 6 non-programmable buttons is rather unique.
Somewhere in that avenue is also the idea to have knob-based navigation. This would allow you to use knob 1 to select a track, knob 2 to select a plugin, knob 3 to select a module, knob 4 to select a submodule. That would allow users to have a lot more space on the E1 for other things than navigation.
I don’t yet have any idea how user could define those modes and how they’d be able to switch between them.
Thanks! For quick remapping of the E1 knobs, you could give the state visualizer a shot. If that window has focus, you can use your keyboard’s arrow keys to page parameters, select plugins or modules. Maybe with some tweaks (like accessing a plugin without opening it, haven’t yet thought about that), you can be able to access those parameters sets quickly using your keyboard.
The tagging system sounds like an excellent concept! I think it could work really well.
I did it manually. The parameter assignment process in CSI is actually quite similar to KnobConnector. In the map file for each plugin, you can assign specific parameters to specific encoders. So I just created custom maps for all the saturation plugins I use and assigned the same encoder to control saturation across all of them. Time-consuming, yes — but it gave me the consistency I was looking for.
As for knob-based navigation — interestingly, that’s how the original Softube Console 1 workflow is set up when using it with their proprietary software (not CSI). But I quickly abandoned that approach. In practice, turning a knob to scroll through a long list of plugins or tracks turned out to be much slower than using a mouse and keyboard. It felt like the workflow was actually getting in the way.
To me, the real power of using controllers during mixing lies in two things:
Achieving a faster workflow than mouse + plugin GUIs allow. (Console 1, in my experience, doesn’t really deliver on this.)
Mixing in a “use your ears” paradigm — relying less on analyzers, avoiding visual bias, and minimizing the need to open plugin windows.
Since different modes may require different layouts, and E1 already allows switching presets on the fly, maybe the channel strip mode could simply be a separate preset — for example, KnobConnector_CS. During production, users could stick with the current preset, which is great for synths with its module/submodule structure, and switch to KnobConnector_CS during mixing for faster access to a broad set of parameters across plugins.
Perhaps each plugin map file could contain a tag or identifier to specify which preset it’s meant for — regular or channel strip mode. Just an idea — I’m not a programmer, so I don’t know if that’s technically feasible or if there’s a more elegant solution
The advantage of that approach will be that users can share their plugin maps while still being able to customize their knob layouts or create additional tags on top of it.
Then it’s still as I remember. I know, that works well enough for your goal but it mixes plugin-specific data with controllers-specific and layout-specific data. I want to find a way to solve these things separately so users can mix and match maps and use them with their own layouts. Note the risk of finding out that there’s a good reason why nobody has done that yet.
Interesting. Can you explain why or reference a timestamp to a video that shows the disadvantage? Could save me some time repeating other’s mistakes.
Would also love to read more details about this.
Yes, it’ll either be based on presets or on changing the layout on the fly (once that is supported by the E1’s lua API). What is still unclear how all of this should be managed. Probably the best way would be if users build their layouts and flow between them as data files for the KnobConnector plugin and the E1 would simply follow this. This would require features on Martin’s roadmap that are not yet implemented, but it has the advantage that it can be made to work with a lot more controllers. The other way would be that the E1 tells the KnobConnector plugin its layout built by the user (possible, technically) but that won’t be possible with a lot of other controllers. Have to think about this more…
This gentleman is showing how it looks to scroll through the list of just one manufacturer’s plugins for a single module in Console 1. Now imagine how painful it would be if the list included multiple vendors — and how much time it would take to choose different options for each module.
That simply doesn’t compare to how fast REAPER is when using toolbars, custom actions, and shortcuts for everything.
I’ve also tried similar knob-based workflows in Native Instruments software, where all synths are organized in a unified library and controlled through their wrapper using Komplete Kontrol or Maschine hardware. In practice, this turned out to be much slower — scrolling through filters and sort options doesn’t speed things up when you know what you want.
Here’s an example of how it works in the NI ecosystem:
To me, a fast workflow for mixing with a controller could look something like this:
You’re sitting in front of the monitor.
Mouse in your right hand, keyboard in front of you, E1 on the left or just above.
You right-click on a track and instantly get access to your parameters — already arranged in the right order, with no switching between windows or modes. Just one click, and you’re ready to mix the essentials.
That’s basically a console-style approach to mixing.
Something like what this engineer does here:
Unfortunately, there’s often no consistent logic. For example, Kush Audio uses “Intensity” for drive/saturation, and plugins like Waves CLA MixHub have tons of duplicate parameter names, making it hard to tell which control corresponds to what in the UI. I imagine building a matching system that accounts for each developer’s naming conventions would be a nightmare — so maybe it’s better to leave that pain to the end user 
