Powerful synths that are CPU friendly?

VST, AU, AAX, CLAP, etc. Plugin Virtual Instruments Discussion
Post Reply New Topic
RELATED
PRODUCTS

Post

Zebra2 is a solid call by the OP.
Maybe check out the other U-He freebies...podolski, etc. Perhaps not as insanely flexible, but still very useful and easy on the CPU as well.
I love Blue II, and a lot of people are/were digging Predator for a while, as well.

In terms of frame rates, it's really simple, folks. Just convert your tempo from quarter notes to seconds, multiply that by your DAW's max PPQ, and that should be your target fps. That way your display can't possibly lag behind your midi.
So, for example: 120bpm = 2 quarter notes per second. Say your DAW's max PPQ is 384. Multiply that by 2 quarter notes per second, and you'd need a refresh rate of 768fps.
The numbers do not lie.
<ducks>
:hihi:
Feed the children! Preferably to starving wild animals.
--
Pooter | Software | Akai MPK-61 | Line 6 Helix | Dynaudio BM5A mk II

Post

BlitBit wrote: Fri May 24, 2019 10:08 pm
crimsonwarlock wrote: Fri May 24, 2019 8:03 pm Crystal is pretty deep and extremely light on CPU for today's standards. Funny that it was regarded a CPU hog back in the day, [...]
Same for Massive which was named as one of the first synths in this thread. Looking forward to the days when Diva will be considered a lightweight synth. Then again this seems to be one of these "name all of the synths" thread so it still has a chance to be mentioned. :wink:
i wish diva could be on this list right now. It probably uses 3times the cpu as zebra2 does

Post

it'll get there. when i got blue and zebra, they were just astonishingly better-sounding than anything else i had at the time...so the (at the time) relatively high cpu hit was worth it.
in the meantime, there are at least lower-quality modes in diva to save some cpu till you render...
Feed the children! Preferably to starving wild animals.
--
Pooter | Software | Akai MPK-61 | Line 6 Helix | Dynaudio BM5A mk II

Post

maxym.srpl wrote: Fri May 24, 2019 5:36 pmYou remember wrongly. Or you missed some piece of information. It all depends on speed objects are moving.
No, it has nothing to do with that. It is about the way in which we see and the threshold for perceiving smooth motion is dependant on environment and it varies between species. It used to be known as persistence of vision but these days is sub-categorised as flicker fusion.
Probably you are referring to framerate of applying to movies in the past. But you are forgetting about motion-blur accompanying quick movements.
Irrelevant. Motion blurring is a phenomenon of capturing images of fast moving objects. It is not a natural phenomenon because your brain long ago learned how to filter it out by moving your eye in a certain way - saccading - and ignoring the indecipherable blurry bits while your eye flits from one spot to another. So when you are watching a movie or TV show you expect to see motion blur because you are used to it, not because that's what you actually see with your eyes.
There are two more factors which are connected to each other.
One of them is a lag. The less FPS, the greater lag - time between an event (let's say touching a knob) and reaction (turning the knob)
Direct consequence of too big lag is questionable responsiveness.
This will not be an issue with the refresh rates we are talking about here. At 60Hz, for example, the time from one frame to the next is 16.7ms, so the lag will be half that, which is the same or better than the latency in your audio stream so the absolute worst it can do is to time your visuals up better with your audio. 8ms is also generally accepted as the smallest time difference perceptible to humans. i.e. if two sounds are triggered 8ms apart, most people will perceive them as being instantaneous.
Our brain used to immediate reaction when manipulating objects. This is what it learned about physics since our birthday. If movement of objects we are operating is not immediate, and is not smooth, then it impacts user experience.
Possibly, although it feels unlikely to me as we all understand inertia, but irrelevant here as the object we are moving is either a mouse or a knob on a MIDI controller. For fine control, I can hold down CTRL and that increases the necessary range of mouse movement by a factor of 10 or more, completely changing the perceived "feel" of the control. Mostly, though, I just hover the cursor over a GUI control and use the mousewheel so my perceived "feel" is that of the clicky mousewheel, complete with fake inertia, not the graphic on the screen.
This is why iPhones with their capacitive touchscreens won the initial battle against competition when they hit the market: because the GUI experience was so immediate and smooth.
Wrong again, that was the difference between capacitive touchscreens and resistive touchscreens, which are far less sensitive to light touches which makes them feel more clunky.
Rather you are an ignorant.
Or, and this is just a theory, maybe in the 25 years I have been working in the film, television and gaming industries I have had to learn a thing or two about this kind of stuff? Just a thought but when you spend six years as an animation product specialist for a massive company like Autodesk, you do tend to learn a bit here and there. Common sense gets you the rest of the way.
NOVAkILL : Asus RoG Flow Z13, Core i9, 16GB RAM, Win11 | EVO 16 | Studio One | bx_oberhausen, GR-8, JP6K, Union, Hexeract, Olga, TRK-01, SEM, BA-1, Thorn, Prestige, Spire, Legend-HZ, ANA-2, VG Iron 2 | Uno Pro, Rocket.

Post

chk071 wrote: Fri May 24, 2019 9:53 pm I had no idea that FPS is even relevant for plugins...
That's because it isn't, generally. Orion allows you to set the refresh rate in fps but that's for accurate metering and it has no effect whatsoever on the perceived responsiveness of the controls of any of it's internal instruments or effects. That comes from nice, big knob graphics and the comparatively long mouse travel required to change values.

It's something anyone should be able to try for themselves. Load up the plugin you think feels the smoothest and one you feel is very clunky. Position your cursor over one of the controls and turn it down to it's minimum setting, then put a piece of paper under your mouse and trace around the mouse with a pen. Now move the control to it's maximum setting and draw around the mouse again so you can see how far you had to move it.

Repeat the procedure for the other plugin and compare how far the mouse travelled in each case. I'll guarantee you that the smooth feeling one travelled much further. I'll also guarantee you that you'll be amazed how little you had to move the mouse. I've found that mostly I can move my mouse between opposite corners in a space that's about the same size as a standard trackpad. It amazes me how much precision we can get from comparatively little movement.
NOVAkILL : Asus RoG Flow Z13, Core i9, 16GB RAM, Win11 | EVO 16 | Studio One | bx_oberhausen, GR-8, JP6K, Union, Hexeract, Olga, TRK-01, SEM, BA-1, Thorn, Prestige, Spire, Legend-HZ, ANA-2, VG Iron 2 | Uno Pro, Rocket.

Post

maxym.srpl wrote: Fri May 24, 2019 6:49 pmBut if GUI is THE dedicated interface for creating a sound (I mean entering values, not only to show up gfx on its own), then one of main factors, probably more important than gfx itself. is responsiveness. And it's it cannot be achieved without enough FPS.
Except the goal isn't to precisely place the GUI control into a certain position, it is to set a value that creates the desired timbre, so while you might be moving the GUI control, you are listening for the right spot, not looking for it. So audio latency becomes your limiting factor because by the time you hear the sound you want, you will have moved the control beyond that point and you will need to move it back slightly. Now, think about that - how many times have you ever heard the sound exactly as you want it and then realised you had moved the control too far and had to move it back a little? Yes, it will happen when you are moving a control quickly, e.g. trying to find exactly 7 semitones of detune, but when you are trying for that ultimate accuracy, you move the controls very slightly so that when you stop get the right value. So all of it becomes completely irrelevant.
NOVAkILL : Asus RoG Flow Z13, Core i9, 16GB RAM, Win11 | EVO 16 | Studio One | bx_oberhausen, GR-8, JP6K, Union, Hexeract, Olga, TRK-01, SEM, BA-1, Thorn, Prestige, Spire, Legend-HZ, ANA-2, VG Iron 2 | Uno Pro, Rocket.

Post

exmatproton wrote: Fri May 24, 2019 3:51 pmI am experiencing this without being an idiot. The difference between rapid @60 and the finicky operation of let's say Vecto is really there.
I don't doubt that, it is something we all experience, but your explanation as to the cause is complete nonsense. Have a look at the experiment I suggested and try it for yourself. It might save you money once you realise you don't need a good graphics card or an expensive gaming monitor to make music.
exmatproton wrote: Fri May 24, 2019 3:57 pmIf i could choose between Vecto @30 FPS of 60, i would 60. Nothing to do with marketing etc. I just hate stuttering. The less stuttering, the better.
First of all, what is Vecto, it doesn't show up on a database search here? Secondly, there is no visible stuttering at 50Hz or 60Hz. None whatsoever. Thirdly, why are you even looking at a knob animation while you program sounds? Why aren't you listening for the correct value or watching a digital display of it (if it needs to be a precise value)?
exmatproton wrote: Fri May 24, 2019 4:03 pmHowever, an update rate of around 60 fps is just working lovely, imho.
Of course it is, because that's the refresh rate for LCD panels. It's what most computers are set to by default, how they are designed to function.
Another option would be to let the user choose between different rates. So "old" users can choose 12 FPS (which they like, if i read it correctly here......) and "other" users can just use 60 and enjoy the fluid goodness
You didn't even bother to read my response to you, did you? I covered this - whether I set Orion 's refresh rate at 1fps or 120fps, it has NO EFFECT on the perception of how "smooth" or responsive knob movement is because the knobs are pre-rendered with a fixed number of frames to cover their full range of represented values and the refresh rate doesn't affect that. To be fair, if you are dealing with a vector GUI it will be different and it is different for a slider in most cases (depending how it is implemented) but, again, the default refresh rate of your monitor will be more than adequate to make everything appear buttery smooth and to refresh things more slowly could actually increase the CPU load because you'd need to intervene to make it happen.
NOVAkILL : Asus RoG Flow Z13, Core i9, 16GB RAM, Win11 | EVO 16 | Studio One | bx_oberhausen, GR-8, JP6K, Union, Hexeract, Olga, TRK-01, SEM, BA-1, Thorn, Prestige, Spire, Legend-HZ, ANA-2, VG Iron 2 | Uno Pro, Rocket.

Post

Sytrus is my bread and butter synth. Super light on cpu too. :tu:

Post

BONES wrote: Sat May 25, 2019 1:36 am
exmatproton wrote: Fri May 24, 2019 3:51 pmI am experiencing this without being an idiot. The difference between rapid @60 and the finicky operation of let's say Vecto is really there.
I don't doubt that, it is something we all experience, but your explanation as to the cause is complete nonsense. Have a look at the experiment I suggested and try it for yourself. It might save you money once you realise you don't need a good graphics card or an expensive gaming monitor to make music.
exmatproton wrote: Fri May 24, 2019 3:57 pmIf i could choose between Vecto @30 FPS of 60, i would 60. Nothing to do with marketing etc. I just hate stuttering. The less stuttering, the better.
First of all, what is Vecto, it doesn't show up on a database search here? Secondly, there is no visible stuttering at 50Hz or 60Hz. None whatsoever. Thirdly, why are you even looking at a knob animation while you program sounds? Why aren't you listening for the correct value or watching a digital display of it (if it needs to be a precise value)?
exmatproton wrote: Fri May 24, 2019 4:03 pmHowever, an update rate of around 60 fps is just working lovely, imho.
Of course it is, because that's the refresh rate for LCD panels. It's what most computers are set to by default, how they are designed to function.
Another option would be to let the user choose between different rates. So "old" users can choose 12 FPS (which they like, if i read it correctly here......) and "other" users can just use 60 and enjoy the fluid goodness
You didn't even bother to read my response to you, did you? I covered this - whether I set Orion 's refresh rate at 1fps or 120fps, it has NO EFFECT on the perception of how "smooth" or responsive knob movement is because the knobs are pre-rendered with a fixed number of frames to cover their full range of represented values and the refresh rate doesn't affect that. To be fair, if you are dealing with a vector GUI it will be different and it is different for a slider in most cases (depending how it is implemented) but, again, the default refresh rate of your monitor will be more than adequate to make everything appear buttery smooth and to refresh things more slowly could actually increase the CPU load because you'd need to intervene to make it happen.
Vecto is a synth by Rob Papen.

Post

Another low CPU synth that doesn't get talked about much is Hybrid 3
This beast is layers of control and hardly taps the CPU.

Actually for what it is and can do, the sales that it usually has for like $15 or sometimes the $1 on plugin boutique is more a steal and a no brainer.
Last edited by MuzikFreq on Sat May 25, 2019 8:21 am, edited 1 time in total.

Post

Maybe sounds strange but i find almost all synths can be low on cpu. The main different is that some can be so simple or so complex that you can have 100X more cpu depending on different presets.
In general the best optimized synths are the one which comes with your DAW.
But i also can run 100+ instances of some third party synths like DRC (Imaginando) where i can run just 10 instances of other while they do not sound better.
Also what means powerful here? I guess it depends on what inspires you or what features you prefer.

Post

Oh ya Viper is quite light too.

Post

idk if GPU accelerated UI is discussed here ..
if yes then what is the problem with GUI running at 120 or 240 fps
if the GPU is doing the work and the cpu is doing the DSP stuff ??
at least any spectrum analyser wont eat my whole CPU to display a 4k screen

i know melda is using gpu for its UI and i think some more devs use opengl as optional UI renderer for their UI.

its just a welcomed additional feature if it supports high refresh rate without sacrificing CPU for UI instead of its DSP
Win 10 x64 with specs enough to run DAW without bouncing any track
KZ IEM,32-bit 384Khz dac running at 32bit 48Khz
mainly use REAPER, MTotalbundle, Unfiltered Audio TRIAD and LION, NI classic collection,......... ETC

Post

Echoes in the Attic wrote: Sat May 25, 2019 8:11 am Oh ya Viper is quite light too.
It is for the most part but some patches can hurt. :lol:

Post

Korg Legacy Collection
Last edited by topaz on Sat May 25, 2019 11:19 am, edited 1 time in total.

Post Reply

Return to “Instruments”