Poll: should SHIFT behave as "fast" or "slow" button?

[TK.]

I've the feeling, that it would be better to change the encoder handling, so that they are in "fast mode" by default, and slow down while the SHIFT button is pressed. Especially for high resolution values like CutOff this would mean, that the whole value range can be sweeped with a single move w/o using the SHIFT button.

Nobody has complained about the current behaviour yet, therefore it would be interesting for me if you agree (-> use the poll function of this article)

Best Regards, Thorsten.

[TK.]

Thanks for voting! I changed the encoder speed handling in RC16 - it works much better now! :)

Best Regards, Thorsten.

[sineSurfer]

fast mode is useful on live performance?, you can't play a keyboard, press the shift button and move the encoder at the same time:(

[TK.]

Yes, the new behaviour is better for live performance.

Best Regards, Thorsten.

[stryd_one]

I wonder if it's possible to make this soft-switchable TK?

I'm personally more inclined to use the knobs to fine-tune patches, than to do filter sweeps and the like, so shift=fast is best for me. Also, all my other synths work that way, so it would be good. Obviously it's not hard to recompile, but it would be really nice if it were in a menu somewhere (or even some strange combination of button presses or something) :)

So who are the other two who voted for shift=fast? :)

[nILS]

I did =)

[stryd_one]

Hah, we're unpopular. We won't be allowed to sit at the cool kid's table in the cafeteria. ;D

[TK.]

[table][tr]

[td][/td]

[td][br]Ha-Ha![br]Nils and Stryd are Slow-Pot-Movers![/td][/tr][/table]

[bugfight]

Ha-Ha![br]Nils and Stryd are Slow-Pot-Movers!

(i heard a little bird say stryd was not so laggard in that regard)

and now there are three of you fargin square pegs

[TK.]

[table][tr]

[td][/td]

[td][br]Ha-Ha![br]Nils, Stryd and Bugfight moving pots so slowly, that recording software gets and integer overrun while timestamping the events![/td][/tr][/table]

(don't worry, just kidding - I will consider a soft-option ;-))

[bugfight]

hey, don't get me wrong, i voted for the change.

something i was going to change myself, eventually...

a soft switch is a good idea though, to take care of these whiners *whack*

[rutgerv]

So who are the other two who voted for shift=fast? :)

That would be me ;)

[/tilted/]

Perhaps a combination of keys to work as a toggle between slow and fast modes?

Fast is of course great for big live moves, but I have been known to do very fine stuff live (like setting frequency of ring mod or FM oscilators, teeny moves here make big changes)

Just a thought...

[stryd_one]

LOL ;D

*Bookmarks the URL to Nelson*

[nILS]

LOL ;D

*Bookmarks the URL to Nelson*

Hehe, if put that smiley in a forum I have a looong time ago ;-) http://web.schickt.de/forum/images/smiles/haha.gif

Nils, Stryd and Bugfight moving pots so slowly, that recording software gets and integer overrun while timestamping the events!

That's true programmer's humour :D

[bugfight]

i move my encoders so fast it looks to tk like they are moving backwards...

[TheAncientOne]

Ha-Ha!Nils, Stryd and Bugfight moving pots so slowly, that recording software gets and integer overrun while timestamping the events!

(don't worry, just kidding - I will consider a soft-option ;-))

Ah, so you see Watson, It was all a cunning ploy to justify  his move to 32 bit processors, luckily for us he did his first test with a 32 disc recursive Tower of Hanoi simulation......

(I like the soft option too, for my 2 cents worth)

[Smithy]

I love a fast shift myself.  ;)

But id prefer shift-slow when t comes to the midibox.  :P