If you, like me, have been frustrated by the lack of fine-grained control afforded by the Organelle’s pots (or by MIDI controls in general for that matter), then you might be interested in my new patch “Infiknob.” It’s packaged up as a demo synth, which might be interesting to some, but the real point is that the use of Infiknob in the demo shows off how you can (say) control a frequency between 0.1 Hz and 20000 Hz in 0.1 Hz increments across the entire range.
The basic theory of (user) operation is that the center portion of the raw control lets you directly control the output one increment at a time, and the extremes are used to auto-increment and auto-decrement at a rate which varies with distance from the center. E.g., if you nudge just above the center range, the value will increment slowly, and as you move further towards the top of the range the rate of change increases.
I spent a while tweaking the behavior, and I think I hit on a sweet spot. Nonetheless I’m open to feedback, suggestions, etc.
I hope y’all find this useful!
The patch is uploaded on Patchstorage, here: https://patchstorage.com/infiknob/
This is great… I think you did manage to find the sweet spot, it is easy to adjust and only takes a second to understand how it is working. Some kind of visual indicating what zone of the knob you are in could be useful, but not totally necessary since once you know how it works you wouldn’t really need it.
It would be great to use this to scrub through long sound files, such as to select start and end loop points…
I like it too…
I think id like to try it so that 9 o’clock and 3 o’clock was where the auto inc/dec starts.
so that would give you a clear point where behaviour changes, even without looking to the screen.
I did once try a similar idea, an ‘encoder’ mode,
but it lacked your centre fine tune zone… and it felt like it was drifting, so I didn’t feel ‘connected’.
but this fine tune/pot mode really helps fight that, which keeping its advantages (non-locking)
definitely makes my head whirl a bit with ideas about using the pots a bit more creatively.
I could imagine having different modes in Orac… I do remember some users talking about using ‘relative’ take over rather than ‘lock’ - but encoder and infiknob could be interesting to ‘test drive’. (*)
(*) this is actually pretty easy for me to do…
I already have some different modes changing values encoder mode (aka incremental), take over (pots) and non-takeover (used for midi), just users dont see it
so switching if over to different mechanisms could be easy enough, at least for a playground to see what feels like it works.
Thanks for the feedback. It certainly makes sense to have more visual feedback. The lack of it in this version is more about where I am in the process than anything else. (Also: This is gonna be a hard nut to crack, given how little screen real estate one has on an Organelle, and given the relative thinness of the abstraction provided by the display API.)
As for where to place the boundaries between scrubbing and auto-inc, I definitely see the draw of the visually obvious 9 o’clock / 3 o’clock. I’ll play with that boundary a bit more, and please do let me know if y’all do any similar experimentation. I’ll admit up-front that I’m a little skeptical, because that will squeeze the auto-inc range and may make for a control that’s a bit overly “jumpy.”
Just FWIW, in an earlier iteration[*] I had the speed of auto-inc increase with time in addition to the distance from center. That added complexity turned out to not particularly help given the size of the auto-inc range (and it also made the operation of the control a bit less obvious), but if the auto-inc range were reduced (per above) then a time-based rate adjustment might become a bona fide useful feature to (re)include.
[*] You can find it in the revision history of the repo (https://github.com/danfuzz/fuzz-synth/tree/master/Infiknob), though (sorry) I didn’t actually tag it or similar.
Loving this patch, especially the slow incremental quality. A couple of questions/comments. First, I couldn’t seem to get the reverb amount to change, don’t know if I’m supposed to be able to do that or not. Second, it would be really cool if the aux button would latch the keys pressed so I don’t have to hold them down. That way I can tweak or just listen instead of keeping my hands fixed to the keyboard.
Thanks for the compliments!
I didn’t actually intend the sound to be all that interesting: It’s really just meant to be a means to the end of demoing the physical control, which is why it’s such a “bare bones” patch (so, e.g. and sorry, no reverb, no pitch bend, no hold pedal, etc. etc.). It absolutely could be built out into something much more complete and performance-worthy.
My (vague) intention is to keep working on the fundamental building blocks for putting together solid patches, and ultimately use them to make (what I hope is) a truly compelling patch. In the mean time, I’d absolutely welcome someone stepping in and running with the synth inside Infiknob. It’s Apache-2 licensed for a reason!
I have some ideas for using it too, but i agree i would prefer also if it could start moving at 9/3 o’clock and a bit more quickly at the beginning, because actually it’s hard to know if it’s static or may move very slowly… (this actual way is cool to generate slow ramps)
i tried to convert it for Orac but had no success yet, will try harder (for setting the bpm on a clock module more precisely)
I’m sorry I haven’t had a chance to do much tweakage on this patch over the last week or so and probably won’t for a little while yet (TLDR: (a) this hobby doesn’t exactly pay; (b) a bad case of stomach flu). In the mean time here’s a quick guide for your own tweakage, should you feel so inclined:
pd control-input is what separates the three segments of the control from each other (auto-down, fine tune, auto-up). There’s a pair of
moseses in there which define the inflection points. Note that the range of the control by the time it makes it into the patch is
[-1..1] (i.e. not
[0..127]). As published the two inflection points are at
The auto- increment/decrement behavior is (unsurprisingly) defined in the subpatch
pd auto-increment. And, its input is also set up to always be in the range
[-1..1]; that is, the layer leading to it “chops out” the fine tune portion of the control range and “fluffs up” the remainder to fill in the whole range without gaps. So (for example)
-0.01 might be an input you see as you edge the control just below the fine tune range, and likewise
0.01 on the other side.
If you like the basic “faster as you get more extreme” behavior but don’t like the specific details, then there are two places that warrant your attention: (a) the
expr on the second inlet (which is pretty clearly marked); and (b) the calculation of
auto_max$0 at the bottom-right of the subpatch.
I hope this helps. Happy hacking!