Do mapped MIDI controllers (that is, “learned” ones) bypass earlier MIDI filters in the chain? It seems so, since Scale CC Value is having no effect.
I’m trying to use mod wheel to control vibrato on TAL Noisemaker (“NM”). Sheesh, should be simple; it’s how vintage synths were generally used back in the day. But no, mostly because NM doesn’t support it as it should (as a modulation parameter, that is, one that adds to or subtracts from another with a scale factor). So, I have to map CC1 values from the full range to the equivalent of 0 to whatever gives the max amount of vibrato I’ll want.
But Scale CC Value is having no effect.
I have Scale CC Value first in the chain and NM second. Before plugging in Scale CC Value I learned mod wheel to control LFO amount to pitch. That part works, but the usable range of the mod wheel is in the middle and just a tiny bit of motion. Plugging in Scale CC Value has no effect.
Scale CC Value parameters:
Filter Channel: Any
Parameter (min): 0 [should be 1]
Parameter (max): 127 [should be 1]
Parameter Mode: Include Range
Value Scale: 0.2
Value Offset: -64
Value Mode: Clamp to 0..127
No effect. Any changes to any settings, still no effect.
Great, thanks! But rather than scale and offset (and requiring what to do with out-of-range) I suggest input min → output min and input max → output max. Just two numbers to configure, both in MIDI terms only, no math required for the user, very simple math (done only at config time) for the mapper. It also avoids issues with scale being in tenths only, so not always exact.
LMK if you’d like me to open an issue or comment on the issue if there is one.
On second thought, while providing scaling is great, that solution makes all MIDI filters for CC’s meaningless. That is, we can’t use plugins for CCs. Maybe that’s OK; what would we do other than mapping, scaling, and momentary vs latching? Oh, smoothing. Well, give the idea some thought about revising the learning system to allow MIDI filters, but your proposed solution would meet most use cases.
This is great. I remember that there was chatting about reverse controls (the organ drawbar folks). So one of the two spare controls might be just “flip” and the other certainly “bend” a.k.a. going into log scale?
Also what the draw bar organ folks would certainly comply with is that the next step could be included in a “make these settings default for current engine” together with the learned midi ccs and other stuff.
I must confess that I don’t find so much engines where there is still an issue with poorly scaled parameters. But as an example, you might want to edit the input and output gain of, let’s say “Simulator/Calf Tape Simulator”, who are obviously just stepped gain multiplicators (0, 1, infinity). Don’t know if this issue could be resolved by scaling.
It could fix as well some sfz parameters which cannot be scaled inside the script due to opcode limitations.
As soon as I see a straight line graph, I think it needs some shape… I am not sure if a single curve (linear) or two curves (+log) or three curves (+exp) are sufficient or optimal. Maybe we have a way to “drag” the curve from straight to curved with the user able to draw that curve. It could use some algorithmic constraints to avoid the need for a full key=value map and it could be challenging to implement the adjustment but it is likely to be advantageous. We can think about this. There may be something to learn from an envelope graph widget I wrote some years ago. Or maybe that is of no use in this instance. Linear is a great start and how all CC are currently mapped to whole ranges so it is a great starting point for this. Well done @jofemodo - this has been on my wish list for a long while.
Yep, it’s just a starting point. Now that the mechanism is deployed, it’s quite easy to improve. Let’s test with this and look for the next steps.
BTW, i’m going to add a config option to ease Channel Pressure mapping from the UI. Until now, channel pressure with zynthian was kind of useless, but now we can adjust the range, what make it really interesting. The idea would be to map channel pressure to CC. We have enough CC numbers and users wanting to use channel pressure would be pleased to “lost” one for this
A big issue I have had with channel pressure is that it applies as an absolute modifier. It really wants to act as a relative modifier, e.g. if filter cutoff is set to 50% and you map channel pressure to it, pressure should change cutoff between 50% and the range, e.g. 50%..70%, not suddenly jumping to 0%.
Implementing relative behavior is challenging with an absolute controller at least in current implementation, but now you can set the value range so the lowest value is the base value (50% for instance), so it wont jump to 0%. To totally avoid jumps when playing the first note after loading the state you must ensure the lowest value in the CC range matches the value saved in the state. Simply save the state after setting the range and playing some notes
I understand you want to soft the transition points in a curve defined by a set of points. This has much sense in CC patterns that currently use simple linear interpolation (and should be improved without doubt!).
But in this case, we have 2 points only. There is no graph out of the range and the only defined points are the minimum and maximum values. Of course, we could define more points and in such a case, it would have sense to use something better than linear interpolation, but, is this really useful for the intended functionality (i.e. adjust the range of MIDI CC controllers)?
What i mean is that we already already have logarithmic parameters implemented, so when a parameter is flagged as logarithmic by the engine, it behaves as logarithmic in the UI. If you learn a logarithmic parameter to MIDI CC, you get logarithmic behavior too.
In the other hand, if you are learning a MIDI CC, most of times you would have a knob or fader that you want to rotate/slide to modify the value in a given range you can set. If the parameter is logarithmic, you would get a logarithmic behavior (this is implemented in the zynthian_controller class). If the parameter is linear, you get a linear behavior. Why would you want to modify the response curve of the knob or fader? IMHO, this would make it harder to use.
For channel pressure, it could have more sense (although i’m not sure until having tested), although this would be something you expect to be implemented by the keyboard controller, like velocity curves, etc.
Of course, i could imagine many scenarios and you can always find use cases for everything, but these won’t be common use-cases. Not something we need to implement urgently. I.e. i would put the effort in improving CC pattern interpolation before
