Announcing: Synthesizers.com Manufacturer Sub-Forum

Please check out the new sub-forum by following the link above. It is nice to have another manufacturer onboard and opening another direct communication line to potential and existing customers

Custom Encoder Caps and Velocity Sensitive Middleware > OSC

From circuitbending to homebrew stompboxes & synths, keep the DIY spirit alive!
Post Reply
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »



This is about the one-off hardware and custom-coded middleware, the audio result is for demonstration purposes. ;)

Have been working for a while on modified encoder caps for getting very fine adjustments into various programs. Hardware modifications and middleware signal processing into VCVRack 2. Converted to a jog wheel style for continuous rotation. A Processing sketch converts the APC40 Midi signal to an OSC stream into VCV, importantly, turning the 128 steps into variable velocity-sensitive from 1/10,00th of a volt on up.

The 3D printed cap prototypes are about iteration 20, will show some of the previous examples below in the thread. precision bearing for no resistance or fingertip friction. Range is unlimited positive/negative, or within a fixed voltage. There are two sets of 8 dials on the APC40, (16 total) each switchable between 8 stored banks, 128 total OSC channels out. /oscA/1-64 & /oscB/1-64 (as well as an additional 8 banks of 8 vertical sliders)

The video is a real-time overlay of the processed signals, the Trowasoft OSC to CV module, Dexter Valley module, no chronological edits, experimenting, the video is about the signal handling and tactile input, more than the drone audio result.

Slow high-resolution input for various applications. Any feedback is welcomed.
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

P9260055-red.jpg
First try, ready-made, LEGO tires. Sticky, not bad, little brutal.
P9260050-red.jpg
CNC machined acrylic, frosted, expensive. not so indexable, nice light transmission effect.
P9260053-red.jpg
First 3D prints, tabletop dials, low indexability.
P9260049-red.jpg
3D prints, tabletop dials with fingertip locks, asym, good indexability, poor continuity of rotation.
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

P9260047-red.jpg
Tabletop cap with rotary index, pentagram.
P9260044-red.jpg
Tabletop cap with oval rotary index, round.
P9260042-red.jpg
Tabletop cap with rotary index, pentagram.
User avatar
Freedj
Common Wiggler
Posts: 76
Joined: Thu Nov 25, 2021 9:10 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by Freedj »

Wow, what a cool design project. It looks like you've really nailed the smooth continuous motion. I love seeing all the design iterations. The frosted ones are gorgeous, but your current design looks like a total joy to use!
User avatar
guest
Super Deluxe Wiggler
Posts: 8242
Joined: Mon Aug 19, 2013 11:49 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by guest »

thats really cool, thanks for sharing.
openmusiclabs.com
User avatar
KSS
Super Deluxe Wiggler
Posts: 10025
Joined: Mon Jan 25, 2016 7:28 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by KSS »

:tu:
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

Freedj wrote: Thu Sep 22, 2022 7:53 am Wow, what a cool design project. It looks like you've really nailed the smooth continuous motion. I love seeing all the design iterations. The frosted ones are gorgeous, but your current design looks like a total joy to use!
Thanks! The frosted ones really glow nicely in a full setup. Hard to mass produce plastic in that thick of a section if I decide to make a product. The flat design requires attention and feel to keep a fingertip centered, the cupped bearing designs are "set and spin" much better for multiple fingers going (attempting coordination of as many as possible) in different directions.

It really is fun to have so many factors changing at once.
guest wrote: Thu Sep 22, 2022 12:27 pm thats really cool, thanks for sharing.
Glad you like it!
rich_de
Wiggling with Experience
Posts: 278
Joined: Thu Nov 19, 2020 3:00 pm

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by rich_de »

The little "cranks" are nifty! Have you considered if (or even measured) the finger as "connecting rod" has the same speeds across x and y? (I could imagine that newbies have an uneven motion here, while trained video editors would turn it at a perfect constant speed after a long period of conditioning...)

Also, is your velocity sensing only for the momentary speed between steps, or do you keep an internal "flywheel" that smoothes out little wiggles or even somehow carries over the speed information while re-gripping? (You'd probably not need the latter with the crank mechanism, because that neatly works around the need to re-grip)

ps I think this accelerating of encoders is an under-appreciated topic, it was that which made the mouse as an interface device feasible at all (even if some badly conditioned Windows users often post flames about it).
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

rich_de wrote: Fri Sep 23, 2022 1:57 pm The little "cranks" are nifty! Have you considered if (or even measured) the finger as "connecting rod" has the same speeds across x and y? (I could imagine that newbies have an uneven motion here, while trained video editors would turn it at a perfect constant speed after a long period of conditioning...)

Also, is your velocity sensing only for the momentary speed between steps, or do you keep an internal "flywheel" that smoothes out little wiggles or even somehow carries over the speed information while re-gripping? (You'd probably not need the latter with the crank mechanism, because that neatly works around the need to re-grip)

ps I think this accelerating of encoders is an under-appreciated topic, it was that which made the mouse as an interface device feasible at all (even if some badly conditioned Windows users often post flames about it).
Some excellent questions, thanks!

Fingers, biomechanically, fingers are hard to translate to XY given all the joints, and each finger has a different amount of dexterity in up-down and side to side, the index finger being super mobile, the others to a lesser degree. The feedback loop, audio or visual, as well as the position feel on the radial limits are a guide. I believe that coordination has to be built like playing a musical instrument with up to eight encoders in play.

Velocity and smoothing is filtered based on the previous millisecond steps with a some anticipation built it, but it currently stops when input stops, for precision, and based on my reactions. Given your question, I can imagine the code needed for a momentum variability that allows a virtual flywheel to be spun up and coast down depending on virtual friction. I can see the possible applications for input, will code it up as a toggle.

Definitely need the crank in my estimation. Gripping involves the thumb and index finger. We have two sets of those digits, limiting manipulation to two radial encoders. The crank type allows for easily three adjustments per hand with some precision or at least concurrency. The regripping, matching momentum, doing it fast enough, unless the "flywheel" is spinning at a good clip, hard to imagine that this would be a workable solution for one or two encoders.

I'm working on a more detailed video specifically of the roto-cap action, it feels quite unique. When adjusting more than two rotary encoders at once, I don't think there is anything comparable.
rich_de
Wiggling with Experience
Posts: 278
Joined: Thu Nov 19, 2020 3:00 pm

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by rich_de »

strato wrote: Fri Sep 23, 2022 9:59 pm
rich_de wrote: Fri Sep 23, 2022 1:57 pm Also, is your velocity sensing only for the momentary speed between steps, or do you keep an internal "flywheel" that smoothes out little wiggles or even somehow carries over the speed information while re-gripping?
Given your question, I can imagine the code needed for a momentum variability that allows a virtual flywheel to be spun up and coast down depending on virtual friction. I can see the possible applications for input, will code it up as a toggle. ... I'm working on a more detailed video specifically of the roto-cap action, it feels quite unique.
I asked, because my poly project relies on four central encoders, and because they're the central interface element, they have to be absolutely bang on in their action. I must have sunk over a net month of work into those, and for 8-bit dynamics, I'm happy. Their interaction is more satisfying than anything I've seen in the wild (Alpha Juno and Microwave 1 being at the opposite end of the spectrum...), but the filter cutoff (really the most important value to be tweaked) has 14 bits, and I'm not entirely satisfied with that, depending on tuning, there's either too much cranking needed, or the "aiming precision" goes downhill.

As I'll stick with the (nice, solid metal...) knobs, I think I'll have to carry over momentum from one grip to the next somehow, with some sort of second-degree acceleration. That's something your little cranks completely solve, because the finger motion can be continuous - and not only for one encoder, but more, making it, as you said, a new kind of instrument.
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

The velocity dial approach grew out of necessity. I first started using midi interfaces with the Unreal Engine, moving cameras along very long (scale 2 kilometer) paths, and slow zooms. The need for jog wheels came out of that work. The Midi Fighter Twister has a velocity-sensitive option in the setup called ENC 3FH/41H, I used that as a starting point and built a similar but much wider range in code for any device.

From before the mini-jog experiments.

I've had two experiences with high-sensitivity encoders in real life, some old two-step potentiometers on a piece of electronic equipment, one fine dial and one coarse, and the axis wheel on milling machines. Both are great for precision, but to cover a longer range, you need hundreds and hundreds of rotations, very limiting. Solved on milling machines with a power feed lever that engages a motor drive.

The jog wheel velocity spin of the Virtual DJ program is a lot like the flywheel you described, will look into implementing that approach as well.
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

rich_de wrote: Sat Sep 24, 2022 7:13 am
... my poly project relies on four central encoders, and because they're the central interface element, they have to be absolutely bang on in their action.
Rich, is there a link to your project?
rich_de
Wiggling with Experience
Posts: 278
Joined: Thu Nov 19, 2020 3:00 pm

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by rich_de »

strato wrote: Sat Sep 24, 2022 8:40 pm
rich_de wrote: Sat Sep 24, 2022 7:13 am ... my poly project relies on four central encoders, and because they're the central interface element, they have to be absolutely bang on in their action.
Rich, is there a link to your project?
Not really, I posted something on a thread about why there aren't (m)any analog poly projects, but I can't find that again. The search here seems incomplete. But here's at least that photo again to give you an idea of how the encoders look, these are prototypes 1 and 2. The final product will have a 5 octave keybed, but the basic control layout will stay the same. It was important to me that the encoders are right in the centre, so they can be accessed with either hand when performing. I found the specific layout was the only way to provide seamless operation of all its features, and from my interaction experience it works great (except for mentioned cutoff setting) - but it's going to be a hard sell with analog classics are valued by the number of knobs by many. ;)
EToG2x.jpg
strato
Learning to Wiggle
Posts: 35
Joined: Sat Aug 14, 2021 2:13 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by strato »

rich_de wrote: Sun Sep 25, 2022 6:06 am ... But here's at least that photo again to give you an idea of how the encoders look, these are prototypes 1 and 2. The final product will have a 5 octave keybed, but the basic control layout will stay the same. It was important to me that the encoders are right in the centre, so they can be accessed with either hand when performing. I found the specific layout was the only way to provide seamless operation of all its features, and from my interaction experience it works great (except for mentioned cutoff setting) ...
Looks good. Depending on how the encoders work, I'd be happy to send you a set of the 3D printed ones to try and get your reaction. Let me know and can arrange it. Would love to get some feedback in different applications.

Here are the latest iterations, lower profile tilted axis.
P9260605-red.jpg
P9260603-RED.jpg
User avatar
KSS
Super Deluxe Wiggler
Posts: 10025
Joined: Mon Jan 25, 2016 7:28 am

Re: Custom Encoder Caps and Velocity Sensitive Middleware > OSC

Post by KSS »

Those^ seem *much* more limiting to use than the 3 and 5 hole version you posted before.
Post Reply

Return to “Music Tech DIY”