I like using OrangeLine FENCE to keep pitch CV within a defined range. It sure is useful how it increments voltages outside the range by multiples of +/-1v, using the principle of octave identity to keep pitch classes the same, harmonically speaking.
Useful! But it’s got a problem, for me! The problem is it quantizes pitch CV to 12 equal-temperament pitches. I work in 5-limit just intonation, so this is an issue, as FENCE has led me astray from the PURE HARMONIC RATIOS I prize.
Therefore I had to roll my own - NONQUANTRALIM™, the Nonquantizing Range Limiter (attached).
Q: Does it work?
A: PRETTY CLOSE! Sometimes the output upper and lower limits are fuzzy by about +/-0.05v, but the voltage that comes out always differs from the input by multiples of 1v, so I’d say it’s OK! There’s also a few spiky artifacts probably caused by micro-timing issues, but a SLEW smooths them right out.
(In other news, I have loads of little saved-selection doodads like this, that I’ve made to solve problems specific to my compositional style, and can post more if people want to see them)
It’s good, but it doesn’t really allow me to change keys - this constructs a chromatic scale built from C, but if I need ratios built from another root, that’s too bad, unless I want to manually adjust the tuning on the fly. In my case I’m solving that problem elsewhere in my patch, and I just need the range limiter with octave identity
A great scaler, but it doesn’t preserve octave identity by adding/subtracting volts only in increments of 1, and therefore makes a mess of my Pure Harmony
Apparently it’s a fold interval! Set it to 1v and FENCE adds/subtracts 1v from any input CV outside the defined range, which is exactly what I need. If only I’d noticed this before I spent yesterday evening designing a pretty good replacement. I should post on this forum more often I think!
I think better yet would be using a single AO-118. Work from top to bottom in left column for steps 1 - 6, then move across the bottom for steps 7 and 8. The result of step 4 can also be passed to the right so that it can be used as the Y value in step 7. (of course the formulas need to be adjusted a bit regarding use of X vs Y in any given formula)
I don’t understand the original patch, but I’m pretty sure the following gives the same result, and with the couple of sample delays added in, all paths have consistent timing, so there should be no need for a slew limiter.
That makes perfect sense - I tried setting it up that way and found that it was like, one notch wider and used 1% CPU, so I rejected the idea, not realizing it had solved my 1-sample-delay problem
