I’ve been experimenting with bringing CV and midi controllers into the XMX, specifically on the Granular and Wavetable modules. Everything works as expected but I’ve found an issue that is tricky to visualise:
Some parameters that have a graphic, such as the start of wave and granular window size, plus the XYZ axis of the wavetable, will show the change of CV and Midi dynamically in real time on the display so it’s easy to see what you are doing. That’s all great.
But, the other numeric only, non-graphic parameters, don’t do this. You set a position / number with the encoder which I guess sets the start or centre point of the control. The CV and midi then varies that position as you control it - but there is no way to see what it is changing other than by ear. The numeric stays the same as the originally set value instead of changing up and down as the cv or midi varies it.
I’ve found that it is easy to get lost with the granular module as I can’t see any visible feedback on say the Number of grains, or many other critical controls.
Not sure if there is way around this?
Maybe a midi controller with its own display? I’m using a Faderfox without a display sadly.
No way of seeing what CV is doing though.
yeah, so this is quite a common ‘thing’ for UIs.
the ‘issue’ for UI design is you cannot really update the value w/ modulation realtime , as it makes adjustment of the base value quite difficult… some modern vsts get around this by having thing like modulation animations around the dial etc.
but its still pretty common for parameters to only show base value (as xmx/ssp does)
we don’t have that here, so indeed I go by sound…
basically, set the base value on the parameter then adjust the modulation to get the range you desire.
It can be useful to use the scopes here - esp, to verify things like scale of modulation and also if its bipolar or unipolar.
the cool bit here is on the same screen (as scopes) you can attenuate/offset signals, and so see that change that is occurring.
the issue with your midi controller is ofc, the same here, as they go via cv, but is a slightly different issue. or at least, there is a different solution to it 
so in my plugins I allow for midi learn on parameters directly.
the difference here, is that as its not modulation, the UI parameters will update as you use your midi controller.
(I also have bi-directional midi support - so midi controllers can update their values too when the UI changes)
so once I release my plugins, you will find these much easier to use with your faderfox - as you will get UI feedback.
Thanks again Mark, that does explain things nicely.
One suggestion might be to add a moving dot somewhere above the value (if there is pixel room?) that would show that the value is under CV or midi control as the dot moves from side to side, or up and down, to show the relative movement against the XMX (or SSP) initial value. I like how the Wavetable Osc shows this subtly with the XYZ modulation.
Also encouraging to hear that your modules will actually show parameter movement under midi control.
Even more reason for us all to await your XMX releases with baited breath!
good idea
please incorporate this visual feedback on the SSP too
yes, this is what I was referring too (as modulation animations).
Its not hard from a UI perspective to draw, but a bit tricky to implement as the cv/audio signals are on the dsp core(s), so you can’t just read the value in the UI (core)… so main effort is getting the data required to the ‘right place’, rather than the drawing of the dot 
the other issue is, there isn’t really a ‘mapping’ from cv signal to parameter, they are different things - so whilst from a user perspective they appear to be associated - in code they often don’t - and in some cases, there is not a 1-1 mapping.
that means every module has to have this coded specifically ( * ) , so its kind time consuming (dev) to update every module/parameter to include this animation.
anyway, this is up to Bert for Synthor,
I’ll consider for my plugins, but its quite a lot of effort to retro fit this for 20+ plugins ( ** )
( * ) ok, in my case, Id probably just add an optional parameter to cv mapping layer, to implement as a generic solution.
however, that still means updating every module to that updated framework. so quite a bit of effort.
( ** ) sorry ,if this sounds ‘negative’… but I prefer to give users some background about whats involved, to set expectations.
personally, Ive got tired of dev/support teams just saying “great idea, I’ll add it to the wishlist” … and it just goes into a blackhole, and you’ve no idea if it’ll ever see the light of day.
That’s important information to know. Great to get an understanding of it. Thx.
It’s really easy to come up with dozens of ‘good ideas’ and ask or hope for them to be implemented without any understanding of the technical issues. Also I do think it is important to accept the product for what it is when launched with its advertised features.
It’s a huge bonus if additional features are implemented later so I’m grateful for that. Also it’s another huge bonus if the platform allows users to contribute with their own plugins. So props to Bert for making it like that and to Mark (and others ?) for doing so much work. I wish I had the skills do do some myself.
I get the technical issue now with the moving dot suggestion - but I think most of us wouldn’t be expecting that to be super accurate. Maybe it could be as simple as a literal blinking dot just so you know that the fixed value shown on the screen is now also under cv or midi control. But yeah, I can see it’s a lot of work to add that to every value of every module. At the end of that day it is what it sounds like that counts - so your ears are always the best indicator.