I use Surge Tuned Delay for vibrato, it has a pitch input. Great for making DIY wow/flutter fx.
Am I correct in thinking the basis for this is temporal quantising of shuffle through increasingly granular Euclidian divisions?
Yes, at the core, but with what seem like some very sophisticated interface and internal tricks (and some nice extras, like a linear modeāsomeone should write a standalone drum linear-izerā¦)
My Venom Rhythm Explorer module has a linear mode available. Rhythm Explorer is heavily inspired by the Vermona randomRHYTHM, which has an offbeat mode - a special case of linear drumming.
Rhythm Explorer supports both the offbeat and regular linear modes.
A standalone ālinearizerā is not a bad idea, I think I may create one for the Venom plugin. The functionality would be dependent on all input triggers being of equal length, and perfectly in sync. I am currently developing my next release, and I think I can include this.
That being said, it would not be hard to construct the functionality with basic logic modules. The first trigger channel A would be preserved as is. Then the next channel B would be (!A & B), yielding Bā. Channel C would then be (!Bā & C), etc. Basically a cascade of relatively simple logic operations. The only tricky part would be inserting sample delays so that the logic is always correct down to the sample level. Putting everything in one module eliminates the need for sample delay adjustments.
Oh, neat! Didnāt know that about either Rhythm Explorer or the randomRHYTHM. Eager to explore.
Iād love to see you take a swing at the generalized linearizer (which, honestly, would be a neat hardware module too, if it doesnāt exist already). Patching it together from components and manually syncing wouldnāt be too bad but since in Rack itād be slipping the consolidated output by, what, two or three samples times the total number of channels, youād also need to delay everything running in parallel with the trigger streamāthatās the bigger inconvenience in my mind, because itās not fully encapsulated in the linearizer block.
(O/T but in quiet moments with Rack I often start thinking about whether thereās a manageable way to avoid paying for the sample delay when itās not necessary to avoid feedback loops for part of the subgraphāmaybe something like āinstant cablesā that fail over to ādelay cablesā as soon as a local cycle appears. The sample delay is a beautiful general solution to enabling feedback, which is a hard requirement for a modular simulator, but it does limit composability in cases like this. Someday Iāll start an experimental fork and waste a ton of time fiddling with graph algorithms before abandoning the attempt.)
Ugh, I just patched a proof of concept and realized I got my logic wrong.
A = A
B = !A && B
C = !(A || B) && C
D = !(A || B || C) && D
etc.
Still not bad to implement
Here is the proof of concept using logic modules. Once you get to 3 or more channels, the added sample delay is constant at 3. I can implement linear drumming for four channels with one Grande VSD (Variable Sample Delay), and one each of Submarine NG (Not Gate), OG (Or Gate), and AG (And Gate). My demo patch shows ānormalā vs linear.
Logic Linear Drumming.vcv (3.2 KB)
And here is a demo showing ānormalā and linear drumming with Rhythm Explorer:
Rhythm Explorer Linear Drumming.vcv (2.9 KB)
I configured channels 2-4 to use the global default mode, and then can easily switch between normal and linear with the Global mode switch (All vs Lin)
Of course linear drumming will typically use different divisions for each channel. It is just easier to demonstrate with all channels at 1/8.
Nice! Very elegant composed build, and the oscilloscope views are a beautiful demonstration of whatās going on. Cool that (against my intuition) the sample delay doesnāt rise past a limit.
Seems like a good candidate for (say) an 8-10/in, 8-10out 4HP along VCV Split/VCV Merge lines? If 8 ins/outs were enough I could imagine an on/off switch up top being useful (although I guess Bypass would do the same thing in this case). Is there anything else to configure? Thereās probably a nice blinkenlights visualization that could go up top as well if it seemed worth the troubleā¦
@DaveVenom, I think this would be a great addition to Venom! (And if you donāt feel like building it Iāll probably take a whack at it later).
I plan to include this in my next release, probably within the next couple months. And agreed, 8 to 10 in/out pairs sounds like a good number.
Global on/off can indeed be implemented via bypass. But a switch for each channel (except 1st) to enable/disable linear mode could be useful. For example, channels 1 and 2 could be allowed to overlap, but channel 3 would remain silent if 1 or 2 is active. That is the kind of flexibility that is built into Rhythm Explorer.
Another possibility is addition of mute buttons, both before and after the logic. A mute before the logic silences the channel and takes it out of the logic computations for other channels. A mute after silences the channel but preserves the channel in logic computations for other channels. But Iām not sure either is worth the real estate, because you can achieve the effect by simply adding a mute module before and/or after the linear beats module.
Iām considering addition of switches to enable grouping in/out pairs into independent zones. So for example you could have three sets of 3,3,4 instead of one set of 10. This is another feature of the Rhythm Explorer.
The algorithm must be capable of performing the logic only at the transition from low to high, which is what Rhythm Explorer does. By default RE works with triggers of equal width, so this does not matter. But RE also has modes that output gates of 50% or 100% of the division length. In gate mode it is critical to only look at the transition from low to high. Employing this logic in a Linear Beats module would allow it to accept gates of varying length, yet still implement linear drumming. Output gates might overlap, but at most one channel would transition from low to high at any given time.
Lastly, I am considering support for polyphonic inputs/outputs. Each polyphony channel would get its own logic computation. In this case I might identify input/output pairs by letters so I can easily differentiate between port channels and polyphony channels in the documentation.
That is so much fun to use!!
These strike me as excellent ideasāvery happy youāre taking this forward! Donāt want to turn this into an OT design thread but if you open one up I will haunt it.
I will add just two things here (sorryāIāll justify it by noting that the Stolperbeats Expander sort of relates to this question):
- Might it be interesting to turn the per-channel switch into two switches, essentially āblock othersā and ābe blocked by othersā? Channel #1 would have the āblock othersā switch but not the ābe blockedā switch. There might be some interesting configurations there. (āmute but blockā is a potentially interesting mode but, yeah, a downstream mute module would handle that)
- Taking that one step further, what about making those switches stochastic? Knobs would probably be overkill but even four or five levels (āblock others 20% of the timeā, ābe blocked 80% of the timeā) might make for some interesting mostly-linear variations, and I think that would be much easier to do in-module (you could probably build a wrapping network of stochastic switches, mults and AND gates, but that starts to get impractical)
Iāve almost finished creating Linear Beats, and Iāve already got a post for my next release asking for testers. I will post info about Linear Beats there once it is closer to being complete, and that will be a good place for feedback.
Interesting idea. I think we need just one more mode, rather than two switches.
Pass all but donāt block can be handled by placing that channel at the top and then starting a new grouping below.
Donāt block downstream, but be blocked by upstream is all that is needed. I will call it āNon-blocking linearā
I am implementing mutes as expanders - they can be input mutes (donāt block, and donāt send the gates), or output mutes (block downstream, but donāt send the gates)
Another interesting idea, but I want to keep Linear Beats focused. I feel that stochastic functionality belongs at the source of the gates. I donāt think it makes much difference where the probability is implemented, and there already exist a number of stochastic pattern generators.
Hello, just adding two tracks to Soundcloud using a Taurus bass pedal Vst as sound source in the Nautilusdev build- it sounds marvellous.
Also I have used a Palette in polyphony mode with 6 voices and that really bounces around the delayline.
For the delay controls is it possible to adjust each individual Chronoblob module? Just a bit of detune makes a lot of difference to the depth of tone.
Any plans to add the Prince of Perception reverse delay in the next build?
SoundCloud handle/link?
Just uploading, when loaded Iāll put it on here sire!
The Palette as sound source version
(Stream Organ diver by Adrian Bottomley | Listen online for free on SoundCloud)
The Linear Beats module is now available for beta testing and feedback.
Itās not even a complicated one:
The EMM has 6 SHARC DSP chips running hand-crafted parallel DSP code. There are likely very few PCs, if any, that could handle the CPU and are not built with the memory architecture or parallelism used in these devices. If that GPU DSP compute project works out, then it might be theoretically possible to do something similar, but a software version of the Eagan Matrix is unlikely to ever happen.
But if you have an EMM, Osmose, or Continuum (or considering one) you can integrate it with Rack using my upcoming HC one plugin. See pachde (#d) HC-One - Plugins & Modules - VCV Community (vcvrack.com). I have a new release coming in the next few days.
Do you really think a PC is less powerful than 6 sharc?