From the original SynthMaker forum (2004–2014), with its members’ names and dates.
TomC ·
I've just completed an equalizer which does 4x oversampling. It's okay CPU-wise,
but was really a LOT of work to get everything working.
Wouldn't it be nice to have a switch in SynthMaker which does:
• upsample the input to a selectable upsample-rate
• reports the (faked) sample rate to the VST/VSTi (maybe BPM, too)
• downsamples the output before it goes back to the VST-host
Upsample/downsample algorithms are widely known, and performance wise
it's best done within SynthMaker, not in our own coding.
This way we can decide if we want the 'normal' behaviour as it is now (low
CPU) or the benefits (sound wise) of a higher sample rate.
Your thoughts?
Tom
aliasant ·
What about an Up/Down sample primitive?
place the Upsample InputStream Primitive first inside a modul you want to oversample and then place the Downsample OutputStream Primitive at the signal end of that modul.
That is what I would like.
infuzion ·
TomC wrote: Upsample/downsample algorithms are widely known, and performance wise it's best done within SynthMaker, not in our own coding.
Honestly, I think most of SM's primitives are made in C++. If you write a module in Code, then transfer it into ASM, then you'll get equal if not better performance. Plus, if you hand-code it yourself, you can tweak it to what your particular project's requirements are (eg use a hop(32) instead of hop(16)...).
I think I tested SM's old ADSR4 primitives compared to a new Code version. I think the Code version was slightly faster, esp when I swithed to a hop(64) which is OK most of the time. Hand re-code into ASM, & you have the fastest ADSR possible in any programming SDK.
I do think that when it comes to green modules, it can be optimized as a primitive. Handy if it used often enough or if it huge & can drag down your VST if it isn't a primitive.
TomC ·
infuzion wrote:
TomC wrote: Upsample/downsample algorithms are widely known, and performance wise it's best done within SynthMaker, not in our own coding.
Honestly, I think most of SM's primitives are made in C++. If you write a module in Code, then transfer it into ASM, then you'll get equal if not better performance. Plus, if you hand-code it yourself, you can tweak it to what your particular project's requirements are (eg use a hop(32) instead of hop(16)...).
I think I tested SM's old ADSR4 primitives compared to a new Code version. I think the Code version was slightly faster, esp when I swithed to a hop(64) which is OK most of the time. Hand re-code into ASM, & you have the fastest ADSR possible in any programming SDK.
I do think that when it comes to green modules, it can be optimized as a primitive. Handy if it used often enough or if it huge & can drag down your VST if it isn't a primitive.
All right and true, but I'd still get the individual samples at the original
sample rate. So if I'd upsample 2x inside one of those modules I'd still
get only one sample per tick and would have to do parallel processing to
process twice as much samples in the same time.
That's what I'm doing right now and it's a PITA.
Tom
aliasant ·
infuzion wrote:
TomC wrote: Upsample/downsample algorithms are widely known, and performance wise it's best done within SynthMaker, not in our own coding.
Honestly, I think most of SM's primitives are made in C++. If you write a module in Code, then transfer it into ASM, then you'll get equal if not better performance. Plus, if you hand-code it yourself, you can tweak it to what your particular project's requirements are (eg use a hop(32) instead of hop(16)...).
I think I tested SM's old ADSR4 primitives compared to a new Code version. I think the Code version was slightly faster, esp when I swithed to a hop(64) which is OK most of the time. Hand re-code into ASM, & you have the fastest ADSR possible in any programming SDK.
I do think that when it comes to green modules, it can be optimized as a primitive. Handy if it used often enough or if it huge & can drag down your VST if it isn't a primitive.
Infuzion. Please remember the most of the SM users, like me, doesnt know how to write code.
That is one huge reason why the use SM and other similar programs.
I have no clue how to write an oversampling thing.
eg. What Im looking for in my compressor project is a way to oversample the process. As it is now it calculates a new gain at samplerate. eg. 44100 times / second if thats the samplerate used in the host.. I would like to make that maybe 2xsr or even 4xsr. That would make it sound much better. But Im not even sure I could do that right now. Is it possible?
So. A simple primitive that lets us set the amount of oversampling in that particular module would be really nice.
exonerate ·
Yeah i would like to see an upsample/downsample primitive also.
Kind of like the new double components, where everything in between them would be run at the samplerate specified.
SM should come with a premade solution for this, so non coders and dsp guru s can get the benefits. Even if you have no problems doing this your self I'm sure these primitive would be very handy.
cheers 😉
Exo
bootsy ·
A BIG BUMP
aliasant ·
Im guessing now but isnt there a fairly simple way to do it with code?
Anyone dare to show us?
=)
edit:
I found this code from infuzion in the forum but it doesnt make much sense to me.
Tried pasting it into an assembler but the code looks broken....
Anyways. here it is:
//Poly/Pack4 64bit process
streamin in;streamout out;
float temp32;
movaps xmm7,in;
cvtps2pd xmm0,xmm7; //{3,3-2} move positions 0&1 into 64bit float
// 64bit process with xmm0
cvtpd2ps xmm6,xmm0; //{10,11-10}
movlps temp32,xmm6; //{2,6-1} not needed if xmm6 isn't used in 64bit processing
movaps xmm7,in; //{2,6-1} not needed if xmm7 wasn't used
movhlps xmm7,xmm7; //{2,6} bounce positions 2&3 to 0&1
cvtps2pd xmm0,xmm7; //{3,3-2} move positions 0&1 into 64bit float
// 64bit process with xmm0, likely just copy the above
cvtpd2ps xmm7,xmm0; //{10,11-10} recycle xmm7
movlps xmm6,temp32; //{2,6-1} not needed if xmm6 isn't used in 64bit processing
movhps xmm6,xmm7; //{2,6-1} merge both stages
movaps out,xmm6;
// fini {total extra latentcy:37-30,57-32}
infuzion ·
aliasant wrote: I found this code from infuzion in the forum but it doesnt make much sense to me. Tried pasting it into an assembler but the code looks broken....
It's really not a biggie from your side, but would make A LOT of filters sound so much better.
Doing the up/downsampling in code really sucks...
Tom
Edit: Oh, and I don't think doing this with a primitive is as easy as it seems to be. Let's keep things simple with a global SM-switch.
At least that increases the chances to get it at all...
sunsynth ·
I second that... Tom
I beg you 2 malc... give us a switch plus an int 4 the oversampling rate... 😉
or even that up/downsample primitive... 🙂
Merry XMas!
Walter
infuzion ·
What's wrong with the oversampling that is available now?
TomC ·
infuzion wrote: What's wrong with the oversampling that is available now?
There's no oversampling available right now in SynthMaker.
And if you do it of your own ( no matter whether you use the Oversampling toolkit or do it on your own)
1: the schematic becomes a mess
2: the schematic depends on the oversampling
3: you can't re-use existing schematics without changes
4: you have to know how oversampling works. Most users don't.
On the other side, introducing oversampling within SynthMaker itself is something like, well, a dozen code lines for malc and EVERYONE can use it without even knowing what it is.
Tom
Andrew J ·
I'd be a little surprised if it could be done in as little as a dozen lines of code! Also, I hope people take the effort to understand the basic concepts before they use it 🙂
sunsynth ·
Hi Andrew...
my problem is i only can use 2x oversampling now because i use mono4 (use all 4) and i cannot duplicate my hole effects-section for 4x or more Oversampling because this would make my biiig project far too big 🙁
Walter
btw: Happy New Year all SM-Freaks!
TomC ·
Andrew J wrote: I'd be a little surprised if it could be done in as little as a dozen lines of code! Also, I hope people take the effort to understand the basic concepts before they use it 🙂
There's one piece of code which reads the hosts sample rate and bit depth.
Upsample there (there's a lot of C++ code examples around the internet about up/downsampling, so there's not much to code here. Cut&paste doesn't count as code lines 🙂 ).
Report the (faked) sample rate to the schematic.
Downsample where the signal leaves the schematic.
malc's work would indeed just be a couple of new lines.
Tom
Andrew J ·
Hey I'm not trying to bag the idea - I like it!
I just think there might be a few caveats in the implementation. When it comes down to it, the up- and down- sampling would end up being done with decimating filters (as per the toolkit) and you'll still end up with half the CPU time to do your processing for each 2X factor. The whole thing could look a lot simpler for the user, but in reality it's still complicated underneath - and this comes at a cost.
infuzion ·
http://chris.r.walton.googlepages.com/oversampler
With source code.
Then again, why not just use the external wrapper, instead of building it into SM?
Andrew J ·
Coincidentally, Chris has featured in a bit of a flame war on the VST PlugIns mailing list over the last few days. Only mentioned that because I bothered to read through all of it 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker