RhythmEcho private beta
-
- KVRist
- 59 posts since 2 Jan, 2026
Hey Rich, thanks for your nice comments. I am a hardcore programmer, maybe one of several guys in the market. But, you should fully focus on your own design. If your plugin does not cause any crush or freeze in different circumstances, that would be great. Efficiency comes second. Of course, I don't know your code base (I should not, keep it secret), you should only listen to your paid customers (mostly). They really care about your product!
-
- KVRist
- Topic Starter
- 113 posts since 3 May, 2005 from Honolulu
Thanks, I had a detailed response, a real TL;dR that got eaten. lol, now I have another one.
TL;dR: Here are my design principles for RhythmEcho, based on lots of thought, care, performance hours, production hours, and so forth. 1.Less-clicks = better. 2. simple as possible but no simpler. 3. Object permanence. Once something appears, it will always be in the exact same place when visible. 4. Start simplest and unfold complex as you need it. 5. Anything that functions as anything is a module. Modules connect, and modules can contain other modules. this extends from the GUI to the DSP. You can probably stop here and not miss anything, but read on for the details....
First of all, I really am glad to have your ideas and feedback. Spaghetti was strained and sorted in to modules in 2012 and everything since is highly modular to the point I could pull my eq out of RhythmEcho as a separate plugin for KVR DC '26 with very little effort (search WayQ and vote for me!), and by cross-tagging WayQ and RhythmEcho in GitHub, changes in one get propagated to the other If I want them too. I keep things intensely modular because I have built the plugin in Plogue Bidule, iOS Audulus, Max, and PD and know what every little part down to and including the DSP maths does. by keeping it modular, even though I am black-boxing in regard to the code, I can debug quickly and accurately since I know exactly what everything does and can tell immediately if something goes off the rails even if everything still builds.
I want to keep the CPU very low, and I've run the current version in six instances (five tracks and a send) with midi, audio, samples and all without breaking a sweat. in part, that is from knowing what I want the modules to do down to the exact DSP. It is meant to be used with other plugins and instruments, not be the center of the universe like a bunch of my guitar amp modelers. I wish I could pare a little more off, but it is good enough and has been stable throughout the 0.9.8 cycle.
As far as removing everything unnecessary, I have a different take on it that is working so far. I don't add anything that could be done as well with another plugin. So no saturation, compression or box of stompboxes found as the effects section of many plugins. The simplest thing is that *everything* in RhythmEcho descends from the onset detect and that gets into some complex-at-first but extremely fun and useful territory. I manage this by presenting the initial state as "Sane" with just the detection and setting of the delay to your playing with standard feedback and a table of fractions that musically modify the detected delay time. This is set in preset 000, the default, so that the onset-detected delay time is not modified so you can speed up and slow down your playing to understand exactly what it is doing. The fraction table then opens that up along with feedback. Earlier version had more complicated stuff as the initial preset, but what happened is if the sidechain/main input to the sensor was busy at all it would just be a mess and people couldn't figure out the patterns and would discard RhythmEcho as too complex to make sense of. There are a lot of bad sounds to be had, but rather than curate and remove, I leave them there for other people to discover things other than what I put there for them.
From this initial "sane" mode, RhythmEcho then unfolds along two axes, the Link/unlink buttons, which introduce the second channel controls as you need them. And "FAFO" mode, which opens up the FAFO controls that can really F with the sound, but if you use them one at a time as you need them or as you "F Around" they make sense pretty quickly and if something sounds bad, it is usually a matter of turning off what you just turned on.
The two-layer unfolding of the complexity makes it gradual and as needed. the complexity requires a second design feature which drives me nuts when it is not attended to (short drive!:hyper:), namely **Object Permanence**: If something appears in the GUI, it will always be exactly right there when it appears. the counter examples would be the new iOS, Zoom, Google Meet: somehow it is considered some kind of context-sensitivity to move everything around when you change one thing. I pretty much curse it every time I encounter it and object permanence is my response: No matter what else you change, Swoop will always appear in the same place, and even when you are in deep FAFO and unlinked territory, The SANE interface that you started with is still visible with all the parts exactly where they were at the start. once something appears, it always appears right there.
This leads to the last design principle I have been using here, which is that everything is based in the idea that it be usable in a live situation with just a mouse. less clicks=better, and with three careful exceptions, no performance/flow-crushing menu diving. the exceptions are the two graphs, which have a tab for each channel to save real estate, and the top panel stuff, which is not relative to workflow or performance other than the preset dropdown.
While I am bouncing off your post, I am not being critical of it at all. I really like what you are doing and hope I can get around to checking your plugs that I have downloaded, so please don't take this as me being defensive or critical. I have wanted to share some of the design principles behind RhythmEcho. I have a bunch of design docs, but they are for my use and not really fit for public consumption, so I used your post as an excuse to share some of them here so people know what the design is all about since I've put a lot of thought and care, playing hours, and performing and producing hours into it. Cheers, and if you made it through this far, thanks for reading!
TL;dR: Here are my design principles for RhythmEcho, based on lots of thought, care, performance hours, production hours, and so forth. 1.Less-clicks = better. 2. simple as possible but no simpler. 3. Object permanence. Once something appears, it will always be in the exact same place when visible. 4. Start simplest and unfold complex as you need it. 5. Anything that functions as anything is a module. Modules connect, and modules can contain other modules. this extends from the GUI to the DSP. You can probably stop here and not miss anything, but read on for the details....
First of all, I really am glad to have your ideas and feedback. Spaghetti was strained and sorted in to modules in 2012 and everything since is highly modular to the point I could pull my eq out of RhythmEcho as a separate plugin for KVR DC '26 with very little effort (search WayQ and vote for me!), and by cross-tagging WayQ and RhythmEcho in GitHub, changes in one get propagated to the other If I want them too. I keep things intensely modular because I have built the plugin in Plogue Bidule, iOS Audulus, Max, and PD and know what every little part down to and including the DSP maths does. by keeping it modular, even though I am black-boxing in regard to the code, I can debug quickly and accurately since I know exactly what everything does and can tell immediately if something goes off the rails even if everything still builds.
I want to keep the CPU very low, and I've run the current version in six instances (five tracks and a send) with midi, audio, samples and all without breaking a sweat. in part, that is from knowing what I want the modules to do down to the exact DSP. It is meant to be used with other plugins and instruments, not be the center of the universe like a bunch of my guitar amp modelers. I wish I could pare a little more off, but it is good enough and has been stable throughout the 0.9.8 cycle.
As far as removing everything unnecessary, I have a different take on it that is working so far. I don't add anything that could be done as well with another plugin. So no saturation, compression or box of stompboxes found as the effects section of many plugins. The simplest thing is that *everything* in RhythmEcho descends from the onset detect and that gets into some complex-at-first but extremely fun and useful territory. I manage this by presenting the initial state as "Sane" with just the detection and setting of the delay to your playing with standard feedback and a table of fractions that musically modify the detected delay time. This is set in preset 000, the default, so that the onset-detected delay time is not modified so you can speed up and slow down your playing to understand exactly what it is doing. The fraction table then opens that up along with feedback. Earlier version had more complicated stuff as the initial preset, but what happened is if the sidechain/main input to the sensor was busy at all it would just be a mess and people couldn't figure out the patterns and would discard RhythmEcho as too complex to make sense of. There are a lot of bad sounds to be had, but rather than curate and remove, I leave them there for other people to discover things other than what I put there for them.
From this initial "sane" mode, RhythmEcho then unfolds along two axes, the Link/unlink buttons, which introduce the second channel controls as you need them. And "FAFO" mode, which opens up the FAFO controls that can really F with the sound, but if you use them one at a time as you need them or as you "F Around" they make sense pretty quickly and if something sounds bad, it is usually a matter of turning off what you just turned on.
The two-layer unfolding of the complexity makes it gradual and as needed. the complexity requires a second design feature which drives me nuts when it is not attended to (short drive!:hyper:), namely **Object Permanence**: If something appears in the GUI, it will always be exactly right there when it appears. the counter examples would be the new iOS, Zoom, Google Meet: somehow it is considered some kind of context-sensitivity to move everything around when you change one thing. I pretty much curse it every time I encounter it and object permanence is my response: No matter what else you change, Swoop will always appear in the same place, and even when you are in deep FAFO and unlinked territory, The SANE interface that you started with is still visible with all the parts exactly where they were at the start. once something appears, it always appears right there.
This leads to the last design principle I have been using here, which is that everything is based in the idea that it be usable in a live situation with just a mouse. less clicks=better, and with three careful exceptions, no performance/flow-crushing menu diving. the exceptions are the two graphs, which have a tab for each channel to save real estate, and the top panel stuff, which is not relative to workflow or performance other than the preset dropdown.
While I am bouncing off your post, I am not being critical of it at all. I really like what you are doing and hope I can get around to checking your plugs that I have downloaded, so please don't take this as me being defensive or critical. I have wanted to share some of the design principles behind RhythmEcho. I have a bunch of design docs, but they are for my use and not really fit for public consumption, so I used your post as an excuse to share some of them here so people know what the design is all about since I've put a lot of thought and care, playing hours, and performing and producing hours into it. Cheers, and if you made it through this far, thanks for reading!
my experimental improv duo, rreplay.
more of my music
occasional experimental sound blog all things vst, guitar synth, and more.
The Digital Guitarist.
more of my music
occasional experimental sound blog all things vst, guitar synth, and more.
The Digital Guitarist.
-
- KVRist
- 59 posts since 2 Jan, 2026
Very cool. Modular design is a great choice. It is really easy to maintain. I follow this design style in some of my own plugins.
It seems that your next thing is only users, and their feedback. As I mentioned before, keep your code base for your own because you spend so much time and made huge effort. Of course, your product would not be free. Nowadays, open source code projects have been commercially released. Developers are not careful about the licence types. Well, JUCE 8 forces developers to make their releases open source if its licence fee is not paid. I don't blame them, it is a kind of company policy move.
It seems that your next thing is only users, and their feedback. As I mentioned before, keep your code base for your own because you spend so much time and made huge effort. Of course, your product would not be free. Nowadays, open source code projects have been commercially released. Developers are not careful about the licence types. Well, JUCE 8 forces developers to make their releases open source if its licence fee is not paid. I don't blame them, it is a kind of company policy move.