From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
100% ASM is best, but there is a faster Retrigger replacement.
This is the same as exonerate's last version that aliasant & I helped on, except I found a movaps xmm0,gatePrev; that needed to be trimmed, & I removed most linebreaks to use fewer Kb 😉
streamin env;streamboolin finished;streamboolin gate;streamout out;streamboolout kill;
float gatePrev=0;float release=0;float F4=4;float F0=0;float F1=1;float FM1=-1;
movaps xmm7,env;movaps xmm6,gate;movaps xmm4,F4;movaps xmm3,release;movaps xmm2,gatePrev;movaps xmm1,F0;
movaps xmm0,xmm2;cmpps xmm2,xmm1,2;andps xmm2,xmm6;
cmpps xmm0,xmm1,6;orps xmm3,xmm0;movaps xmm0,xmm6;cmpps xmm0,xmm1,0;andps xmm3,xmm0;
movaps xmm5,finished;cmpps xmm5,xmm1,0;andps xmm3,xmm5;movaps release,xmm3;
movaps xmm0,xmm2;cmpps xmm0,xmm1,0;andps xmm0,xmm7;andps xmm0,xmm6;addps xmm0,xmm2;movaps gatePrev,xmm6;
cmpps xmm6,xmm1,0;movaps xmm2,xmm3;andps xmm2,xmm4;addps xmm0,xmm2;movaps xmm1,F0;cmpps xmm3,xmm1,0;andps xmm3,xmm6;andps xmm3,FM1;addps xmm0,xmm3;
movaps xmm1,xmm7;cmpps xmm1,xmm4,5;andps xmm1,xmm7;movaps xmm2,xmm7;cmpps xmm2,xmm4,1;andps xmm0,xmm2;addps xmm0,xmm1;movaps out,xmm0;
cmpps xmm7,xmm4,0;cmpps xmm0,FM1,0;orps xmm0,finished;andps xmm0,xmm7;movaps kill,xmm0;
This uses 28 cycles on my Core2, while the old Code uses 51. Not all that many, but *4 envelopes, then you're talking 92 cycles, which is ~= a free AHD.
I do not think the Multiplex & last Selector is needed in the Gate either.
Tom7777 ·
+1 vote, imo all code based things should be ASM or highly optimized as much as possible 😀
TomC ·
Tom7777 wrote: +1 vote, imo all code based things should be ASM or highly optimized as much as possible 😀
-1 vote
If you release software with included source code the code itself should be readable and well documented.
The fact that you already know how to code doesn't justify to release such a mess so no one else can learn from it.
Comments/carriage returns get removed anyway when the code compiles, and saving 20 byte in ASCII in a time
where my mobile phone has about 250 times the capacity of my first hard disk is just sick.
Tom
infuzion ·
TomC wrote: If you release software with included source code the code itself should be readable and well documented
I agree, that is what the WIKI &/or extra downloads/install folders are for.
If you do not have fast & smaller (KB-wise) modules from the start, then you'll end up with situations like the one I'm in now. When I was hired to work on a VSTi, it had almost 26,000 modules, approaching 15Mb (that is a M for Mega) with no samples included. I refused to work on it until they did some drastic reduction, since I could not even edit it with out crashing & lagging. I'm supposed to get the CPU% from down 40% on a Core2 (where most pro-synths take only 8%) down to a reasonable level.
If SM had all modules bug free, fast & small as possible, the project manager would not have to spend another 000 just to make his synth reasonable with CPU & memory usage.
TomC ·
infuzion wrote: If you do not have fast & smaller (KB-wise) modules from the start, then you'll end up with situations like the one I'm in now. When I was hired to work on a VSTi, it had almost 26,000 modules, approaching 15Mb (that is a M for Mega) with no samples included. I refused to work on it until they did some drastic reduction, since I could not even edit it with out crashing & lagging. I'm supposed to get the CPU% from down 40% on a Core2 (where most pro-synths take only 8%) down to a reasonable level.
Almost all programs which run too slow and need too much memory do this by design, not by implementation details.
If malc would think the same as you your "optimized" module wouldn't exist at all, because you'd never understand the original one good enough to significantly improve it.
Fast and optimized code develops BECAUSE everything is well formatted and documented.
Just believe me in this one. If there's anything where I have some Uber-Yedi-knowledge than it's software
development (which, just to prevent this discussion, is not necessarily related to the programing skills of the people involved).
Tom
Tom7777 ·
Ok point taken, in that case the commented un-optimized version and another highly optimized version or as extra downloads but everything does need to be optimized highly mainly because Sm doesn't hold it's own against others cpu wise imo.
infuzion ·
It really depends on your goals:
SM for education: SM is great in how to learn programming in general, audio-math, how VSTs work, etc. Then all the comments & hand-holding is very beneficial. I agree with you 100% TomC that this is needed.
SM to create commercial VSTs: School is over for me, though I would like to learn more; I need to make money with my years of hobby-work. I'm sure I can reduce a VST in SM that is using 15% CPU currently down to a more professional level using ASM, given enoug time. But, the project I'm hired to do is trying to get CPU% down from 40%, the main issue right now is their matrix eating up 50% of the CPU. If I can't get their CPU% down, then I'll have to quit their project & advise them to find C++ programmers. I'm almost thinking it would be better for me to also take the C++ route, & just buy JUCE so I wouldn't have to start from scratch.
Tom7777 ·
Yeah i agree it's depending on what you want as you say, originally after using SE for a few years and having learned synthesis i moved onto SM which let me make things i was happy with sound wise but the problem that got much bigger for me over time is as i moved to making public vsts because i found that lowest cpu possible is probably the biggest thing in demand even though pc's are advancing and the thing is people are not willing to buy a whole new pc just so they can run loads of SM plugins when theres plenty of others out there that are alot more efficient there happy to use, so if you release things then lowest cpu possible is a must.
I agree you about the learning side as having a look at the c code helps a great deal but it's 2 sided really so you need both as lots will prefer to build than learn esspecially now the FL thing has happened im guessing. What i do when i comment things is use a text module, maybe you could have the optimized version as tool box standard but then inside have a text module or maybe a new code display only type thing with highlighting displaying the stages it went through with the original c version. Then i guess it could get documented also maybe as a more detailed wiki article too. We have a developer mode in SM so maybe there should be a pro/optimized mode where it swaps standard stuff for super efficient coded versions. 🙂
Im starting to replace as much as i can with the maths etc with code if i open SM because cpu always seems too high unless im making a simple effect etc but i still try to optimize those also. Cpu is ok in SM of course but much less so for synths to effects but for running multiple instances of plugins users will always avoid SM plugins for cpu etc and load times you only need to go over to KVR etc to see this for the majority of plugins, even for some of the best in peoples opinion that are mostly optimized asm code etc people avoid due to host problems or load times.
infuzion ·
Tom7777 wrote: We have a developer mode in SM so maybe there should be a pro/optimized mode where it swaps standard stuff for super efficient coded versions.
That could be an option.
Wrote something here? To have a post removed or your name hidden, write to [email protected].