From the original SynthMaker forum (2004–2014), with its members’ names and dates.
cyto ·
I have been on somewhat of a reverb kick lately (as some of you who talk to me "privately" are painfully aware). In my experiments, I always dreaded calculating early reflections. So I developed a little visual "ray tracer" tool for myself. After all the gory math it took to get it right, I thought it would be a shame to keep it to myself. So I threw a simple Shroeder algo on the end of it and wrapped it up in this little module...
Yes, you can move the little head and speaker around 🙂
Have Fun!
-cyto
infuzion ·
Wow, sounds great! I like the colors also; makes me yearn for Halloween 😉
If you ever get the itch to do another round of optimization on your OSM again, may I suggest the following?
1) Alot of your green maths can benefit from avoiding divides:
old: x / pi
new: x * 0.3183098861837906715377675267450287240689192914809128
In fbGain coeffs
old:
(1 / (in / coef0)) ^ (-60/20)^10
(1 / (in / coef1)) ^ (-60/20)^10
...
(1 / (in / coef15)) ^ (-60/20)^10
new:
Sample & Hold(1/in)
(S&H * coefX) ^ 59049
ALOT of expensive divides saved there!
Note: S&H does take up some CPU & memory to load (prevents the math to be re-ran, so reads are faster), but with 16 math chains, it would be worth it IMHO.
2) Your "Slow Pack" ASM is a good idea! Maybe look into "Hop on Change" or whatever Toggie calls it can cut back on cycles even more, since reverbs, esp room, tend not to have too much VST automation.
3) ASM is very good, but can go faster with some smarter assignments, reordering & shuffling; old:
//combs 1-4
movaps xmm7,xmm0;
movaps xmm6,xmm5;
movaps xmm1,delay1;
addps xmm1,modAdd1;
movaps xmm2,xmm1;
addps xmm2,xmm3;
cvtps2dq xmm2,xmm2;
cvtdq2ps xmm2,xmm2;
subps xmm1,xmm2;
subps xmm6,xmm1;
subps xmm7,xmm2;
addps xmm7,xmm4;
cvtps2dq xmm7,xmm7;
movaps frac1near,xmm1;
movaps frac1far,xmm6;
movaps fetch1,xmm7;
Untested new, executed at same time on same lines:
//combs 1-4
movaps xmm2,delay1;movaps xmm7,xmm0;
addps xmm2,modAdd1;movaps xmm6,xmm5;
movaps xmm1,xmm2;addps xmm2,xmm3;
cvtps2dq xmm2,xmm2;
cvtdq2ps xmm2,xmm2;addps xmm7,xmm4;
subps xmm7,xmm2;
cvtps2dq xmm7,xmm7;subps xmm1,xmm2;
movaps fetch1,xmm7;subps xmm6,xmm1;
movaps frac1near,xmm1;
movaps frac1far,xmm6;
Newer CPUs, esp Core2Duo & on, do some reordering automatically, but I also helped reduce the dependance chains. Also look at the maths; keep in mind that * & / can be done at the same time as + & -, as long as the results are stored in different registers.
Thanks again!
Mo ·
Thanks a lot cyto, great example!
-What means "7" into "Opts" in the preset manager?
infuzion ·
Mo wrote: -What means "7" into "Opts" in the preset manager?
1 + 2 + 3
Mo ·
infuzion wrote:
Mo wrote: -What means "7" into "Opts" in the preset manager?
1 + 2 + 3
Thank you, was not aware that you can add options that way.
infuzion ·
Mo wrote:
infuzion wrote:
Mo wrote: -What means "7" into "Opts" in the preset manager?
1 + 2 + 3
Thank you, was not aware that you can add options that way.
Welcome! I was hoping you could "add" the clues up, & not think I was making sarcastic math 😉
Xtinct ·
infuzion wrote: Wow, sounds great! I like the colors also; makes me yearn for Halloween 😉
Strangely enough also the closing date for the KVR developer challenge 😉
billv ·
Sound's great and it's pretty good on CPU too!.
Thanks for sharing this Cyto. Cheers mate.
cyto ·
Thanks for the feedback so far, guys!
Infusion, thank you for the optimization ideas. Though, I have to be nit-picky 😉
The exponent in the "gain-scaler" is 10^(-60/20), not (-60/20)^10. Quite a difference between .001 and 59049! But your point is well-taken: I should pre-calculate that stuff. If you saw an earlier version of this thing, you know why it is like that. I have gotten into the habit of having a lot of the scaling coefficients calculated like that so I only need to go in and change one value and the whole thing updates (and it saves me from digging into the modules). I thought I got rid of all of them (except the LPF/HPF ranges), but that one slipped by. To give you an idea...
About the "hop-on-demand"... I am a big fan of that technique, but in this case I'm not sure it would be that beneficial. There are 32 values that would need to be tested, and I think the logic involved in testing would certainly outweigh the fld/fstp routines that are run every 4096 cycles.
I will look into the asm reordering you suggested. That is that "final-frontier" of optimization that I haven't gotten too far into. Though, this particular code can be simplified even more before doing so (my interpolation routines are not the best here - I can easily half there CPU demand on them by doing some basic algebraic simplification). Honestly, I got kind of tired looking at this thing and just wanted to post it already!
But seriously, Thank you for the detailed critique! It certainly has given me given me some things to think about.
-cyto
trogluddite ·
Just wonderful, Cyto - that really brings something to SM that was sorely lacking. 😀
For so long, we've been stuck with reverbs that are all "tail" and no "body" - early reflections give to reverb what transients do to instrument timbre, and your design truly gives a sense of a real environment rather than the usual vague wash of generic "space". ER's like these are just the thing for giving life to a mix without having to swamp everything in mush just so that the effect can be heard - like many of the best reverbs, I get the sense that this baby will shine when subtlety is the order of the day.
The code can certainly be somewhat optimised, but without guys like you to suss out these fantastic algorithms, all the DSP coding tricks in the world would be a waste of time. 😇
Xtinct ·
Hey I wasn't joking about the KVR challenge this deserves to be up there and I'm sure with the help of all the people you have helped in the past you could win prizes and validate that SM isn't just a toy.
infuzion ·
cyto wrote: The exponent in the "gain-scaler" is 10^(-60/20), not (-60/20)^10. Quite a difference between .001 and 59049!
Oh little details! 😉
cyto wrote: About the "hop-on-demand"... I am a big fan of that technique, but in this case I'm not sure it would be that beneficial. There are 32 values that would need to be tested, and I think the logic involved in testing would certainly outweigh the fld/fstp routines that are run every 4096 cycles.
IIRC, Trog's technique is VERY efficient; only a few ops more. You could add all the green inputs together & input that sum to check. Depends on how much automation you expect; if none, then why re run every 4096? Maybe increase the hop(), or do Trog's trick?
cyto wrote: I will look into the asm reordering you suggested. That is that "final-frontier" of optimization that I haven't gotten too far into. Though, this particular code can be simplified even more before doing so (my interpolation routines are not the best here - I can easily half there CPU demand on them by doing some basic algebraic simplification)
It usually takes me 3+ rounds to optimize. I usually start with the math reduction first, though I don't always notice it until deep into the ASM.
trogluddite wrote: The code can certainly be somewhat optimised, but without guys like you to suss out these fantastic algorithms, all the DSP coding tricks in the world would be a waste of time. 😇
I agree!
DigitalWhiteByte ·
WoW, it works fine on an Intel Celeron M @ 900Mgz ~ 7-8% cpu meter inside SM.,
whereas it is not yet optimized by the whole community 🙂
Good Sound and Good Result.
If you have desire and time,
it would be nice to have some explanation of the whole algorithm,
formulas and links, also useful for us to understand the theoretical aspect of it.
Curiosity, you created this by using [name removed]?
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker