The biggest bottleneck

[brinnandeskepp]

My only gripe with my beloved Prophet rev2 is the unnecessary bottleneck created by low resolution control values between the encoders, digital control layer, and analogue hardware layer (and by extension the current implementation of external NRPN control).

For a synthesiser that positions itself as microtonally capable (which was the main selling point for me personally), it would make sense to either adapt the “stepped semi-tone tuning of the filter feature” to the currently selected global tuning, or to discard it in favour of truly fine grained “one cent” steps.

Curiously, 14 bit MIDI/NRPN (which the synth already uses), would be capable of (pretty much) exactly this. If you multiply the current 164 (filter) value range (100 cents each) by 10 = 16,400. Where the maximum values possible in 14 bit MIDI = 128 x 128 = 16,384. Regular 0-128 step controls fit within 14 bit because at 10x the resolution this would be 12,800.

I think the human ear can only distinguish ~5 cent steps, so it doesn’t need to be that high, but 12 tone equal temperament semitones are at best a hinderance to my compositional praxis.

I believe that my Prophet’s microtonal little brother-from-another-mother, the Korg Monologue, uses higher resolution internal control values, and consequently feels much smoother and “analogue” to operate than the Prophet with its current firmware.

Anybody else feel limited by the 8 bit control layer on the Prophet rev2? I understand that some people prefer (or excuse) 8 bit control because you want to tune your filters in semitone steps. This is why I think that high resolution control should be a global feature you can enable or disable. This would also allow you to send 14-bit NRPN messages as control. Currently, even though the instrument accepts NRPN messages, it only accepts an 8 bit value range.

Thoughts?

[AlainHubert]

I agree. Wholeheartedly.
In 2018, we shouldn't be hostage to 8 bit (or so) digital resolution of limited (and very expensive at the time) technology of the early eighties. Especially not when a 16 bit ADC are readily available very inexpensively and memory size is absolutely not an issue anymore.

[maxter]

+1 here.

This issue that has been brought up earlier, and someone mentioned that the internal resolution of controllers is actually higher, in some cases, than what the Rev2 sends and receives via midi, i e the midi is unnecessarily quantized. The mod wheel for instance, which has higher resolution than 128, so if it's assigned to the filter it can make smooth filter sweeps, but if one records this on a midi sequencer and plays it back it is not smooth, because of quantization which then introduces filter stepping. This would seem quite disabling to many who'd want full midi editing capabilities of their live takes for recording purposes, or who just want to use an external 14-bit midi controller for controlling the filter.

Pitch Bend is already up to speed with full 14-bit resolution, so why not expand the functionality of CC#1 as well? And perhaps a dedicated 14-bit control resolution for the filter? I don't think they'd have to add 14-bit resolution to ALL controls, probably just the filter.

Other than that, I don't see many shortcomings needed to be addressed on the Rev2, other than the usual bug-fixing. Better filter control is THE big one left, imo.

I hope I'm not derailing too much here, just wanted to add some thoughts.

[Djinn]

Iv said it before in other thread but il say it again
Yes yes yes to 14bit higher resolution controls
This is my #1 request

Pleeeaaassse

[brinnandeskepp]

external 14-bit midi controller for controlling the filter.

The insane thing here is that the filter is ALREADY using a higher resolution NRPN control message to accomodate 164 steps instead of 128, because the steps are tuned to semitones. They could take this same implementation but increase the resolution tenfold on all controls and the instrument would be so much more playable and sonically delicious.

It's a bit like having a sports car with not enough gears in the gear box. It could go really fast... However in this case it's just a matter of implementing a better firmware. Wouldn't even be that hard.

[AlainHubert]

I'm afraid that, in current Sequential machines, the hardware that reads potentiometers is designed that way (low resolution), even though the software has a lot more resolution internally.

I think it would be time to update the MIDI specification to reflect modern times, with a standard 16 bit resolution for everything (without the need for that NRPN 14 bit crap), and faster speed data transfer (useful for large sysex dumps). It could be called simply MIDI 16 and be backward compatible with the current one.

[Razmo]

As I wrote in another thread about this, I'd for one would NOT want the NRPN's to change as they are currently adapted precisely to the SysEx (and internal) resolution of 8bits max... it would completely fuck up the SysEx structure of any editor out there, if this was changed...

Noone by the way, knows what the resolution of the knobs are at all anyway... they are probably multiplexed into an MCU ADC, and those are rarely above 10 bits, and would need to be at least 14bits to fit the NRPN fully, plus the fact that such controls would probably be wobbly as hell as even the slightest key-hit might change the physical controllers values a tiny bit... I've seen even 8bit knobs do this "flickering" between two adjacent values because of this. I'm not sure if this can be fixed with hardware capacitors or something though...

I do not see how you would change the current internal resolution without a complete rewrite of the memory structure... I understand why some of you might want this, but I really do not think this will see the light of day... maybe in SCI future synths... but I doubt it will happen in the REV2.

[brinnandeskepp]

I think it would be time to update the MIDI specification to reflect modern times, with a standard 16 bit resolution for everything (without the need for that NRPN 14 bit crap), and faster speed data transfer (useful for large sysex dumps). It could be called simply MIDI 16 and be backward compatible with the current one.

MIDI is handy because it's compatible with everything, new and old. NRPN looks like a bit of a hack to get the best of both worlds (new features, backwards compatible). However, people who are developing cutting edge technology tend to use OSC as a replacement for MIDI, which fixes all of its shortcomings. However this is not backwards compatible. No need to reinvent MIDI. We already have better replacements, and 14-bit NRPN MIDI already does what we need in this case (and is already in the box in question).

[brinnandeskepp]

As I wrote in another thread about this, I'd for one would NOT want the NRPN's to change as they are currently adapted precisely to the SysEx (and internal) resolution of 8bits max... it would completely fuck up the SysEx structure of any editor out there, if this was changed...

Noone by the way, knows what the resolution of the knobs are at all anyway... they are probably multiplexed into an MCU ADC, and those are rarely above 10 bits, and would need to be at least 14bits to fit the NRPN fully, plus the fact that such controls would probably be wobbly as hell as even the slightest key-hit might change the physical controllers values a tiny bit... I've seen even 8bit knobs do this "flickering" between two adjacent values because of this. I'm not sure if this can be fixed with hardware capacitors or something though...

I do not see how you would change the current internal resolution without a complete rewrite of the memory structure... I understand why some of you might want this, but I really do not think this will see the light of day... maybe in SCI future synths... but I doubt it will happen in the REV2.

• I really think that the sound and playability of the instrument is more important than any software editors currently out there.
• Somebody knows or can test what the resolution is (Dave or the other developers).
• 10 bits is perfect. Possible values = 0-1023. This would allow for filter 'steps' of 16 cents instead of semi-tones.
• Not an issue on my cheap Korg synth, which uses high res internal control (10-bit, 0-1023). Even if flickering was a side effect of high res controls I would much rather live with that than a handicapped instrument that can't sound up to its full potential.

EDIT: Realized that 0-127 is 7 bit, not 8.

[Razmo]

As I wrote in another thread about this, I'd for one would NOT want the NRPN's to change as they are currently adapted precisely to the SysEx (and internal) resolution of 8bits max... it would completely fuck up the SysEx structure of any editor out there, if this was changed...

Noone by the way, knows what the resolution of the knobs are at all anyway... they are probably multiplexed into an MCU ADC, and those are rarely above 10 bits, and would need to be at least 14bits to fit the NRPN fully, plus the fact that such controls would probably be wobbly as hell as even the slightest key-hit might change the physical controllers values a tiny bit... I've seen even 8bit knobs do this "flickering" between two adjacent values because of this. I'm not sure if this can be fixed with hardware capacitors or something though...

I do not see how you would change the current internal resolution without a complete rewrite of the memory structure... I understand why some of you might want this, but I really do not think this will see the light of day... maybe in SCI future synths... but I doubt it will happen in the REV2.

• I really think that the sound and playability of the instrument is more important than any software editors currently out there.
• Somebody knows or can test what the resolution is (Dave or the other developers).
• 10 bits is perfect. Possible values = 0-1023. This would allow for filter 'steps' of 16 cents instead of semi-tones.
• Not an issue on my cheap Korg synth, which uses high res internal control (10-bit, 0-1023). Even if flickering was a side effect of high res controls I would much rather live with that than a handicapped instrument that can't sound up to its full potential.

EDIT: Realized that 0-127 is 7 bit, not 8.

Fair points, but you and I are clearly using the synth very differently... the point is that if anything is changed to a higher resolution, I'd want it to be something you can switch in the global settings... the SysEx should not be changed for a higher resolution because then everything made thus far would not be compatible... this also makes it possible to store a full resolution of a parameter and then recall it later... everything stored would be quantized to 8bits...

And that is probably the problem with this... the knobs was made to edit the stored values, not for being controller knobs like the wheel or modwheel etc... all the parameters are "starting points" covering the full range, but at a lower resolution... unfortunately that memory resolution is now hardwired to 8bits and have been that on all DSI/SCI synths until now (and is on MANY other synths by the way).

I'd welcome a global setting that would allow for users to enable 14bit resolution NRPNs both in sending and receiving knob parameters on REV2, but I'd really hate if they changed the SysEx memory 8bit structure that are there now cause it would destroy backwards compatibility unless they made live conversions when loading older SysEx formats then.

But I shiver by the thoughts of what such a memory change would require in working hours for SCI... They hardly do any of the many feature requests we see in the feature request thread in here, so I'm pretty certain none of it will happen...

[maxter]

As I wrote in another thread about this, I'd for one would NOT want the NRPN's to change as they are currently adapted precisely to the SysEx (and internal) resolution of 8bits max... it would completely fuck up the SysEx structure of any editor out there, if this was changed...

Noone by the way, knows what the resolution of the knobs are at all anyway... they are probably multiplexed into an MCU ADC, and those are rarely above 10 bits, and would need to be at least 14bits to fit the NRPN fully, plus the fact that such controls would probably be wobbly as hell as even the slightest key-hit might change the physical controllers values a tiny bit... I've seen even 8bit knobs do this "flickering" between two adjacent values because of this. I'm not sure if this can be fixed with hardware capacitors or something though...

I do not see how you would change the current internal resolution without a complete rewrite of the memory structure... I understand why some of you might want this, but I really do not think this will see the light of day... maybe in SCI future synths... but I doubt it will happen in the REV2.

• I really think that the sound and playability of the instrument is more important than any software editors currently out there.
• Somebody knows or can test what the resolution is (Dave or the other developers).
• 10 bits is perfect. Possible values = 0-1023. This would allow for filter 'steps' of 16 cents instead of semi-tones.
• Not an issue on my cheap Korg synth, which uses high res internal control (10-bit, 0-1023). Even if flickering was a side effect of high res controls I would much rather live with that than a handicapped instrument that can't sound up to its full potential.

EDIT: Realized that 0-127 is 7 bit, not 8.

Fair points, but you and I are clearly using the synth very differently... the point is that if anything is changed to a higher resolution, I'd want it to be something you can switch in the global settings... the SysEx should not be changed for a higher resolution because then everything made thus far would not be compatible... this also makes it possible to store a full resolution of a parameter and then recall it later... everything stored would be quantized to 8bits...

And that is probably the problem with this... the knobs was made to edit the stored values, not for being controller knobs like the wheel or modwheel etc... all the parameters are "starting points" covering the full range, but at a lower resolution... unfortunately that memory resolution is now hardwired to 8bits and have been that on all DSI/SCI synths until now (and is on MANY other synths by the way).

I'd welcome a global setting that would allow for users to enable 14bit resolution NRPNs both in sending and receiving knob parameters on REV2, but I'd really hate if they changed the SysEx memory 8bit structure that are there now cause it would destroy backwards compatibility unless they made live conversions when loading older SysEx formats then.

But I shiver by the thoughts of what such a memory change would require in working hours for SCI... They hardly do any of the many feature requests we see in the feature request thread in here, so I'm pretty certain none of it will happen...

Well, brinnandeskepp originally wrote that he also thought it should be a global on/off parameter. And he has mainly just been talking about the filter only. That's ONE parameter. To me personally, it's the ONLY parameter that could really need to be upped to a higher resolution. Needn't be too much screwing with the sysex for that, or the editors, or to implement it, imo. Worst case scenario, add an extra parameter value at the end, backwards compatible so that it fine-tunes the filter if it's there and if it's not it just gets assigned a 0, so old patches wouldn't change either (kind of like the second CC for mod wheel or 7-bit vs 14-bit pitch bend). But this is not a big concern for me.

The MOD WHEEL, on the other hand, should really be 14-bit though, like the pitch bend (I mean really, why not?), and as it's not a parameter, it wouldn't screw with the sysex at all. I see no point in NOT making it 14-bit, adding it's second CC#33, and why not for some others like breath control and expression (#34 & #43) while you're at it. That would greatly increase the external midi controlling options in a heartbeat, allowing for smooth filter sweeps at least.

Since you can assign pitch bend, which is 14-bit, as a modulation source, I'd be interested to know if that resolution is then quantized in any way when assigned to a mod destination. I've only used it this way for an extended pitch bend range, assigned to osc pitch, as I use an R2M midi controller, but I haven't noticed any quantization in that case (I'll have to try filter as a destination I guess). But I suspect it wouldn't be a problem to extend these other controllers to 14-bit resolution as well (or at least something higher than 7-). I feel somewhat like living in the past with 7-bit resolution in this case especially, I could live without higher resolution for the filter parameter if I could just control it via higher resolution external midi. I think one should be a able to program smooth filter sweeps via sequencer or DAW in 2018.

[brinnandeskepp]

Fair points, but you and I are clearly using the synth very differently... the point is that if anything is changed to a higher resolution, I'd want it to be something you can switch in the global settings... the SysEx should not be changed for a higher resolution because then everything made thus far would not be compatible... this also makes it possible to store a full resolution of a parameter and then recall it later... everything stored would be quantized to 8bits...

And that is probably the problem with this... the knobs was made to edit the stored values, not for being controller knobs like the wheel or modwheel etc... all the parameters are "starting points" covering the full range, but at a lower resolution... unfortunately that memory resolution is now hardwired to 8bits and have been that on all DSI/SCI synths until now (and is on MANY other synths by the way).

I'd welcome a global setting that would allow for users to enable 14bit resolution NRPNs both in sending and receiving knob parameters on REV2, but I'd really hate if they changed the SysEx memory 8bit structure that are there now cause it would destroy backwards compatibility unless they made live conversions when loading older SysEx formats then.

But I shiver by the thoughts of what such a memory change would require in working hours for SCI... They hardly do any of the many feature requests we see in the feature request thread in here, so I'm pretty certain none of it will happen...

You'll see that in the original post I said that it should be a global setting, high res or not, because I remembered your points having been brought up before.

Also, I'm not so sure about the memory issue you bring up. I don't think it's necessary to save these higher resolution parameter values. They just need to be available on the front panel when you play, as well as via NRPN from external devices or a computer.

It's dawning on me that in the old school way of playing, modulation is done with the mod wheel and perhaps via pedals, not by using the pots on the front panel. But the way I work I don't even have a keyboard. I use sequencers that feed streams of notes in as I modulate the timbre and tuning of the sound with the rotaries. A lot of the effect that I'm looking for is the smooth transition between states of overtone structure or timbre. This is especially important in 'vertical music' or drone music, where you're slowly morphing the texture of the sound only, while the notes remain more or less static. Any stepped/quantized/ladder type effect caused by low res digital control in this situation sounds cheap in this context.

[brinnandeskepp]

Well, brinnandeskepp originally wrote that he also thought it should be a global on/off parameter. And he has mainly just been talking about the filter only. That's ONE parameter. To me personally, it's the ONLY parameter that could really need to be upped to a higher resolution. Needn't be too much screwing with the sysex for that, or the editors, or to implement it, imo. Worst case scenario, add an extra parameter value at the end, backwards compatible so that it fine-tunes the filter if it's there and if it's not it just gets assigned a 0, so old patches wouldn't change either (kind of like the second CC for mod wheel or 7-bit vs 14-bit pitch bend). But this is not a big concern for me.

The MOD WHEEL, on the other hand, should really be 14-bit though, like the pitch bend (I mean really, why not?), and as it's not a parameter, it wouldn't screw with the sysex at all. I see no point in NOT making it 14-bit, adding it's second CC#33, and why not for some others like breath control and expression (#34 & #43) while you're at it. That would greatly increase the external midi controlling options in a heartbeat, allowing for smooth filter sweeps at least.

Since you can assign pitch bend, which is 14-bit, as a modulation source, I'd be interested to know if that resolution is then quantized in any way when assigned to a mod destination. I've only used it this way for an extended pitch bend range, assigned to osc pitch, as I use an R2M midi controller, but I haven't noticed any quantization in that case (I'll have to try filter as a destination I guess). But I suspect it wouldn't be a problem to extend these other controllers to 14-bit resolution as well (or at least something higher than 7-). I feel somewhat like living in the past with 7-bit resolution in this case especially, I could live without higher resolution for the filter parameter if I could just control it via higher resolution external midi. I think one should be a able to program smooth filter sweeps via sequencer or DAW in 2018.

I really think all controls should be at least 10-bit. Not just the filter. Some are more important, for sure, but I would really love to have a smooth response an all the controls for the filter (resonance, velocity, env, key). FX too. Anything that changes the tuning, tonal or harmonic structure of the sound.

Is the mod wheel currently just 7-bit?

EDIT: I just tried sending a small amount of mod wheel to the filter cutoff and it sounds like it's possible to make smaller changes to the filter than the 7 bit steps available on the main control or via MIDI. I'm assuming that LFOs and MODs are added or subtracted from the main values. Not sure what the internal resolution might be here, but it seems higher.

[maxter]

Well, brinnandeskepp originally wrote that he also thought it should be a global on/off parameter. And he has mainly just been talking about the filter only. That's ONE parameter. To me personally, it's the ONLY parameter that could really need to be upped to a higher resolution. Needn't be too much screwing with the sysex for that, or the editors, or to implement it, imo. Worst case scenario, add an extra parameter value at the end, backwards compatible so that it fine-tunes the filter if it's there and if it's not it just gets assigned a 0, so old patches wouldn't change either (kind of like the second CC for mod wheel or 7-bit vs 14-bit pitch bend). But this is not a big concern for me.

The MOD WHEEL, on the other hand, should really be 14-bit though, like the pitch bend (I mean really, why not?), and as it's not a parameter, it wouldn't screw with the sysex at all. I see no point in NOT making it 14-bit, adding it's second CC#33, and why not for some others like breath control and expression (#34 & #43) while you're at it. That would greatly increase the external midi controlling options in a heartbeat, allowing for smooth filter sweeps at least.

Since you can assign pitch bend, which is 14-bit, as a modulation source, I'd be interested to know if that resolution is then quantized in any way when assigned to a mod destination. I've only used it this way for an extended pitch bend range, assigned to osc pitch, as I use an R2M midi controller, but I haven't noticed any quantization in that case (I'll have to try filter as a destination I guess). But I suspect it wouldn't be a problem to extend these other controllers to 14-bit resolution as well (or at least something higher than 7-). I feel somewhat like living in the past with 7-bit resolution in this case especially, I could live without higher resolution for the filter parameter if I could just control it via higher resolution external midi. I think one should be a able to program smooth filter sweeps via sequencer or DAW in 2018.

I really think all controls should be at least 10-bit. Not just the filter. Some are more important, for sure, but I would really love to have a smooth response an all the controls for the filter (resonance, velocity, env, key). FX too. Anything that changes the tuning, tonal or harmonic structure of the sound.

Is the mod wheel currently just 7-bit?

EDIT: I just tried sending a small amount of mod wheel to the filter cutoff and it sounds like it's possible to make smaller changes to the filter than the 7 bit steps available on the main control or via MIDI. I'm assuming that LFOs and MODs are added or subtracted from the main values. Not sure what the internal resolution might be here, but it seems higher.

I would have no need to save a higher resolution value in the sysex either, I just suspected that those using the Rev2 for the purposes you’re using it might. But if not it seems there would be no need to change the sysex at all, so nothing to worry about there then.

Sending a small amount of mod wheel... Do you mean a low modulation amount in the mod matrix, from mod wheel to filter cutoff? If so, yes, the 128-bit range is of course converted/extrapolated to do smooth filter sweeps, but in a narrow range. What I originally meant is that the cc#1 via midi in (and midi out of course) is limited to 7-bit, while it was claimed in a previous thread by someone that when using the actual mod wheel on the Rev2 the internal resolution is higher (from mod wheel directly to a destination), which would mean that when using it live it’d be possible to do broader smooth filter sweeps than when midi-recording the same mod wheel motions and playing it back, because then it would be 7-bit, first out and then back in.

My actual point for wanting higher resolution for external midi controls, in this case 14-bit would be the most logical because then you could still use it with 7-bit if your controller only supports that (with no need for a global on/off for these), would be that you could use these controllers (the various cc ones that are available as external mod sources in the matrix) assigned to different parameters via the matrix for making really smooth and fine adjustments to the parameters that have a lower resolution directly via the knobs. You could reach those spots ”in between”, without actually messing with knob resolution, sysex or anything else, and tweak everything smoothly without stepping. As most of these (cc#11 being the exception) are available as ”locked in” modulation sources in the matrix, they wouldn’t take up slot 1-8 (unless you’d want to control more than one parameter with each control).

[Razmo]

The bottleneck is actually the MIDI specs because internally, the REV2 works at much higher resolutions... If you route modwheel or aftertouch etc. Directly to a parameter, then that parameter will be controlled at the max resolution for that parameter..  The problem is when you either use MIDI echo with local off, or send back MIDI from a sequencer, because all CCs are only 7 bit wide... The industry has made it standard to only use CC#1 for modwheel, so the extra depth possible with CC#33 is not used... And if a keyboard did, then that extra CC#33 would no doubt confuse other synths connected to it since many synths would use CC#33 for other parameters.

I think I suggested in the other thread, that if a full 14bit set of MIDI messages should be made, it should be done by a global switch that enable sending a whole new set of NRPNs (and recieving them) so that the current NRPNs will be left unaltered for backward compatibility.

I fully understand why people want this, and I agree with it, as long as it does not screw up what is already there

[maxter]

Good points, I agree.

brinnandeskepp, what I mentioned about the ”locked in” modulation sources could actually serve as a temporary work-around for your problem, if you’d get a cheap small programmable midi controller. Just assign those sources to your preferred destinations, with the actual benefit of having the ranges controllable via the amount, and as you noted with smaller amounts smoother transition. Not the optimal solution, but it works, and since noone knows when or if these issues will be addressed at all... Some controllers have rotary encoders on which the ”speed” (how many steps a full knob-turn equals) is controllable, which allows for REALLY fine/slow control of midi messages.

[OneLittleFonzie]

Using NRPNs is very nice but it is not possible to change the implementation anymore (backwards compatibility). DSI could consider using the MSB+LSB midi CC like Moog does (at least on my Sub Phatty).

[OneLittleFonzie]

Using NRPNs is very nice but it is not possible to change the implementation anymore (backwards compatibility). DSI could consider using the MSB+LSB midi CC like Moog does (at least on my Sub Phatty).

They've already used the LSB CCs. Never mind!

[Razmo]

Using NRPNs is very nice but it is not possible to change the implementation anymore (backwards compatibility). DSI could consider using the MSB+LSB midi CC like Moog does (at least on my Sub Phatty).

Yes... they could actually use NRPNs because you have 16384 of these available, and they have definitely not used up all of those yet... they just need to use some of the numbers not already in use, and then make a simple switch in the global settings for users to decide if the knobs should send these instead of the other ones... people just have to realise that if they do use these new NRPNs, that when the tweaks are stored into memory, it will be truncated to the 8bit versions.... that means that if a program is edited when in this special mode, then parameters that is very sensitive to miniscule adjustment will probably not sound exactly the same when recalled from memory again since they were truncated to 8bit when stored.

There seems to be all sorts of small things to take into account if this was made... so I really do not think it will ever happen as i said earlier... SCI has included how many new features from the comprehensive "Feature Requests" thread in here!? ... it's next to absolutely none, so a change this big is very VERY unlikely... the "Feature Requests" thread is more or less pointless when nothing is added... i think I've seen about ONE request put in, and that's about it... Arp Beat Sync if I recall right...

[brinnandeskepp]

people just have to realise that if they do use these new NRPNs, that when the tweaks are stored into memory, it will be truncated to the 8bit versions.... that means that if a program is edited when in this special mode, then parameters that is very sensitive to miniscule adjustment will probably not sound exactly the same when recalled from memory again since they were truncated to 8bit when stored.

Totally fine! It's the hands-on use of the synth that is the matter here, not the exact state of a saved patch.

I think this feature would be more one of the more marketable ones. More than most of the minor feature requests. Perhaps the smartest move would be MPE support. I'm fairly certain that at some point this is coming (at least to new DSI instruments). LinnStrument plus MPE Sequential/DSI gear makes so much sense. But I think if the move is towards playability and performance, then getting rid of this unfortunate bottle neck would also make a lot of sense. Showing off a "high resolution control mode" in a YouTube video would impress a lot of people who'd never through about that before, and would evolve the instrument to the next level.