From the original SynthMaker forum (2004–2014), with its members’ names and dates.
tester ·
If I'm correct - Lissajous curves are the same kind of pictures, that wavelab displays on recording pannel, showing local phase difference between left and right channel. How to make such plot from two audio streams? I have no experience with plots, but just recently found, that this kind of measurement yet can be useful in certain situations.
By the way - are there any other memorable visualizations here on SM forum, that could add some optical aesthetics to sound?
trogluddite ·
Not seen the Wavelab thing, but for some Lissajous figures, take a look at my old Goniometer.. There's another thread HERE where I posted some other, similar visuals - though none of those are audio driven,they have parameters that could, in principle, be modulated by an envelope follower etc. Treat these kind of animations with caution though! - SM's screen refreshes (= Windows GDI) eat lots of CPU, so keep any eye on the Task Manager CPU meter if you make them big or use fast frame rates. (GUI CPU count is not shown on SM's internal meter - hence using Task Manager).
tester ·
Okay, thanks. I rather expect to make small pannels at refresh rate below 25 fps. Besides very basic measurements - it should attract the eye, not kill the computer 😉
trogluddite ·
tester wrote: I rather expect to make small pannels at refresh rate below 25 fps
If you intend to have many such small panels, here's something I learned. Despite what I said before about size, one "big" redraw is usually more efficient than lots of smaller ones. So, if you can, tile your displays close together and use a shared Area ReDraw to refresh all of them all simultaneously.
tester ·
Thanks. There will be probably not more than 3-4 units per whole app, to display cumulative views, like wave, spectra, phase. By the way - is there a difference in performance/stability between bitmap driven guis and SM shape made guis?
trogluddite ·
tester wrote: is there a difference in performance/stability between bitmap driven guis and SM shape made guis
There is, and it can be quite significant. To display (part of) a bitmap is very simple, the pixels are simply copied across into your graphics card buffer. "Geometry" primitives require a lot more computation to calculate the pixels which need to be changed, and they will often consist of many overlapping elements that must be combined. This is one reason why I so often use "Bitmap caches" in my display schematics - most useful if there are overlapping "layers" of GUI, as unchanged layers can be drawn from the bitmap cache instead of having all of their component parts recalculated.
This is largely because SM makes use of the (very old) GDI+ graphics routines, which are part of the Windows software. This makes compatibility across systems very easy to maintain, but it does all of its processing using the main CPU - unlike, say, DirectX or openGL, which are able to use the hardware acceleration of the graphics card processor to draw shapes much more efficiently. This also explains the "greedy" nature of ReDraws - all of the the mixing of "layers" etc. is also done by your main CPU. So minimising the number of overlapping layers and the use of "transparent" pixels can also help to optimise GUI performance.
tester ·
"a lot more computation" - I assume this refers rather to visualizations than simple sliders and knobs, that are static when not dragged?
trogluddite ·
Yes, the extra computation only happens when an element is ReDrawn - which for most controls, is only when you are dragging them. A simple experiment will demonstrate this. Create a schematic with only a "Vector Knob", and resize the knob to be quite large. Now open Task Manager and select the "performance" tab. Watch what happens to the CPU graph when you go mad throwing the knob quickly backwards and forwards! What you are seeing is not SM using lots of CPU, rather it is the load of the Windows' GDI+ engine generating the image for display (hence not seen on SM's own CPU meter).
The only caveat, is to take care with graphics which overlap. If two MGUI areas overlap by even 1 pixel, then re-drawing one of them causes parts of the other to be refreshed. The trouble with this is that even a partial re-draw of an MGUI causes any "geometric" primitives connected to it (including graphs etc.) to be recalculated, even if the geometry has not changed, or is not part of the overlapping section - this can even cause a flurry of "backwards" triggers to re-calculate everything all the way back to the source parameters. Careful use of trigger blockers, sample and holds, and "bitmap caches" can really help with this kind of super-imposed imagery, by ensuring that unchanged elements can be refreshed from a buffered bitmap rather than by re-drawing the geometry. A search for "bitmap buffer" or "bitmap cache" should yield some good examples of this technique used in practice.
As you would predict, for some designs, optimising the GUI can be much more siginificant than endless tweaking of assembly to save a handful of CPU cycles in the audio streams.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker