First of all, I’d like to thank you for this wonderful little thing you’ve created! I’m a bass player and I mainly use my zynthian (a custom with an external usb sound card) as a sort of mini dsp for room EQ and occasional light effects that don’t deserve a dedicated pedal.
The problem I run into is that EQ plug-ins have a wide frequency range. There are times when I wish my cc could adjust the center frequency parameter from -1 or 2 octave (with cc to 0) to +1 or 2 octave (with cc to 127) for fine tuning. But I can’t find a way to adjust the scale of a parameter.
Is there a way to do it?
Thank you very much!
Nicolas
Welcome @Nicolas to Zynthianland. Your use of Zynthian is interesting. It is fun to hear the many ways we use this versatile device.
Currently there is not a way to constrain the range that a CC controls. The full range (0…127) is mapped to the full range of the parameter. I can certainly see that constraining or modifying the range could be advantageous. That may include a limited, relative adjustment rather than absolute as requested here. (I think some form of relative adjustment was implemented but I have never used it and am not sure of its state.)
May I suggest you add a feature request in the issue tracker?
And what about fine adjustment of a parameter? For instance, in the C* Click Metronome, you can adjust the BPM, with a resolution of 0.1. But, when I turn the encoder, it changes by a large amount (around 1.2), and it’s very hard, when not imposible, to set it to something like 60 BPM (it jumps from 59.5 to 60.6).
I’ve searched the documentation, but didn’t find anything.
The issue has been informally discussed.
It is a very necessary charateristic.
I have a two Roland EV-5 voltage pedal, and one of them drives the cajon volume fader but , as you say I have no way of defining the range or offset. I would like to limit the maximum range of the pedal within the snapshot, but would have to do this withing the BluePill that controls this process. . . At present if the pedal goes all the way down the cajon will feed back.
We require a transformation available at every possible control node that allows a range an offset (+/-) and a transfer curve. This would also seem to be the obvious place to allow multiple control of a parameter. The ability to adjust an expressive parameter from two or more control devices over ranges that relate purely to the incoming source would also seem required. We are limited to one controlling device per parameter.
I tend to start sounding like a stuck record at this point because this problem has been addressed before by the Nord Modular with Morphs…
MORPHS
MORPHS allow you to tweak several parameters at once by one physical play controller, like by a Modwheel or the Keyboard Aftertouch. Which basically means that one physical controller will ‘play’ several module knobs at once. Each parameter can have its individual MORPH range. In total there are eight MORPH groups, each associated with its own physical controller. A total of twenty five parameters can be assigned to the MORPH groups. MORPHS can be instantly assigned and their MORPH ranges adjusted with the panel controls on the G2 and G2X models.
Obviously this is a subject for post Oram Stable. This probably is considerably more detailed that what might be envisaged but there is an inevitable path that leads this way. There is a solution that involves constructing an lv2 MIDI module that can be inserted into the MIDI jack map at ‘appropriate’ places manually but I imagine the current graph module on the GUI in it’s directory structure layout would quickly become rather tiring to implement.
Let us just enjoy the success of the current implementation that got us here!
For me, it would just work to have a way of increasing the resolution of a certain knob. For instance, pressing ALT may multiply the knob step by 0.1, or something like that
The range scaling is done based on the total range of the parameter and some simple division calculation. This can result in rounding errors and may give undesirable resolution. We try to compensate by changing the resolution of the change of value based on the speed of rotation but this too is a fairly simple algorithm.
The idea of having a modifier (like ALT) to increase resolution is good. We still map the range to the MIDI CC range (0…127) for remote control.
@oscaracena should raise a feature request for this.
I just commited the implementation for V5 using the ALT mode, as suggested. It works quite nicely! I don’t understand why we didn’t implement this before
Just update and test (Oram, of course!)
Now we need a workflow for V4 and touch:
For V4, i’m thinking of implementing “rotate while pushing”
For Touch, i’m open to any ideas, but the most simple would be to add the “ALT” button , replacing the “sidebar” toggle, for instance
Touch could use horizontal drag for fine control. I am designing an alternative workflow (same as V5) for MIDI learn that currently uses horizontal drag.
Rotate whilst pushed sounds good but it may prove mechanically challenging.
Yep. I don’t like very much, but we need a decent workflow for V4.
BTW, i just implemented a POC for touch, adding ALT to the buttonbar.
Horizontal drag sounds interesting. I’m also thinking of mimicking the V5 encoder-switch workflow with touch
Not everyone has S1-4. Some builds only have 4 encoders, e.g. V3.
I don’t like it! The implementation is flawed (issue 1182) and it doesn’t align with the touch UI. (ALT is a keypad modifier and touch does not have the concept of keypad.) I have implemented horizontal drag for fine control. Be aware that the direction of drag (vertical or horizontal) is detected during inital motion then is locked until released, i.e. if it detects you are dragging vertically, you must release and touch again before you can drag horizontally. This is common behaviour throughout zynthian touch interface.
I was bitten by a fish so maybe that has effected me but I was mostly pointing out that we want a consistent approach so avoiding depending on features users may not have. Of course everyone is free to customise their zynths as much as they like. Why not add a button that just plays a blast of bagpipes?
Well, so finally, and before the Oram release, i decided that fine-parameter adjustment should be implemented for all interfaces, so it’s
V5 & MINI_V2: ALT mode or Push+Rotate knob
V1 to V4 (“classic” wiring layouts): Push+Rotate knob
TOUCH: Horizontal drag on the controller widget
I’m quite happy with the push+rotate implementation as i got it working without interfering the normal push/release behavior. After pushing, you must start rotating before 2 seconds and the release will be ignored. Easy and it really works!
(@riban, this would be cool to have in the mixer, parameter editor, etc.)
And yes, this should be considered as a bugfix, not a new feature
