Optimizing Encoder Behavior in MBSID Firmware

[TK.]

I got some complains about the rotary encoder behavior in the MBSID firmware lately, and think that this can be changed & optimized in the firmware easily.

 

Different variants are possible - let's try to find the best suitable solution together!

Who would be interested to test some variants?

 

Best Regards, Thorsten.

 

[jrp]

Hello Thorsten,

 

Thats very nice! I would be glad to do some testing! SID is awesome!

[3090]

Ciao Thorsten,

 

I am  interested in this variant.

 

The suggestion i can give to improve the behave of  MBSID are the followings:

 

-Values of 127 instead 255

-Fast Response turning the knobs: to easily edit and cover  the  whole range of value in one turn of the encoder: 0 - 127

 

 

From my experience, i feel good using the "Relative  Mode" and the "Jump Mode" in the DSI Poly Evolver.

 

 

For explain i paste from the Poly Evolver Keyboard Manual Addendum:

 

The latest version of the Poly Evolver Keyboard operating system adds an item, PotMode, to the Global parameters that is not documented in the manual. (See page 18 of the Operation Manual for more information about the Global param- eters.)

PotMode: Relative (default), Passthru, Jump – On the latest version of the Poly Evolver Keyboard, many of the 78 front panel controls are potentiometers or “pots.†There are three pot modes to determine how the synth reacts when the related parameters are edited.

When set to Relative, changes are relative to the stored setting. In Relative mode, the full value range is not available until either the minimum or maximum value and the respective lower or upper limit of the pot’s travel is reached.

For example, the Resonance parameter has a value range of 0 to 127. Let’s say the physical position of the Resonance pot is the equivalent of a value of 100. If you switch to a program that has a stored Resonance setting of 63 and turn the pot all the way up, it will only go to 90. To get to the maximum value of 127, you first have to turn down until the value is at the other extreme and the pot

is at the limit of its travel (in this case, 0 and fully counter-clockwise, respec- tively).

In Passthru mode, turning the pot has no effect until after the edited value equals the preset value (that is, until the edited value “passes through†the stored value).

Jump mode uses an absolute value based upon the position of the pot when edited: turn a pot and the value jumps immediately from the stored value to the edited value.When set to Relative, changes are relative to the stored setting. In Relative mode, the full value range is not available until either the minimum or maximum value and the respective lower or upper limit of the pot’s travel is reached.

 

 

i hope to be helpful

 

Best Regards from Italy

 

3090

Edited May 27, 2014 by 3090

[TK.]

@3090: you are mixing pots with rotary encoders - the modes that you are explaining are already supported by typical MIDIbox based controllers since more than 10 years; they are well known to me.

 

But pots are not supported by MIDIbox SID. Please let's focus to improve the existing hardware!

 

It would be helpful, if only people join the discussion who already own a MIDIbox SID, know the current behaviour, and help to evaluate various software options.

Otherwise I fear that I'm more busy with explaining unnecessary details (the "what" and "why") instead of doing the actual work. :-/

Please also note that I'm not planning to develop a new hardware.

 

 

@jrp: please find a prebuilt binary with the new "DEFAULT_TESTMODE_ENC_SPEED" under:

http://www.ucapps.de/mios/midibox_sid_v2_044_enctest1.zip

 

It's enabled by default (and has to be disabled to get MBSID "productive" again).

 

All encoders are configured with the same speed mode which doesn't vary automatically depending on the value range (as they are normally doing).

You can change the speed settings by pressing the SHIFT button + GP button 1 and 2 (to toggle modes and speeds)

 

Please try to find best matching mode/speed values for following value ranges:

- CutOff (12bit value range)

- Resonance (8bit value range)

- Depth (bidir 7bit value range)

- Sustain (4bit value range)

 

I would like to know two sets: one set of mode/speed values for "normal behaviour", and another one which should be used later to slow down the incrementer (when the SHIFT button is pressed).

 

Best Regards, Thorsten.

[3090]

Dear Thorsten,
 
I own a MB6582, that i bought, not build.
I know the current behave and it is improvable, as now is not well usable.
 
I wrote about the pot behave like example.
 
Best Regards
 
3090

[TK.]

In this case I would propose that you try the testmode in the new firmware.

Help to find better matching values and give feedback about your thoughts.

 

With good settings the value range shouldn't matter, it should always feel "good" and "usable".

 

For encoders I don't really see an advantage if I would try to translate a relative or passthrough (resp. "snap" or "soft-takeover") mode.

This wouldn't solve the problem that we actually only need better speed parameters.

 

Best Regards, Thorsten.

[sonofprent]

I don't know if you caught my post on this or would consider it an improvement but how do you feel about removing the 'non destructive' external CC thing- ie you can save changes after externally tweaking CC's. Thanks for looking at the encoder speed btw- I think the new approach (shift for slower) will be much more useable.

[TK.]

Yes, I read it, and think it makes sense to change the behaviour, so that incoming CC values will also be stored in the edit buffer.

Only value changes caused by ModWheel, Velocity, Aftertouch, Knobs and Wavetable shouldn't be stored.

It will be an option which is enabled by default (because I guess that most people will like it), and could be disabled in setup_*.asm (for the minority who doesn't like it).

 

In addition, I will add a "CC dump request" which will allow to synchronize a MBNG with the current patch CCs.

 

Behaviour of SHIFT button will be configurable as well, and switched back to the original "slow" switching like in pre-42 releases.

 

Back to topic: help to find best matching speed parameters, please! ;-)

 

Best Regards, Thorsten.

[3090]

i will follow your suggestion to try the testmode in the new firmaware,

and will give feedback about it.

 

:smile:

 

Best Regards

 

3090

[jrp]

Hello,

 

Thanks for putting this up!

 

The testmode works perfectly but i am missing sound from my sid after uploading. Is that intended? I had to test the speed modes relaying on display rather than sound feedback. This makes me a little unsure.

 

Just for my understanding: The firmware will read how fast i turn the encoder and act accordingly, so there will still be full resolution, no audible steps, right?

The firmware seems to switch between two speeds as soon as a certain turning-speed-threshold is reached. Is this correct?

 

 

Here are my findings with 20 ppt detented encoders from unknown manufactor (i assume these values will differ if other encoders are used):

 

First of all: I am very happy!!!

 

For Fast mode:

 

- Cutoff:

Speed 7 - it still takes 2 full turns to cycle through the whole range. So it could even be a bit faster. But since i couldn´t hear anything i don´t know if it will feel smoth. But i know it is actually handy to dial through the whole range with the twist of a finger sometimes.

If i consider an additional analog pot for tweaking (from the knob function or from outside via NRPN) than 7 is propably perfect for normal editing.

 

- Resonance:

Speed 4 - 360 deg turn. Could be a little bit faster, but seems best value for me.

Speed 5 - a bit faster feel than a analog pot would give. That makes it too fast definitly.

 

- Depth:

Is actually the same range as resonance, right?

I would use speed 4. Maybe 3 is better since it is split around 0 so it will normally require less fast tweaking. Really would like to hear how it reacts.

 

4bit Sustain:

Speed 1 is nice, perfect would be inbetween 1 and 2. Actually normal is also fine for this :)

 

 

Slow Mode:

 

I personally propably would not use it as the ecoders already sense the acceleration. Turning the pot slowly works well.

Bisides that, for all the 10bit, 8bit and 4bit parameters Slow 0 or Normal (is it the same?) seemed useful.

 

 

Is there any chance these values will be adjustable by the user in a final release?

Edited May 27, 2014 by jrp

[jrp]

Sorry, i try to stay on topic, but this is just too exciting...:

 

 

In addition, I will add a "CC dump request" which will allow to synchronize a MBNG with the current patch CCs.

 

This sounds very interesting. So it could bring ledrings to our sid? Among other things... Analog pots in snap mode maybe...

But isn´t a CC always a 7bit value?

I feel especially cutoff modulation will suffer from lower resolution. The range of sound-frequency is simply enormous.

In the sysex implemention i read this: Is it not the same? I was scratching my head about the possiblilities for a CS in combination with MB_NG

01/b) F0 00 00 7E 4B <device-number> 01 08 00 00 F7  Request the current patch edit buffer (direct read from RAM)

 

[TK.]

Yes, in conjunction with MBNG you could also add LED rings if you still prefer rotary encoders. Or you could use pots and/or (motor)faders.

 

Control via SysEx is possible as well of course, but the setup is more difficult, and sending the complete patch takes more time.

If you are only interested on a high-res CutOff, then send it as a NRPN parameter, and set the appr. LED ring via the CC dump.

 

Best Regards, Thorsten.

[sonofprent]

Yes, I read it, and think it makes sense to change the behaviour, so that incoming CC values will also be stored in the edit buffer.

Only value changes caused by ModWheel, Velocity, Aftertouch, Knobs and Wavetable shouldn't be stored.

It will be an option which is enabled by default (because I guess that most people will like it), and could be disabled in setup_*.asm (for the minority who doesn't like it).

 

In addition, I will add a "CC dump request" which will allow to synchronize a MBNG with the current patch CCs.

 

Behaviour of SHIFT button will be configurable as well, and switched back to the original "slow" switching like in pre-42 releases.

 

Back to topic: help to find best matching speed parameters, please! ;-)

 

Best Regards, Thorsten.

 

 

That's fantastic, thanks muchly Thorsten! I'll look into doing some speed tests once back with the SID next week- in theory anything that does the full range in a single turn is what I'd like, though others who have tested may find something that works better, in which case I will bow to their superior judgement!

 

Thanks again for this, great stuff indeed! 

[jrp]

The problem i see is that with different encoders the responce will be different. Combining SID with MB_NG sounds very exciting indeed.

 

About my SID not outputting sound with the new firmware: I simply forgot that my ensamble settings were overwritten by the upload (for now i have only one bankstick - i´m prototyping analog enhancements at the moment). I was simply sending on the wrong channel ;-)

[jrp]

I just played with this a bit more. My setup is including CEM3379 filters.

Sweep could even be a bit faster than speed 7 but it´s nice like this already. Unfortunately tweaking the knob does not produce a smoth filter sweep. It sounds more like a glissando (=stepped).

[TK.]

I agree that speed 8 would be nice, on the other hand - as you already noticed - this will lead into more stepiness.

 

In order to compensate this effect for CutOff, you could activate the FIP option in the FIL menu, which smooths the waveform.

 

 

New firmware available where encoder behaviour should be much better:

http://www.ucapps.de/mios/midibox_sid_v2_044_enctest2.zip

 

• changed encoder speed modes depending on resolution
• encoders are fast by default, and SHIFT button slows down encoder speed
• speed of the "menu" encoder now also varied depending on the resolution.
  Especially sammichSID users will like this change

Please try!

 

Best Regards, Thorsten.

[jrp]

i could only do a quick test right now and i can say cutoff and depth work much better now! This is really cool! Could still be a little faster for very fast wide speeps, but on the other hand that would be best done by a pot anyhow... so i think your efford on this toppic was a great success.

Is there a way for the user to configure the reponces further within the firmware to adapt for different encoders or is this simply to difficult?

 

I have the impression that envelope2 is messed up/not working on some of my patches, but i assume this is due to some error on my side again. These patches had been made with a modded firmware where i had dec 1 and dec 2 flipped in the menu for conventional ADSR responce.

Unfortunately i´ll propably not have any time over the weekend for further testing. But for now, it feels really good tweaking the knobs. Envelope is working when setting up a new patch.

 

Regarding envelopes (please just say to complex - i don´t want to steal your time - and i wouldn´t want to start a new thread asking for stuff): I have been searching the code with no success for a way to double the envelope1 depth within the modmatrix. Right now i assign env1 to source 1 and 2, using 1+2 opperation like described in the manual, to get a full-range cv sweep to my vcas. So to add more amplitude modulation (eg multiply env with velocity or a lfo) an additional modulation path has to be used.

Also i was trying desperate to change modulation target osc pitch 1,2,3 to ext 7,8,Q simply couse i use these more and hate not using half the cool modmatrix.

Not important, it works nice this way, but i just can´t resist trying to tailor your application to my setup as much as possible. Call it an obsession ;-)

No idea if these are easy tweaks or require larger code rewrite. If i get a hint how to figure it out i would be glad to write a easy to follow step by step guide for the wiki. I see these things will make the application incompatible to existing patches and are only for a user who can live with that.

[TK.]

I would like to get some more feedback from other users before release to ensure that most people are satisfied with the changes - resp. are there users who don't like the change?

 

You could vary the speed for different encoders in CS_MENU_EncSpeedSet - the part which sets the speed depending on the range is clearly separated and therefore easy to change for your needs.

I'm not planning to provide this as a generic option for all people, because it would increase the complexity for adaptions (e.g. if somebody wants to add more encoders, he would have to do changes at one additional place). And streamlining the encoder configuration to simplify changes would be a huge task at my side.

Do other users have the same problem like jrp, that rotary encoders need different speed configurations although they control the same range?

 

This is the wrong topic to reply your additional questions - here we talk about encoder behavior optimizations...

I would need some time to understand the firmware that I programmed many years ago anyhow to give you sufficient answers... ;-))

 

Best Regards, Thorsten.

[jrp]

We shoud stay on topic, you are right.

About different speeds for controllers controlling the same range - this is not really necessary. But it could come in handy to really tweak the responce of the CS - i cannot really tell by now.

I am also really interested how other users feel about this topic, and what types of encoders they are using. I was searching the forum a lot before because i thought i simply had bought the wrong encoders.

 

Thanks for pointing me to the right direction. I can very much understand your point not providing this as a general configuration option. I find it also very positive if some hints are given where to look instead. Might be a lot of trial and error for someone like me, but it gives the interested a very little gasp on how a sourcecode like this is functioning.

In CS_Menu.inc i found this, i figure this is the place where the responce could be adapted for different types of encoders:

 

CS_MENU_EncSpeedSet_ModVal_GT1F
    ;; max value > 0x1f: set fast speed depending on range:
    movf    CS_MENU_PARAMETER_MAX_H, W
    andlw    0xf3
    bnz    CS_MENU_EncSpeedSet_ModVal_GE400
    movf    CS_MENU_PARAMETER_MAX_H, W
    bnz    CS_MENU_EncSpeedSet_ModVal_GE100
    movf    CS_MENU_PARAMETER_MAX_L, W
    andlw    0x80
    bnz    CS_MENU_EncSpeedSet_ModVal_GE80
    movf    CS_MENU_PARAMETER_MAX_L, W
    andlw    0xc0
    bnz    CS_MENU_EncSpeedSet_ModVal_GE40

[jjonas]

I would like to get some more feedback from other users before release to ensure that most people are satisfied with the changes - resp. are there users who don't like the change?

 

I tested this now only briefly, but I liked the changed (=faster) encoder behaviour, I think it's better than the old. I felt that even with the faster setting I could still turn the knobs slowly enough to have e.g. cutoff change slowly; I didn't feel like I have to use Shift+turn function to make it slower.

 

Do other users have the same problem like jrp, that rotary encoders need different speed configurations although they control the same range?

 

I can see why that might be desirable, but personally, if the option was available, I'm not sure I'd make use of it. Just my 2pF...

[jrp]

Yesterday night i had the time to play with my MB_SID and get a better impression of the new feature.

 

The Speed is actually good - turning an encoder two times for the whole range still feels very resposive. In audio ranges are very big...

 

The "steppiness" does not feel so good, unfortunately, especially when trying to do small changes.

 

It seems to me that the transission between slow and accelerated speed is quite low. When an encoder is turned slowly the increments are smooth and slow. Go just a little faster (but still quite slowly) the threshold is reached and speed is accelerated. If this threshold would come in a bit later that would feel much better.

[sonofprent]

I'll have a go at getting this on on the weekend...

[TK.]

It seems to me that the transission between slow and accelerated speed is quite low. When an encoder is turned slowly the increments are smooth and slow. Go just a little faster (but still quite slowly) the threshold is reached and speed is accelerated. If this threshold would come in a bit later that would feel much better.

 

I know what you mean, because I had the same impression and see the need for improvements.

But it won't be trivial, especially since a (more than 10 years old) routine in MIOS8 has to be overworked, and this will be *very* time consuming.

 

However, meanwhile I got the idea that I could try to improve this in MIOS32 first, which has the same algorithm. And once I'm happy, I could translate it into the (assembly based) MIOS8.

Hopefully it will be possible without consuming additional RAM, because there is no free RAM available in MIOS8...

 

Best Regards, Thorsten.

[TK.]

Ok, starting with MIOS32 was a good idea, because especially the possibility to send "printf" like debug messages helped me to find an easy solution, which also fits nicely into MIOS8.

 

Could you please install this new MIOS version: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html

 

Thereafter install MBSID V2 again: /edit: removed expired link, please download the official version under http://www.ucapps.de/mios_download.html

 

(still enctest2, the same that I provided some days ago)

Encoders should behave better now!

 

Best Regards, Thorsten.

[jrp]

wow! you are incredible.

I read your first post and was already forming thoughts like "oh, what a pitty, i hoped it was a simple adjustment". No surprise, i cannot "read" assembler but i have read about it....

And then that second post :smile:

So you changed it by altering mios8 if i understand correctly. Will this have an effect (positive or negative) on other applications, like MB64e?

I´ll try this as soon as possible!

 

Regarding Steps: I recorded some sounds today and was tweaking the synth, quickly editing. Fast mode feels a lot better to me now. Some of the stepiness i heard was exagerated because i was controlling external vca that was poorly calibrated and was missing a smoothing cap at the controll pin.