From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Tom7777 ·
Recently i have been using a coded synth and the cpu is so much lower than my projects are, so my request is more optimized, cpu efficiant low level modules for all of us who can't code, because i notice low much lower the code based projects made with SM are also, from what i understand coded C oscs etc are way lower than the default and then ASM is even lower still, so yeah as i really can't code and i have tried to learn (know basic dsp stuff only) i would like more optimized stuff, i think the great thing with SM and SE and similar apps is that no coding is required, but it seems to me that coders have way more efficiant projects. 🙂
matti ·
To my knowledge you can't get any more efficient oscs in SM than the current toolbox 2048+ wavedraw stuff. If you know of any please let me know 😉
Most important thing in optimizing in SM in my oppinion is the way you organize things. You can save alot of resources by doing stuff with "simpler" ways than you first thought. Also limiting processing only to the things that need to be processed helps too. This is very true in redraw- and trigger management.
Analyze your schematics with counters to see what's going on. That's my advice 🙂
edit: Oh hmm.. did you mean coded synths as in coded with something else than SM? Like C++?
infuzion ·
Tom7777 wrote: ...more optimized, cpu efficiant low level modules for all of us who can't code
& faster higher level modules please. Always can use faster 🙂
Tom7777 ·
Well yeah i have tried recent c coded synths and you can have like 12 instances running in a host etc whereas my SM export you can get about 5, im sure that its possible to get lower cpu and it could also be certain combinations of modules etc could also have higher cpu than others, i guess i could try and turn all the maths into ASM which would no doubt lower it but the whole point of programs like SM is that you don't have to know code to make decent stuff, but i keep on getting the feeling im going to have to learn coding to compete with coded stuff etc all the time. Not saying that i havent had efficiant stuff made with SM as i have made various things which are fairly nice cpu and simple 3 osc va synths etc which are fine until you start adding nice new features and then they suddenly go up in cpu and theres others like modulated fx which can drain alot of cpu so i guess it varies with the different modules, i wasnt just refering to the oscs but all the other modules also but the oscs should be fairly highly optimized imo as they are the most commonly used. I mainly made this request because i can't see me learning to code well anytime soon so i use whats available to me in the selection available. 🙂
infuzion ·
Tom7777 wrote: Well yeah i have tried recent c coded synths and you can have like 12 instances running in a host etc whereas my SM export you can get about 5
I'm confused; are you writing new OSC in C++ or in SM Code? Of course your Code synths will run faster; you don't have sync, phase, anti-aliasing bandlimiting, etc? Your stripped OSCs may be handy for LFOs, but can they as full-featured as SM OSCs?
I find hand-coded envelopes are better than SM's ADSR4 primitives, but that is largely because I can alter the hop to 16 or even 64 & still be useful, I can knock out stages, etc. I also can re-code into ASM very well...
Devs: Let me know if you would like ASM reductions 😇
Tom7777 ·
I'm confused; are you writing new OSC in C++ or in SM Code? Of course your Code synths will run faster; you don't have sync, phase, anti-aliasing bandlimiting, etc? Your stripped OSCs may be handy for LFOs, but can they as full-featured as SM OSCs?
Sorry you read what i said the wrong way which is probably my fault, i have been making music recently with a synth that was coded in c (not sm code), i have a synth i have made in sm using standard modules with modifications, i was making a comparision in the efficiancy of both, the synth that was coded in c (not sm c) could run alot more instances than my sm made synth, i know i probably shouldn't compare the 2 but what my hope is that one day i will be able to make a synth in SM using defualt/stock modules supplied without having to learn asm or anything and have it run efficiantly a bit behind the coded (because im sure code can be optimized etc).
infuzion ·
Tom7777 wrote: ...my hope is that one day i will be able to make a synth in SM using defualt/stock modules supplied without having to learn asm or anything and have it run efficiantly a bit behind the coded (because im sure code can be optimized etc).
I agree 100%. The stock SM modules are cool to learn from, but I wouldn't use them as-is; I can get up to 25% CPU reduction optimizing them. That's why I made this posting:
SM's modules: efficiency vs readability?
I wrote Computer Music (UK mag) about them packaging some of my optimized modules in their DVD, but they decided to distribute a mini-full-SM instead. No love 😕
Tom7777 ·
Topics like this always seem to just pass by and never get much notice for some reason, anyways
Just came across this synth -
[old link]
Its a perfect example of high cpu in SM stuff, its a nice project, fairly reasonable size in term of features, no doubt put together with examples from various places which is a good example of using the community/forum in a positive way yet the cpu is fairly high still, i think projects like this should be 20% max and i think what the dev has done is fine, i still think thats a reasonable expectation and i still have a feeling certain combinations of modules can bump the cpu up, it still seems one has to learn to optimize to have a reasonable project when using default modules but should this really be the case. Imo the devs did a great job on loading speed so i have hopes that cpu will get focus next.
infuzion ·
Re-writing several stream math into Code into ASM is an easy way to gain 5-35% of CPU savings.
aliasant ·
infuzion wrote: Re-writing several stream math into Code into ASM is an easy way to gain 5-35% of CPU savings.
This is interesting.
I have started to use simple math stuff like x / + & - in code instead of the primitives and just learned that I can combine them like this silly example.
Streamin In;
Streamin B:
Streamin C;
out =( (In + B) * 2) - C
This works great and helps me save cpu and loading time but.
How would this look converted into ASM ??
Please make this example into ASM code so I can understand how to do this.
exonerate ·
aliasant wrote:
infuzion wrote: Re-writing several stream math into Code into ASM is an easy way to gain 5-35% of CPU savings.
This is interesting.
I have started to use simple math stuff like x / + & - in code instead of the primitives and just learned that I can combine them like this silly example.
Streamin In;
Streamin B:
Streamin C;
out =( (In + B) * 2) - C
This works great and helps me save cpu and loading time but.
How would this look converted into ASM ??
Please make this example into ASM code so I can understand how to do this.
you just connect a text component to the "S" string output,
So now i removed two movaps and the code now only uses the xmm0 register.
Very often you'll see unneeded movaps like that, I just comment them out and keep using the same register, you need to be careful though doing that on large sections of code sometimes the movaps is used to store an old value for use later on.
Oh and if your writing code in the code module connect a text component up so you can see the ASM , helps to find inefficiencies in your code while you type!
Is it possible to optimize?
I have a shitload of dezippers in my projects. Using them everywere.
If its possible to save some here it would matter in the end, even if optimizing only 1 would not accomplish much.
Tom7777 ·
Just wanna make sure i follow the simple bits of code as well i don't code hardly, this - out=(A+B)*0.5; would be from -
? Would be nice to have it lowered for non maths stuff but these optimization tricks are handy to know 🙂
It's already good optimized, but your can still remove one movaps instruction.
Tom
TomC ·
Oh, and while I'm at it: a lot of tanh stuff works with arctan as well, and for arctan I wrote an approximation with just 8 lines of SSE code.
Tom
rl ·
(thanks for giving me credits, aliasant 🙂 )
My opinion is: know what you're doing. Just connecting basic modules together would be a naive approach. For example: the standard oscillators are absolute overkill for LFO's in terms of memory consumption - because of the "mip map" tables for bandlimiting - and CPU power, since they run at sample rate.
To illustrate my point let's have a look at the standard sine oscillator. On my computer it has an average CPU load of 230 cycles/sample.
This is quite good, regarding the fact that the oscillator does also phase modulation and sync.
Here is a naive and simple implementation using the code module
streamin freq;
streamout out;
out = sin1(phase);
but not too much. The problem is the expensive sin1 call per sample.
Now I could try to optimize the sine call until the police comes, but I just use another algorithm instead:
// sine osc using the magic circle algorithm
// Rudolf Lindner, 2006, rlma-labs.de
streamin f;
streamin A;
streamout o;
float sin;
float cos;
float mul;
stage (0) {
sin=0;cos=1;
}
hop (32) {
// mul=2*sin(pi*frequency/samplerate)
mul = 2*sin1(0.25*f);
}
sin = sin + mul * cos;
cos = cos - mul * sin;
o=A*sin;
This takes only 82 cycles/sample! (beats the standard osc by a factor of 3)
The interesting thing here is that I could put the expensive sine calculation into a hop() block, since it's only needed when the frequency changes (in this case it's not suitable for phase/frequency modulation at sample rate). Outside the hop the algorithm needs just 2 muls, 2 adds and 2 assignments.
This is even faster than interpolated wavetable lookup.
Since a hop(64) does no give any significant improvement, there is no need to further optimize the sin1 call.
In good synth/effect SW you will find all sorts of this tricks. It's a matter to judge when and how optimizations are appropriate.
Since I'm on topic:
Unfortunately there are things that can be done by connecting primitives and there are things that can be done using the code module.
For optimization purposes either the primitives would need some hop functionality (especially FloatArrayToPoly and Mem WaveRead) or the code module needs handling of arrays and Mem data. This has been requested a number of times before.
infuzion ·
exonerate wrote: The ASM can be reduced....
streamin In;streamin B;streamin C;streamout out;float F2=2;
movaps xmm0,In;
addps xmm0,B;
//movaps xmm1,xmm0;
mulps xmm0,F2;
//movaps xmm2,xmm1;
subps xmm0,C;
//Assignment> sLeft=xmm2
movaps out,xmm0;
You have done well wise ASM student.
When one wishes to move the rock, one must also look at the ground as well as a rock. So to become a red-belt ASM Master, one must also consider algebra in the light. Remember when you were a grasshopper, how x*2=x+x. Thus:
//mulps xmm0,F2;
addps xmm0,xmm0; //saves 2-3 cycles from using + not * and not fetching F2
😉
There are some great tips in this thread! We could re-program SM's Code in the shipping modules in ASM & post them on the WIKI.
aliasant ·
This is turning out to be one great thread!!!
Rubbing my three brain cells as hard as I can.....
infuzion ·
aliasant wrote: Rubbing my three brain cells as hard as I can.....
LOL How about a cheat sheet:
[old link]
aliasant ·
infuzion wrote:
aliasant wrote: Rubbing my three brain cells as hard as I can.....
infuzion wrote:
//mulps xmm0,F2;
addps xmm0,xmm0; //saves 2-3 cycles from using + not * and not fetching F2
😉
Do you know of an online manual where the number of cycles per SSE instruction are listed?
I had already a hard time to find the complete SSE syntax.
Thanks.
Tom
infuzion ·
TomC wrote: Do you know of an online manual where the number of cycles per SSE instruction are listed?
see link I posted above 😀
stefan ·
TomC wrote:
infuzion wrote:
//mulps xmm0,F2;
addps xmm0,xmm0; //saves 2-3 cycles from using + not * and not fetching F2
😉
Do you know of an online manual where the number of cycles per SSE instruction are listed?
I had already a hard time to find the complete SSE syntax.
Thanks.
Tom
It's not really as simple as number of cycles. The number of cycles to execute a mul is just one afaik, but the latency is higher than of an add maybe. Latency is fairly important these days, and you can optimize your code by making sure to execute calculations as far ahead as possible (meaning that you don't need the result until a few instructions later).
TomC ·
stefan wrote: It's not really as simple as number of cycles. The number of cycles to execute a mul is just one afaik, but the latency is higher than of an add maybe. Latency is fairly important these days, and you can optimize your code by making sure to execute calculations as far ahead as possible (meaning that you don't need the result until a few instructions later).
That's quite interesting. So if I understand you correctly, when I have to compute something and put the result into xmm0, and I use xmm0 for another computation this new computation has to wait until the first one has finished?
Any further reading about that?
Cheers,
Tom
stefan ·
TomC wrote:
stefan wrote: It's not really as simple as number of cycles. The number of cycles to execute a mul is just one afaik, but the latency is higher than of an add maybe. Latency is fairly important these days, and you can optimize your code by making sure to execute calculations as far ahead as possible (meaning that you don't need the result until a few instructions later).
That's quite interesting. So if I understand you correctly, when I have to compute something and put the result into xmm0, and I use xmm0 for another computation this new computation has to wait until the first one has finished?
Any further reading about that?
Cheers,
Tom
You are indeed correct sir!
Dunno where to read more about it. Google "instruction latency" or something 🙂
Acrobat ·
aliasant wrote: Rubbing my three brain cells as hard as I can.....
... and my 2 are doing the same... 😉
infuzion ·
stefan wrote: It's not really as simple as number of cycles. The number of cycles to execute a mul is just one afaik, but the latency is higher than of an add maybe. Latency is fairly important these days, and you can optimize your code by making sure to execute calculations as far ahead as possible (meaning that you don't need the result until a few instructions later).
I miss-read the chart; you are correct 🙂 But that mul does have a slightly longer latency, & I think it costs extra latency &/or cycle to fetch data from a memory location verses a xmm register.
Something notable from Intel®64 and IA-32 Architectures Optimization Reference Manual, Order Number: 248966-014, November 2006
Although instruction latency may be useful in some limited situations (e.g., a tight loop with a dependency chain that exposes instruction latency), software optimization on super-scalar, out-of-order microarchitecture, in general, will benefit much more on increasing the effective throughput of the larger-scale code path. Coding techniques that rely on instruction latency alone to influence the scheduling of instruction is likely to be sub-optimal as such coding tech-nique is likely to interfere with the out-of-order machine or restrict the amount of instruction-level parallelism.
Not 100% sure what that means, but sounds like messing with the calculation order might not be a good idea?
Acrobat & aliasant: I learned to Peek & Poke code for the Comadore64, & learned some assembly in collage years ago or just before that. B)
stefan ·
infuzion wrote: But that mul does have a slightly longer latency, & I think it costs extra latency &/or cycle to fetch data from a memory location verses a xmm register.
Correct, registers are much faster to read/write than variables in memory.
Regarding the rest, well, FWIW, almost all audio DSP is tight loops with exposed latencies in their dependency chains 🙂
infuzion ·
stefan wrote: Regarding the rest, well, FWIW, almost all audio DSP is tight loops with exposed latencies in their dependency chains
Urmm... stefan I imagine you're Swedish, but can you re-say that in plain English please? 😇
Acrobat ·
infuzion wrote: I learned to Peek & Poke code for the Comadore64
30 millions users can't be wrong! 😉
stefan ·
infuzion wrote:
stefan wrote: Regarding the rest, well, FWIW, almost all audio DSP is tight loops with exposed latencies in their dependency chains
Urmm... stefan I imagine you're Swedish, but can you re-say that in plain English please? 😇
Why yes I am 🙂
I was just referring back to what you quoted:
Although instruction latency may be useful in some limited situations (e.g., a tight loop with a dependency chain that exposes instruction latency)
and stated that most DSP code consists mainly of such tight loops.
infuzion ·
I really hope SM's (and others') modules will be updated to speed-optimized versions soon. Almost every synth-posting on SM's forum I reply with "CPU is too high". I think if someone were to ask me today if they just wanted to make useful VSTs for others, I'd have to recommend SE over SM, since SE has many modules out there that simply run faster. Sorry 🙁
Tom7777 ·
I think if someone were to ask me today if they just wanted to make useful VSTs for others, I'd have to recommend SE over SM, since SE has many modules out there that simply run faster. Sorry
Same here, you can make very nice stuff due to the low level workflow but if your going the non code route i have to agree SE wins in terms of cpu.
infuzion ·
Tom7777 wrote: Same here, you can make very nice stuff due to the low level workflow but if your going the non code route i have to agree SE wins in terms of cpu.
Actually, SE can make faster or higher-quality ASM as well, since SE has a C++ SDK, therefore allows full ASM including SSE2,SSE3, etc. So SE has access to SSE shuffling, 64bit SSE... & some SE modules are coded in SSE. Just that speed might not be in the entire SE audio path.
So, I use SE as a baseline comparing speed & quality with SM VSTs. Bones/Novakill can make some good VSTs in both sound & decent CPU, since he uses some tight (3rd party) SE modules. SM cannot compare out of the box once you add effects, & maybe even LFOs. It takes ALOT of SSE re-coding & some green optimization to make SM comparable IMHO. 😝
stefan ·
But, uhm, what if you'd use tight 3rd party modules (in SM that is)? 😉 (sorry, couldn't resist).
I get where you're coming from though. And, well, I agree to some extent, I fear the main issue is that the toolbox would have to maintain both "easy-to-understand/use" AND highly optimized ones.
Maybe highly optimized versions of certain key components could be user developed and maintained on the wiki for now?
infuzion ·
stefan wrote: I get where you're coming from though. And, well, I agree to some extent, I fear the main issue is that the toolbox would have to maintain both "easy-to-understand/use" AND highly optimized ones.
Maybe highly optimized versions of certain key components could be user developed and maintained on the wiki for now?
That was the entire point of this poll I posted almost a year ago. Most feedback & the majority of (the few) votes said atleast optimize code on the WIKI, & most voted for shipped in the toolbox.
But, nothing came from it from either devs or users. So I pasted some notes in the WIKI to teach others how to do it. And still no SM-optimized code. 😠 It take alot of time to truly optimize; I got exo's great Multi-stage Env faster & smaller about 30 hours of work, I my fork is even 4% less CPU in the green code (& I'm not done optimizing yet).
I don't mind helping out, but I'm not a fast coder, & I have alot on my plate. I plan on making a VST which I'll sell about 50-200USD, then focus on DJing both as a way to sell songs I make from using my own VST & to make personal contacts to sell the VST & songs. I have an open door to DJ at "The Church" down the street from me, which won Winter Music Conference's Best-Club award (I think in the world) for 3+ years of its 8 years of existence. & it was bought out by the same owner of BeatPort.
So, if I think my VST won't make the cut to sell for 50+ (eg too slow, too flaky in Live/Cubase, or take too long to re-code), I'll simply leave SM, the SM forum & WIKI, then solely focus on DJing & making music. I'm going to give about 2-4 weeks to decide. Sorry I don't want to sound like a cry baby or too harsh, but business is business.
stefan ·
Of course 🙂 You do as you see fit. FWIW, what you put into this community is great, imo.
Regarding user efforts
It's just that a lot of users (not just you!) optimize their schematics. AND release them. It's just that the modules doesn't get to the WIKI. I'm not entirely sure the WIKI speaks to peoples will to share what they create and something else might serve that purpose better.. This is definately not an issue about laziness, because there's lots of users doing heavy SM work, so it's obviously about something else, and it might just be the WIKI itself that is the issue. Should probably be discussed elsewhere though 😉
infuzion ·
Thanks for the complement.
stefan wrote: It's just that a lot of users (not just you!) optimize their schematics. AND release them.
Well, I don't see that many optimized OSMs, a few hacks with ASM (like the pseudo-sine), but that is it (what am I missing?).
Back on topic:
I think that if someone paid for SM, esp the Standard Edition which is for real money, they would expect to be able to produce pro-level VSTs fairly easily, from the toolbox & a bit of programming. But you can't from the toolbox, you can make a cool VST that eats half your CPU, but nothing sellable IMHO. & there are so many free/cheap VSTs that are both cool & decent-speed (thanks to SE & free SDKs), I don't keep CPU hogs on my HD, nor would I expect my users to. & most don't know ASM, nor want to learn the minute details about all the primitives.
==
Personally, I'm shifting to a more you-scratch-my-back, I'll-scratch-yours approach rather than put everything on the WIKI. I'm starting to share only with a select few in private in exchange for help. Unless someone wants to pay me 😉
stefan ·
I guess we might have different reference points regarding what is decent performace. As long as an advanced synth uses less than like 20%, and a simple one less than 10% on my CPU I'm usually happy with it's performance and I've tried plenty commercial VSTi's that has had worse performance than somewhat equal SM VSTi's, even if it's not the norm (there are several quite new one that easily ends up needing more than all my CPU power when doing normal things on the keyboard). I usually find that for instance AngularMomentums creations have quite good performance, even though he doesn't go the ASM route.
Usually when CPU usage skyrockets, I find that it's not due to lack of low level optimization, but high level dito. Both when it comes to my own and others creations. When comparing specific scenarios with C++ or SE equivalents SM really isn't bad in the general case. There might of course be certain scenarios where it excels and others where it does somewhat the opposite.
But, to take "your stance" for a wee bit, I think the good performance creations might drown in the noise, so to speak 🙂 But I think for instance a lot of the stuff in the examples section performs quite well.
Tom7777 ·
I think that if someone paid for SM, esp the Standard Edition which is for real money, they would expect to be able to produce pro-level VSTs fairly easily, from the toolbox & a bit of programming. But you can't from the toolbox, you can make a cool VST that eats half your CPU, but nothing sellable IMHO.
Thats exactly how i feel, i have the ideas, in SM i can create them but the cpu is just not at a professional level imo, it's reasonable of course but could be way better, i use alot of low level stuff which i have made or customized from various forum things, i tried optimizing the other day by changing maths and code modules to asm and still didn't lower it much unfortunately. People like to use as many instances as they can in music projects they make and when a SM synth with a few fx is around 25-30% or more plus the big company synths can be less than that but way more complex so they choose another synth to work with than the SM synth.
Nu Audio Science ·
I think anybody can see currently that SM stuff is way higher CPU than other languages it can be compared to and that includes SE and C++
I can easily create a very basic synth or a very complicated one in SE and SM to prove the point
However SM does have the advantage of once you have created something you can revisit and optomise it and normally get very good CPU reductions
It will never have a chance against optomised C++ coding but it can come pretty damn close to SE
The more worrying thing for me at the moment is the fact that SM is getting the reputation that on sound it is pound for pound worse than SE for more CPU
This has been hinted at a few times on different forums and it wont take long for the hints to turn to facts (We know what forum are like)
At the moment i dont SM as anything more than hobbyists creating designs that may want to recoup a little of there hobby time by selling something interesting
No serious company or any individual that is serious about starting a company creating software will use SM as there sole creative force
Now having said that does SM have a place within a serious company
Very much so without a doubt
If you prototype something in SM and then take it to C++ for optimising and portability to other pltforms you will find it much easier than doing the same thing from SE
For it to be the number one vst prototyping tool it would be nice to haqve a save as C++ option but i doubt very much that that is going to happen anytime soon
By the way i know of at least two major VST developers that have in house systems very similar to SM for prototyping and one of those devs has told me that theirs is no way as complete as SM but does have the save as C++ option and no save as VST 🙂
All being said i think SM has its place
NAS
Tom7777 ·
True, however i do think SM should be able to be used to make serious projects, the whole point of the program is that you don't have to be a coder to make something nice, and for coders it a great way to test and prototype things but also have efficient projects via coding.
I think it is possible for SM to go the next step and have efficient working projects, with SE even stuff that just uses the default stock modules can be efficiant and i have tried a lot of good stuff like this which maybe used 1 or 2 3rd party modules, because i think thats been a focus of it's development, the thing with software like this if nobody complains about certain things nothing will ever happen and everything will be assumed is fine, until people started talking about the load times nothing happened for a while which is why i made this thread as i think cpu should be the next major focus, i think the team did a good job on the load times so im sure they can work on the low level module efficiancy and lower that so even non coders can have nice projects running, not on par with some coded stuff of course but close behind, at least i hope so.
Nu Audio Science ·
Yeah i should have stated that in my post to be honest
I have more faith in the devs of SM than i do in most devs and i think that optimisation will be something they get into more and more as time goes by
I dont however think it is going to be a quick thing to achieve but i do believe they will do it
You are right to think that SM will and should be useable as a serious platform and i believe that eventually it may even be on par with C++ in terms of CPU usage pound for pound
However at the moment i honestly believe that the package needs to become a lot more complete than a lot more optomised to be truthful
Maybe its just me but there ya go
NAS
Tom7777 ·
In terms of being complete i think the program features are very user friendly already and alot of bases have been covered, i think other than a few new modules for midi and sampling etc the program allows you to do quite alot of stuff and on the forum alot of the major elements have been done in terms of controls, fx and mid level features etc, but the green based engive needs to be done for sequencing etc which is another major thing also and then theres mac ports etc but i think that should come later myself as SM is becoming more recognized now and stuff is being released with it as we speak so efficiancy is effecting things right now, but yeahs theres all sorts of stuff to come but personally i think that this should be next or at least fairly soon but an on going thing for development, imo with all the FL stuff happening the teams busy at the moment but my hope is this will be soon and modules can be added over time with new releases. Also with the FL thing optimized stuff would be a benifit as much for the FL users as there going to want to have as many instances going in a track as they can get with there creations. 🙂
Eska ·
I am working on a commercial synth that uses ~0.7% per voice on my E6600,2.4GHz Dual Core. Only 40% of the code is optimized yet. Means: It`s not only ASM. It is about organizing, deciding where to hop, to interpolate, to multiplex datastreams ect. In SE you need C++ to to do that. Here it`s fun.
Nu Audio Science ·
Fiarplay to you Eska
I have seen stuff recently that i thought was very acceptable on the CPU front too for what was happening 🙂
Also i have found in recent times that FX created in SM are very comparable to other languages
NAS
Tom7777 ·
I am working on a commercial synth that uses ~0.7% per voice on my E6600,2.4GHz Dual Core. Only 40% of the code is optimized yet. Means: It`s not only ASM. It is about organizing, deciding where to hop, to interpolate, to multiplex datastreams ect. In SE you need C++ to to do that. Here it`s fun.
Yeah but were talking about when not coding here really 😉 Coders can have very efficiant stuff yeah but if your using stock modules you get way higher cpu than that for sure. I don't think one should have to learn how to code but it almost seems that you have to learn it with SM in it's current state to have an efficiant project.
stefan ·
Tom7777 wrote:
I am working on a commercial synth that uses ~0.7% per voice on my E6600,2.4GHz Dual Core. Only 40% of the code is optimized yet. Means: It`s not only ASM. It is about organizing, deciding where to hop, to interpolate, to multiplex datastreams ect. In SE you need C++ to to do that. Here it`s fun.
Yeah but were talking about when not coding here really 😉 Coders can have very efficiant stuff yeah but if your using stock modules you get way higher cpu than that for sure. I don't think one should have to learn how to code but it almost seems that you have to learn it with SM in it's current state to have an efficiant project.
To some extent I disagree. I think both creations you've made and others (like the aforementioned AngularMomentum) have good performance without either of you resorting to code. High level optimization is usually more important than low level dito. But not always.
infuzion ·
stefan wrote: I guess we might have different reference points regarding what is decent performace. As long as an advanced synth uses less than like 20%, and a simple one less than 10% on my CPU I'm usually happy with it's performance...When comparing specific scenarios with C++ or SE equivalents SM really isn't bad in the general case.
I also look for under 10% on my Athlon64, but 10% with synths that are complex, since I will depend on Live in live situations, & need the headroom. I'll only will use a high-CPU synth/effect if I can reduce the amount of parts enabled in it (turn off effects until it dips below 10%). I won't use a hungry CPU but cool synth like Computer Music's Dominator, unless I'll make samples out of it or will freeze the track, but only on rare occasions, & I have very very few of such synths on my HD.
Really the only way to test CPU properly is to have the same synth & effects made in C++, SM, & SE.
NAS, yes I don't expect make a living off of SM, only sell perhaps 1-2 copies at 50+. & Some % will go to other SM authors that I used their modules, & some will be given free to other freeware authors. I think SM's devs are great, but they have alot to do with squishing bugs, supporting FL, SMX, etc, But I don't expect optimized modules out of them. I think they (perhaps correctly) that users will prove it, but now after a year later of me encouraging that I haven't really seen that movement. & I feel I've done more my share in this department. I will swap behind the scenes with you & others optimized modules though 😉
NAS/Tom-dan: I agree w/usability; I think SM's strong suit is that it is great to learn with.
Eska: SM's Code sometimes produces good ASM on its own, esp. when compared with regular C++. Also, Intel's core is VERY fast with ASM, both compared with AMD & their own PentiumD & M. & I think SM has decent CPU with OSCs, though the sync issues are a disappointment. Really my issue is with any module that is has alot of green primitives &/or big CODE/stream math primitives, which are SM knobs, effects... The OSCs are decent, & the Code ENV are decent CPU wise but could be better.
Tom7777 ·
Well imo, my effects are fair depending on what they are, like i made a multi band phaser which was around 56% no doubt it needs optimized allpass filters etc for the 8 bands however i can't code that, reverb can also get high, i have had way lower effects also though but my synths are usually around 20-25% and i use alot of techniques to lower the cpu as much as i can like turning things off when set to 0 etc but when everythings running like a few effects sections they can be 35+% on my pc anyways and i don't really think thats too efficiant. I use mostly low level stuff and not coded, true most stuff can be fair in general but in a commercial view it could be alot better especially for the more simple things.
rl ·
SM isn't that bad in terms of performance, but there are little bits missing
here and there.
I personally would like to see a much more complete code module e.g. supporting memory or float array in's and out's, loops using variables, etc.... Maybe even a non-SSE able code module.
Why not release an audio SDK? So everyone and me is free to build his own stuff and could stop whining about missing features, bad perfomance,....
Rudolf
Tom7777 ·
Why not release an audio SDK? So everyone and me is free to build his own stuff and could stop whining about missing features, bad perfomance,....
Well that would be cool i think and would allow the devs to focus more on key developments if they didn't have to worry about new modules all the time. But also i think optimization would still be important for anyone who wouldn't be coding there own modules and needed a certain feature etc and would be making it using low level modules. There would be no point in them if they would just be replaced by 3rd party ones really, i think there is however if there made stable and very efficiant code wise inside which is what im hoping will happen. Again there reasonable but could be better.
aliasant ·
Nu Audio Science wrote:
Now having said that does SM have a place within a serious company
Very much so without a doubt
If you prototype something in SM and then take it to C++ for optimising and portability to other pltforms you will find it much easier than doing the same thing from SE
For it to be the number one vst prototyping tool it would be nice to haqve a save as C++ option but i doubt very much that that is going to happen anytime soon
NAS
Since Im not a coder but more a visual designer of sorts, I dont fully understand all this but it makes me dream of a possibility to convert my SM plugins to other formats. Like the Mac?
Explain to me and the other dumbheads here what a "save to c++" would let us to do.
Is there anyone here that has ported a SM creation into other platforms?
Is it at all possible?
Anyone here knows how to do this?
Nu Audio Science ·
Well SM is closer to the paradigms followed by coding a lot more than SE which is closer to the paradigms followed by analogue modulars
This basically means a coder could in effect look through a design in SM and gradually work out how to code it quite well where as in SE this isnt really the case
I would even go as far as saying that if you programmed a lot of things in low level components inside SM you would find it easy to cross over to C++ once you actually understood the C++ paradigm
We are not talking languages here but moreso DSP coding and the same applies between languages to be honest
So DSP in SM is pretty much designed the way DSP is in any other language
Limitations and so on in the code module aside 😉
NAS
TomC ·
rl wrote: I personally would like to see a much more complete code module e.g. supporting memory or float array in's and out's, loops using variables, etc.... Maybe even a non-SSE able code module.
If the code modules were more complete (see here) and we'd have a similar code module for green stuff the SM devs could do what they can best and the coders around here could do all the optimizations to their liking.
And make the modules lockable so people won't need to worry about releasing their genius ideas for free.
These are changes which do NOT need a lot of development from the SM people, do NOT change the paradigm of SM (like allowing external .dll would) and would still serve both sides.
And it could be implemented in a couple of weeks. I'd be the first one to beta test it for free
Tom
TomC ·
Addentum:
stefan, we have some really good coders like infuzion and rl around here.
Provide them the tools they need and YOUR product will improve. It'll be a win-win situation!
Tom
infuzion ·
First thing; I want to make it clear I expect SM's VSTs to sometimes be a bit slower, because of the overhead. That is why I like to compare SM with SE. & I'm not going to keep arguing if a SM-VST-x is fast enough or not; this is subjective, depends on your CPU, host, etc.
Simply said, SM's shipping modules can (& IMHO should) be much faster & smaller.
rl wrote: Why not release an audio SDK?
oh no not that can of worms again! 😮 LOL
TomC wrote: If the code modules were more complete (see here) and we'd have a similar code module for green stuff the SM devs could do what they can best and the coders around here could do all the optimizations to their liking...These are changes which do NOT need a lot of development from the SM people
Jorge was working on adding LUA to SM, as part as the SynthMakerX project. With it, all your dreams of green code will come true, + more. Very alpha, but did have some meat functionality. No new news in a year now on LUA though. I'm not sure if it will speed up smaller sections of green code, but I think something like the MSE would, or atleast easier to code & read.
Tom7777 ·
I think Infuzion said that sync'd modules slow down SM when building, im probably wrong but i don't think they reduce cpu and only help when using multiple modules in a project that need to be the same, in a email to malc i just sent i suggested if they don't reduce cpu that maybe they should if possible, again im probably wrong but i think in code you can lower cpu with commands if a section of code is doing the same thing multiple times so it would be great if possible to apply that to the compiled code, certain things can use lots of the same things so if it's possible to do i think this would allow for huge cpu reductions. 🙂
infuzion ·
Tom7777 wrote: I think Infuzion said that sync'd modules slow down SM when building
I was referring to editing, not final VST. Examples; alot of sync'd modules will make the OSM open slower, slower to open up modules, copy/paste, etc. (really per Malc, but I can see a correlation myself)
Acrobat ·
infuzion wrote:
Tom7777 wrote: I think Infuzion said that sync'd modules slow down SM when building
I was referring to editing, not final VST. Examples; alot of sync'd modules will make the OSM open slower, slower to open up modules, copy/paste, etc. (really per Malc, but I can see a correlation myself)
...true, anyway, I noticed that rationalizing in general terms (white, blue, greens, yellows, whatever) reduces loading times as there are less varaibles calls when the instrument is choosen up from the host...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker