From the original SynthMaker forum (2004–2014), with its members’ names and dates.
platinumears ·
Hi all.
Its a while since I posted here, but I have nevertheless been beavering away at a compressor / expander plug, which I thought was going pretty well: I had carefully optimized the stream module's cpu use, and was getting very acceptable readings both from SM's own cpu meter when running the schematic, and from the cpu meters in Reaper when testing the plug.
Then I checked Task manager: this was reading between 25% and 50% cpu use, both for Synthmaker and for Reaper, and this figure did not change when disabling the plug or stopping the schematic... however, it did drop to almost nothing when I closed the GUI in reaper.
So I have tried to isolate the problem, and here is what I came up with:
This is a simple schematic with 6 copies of my input level meter, each fed a stream of random values between 0 and 1, with a switch to turn the tick 25 on or off. On my system the cpu use reported by task manager increases dramatically (from 0 to 20-30%) when I turn on the switch, which doesn't seem right to me.
I created the meters by modifying the animated bitmap knob module, and loading in png strips created with Knobman: did I do something wrong? Or is this a SM bug? Any other suggestions...?
TIA 🙂
sunsynth ·
Hi,
this is a known behaviour of SM... 🙁
You need redrawlimiters and u have 2 divide the ticker by 3 or more for the m2f...
and try to minimize the redraw window size if possible: bigger size = more CPU use!
rl ·
In addition to sunsynths post I checked re-building the readout using vector primitives instead of bitmaps, but with barely noticeable difference (1~2 %).
Little offtopic, but skipping the Float Readouts gives a huge performance push.
platinumears ·
Thanks for the responses.
sunsynth wrote: You need redrawlimiters and u have 2 divide the ticker by 3 or more for the m2f...
and try to minimize the redraw window size if possible: bigger size = more CPU use!
I had a single tick 25 driving all my meters, just as in my example: I tried a single redraw limiter on that, with only a slight improvement it seemed. I assume that would be the same as adding individual redraw limiters to each module?
I am reluctant to divide the ticker: even just dividing by two seemed to make the display unnacceptably jerky... I would rather lose the meters entirely than include unreadable ones!
I believe my redraw window size is already just the size of the meter itself. Or did I do something wrong?
rl wrote: skipping the Float Readouts gives a huge performance push.
interesting: that does seem to make a big difference with the example schematic. But I didn't have any float readouts in the original compressor schematic, other than those used to store constants... 😕
trogluddite ·
If it's any consolation - your schematic is about as good as you can do animation in SM 🙁 . GUI CPU usage is just very inefficient. Try this out to see what I mean...
Load any schematic with some knobs in it then call uo the CPU meters in windows task manager (CTRL-ALT-DEL then click performance). Now back in SM grab a control and wiggle it around like mad... notice the way the CPU usage shoots up. For this reason, if you're using an SM design as a VST plugin, always close it's GUI window when playing back knob automation from the host, so that the animation doesn't load the CPU.
For me this is SMs one big Achilles Heel - I love absolutely everything else about it, but sometimes visual feedback is really needed to make a design useful - not just for the sake of looking pretty.
The Luddite
infuzion ·
trogluddite wrote: Now back in SM grab a control and wiggle it around like mad... notice the way the CPU usage shoots up. For this reason, if you're using an SM design as a VST plugin, always close it's GUI window when playing back knob automation from the host, so that the animation doesn't load the CPU.
[old link]
One tip I haven't included there is make a heart-beat system, & have only 15 ticks/second.
trogluddite ·
Dammit. I keep forgetting that you can put links to the Wiki - would save me loads of typing! Must be why my fingers are too short to play piano properly! LOL 😉
Seriously though, this stuff does annoy me 😕 - I'm just learning to make code into asm and then optimise it. Then I add a couple of tiny little level meters at 25ticks and wonder why I went to all that effort to try and get CPU usage down. The tips and tricks that forum folks have shown me over the last 6 months are really helpful (thanX 😍 ), but the core GUI performance is just too slow. Techy friends tell me that Windows user interface stuff is about as useless as using WDM drivers for audio - bypassing all that crap is no easy task. I feel sorry for Malc and Jorge - poor guys must get fed up hearing these whinges (I think moaning is in my DNA!) .
The Luddite
Andrew J ·
You might want to try using the View Area primitive. It can make quite a difference when you have a number of GUI elements.
trogluddite ·
Yeah, tried that and also just redrawing only the critical area - down to only 1 square by 4 (couple of dozen meters at once though - greedy me). I've also found that having less layers overlapping really helps. If you have say, a front panel background + section panel + meter background + moving part + bezel; the redrawing is very poor as so many different layers and transparencies need to be calculated. The background render Module in the Wiki is good for reducing this. I wonder if anyone has noticed big differences between different CPU / Graphic Card / DirectDraw architectures. Some people find this more of a problem than others - but I suppose some are content to just have high CPU - I want to use a weedy laptop on stage so CPU optimising is pretty high on my list.
The Luddite
matti ·
trogluddite wrote: If it's any consolation - your schematic is about as good as you can do animation in SM 🙁
How about this? (see the attachment)
Btw. The problem you are having with the knobs can easily be fixed by limiting the events the controller makes when it's moved. For example there's no need to do the whole bunch of graphics calculations when the knob is wiggled. I can post an example of that too.
matti ·
Here's a quick knob example.
infuzion ·
trogluddite wrote: ...I've also found that having less layers overlapping really helps. If you have say, a front panel background + section panel + meter background + moving part + bezel; the redrawing is very poor as so many different layers and transparencies need to be calculated. The background render Module in the Wiki is good for reducing this.
Ooohh, that tip should go in the WiKi as well! Adding a before/after OSM would be gravy. You helped school even an old timer like me 😉
trogluddite wrote: I want to use a weedy laptop on stage so CPU optimising is pretty high on my list.
That's one of the main reasons why I'm always on a CPU% rampage all the time. More specifically, optimizing using laptops for live performance, so no hiccups allowed.
trogluddite ·
@matti
Get the idea of lowering the framerate, but there's a limit to how slow you can go and still keep meters useful. The knob quantising example is ace though 😀 - definitely something I shall look into using in the future. Would be a nice to see just the quantising part as a self contained module for the developer's toolkit - I can already see uses for it well beyond just the GUI parts of a schematic - very clever way to cut down on green triggers.
infuzion wrote: always on a CPU% rampage
I was a pale, acne ridden Sinclair ZX81 (sold as a Timex I think in the US) programmer with no GF in my youth - I still try and program like I've only got 1k of RAM running at 4MHz (Just like my brain sometimes 😉 LOL). I'll get onto the Wiki soon - my big PC is busy with boring stuff from my job for a while 🙁
The Luddite
matti ·
trogluddite wrote: @matti
Get the idea of lowering the framerate, but there's a limit to how slow you can go and still keep meters useful.
Well.. i actually upped the framerate to 50fps and lowered the cpu usage from 100% to 0%(according to the task manager over here). Look inside the osm to see what i did.
It seems to stay at 0% even with 100fps.
First thing in every graphics optimization is to remove the float- and int-primitives that might get updated. They are a major cpu hog. Next thing would be to reduce the amount of redraws to a minimum. One redraw of 10x10 is much cheaper on the cpu than ten 1x1 redraws. In my example i reduced the redraw to just one, even tho i extended the area of the redraw. I also removed most of the junk that wasn't needed on the meters..
trogluddite wrote: The knob quantising example is ace though 😀 - definitely something I shall look into using in the future. Would be a nice to see just the quantising part as a self contained module for the developer's toolkit - I can already see uses for it well beyond just the GUI parts of a schematic - very clever way to cut down on green triggers.
The quantizing originates from some other example here on the forum. I can't take full credit 🙂
But there's a lot of changes to the knob in general to reduce the module count and other processing etc. I have even more advanced knobs which have thread safety's and value-label tricks, but the main idea is the same. (labels eat a lot of cpu too, if done improperly)
infuzion ·
trogluddite wrote: I was a pale, acne ridden Sinclair ZX81 (sold as a Timex I think in the US) programmer with no GF in my youth - I still try and program like I've only got 1k of RAM running at 4MHz
I have you beat; I started on the Radio Shack TRS-80s ("trash-80"), then my parents got me a Timex/Sinclair w/the memory upgrade. I didn't really program until the Comodore64, where you did also have to worry about memory.
Now, I don't worry about memory toooo much (though I'd still prefer to have 1 SM DLL that was external than to wrap the SM DLL inside the 20 VSTs I could run at once, & a smaller .OSM is faster to load/edit), but I'll sacrifice memory for speed for VSTs any day. In webdesign, memory footprint & speed tend to go hand in hand more.
matti has more tips that should go in the WiKi! 😉
Tzarls ·
Wow.....TRS-80......I need the sudden urge to hook up my old CoCo 2... 🙂 I remember having a Timex 1000 with, what, 2 Kb of RAM... I think the expansion was 16KB. I stil have it lying somewhere....
sunsynth ·
Yeah, i loved my good old ZX 81, Spectrum... 😍
16 + 48 kB Ram
Man, the Taxis in London made me poor on the way to the game-dealer's... 😈
trogluddite ·
@matti
How are you measuring CPU useage? Using windows task manager your example shows similar usage to the orginal example on my system. I'm just wondering if folks get wildly differing results depending on the number of CPU cores or graphics card driver efficiency or something... The single redraw idea is cool - all my meters are lined up together so it should be really easy to implement without re-arranging my front panel!
The Luddite
matti ·
trogluddite wrote: @matti
How are you measuring CPU useage? Using windows task manager your example shows similar usage to the orginal example on my system. I'm just wondering if folks get wildly differing results depending on the number of CPU cores or graphics card driver efficiency or something... The single redraw idea is cool - all my meters are lined up together so it should be really easy to implement without re-arranging my front panel!
The Luddite
Really? I'm measuring it through the task manager. I get wildly better results with my example than the original one. Are you using XP or Vista? What kind of machine you have? Mine is a dual core Pentium4(aka Pentium D) at 2.8GHz, running WinXP and a Geforce 8800. Tho i think the graphics card shouldn't have any effect on it(unless it doesn't support basic accelerations etc).
This reminds me that i need to do more tests on my laptops..
🙂
trogluddite ·
@matti
Tried your example on my big machine now (Quad Core 6700)- and yes, there is definitely a big improvement in CPU there 🙂 . My first test was on my internet machine (Intel Atom netbook), so it does seem that the machine you use can have quite a big effect on this - I'm guessing that maybe the netbook has a low powered graphics chip without much hardware acceleration.
The Luddite
infuzion ·
trogluddite wrote: Tried your example on my big machine now (Quad Core 6700)- and yes, there is definitely a big improvement in CPU there 🙂 . My first test was on my internet machine (Intel Atom netbook...
You should always test on weaker machines, especially if you want to give away as free or very cheap. I'd say the older Atoms released last year is OK for an low-end test... Athlon64 single-core is best IMHO... I personally think P4s with HyperThreading outside the range of worth while supporting, though you may want to go that low.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker