Cabbage Logo
Back to Cabbage Site

Encoder upgrades

Would any upgrades of the encoder widget be possible?
A couple of things you can see in the video are that it doesn’t repeat at a regular location or value on each rotation and when returning to its original location its value has shifted.
I would like to be able to use it as an accurate endless azimuth control for surround panning.

I’ll take a look, a bit part of the problem with this widgets is it depends on the pixel density, screen resolution and the actual size of the encoder. Let me take a look. I probably won’t get a chance to look at it until next week. I’ll let you know.

I’m just getting around to looking at this now. I’m tempted to rewrite the entire widget :grimacing:

@iainmccurdy I have hit a wall with this. I tried a few different approaches but they all result in things moving out of sync at some point due to either the speed I drag at, the size of the widget, step size, etc. But, I was able to hobble something together. The first thing I did was get rid of the position indicator. Setting trackerColour(0, 0, 0, 0) wasn’t working originally, but I pushed a fix. Anyway with this gone one doesn’t even notice the issues any more :rofl: And if you take your info from the position of things on the screen it seems to work pretty well.

endlessEncoder.csd (1.2 KB)

Thanks for taking a look at this, Rory.
I had a go myself at using a rotating image as the indicator. Maybe the encoder can be set up using two critical input values:
The repeat increment for each full turn
The integer number of steps for each full turn (which therefore defines the size of each step, both graphically and in terms of the number sent out on the channel).
Here are a couple of my own efforts, one repeating at 360 for an azimuth control and the other repeating at 1.

EndlessEncoderRepeatsAt360.csd (907 Bytes) EndlessEncoderRepeatsAt1.csd (909 Bytes)

It’s interesting that you did this with an nslider. That’s what I was looking at yesterday, basically modifying the nslider to work like an endless encoder. It seems to have a better response to the encoder. I’ll take a look later and see if I can swap out the underlying mechanics of the encoder with an nslider.

[edit] ah, I see, you’re using both an encoder and an nslider…
[edit2] and now I see why :rofl: Sorry, I hadn’t had my coffee yet this morning…

@iainmccurdy, try the latest beta build when you get a chance. I’ve added a repeatInterval() identifier that makes it behave like your example. :+1: One thing I noticed though, the endless encoder now starts with the marker at the bottom rather than the top. I guess that’s fine, but I can update it if you wish?

Thanks, Rory.
I can set an initial position using value() but as soon as the encoder is touched, it jumps to 6 o’clock. I think if would still be useful to set its initial graphical position for, for example, my original case example of an azimuth control for surround panning which would normally start at 12 o’clock and 0 degrees.
Between the repeatInterval() and increment() this, this is working well though. The only thing is that if I set 360 as the repeat interval and 1 as the increment it takes quite a while to complete a cycle. It doesn’t seem to respond to mouse velocity.

Yeah, a bit of work to do yet. I’ll keep at it.

I just pushed a new version that will start at 0, unless an initial value is set. The position will be value/repeatInterval of a full rotation. I also updated the sensitivity to bring it more in line with other sliders. Now you can quickly complete one cycle in a much shorter time. :clap:

Thanks, Rory. Setting an initial position seems to work well now.
Should the encoder not move quicker when I move the mouse quicker? In the video below, this doesn’t seem to be the case. This is with 2.9.17.

Can the value box be tweaked so that its display resolution follows the increment value? If I have an increment of 1 set, it still displays 3 decimal places.

Sure, that should be possible.

You would think so? This certainly isn’t there by design. I’ll take a look.

Here’s what I’m working on that’s using these encoders. It decodes double MS recordings for projection into up to 8 speakers.

Tasty! I’ll try to sort out those last few niggle today :+1:

Next batch of changes just pushed through.

  1. The textbox will now display the correct number of decimal places
  2. Dragging the mouse quicker will cause the slider to move quicker
  3. Pressing Ctrl or Alt will slow the slider down by increasing sensitivity.

I’ve tried to match the behaviour of the slider class here as best I can. Note that you can’t always get the resolution/step size you wish. If for example you set the repeat pattern to 1000 and slider increment to 0.001, you’ll never see values increment by 0.001 due to the screen resolution. But overall I think this is a much better widget than before :slight_smile:

Yes, I think it’s been a successful venture, even if it’s a niche widget. “Better to have an encoder and not need one that to need…”. I just gave a seminar on the DMS Decoder and I commended your assistance! I think the increment limitation seems obvious and in the example you describe, the user should simply reduce the repeat interval.

There’s one other niggle I noticed in the current version in that some encoders jump to zero when interacted with. It doesn’t always seem to be consistent but in the video below it seems to be more with the ones that were initialised to the right (a positive value) than for the ones initialised to the left (a negative value).

Hmm, I can’t seem to recreate the issue. Can you prepare a simple example? I’ve tried various value settings, but can’t seem to trigger the issue :thinking: What are the ranges you’re using 0-360? Increment 1?

[edit] double-clicking always returns the encoder to 0, when it should return it to the initial value, I wonder if you might be accidently double clicking on the trackpad? It’s easily done. Either way, clicking shouldn’t return to 0…

[edit 2] I just pushed a fix for the double-click, hopefully this will resolve the issue you’re having…

The mouse-velocity tracking is a big improvement now.

I’m still seeing the jumping-to-zero thing with some encoders, and here is a video of it in a stripped down csd. (Repeat:360, Increment:1) Enctest.csd (1.6 KB)

One clue could be that the value boxes aren’t displaying integers until after they are interacted with. Is it related to to the use of value()?

I fixe that issue with the initial value not displaying correctly, but I can’t for the life of me reproduce the problem :man_shrugging:

I have tested on Windows and a Mac and I see no problems. Are you using a trackpad? If so, is there any way you can get your hands on a mouse to test?