Performative, tactile control via kobs and sliders

Hey Lars, I don’t have a way of measuring time in anything less than a second. But I think I could probably twist a frictionless knob from one extent to the other in, let’s say, 250 milliseconds? But then the question becomes, what is the optimal slew rate based on that mechanical limit? And is the slew fixed or variable? I certainly wouldn’t want 250 milliseconds of delay if I was only moving the knob, say, 10 degrees instead of 300 degrees.

In a perfect world, pots would be buffered to even out any mechanical noise, but have zero friction and zero latency. I have no idea if that is technically possible or feasible.


I don’t have an encoder at all… been limited to vector graphic tests since I started collecting modules back in October

@dryodryo, do you need this? I think it will help us organize.

You could try taking a video of yourself turning the knob, and then see how many frames the motion takes, and multiply that by the 1 / FPS, for a rough approximation of period. I think 250ms is probably realistic!

But then the question becomes, what is the optimal slew rate based on that mechanical limit? And is the slew fixed or variable? I certainly wouldn’t want 250 milliseconds of delay if I was only moving the knob, say, 10 degrees instead of 300 degrees.

Slew is rated in V/s, or the increment of time taken for the voltage to rise 1 Volt. So it is already proportional – for example, if we move the knob across 10% of the control range, the slew across that period will be 1/10th the time it takes to transition across 100% of the same control range. So slew is proportional to the knob distance traveled.

Side note: This is different from tweens or animation events (which is another fascinating topic) – where typically you define the transition time independently from the range over which you are transitioning.

So since our control pot moves across 0V to 1V, this makes 250ms a slew of 4V/s.
Since the slew is “moving with your hand” for the reasons mentioned above, its effect on knob responsiveness are going to be transparent if our circuit slew is matched to the speed of your knob turning motion. 33mS or a slew of around 30V/s is enough to minimize glitches that may appear in the image due to resistive noise from the pot.

I’ll get a simulation pulled up and see where FKG3 Threshold sits related to these numbers in a sec, and then compare that to the pots on say, ESG3, and we will have some useful information.


@7pip Thanks for the offer, I’m only interested in HD formats. Otherwise I would have re-entered the modular video world with the Visionary series ten years ago!

ESG3 getting very close to shipping, a little bird told me the serial plates are printed for the first 100 production units.

1 Like

OK I’m back (had to pick up the boy!)

Here’s a graph of the existing FKG3 slew circuit across a full scale knob sweep time of 250ms. We’re actually looking pretty good, by that metric – but just shy of your ideal response curve.

Here is the same time constant, showing the amount of slew on other pots in the Gen3 series modules:

So you can see, there’s quite a difference – but the first curve is still matched pretty closely to something reasonable as the human limitation on response speed. The second curve should be more or less invisible, just “silky” rather than slewed.

If you want the second response curve, replace R58 on the middle PCB assembly (lzxpcb-fkg3-core) with a 1K resistor (previously a 10K resistor.)


Thanks for taking the time to look into this. I will have a better sense of what’s happening when I get the ESG3. But all I can say right now is, based on watching Nick’s Twitch demos, the key threshold pot has what looks like a slow-in, slow-out rather than a linear response. And it looks like the onscreen motion is still going after the mechanical knob motion is complete. I’m happy to set this aside for the moment until I can get you some more concrete feedback.

On a positive note, the mechanical motion of the pots is good. Very little friction on the Threshold and Softness pots, lots of friction on the CV gain pots. That part of the physical design was definitely optimized for performance and stability.

Thanks again, I really appreciate the “hands-on” approach!


Right! I like that too. The detented pot is really a 2-in-1 scale – since you have a full sweep on either side of the detent. So I like the greater friction there – if you are going by haptic feedback (eyes closed), you can “feel” the sweep range this way … more friction = smaller range, less friction = wider range.


Right – that’s what a simple RC filter looks like – same as the slopes above. A “performance slew” with different curve options and adjustable time constant is something I am planning to merge with audio envelope follower functionality on a future module, as that is a natural fit.


Cab 1 will be the animation cabinet

Please note the triple Wogglebugs!

ahh yep, this is my planned Control Skiff - already have the modules and rails, just need to make time to build the case. Note the NLC modules, chaos is way more interesting than random :cowboy_hat_face:

going back to the original topic, I’m typically not a fan of “played” audio and video, where the control being interacted with is directly audible/visible in the performance and you can see their movement directly translated - much prefer at least one step of separation. ie having a slew or envelope between the human and the modulated signal, or the LFO speed being increased which then changes the way the filter or VCA is processing the signal.

That might be because I prefer slow, droney, meditative A/V experiences - and too many times the direct human control makes the performance feel “adjusted” rather than “performed”


@Rik_bS That’s a great observation… if we talk about visual music concepts, the “Mickey Mouse” effect is always a concern. That’s the question of whether visual and audio should be in sync or not. If you want tight synchronization, it had better be tight. That’s what I’m on about regarding the tactile response. But even if one is trying to achieve a counterpoint to the musical rhythm, one still needs a reliable, responsive control.

1 Like

That’s my experience as well – those small motions when you’re dialing in the sweet spot, having a little slew helps you guide the voltage into place transparently instead of it looking like a series of nudges. With feedback especially, a nudge can end up rippling down through your feedback chain quite obviously even when you’re operating the knob with care and uncaffeinated. So the end effect for me is the slew provides more control, not less – it’s meant to satisify a design goal of “maximize the usability of hands on controls.”

@dryodryo I’m incredibly interested to get your second take after trying the module out in context – once your fingers are on it, adjusting the threshold of a video key in time to a musical track, doing what’s instinctive to you as a performer, I want to know if your thoughts change at all. You will probably feel the same, if it’s something that’s already bugging you, but it’s a nice case study.


Thanks Lars, I totally get what you’re talking about regarding the super sensitive nature of some patches and effects such as feedback. That’s definitely a case where smoothing out the user’s motion is helpful. In the case of more extreme / fast / staccato playing, the smoothing is a deal-breaker.

The other issue I have is the non-linearity of the response. To the best of my ability I rotate the knob at a linear, constant speed … but the system decides to accelerate out of, and decelerate into, its resting state. Not gonna work for me, sorry.

If you do build a slew module I would love to have one in my toolkit. I have some Pulp Logic ones which are pretty nifty, but choices for different types of curves would be wondrous.

I read your flagged comment.
What I meant with my comment is that as a developer , I cannot cater to all needs.
And the pots are not interchangeable, so it is not that easy to fix.
edit: I found this one: P260T looks like it has the same footprint as an Alpha pot… though expensive.
Musicthingmodular make the “Control” module, which uses those. (but has no 0-1v output)

Personally, I try to make my modules affordable, and such fancy pots are definitely not. (+10 euro per potmeter)

You already inspired me to think up a module with those smooth multiturn / or singleturn blue potmeters mounted with a large round custom made knobs. precise voltages…


Just going to start this note by saying : IN LARS WE TRUST - LZX4LIFE

Nice to see some spirited discussion back in the forum. I would just like to add that in my use case I absolutely NEED resistance in the pots in my rig and especially due to live performance concerns.

If anyone has ever reached through patch cables to make an adjustment and accidentally bumped or had the cables fall onto a pot on a nearby module and have the video output go completely wayward and have to scramble to track down what module and which knob (or two) got knocked out of place and dial in the appropriate knob placement again might appreciate a bit of resistance in the pots.

This is definitely manageable in a smaller 3U or 6U system but in a larger system it becomes more likely for this to happen and more challenging troubleshoot in a performance environment.

I understand that other users have different concerns, opinions, and use cases but I prefer the secure pots with a bit of resistance.

Regarding slew on FKG3 pots, I am kinda surprised it took this long to come up. Maybe its just that everyone’s rigs have been on a shelf indefinitely (like mine) waiting for ESG3, TBC2, etc… Nonetheless, the slew on these pots is a significant issue for me.

After reading through some of the correspondence here it seems to make sense that maybe there should be some slew in order to make the knob moves smooth…? I don’t know, I am sure the community will find a good mid-point sweetspot for a curve that works for everyone BUT my main issue is more about the calibration of these being consistent. I have a few FKG3’s and the slew on that knob seems to be different on each module which is really annoying and makes knob adjustment hard to gauge, when adjustment on one module reacts slightly different than on the same module right next to it. So, whatever it ends up being please make it consistent. On one of the FKG3’s I can move the knob and my hand is already off the knob before I can see the adjustment start to visibly happen - not ideal.

Also, it seems that the softness knob on a couple seems to be way off. After seeing the post of @jwsmithwick1 (thanks for this) - I now know this is a known issue and needs an RMA. Would be GREAT to have a thread of some sort to list known issues - so we all don’t have to spend hours troubleshooting the same problem.

All this being said, I just want to express my admiration for @creatorlars ability to hear all of our user feedback (which is not an easy task) and gracefully channel it into a productive and educational conversation and the willingness to break it all down in order to make adjustments moving forward.

Looking forward to the upcoming weeks as these new releases start to ship.


That’s correct – the time constant of knob turn speed vs. the frame rate of the video signal is an existing constraint – it’s a design consideration with any video synth design. Actively buffering the pot and adding a slight slew to the voltage is a layer of polishing that we’ve put into all designs since Topogram. It’s not a feature that is required to make a good video synthesizer, or some part of the shared LZX patchable standard, but we feel like it adds an extra level of performance and signal integrity to our instruments specifically.

It seems like we got the slew constant right with Topogram and SMX3 (also applicable to ESG3 and everything else) – but that with FKG3 it’s applied in a way that some people like and some people do not. It’s likely we’ll revise FKG3 to match the slew constant of the other modules in a future revision.

So to be clear, and re: consistency – FKG3 is the only module which has a more liberal slew applied. The others do not. If you like the way your Topogram and SMX3 feel, that’s what to expect in the future. To my knowledge, there should be no differences in that slew constant between different FKG3 assemblies. To ascertain what you’re seeing between your units, I need a measurement or number of some kind. “This one slews half a second, this one takes two seconds” is a huge difference for example, representing an RMA scenario, whereas “this one slews 450ms and this one slews 480ms” is well within tolerances for the components used.


To be clear: your modules are machines – they are engineered to fulfill an elegant balance between specific performance, usability, manufacturability, cost and form factor requirements according to their stated functions. There’s a lot of passion behind the design of these modules but the passion is in fulfilling those requirements to the best of our abilities. In product design, everything is a balance. We’re always happy to receive feedback related to how well that job has been accomplished, and also how well those design requirements were determined in the first place.

But sometimes those aren’t the same thing – for example, if you expect 0.1% linearity and 0.1% tolerances, well we’d have to design a more expensive product for a different market to accomplish that. Best we can do at the “prosumer instrumentation” price point we target is a stack up of tolerances around 1%-2%. Or form factor constraints – for example, while a 4HP TBC or 4HP Ramps module seems like it would be good from a usability perspective, we’d have to sacrifice too many other aspects of our standard (mounting depth, power draw per HP, rear connector usability, etc) in order to accommodate that – a great case in point is modules that fit in one case but not another. So these are examples of feedback that, while we appreciate it, are an area we have to stand our ground and focus on delivering consistent performance.

The useable kind of feedback for us relates to practical experiences with control ranges being off or out of tolerance in certain use cases, or things like too much slew on a pot (like this post.) Or functions you wish existed that don’t yet exist in the landscape, etc – for example, it’s hard to use a module because there are no other modules that are its “other half.” That’s very useful kind of feedback and it just helps us do our jobs better.


I can’t believe my mildly sarcastic comment got deleted. I mean really, there’s a big difference between friendly banter and abuse. It’s a moderator’s job to know the difference.

But apparently there’s no room for humor or irony here. I’ve run afoul of it several times now. Fine. Just the facts from now on. Next time someone makes a mind-numbingly obvious comment, I will just ignore it.

Peace out

sarcasm can be hard to ready as plain text.
but I did not flag your post, so don’t take it out on me.

And as I tried to explain, my comment was not meant as “mind-numbingly obvious”.
Your post comes over as a wish for developers to take seriously.
As a DIY developer, it might be a possibility to offer options for different pots (stiff or smooth rotation)
This is something I had never reseached before, because I assumed it was not available.
But it appears it is.

edit: let’s continue with the discussion.


Friends! I have not seen a community as accommodating as the LZX Facebook and Discourse when listening to and loving new users waiting on the chance to use equipment that may introduce a frame of delay or not accommodate with zero friction, zero latency, staccato capable knobs! Bless us all for making so many video friends. Frabjous joy that we find ourselves here on Earth pondering the real important questions and playing with our video synthesizers no less!