@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.
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 
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.
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)
unless…
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…
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.
FYI, the twitch streams should not be cited as references in terms of timing. example above, I move a control and then watched the output.
The stream is not in “sync” to that kind of level. Cams and synth output go through different chains and equipment. mostly the video feed from the LZX goes through the BMD web presenter and then meets up with cameras going directly to OBS.
This is especially noticeable on audio reactive streams. (i think only one). until we get some of the feeds more in line.
Thanks Nick, that is a very important point!
Loving your Twitch streams, but usually can’t participate in real time because work. Monday through Thursday, I’m slaving over a hot 3D workstation until 7pm. Fridays, I’m usually exhausted.
Crypto-bumping this thread to say I’m loving MATTE. There’s very little slew on the pots. Just enough to avoid noise? But not enough to interfere with real-time performance. So for any parameter with a CV input, MATTE solves this design issue.
Case in point: FKG3 Threshold. The Threshold pot has mad slew, like a half second. But patching MATTE into the Threshold CV makes it possible to “ride” the parameter in a real-time performative sense, with very little slew.
Thanks!
