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.
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.
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?
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.
I don’t think anyone has tried writing the same algorithms for a CPU put together in a complete synth to make a realistic comparison. With the higher end of today’s CPUs, maybe you can get somewhere comparable. Next time I talk to Lippold Haken, I’ll ask about it.
It’s similar to comparing GPU with CPU, except the EM has a parallelized audio computing unit instead of a parallelized image computing unit.
There’s a reason why your computers have GPUs.
Even if the CPU could handle it, it would be a rather large effort to port 20 years of EM development on the SHARC DSPs to software for a PC.
Sure, I know all that stuff. But still, big synths run just find on a PC. 20 cores is in fact “highly parallel”.
Your main point - “don’t hold your breath” I totally agree with. Your other point that it would be difficult to do that much DSP on a PC I disagree with.
It would be cool to have the Eagan Matrix in software.
A PC version would likely be quite a different design. The EMM is Harvard-architecture versus PC CPUs are von-Neumann architecture. The parallelism has quite different characteristics on the two.
sure, but pc’s are so fast compared to an old sharc. sure they are “different”, but PC is just so much faster. I just isn’t hard to do this stuff in software any more.
I’ve thought about this a lot before, as I’m a big fan of the idea of DSP compute cards going mainstream again (given an open standard, unlike UA’s offerings)
I think the 6x Sharc’s probably have significantly less horsepower. The most powerful Sharc from a quick google does 3.600 GFlops sustained. So, 21.6GFlop. A Ryzen 9 5900x (the CPU I’m running) does about 6GFlops per core, so ~140GFlop.
On the surface, that’s a 6x improvement, so no contest. I don’t think that’s correct though. The 5900x is going to be running a full OS and doing lots of background work causing pipeline flushes, load balancing, etc. etc. etc. For a given buffer size we have to stay well below 100% know for sure we’re not going to miss the deadline for the next block. On the Sharc’s theres some over head to be sure (I’d assume some for the interconnects and orchestration to use 6 separate dies) but it isn’t a full OS by any means either. For this reason, I suspect the Sharcs are a bit more capable. They can push right against that limit, so long as they hit the deadline, they’ll always hit the deadline.
The Full desktop has some resource the sharks will never have, like oodles of ram, storage, etc.
I’m not sure that flop for flop those numbers are even correct, or that for both architectures and for DSP flops are even the best unit
The performance of both will depend on the workload because a FLOP is not a FLOP if the operation is given an intinsic instruction or there’s something like SSE in the equation.
This assumes the math in both is even floating point - In rack it is, obviously, but fixed point math on DSP chips was historically common. I have no experience with anything newer than a C55x other than the Daisy Seed for DSP though
yep, I think everyone is correct here. It’s really difficult to compare two totally different architectures. At least until you try to make a big synthesizer out of both of them and have some real data.
