Solution proposal for optimized SM modules

Acrobat · 1 Nov 2008

Agreed! 😀

Tom7777 · 1 Nov 2008

It's a nice comparison method for sure, a multiplexor method with more than 2 versions might be better though say if you had a standard code version also or there was a different way to do it etc. i think that would be better if your meaning to post for others to use, what i do is have a extra folder atm called optimized and just put any decent optimized things in there, not organized due to the no sub folder limitation but i know where they all are at least.

But yeah at the end of the day one only needs to use a single optimization, for the wiki it is great but having more modules than needed for a function only increases filesize so for a system inside SM i dunno. I would rather if it was ok with the optimizer that there was just 1 module as standard in SM as a updated default module but if it had no negative effect over filesize it's a good idea but i can't see why you would want to use a more cpu heavy version myself still if it had been optimized so imo if added in a replacement to the old one would be best.

TomC · 1 Nov 2008

Tom7777 wrote: but i can't see why you would want to use a more cpu heavy version myself still if it had been optimized so imo if added in a replacement to the old one would be best.

- you get the CPU heavy version when you buy SynthMaker, that's why you use it

- if malc finally includes auto-replacement of old standard modules/primitives with newer ones you can easily compare your optimized version against the new standard version without changing the schematic.

- I don't think size is a problem, drives are large and fast, one single wave file in a wave player module is much much bigger. The default size of a SM plug-in is about 1 MB, but it doesn't grow much even when you add hundreds of modules.

- if you really can't sleep because of the file size you can (especially as a beginner) easily remove what's not needed. It's much easier to remove something than to put something together.

Tom

exonerate · 1 Nov 2008

Interesting Idea, adding extra to the file size is not really an issue, but one that is, would be that the editing in SM can become very slow with a large amount of modules, so it would be more of a consideration on that side rather than the resulting file size I think.

The way I see it you would never actually want to use the unoptimized one, so it seems kind of redundant to have it connected to the stream at all, and also you need to take into account the over head of the selector, If I remember correctly it's about 50 cycles for the selector, so by having it set out the way you have it unless the module is super optimized more than the overhead of the selector, there's no benefit from using the optimized version, in fact it could turn out more.

I think with the case of code, the best way to do that I think would be to have the original algorithm coded in normal code and convert that to ASM and use the ASM version labeled "ASM optimized version" and next to it have the normal code in a purgable module named "original code". I would be happy with that because the original code is there to learn from, but you are using the hardcore optimized version which is the version everyone will want to use.

For me this is the only way forward, I want SM modules to be as fast as possible, but if I'm learning I want some easy code to read, so use the ASM and include the easier to read code next to it in a purgable module.

I'll admit your method is great for testing while coding, in fact I do a similar thing myself to make sure I'm not messing the original algorithm up while optimizing, but as an end result to be used, no, it's just adding extra unnecessary overhead when the aim is to optimize........ seems a bit counter productive to me.

Cheers 😉

Exo

infuzion · 1 Nov 2008

TomC wrote: Tom7777 wrote: but i can't see why you would want to use a more cpu heavy version myself still if it had been optimized so imo if added in a replacement to the old one would be best.

- you get the CPU heavy version when you buy SynthMaker, that's why you use it

- I don't think size is a problem, drives are large and fast, one single wave file in a wave player module is much much bigger. The default size of a SM plug-in is about 1 MB, but it doesn't grow much even when you add hundreds of modules.

- if you really can't sleep because of the file size you can (especially as a beginner) easily remove what's not needed. It's much easier to remove something than to put something together.

While in the testing-research phase, this techique is cool, but I'm sorry but I have to 100% disagree with you for actually producing the VST.

1) IMHO, I think one of the reasons SM hasn't really taken off is because SM's modules are so CPU heavy. While assembling a VST is fast, I rarely would use one in real life since I know there are other VSTs (either free or ones that ship with my DAW) use 30-50% less CPU, & are likely use less memory also! I automatically assume all SM-VSTs I see posted on KVR are hogs, & avoid accordingly.

Also worth noting, I'm basically charging a project manager 5-20 extra hours since the SM-standard modules weren't optimized. The schematic got so big (file-size), that it is almost too sluggish to edit even on my 1 year old computer! & for several reasons the CPU is about 50% of 1 core; totally unacceptable for a commercial VST with its capabilities.

SM can make VSTs that are very good on CPU & OK memory-size, but it takes ALOT of pre-optimizing before you start to assemble it.

2) Like I said/linked above, larger OSMs are harder to edit.

3) Copy, pasting, re-linking a ASM block is tricky enough on a larger OSM. Reducing (file-size) GUI many elements, even if they're sync'd like if you have a dozen knobs for 2 ADHSRs, have to be done 1 by 1 since you'll lose the preferences (& location) as you copy & paste.

The more reduction work done ahead (or better yet for you already) the faster you can edit your OSM, & the more professional the results will be. Size & speed still matter even with stronger computers, since people will expect to run more VSTs with a newer computer.

Exo: IIRC, a Selector uses @16 cycles on a AMD64, @4 on my Core2Duo. Not a biggie, but adds up after a while. Perhaps much more if you have many inputs?

TomC · 1 Nov 2008

exonerate wrote: the over head of the selector, If I remember correctly it's about 50 cycles for the selector, so by having it set out the way you have it unless the module is super optimized more than the overhead of the selector, there's no benefit from using the optimized version, in fact it could turn out more.

Outch, you're right, I'd never thought that the Selector/Multiplexer needs THAT much cycles, after all it's just a single connection when switched to one position. I just verified this, both together add (depending on how you measure) somewhere between 45 and 84 cycles to the show. Bummer...

Forget my proposal.

and next to it have the normal code in a purgable module named "original code". I would be happy with that because the original code is there to learn from,

That's what I'll do in the future

Sorry for wasting bandwidth...

Tom

infuzion · 2 Nov 2008

TomC wrote: exonerate wrote: ...and next to it have the normal code in a purgable module named "original code". I would be happy with that because the original code is there to learn from

That's what I'll do in the future Sorry for wasting bandwidth...

I think it is good to think things aloud; perhaps we all can learn something here. It would be a good idea to change the post's title in the 1st posting, so Malc knows to ignore.

aliasant · 2 Nov 2008

Hm.

I alway s place the original code under the asm code in the asm window.

If I need it I can copy it from there and paste it into a code window and start editing it.

It is very simple.

Just type like this under the asm code. ( I know most of you already know this.... )

/original code. streamin in; streamout out; out = in;

I often find myself wanting to change something in a asm code and having to look for it elsewere is not fun so if its right there under the asm code its easy. I always know were to look for it.

Wouldnt that be a good standard thing to do?

infuzion · 2 Nov 2008

I prefer the actual module I use to be small as possible, with all comments & original code on the outside of the actual module.

exonerate · 2 Nov 2008

TomC wrote: That's what I'll do in the future

Sorry for wasting bandwidth...

Tom

Hey no worries, 🙂 I think working out a standard is definitely a good thing, So we can all adopt the same methods and try and get them used in the standard toolbox modules as well.

I used to be more in the legibility camp as far as modules go, but now I'm starting to think f**k it, make them as fast as possible. As far as I can tell from reading a few forums, SM has got a bad reputation for high CPU usage, now I think some people just don't get the SSE thing and don't understand you get four voices for one and are pressing one note and thinking WTF? But regardless of that, some of SMs modules need seriously optimizing, firstly all the envelopes (except Multi stage, I optimized that 😉 well could be ASM'd though I guess) need to be scrapped and done again with a more efficient method, I think it was Zynewave who posted an ADSR a while back that was very efficient as well as very easy to read and understand, SMs env's could be based on that algo. Then that could be hardcore ASM optimized and the result would be super efficient envelopes.

Also I've mentioned this too many times, but why the hell does the high level LFO module use bandlimited oscs?? CPU for this module can be halfed by using non bandlimited versions.

Also I think a big problem SM has is it says "make a synth without writing any code" or something, which is ok if your not arsed about CPU usage, but most are, and to make anything half way efficient in SM you HAVE to use code, so this will be putting people off from using SM, and thoughs that it doesn't put off are learning how to code when the whole reason they started using SM was so that they didn't have too!!

So Seriously something needs to be done, all modules that ship with SM should be hardcore ASM register optimized with the original code next to it, so if anyone does feel the urge to alter or play with the code they can, they'll just have to connect up the original code and alter that.

I think we need to get a standard agreed upon, then convince malc to adopt this in SM, If malc will agree to have the standard in all modules, then we as a community can work together and get everything super optimized, with legible code included next to the ASM, and have malc add them all as defaults.

I'm pretty sure malc would be reluctant to go this route, but Synthmaker is marketed and aimed at people who don't want to code, if they don't want to code they surely don't want to optimize either, so everything should be as efficient as possible, other wise your aiming at the wrong bloody market, surely.

Cheers 😉

Exo

infuzion · 3 Nov 2008

exonerate wrote: I used to be more in the legibility camp as far as modules go, but now I'm starting to think...make them as fast as possible. As far as I can tell from reading a few forums, SM has got a bad reputation for high CPU usage... But regardless of that, some of SMs modules need seriously optimizing, firstly all the envelopes (except Multi stage, I optimized that 😉 well could be ASM'd though I guess) need to be scrapped and done again with a more efficient method, I think it was Zynewave who posted an ADSR a while back that was very efficient as well as very easy to read and understand, SMs env's could be based on that algo. Then that could be hardcore ASM optimized and the result would be super efficient envelopes.

Also I've mentioned this too many times, but why the hell does the high level LFO module use bandlimited oscs?? CPU for this module can be halfed by using non bandlimited versions.

I think readable versions should be available, like on the WIKI; that's why I put that idea on the other thread.

The Coded envelopes are complex since they have so many features; IIRC, Zynewave is missing some of those features (which some may not need). That said, I think much of what goes on in the said Code can be put into green math for most applications, but there may be times there may be need for a fully Code version. One can likely save 10% of CPU with out even going to ASM there.

There are non-bandlimited OSCs for LFOs in the WIKI.

exonerate · 3 Nov 2008

infuzion wrote: I think readable versions should be available, like on the WIKI; that's why I put that idea on the other thread.

The Coded envelopes are complex since they have so many features; IIRC, Zynewave is missing some of those features (which some may not need). That said, I think much of what goes on in the said Code can be put into green math for most applications, but there may be times there may be need for a fully Code version. One can likely save 10% of CPU with out even going to ASM there.

There are non-bandlimited OSCs for LFOs in the WIKI.

Good points, yes I think zynewaves envelope did omit some features, also I think adding hold to them wouldn't be possible without an extra count just for the hold. But regardless the envs can be optimized a fair bit anyway as you said without going to ASM.

I put the non bandlimited LFO on the wiki, but I think the high level LFO in SM should have non bandlimited oscs as standard, there used to be a sine LFO primitive that should come back as well as square LFO, saw LFO ect... using a non bandlimited version of the square actually saves you about 80 percent CPU because the square is using two sawtooths and so has twice the CPU as the other oscs. Malc could code some LFO primitives in a matter of minutes and use them in the LFO, or even simpler add my version from the wiki as the default.

Trust me if someone is using the standard LFO and are using say 4, which is not unusual, each LFO is then using knocking on for 1 percent of the overall CPU use, so thats adding 4 percent to the taskmanager, just for something as basic as LFOs, that can be halved by using non bandlimited versions, knocking two percent off the overall CPU use of a synth is no small thing, that's huge.

Cheers 😉

Exo

Acrobat · 3 Nov 2008

exonerate wrote: Malc could code some LFO primitives in a matter of minutes and use them in the LFO, or even simpler add my version from the wiki as the default.

There used to be a SineLFO in the chorus module, Ive used it many times but it seems to have a different frequency scaling, I think you mean something like that?

I'd say it would be as simple to have a non-bandlimited, special LOW quality wavetable reader, so the new LFOs could have any shape... dunno maybe it is doable with todays primitives too.. 🙂