From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
When ever SM uses high resolution array, SM eats CPU like mad. 2048 wavetables sound nice, when I do a WT crossfade (2 Multiply Float Array, Float Array Add them), my laptop uses about 17% CPU. Loading an OSM with 56 WTs takes over 10 seconds on a Intel quad.
I've run larger pivot tables & more complicated math on a Pentium2 for over a year, & never seen lag like this. Granted, this on a spreadsheet & a few database programs built for this and SM is a synth program, but I'd expect with more modern programming techniques & a faster CPU should be now closer to the same speed I've had before, not much much worse.
I guess one can severally limit the triggers to such array math for a semi-crippled workaround, but the slow loading time shows an inherent problem with how SM handles arrays.
stefan ·
Do you store the entire 56 tables? If so, there's no need for that. You only need to store the waveforms, and generate the table upon switching waveform.
Doing fades in "green" is a bad idea, do you regenerate the table for each change of the fade value? It's better to have two tables generated just once and do the fade in stream.
infuzion ·
Wave Table primitive does not save its loaded data when you save the file. Only Float Array etc does.
I want to mix between 2 waveforms, & need to provide feedback as it happens. Thus the Float Array mults & add. Fading in the stream is good only if I wanted to do "live" modulation, which I do not at this time. So that idea, though good, is a CPU% waster for me right now.
Tom7777 ·
Infuzion i agree, and i have said about this in the past, if you have a page of arrays even if they are not in use (just texts) they slow things down a huge amount. It was never fixed.
Tom7777 ·
Quick example of what i mean, it's just arrays doing nothing but show the issue im talking about. On the array page move something, copy/paste something, right click to make the menu appear etc. For me this is quite slow, the more arrays it goes even slower, each of these are only 256 also.
exonerate ·
infuzion wrote: Loading an OSM with 56 WTs takes over 10 seconds on a Intel quad.
If that's 56 actual wavetables as in wavetable creates, then that is to be expected I think. If you just mean 56 arrays then that does sound slow.
With the crossfade I'd only do that with an array if you need to for a waveform display, and then you should resample the arrays before hand to a low resolution like 128/256 (which should be enough for a graphical display).
Cheers 😉
Exo
exonerate ·
Tom7777 wrote: Quick example of what i mean, it's just arrays doing nothing but show the issue im talking about. On the array page move something, copy/paste something, right click to make the menu appear etc. For me this is quite slow, the more arrays it goes even slower, each of these are only 256 also.
Yes this is more of an editing issue, you have a lot of text components all on one screen which can each be edited.
By the way you are alot better off storing your waveforms in actual arrays (not text components) because when you have them in text component they have to be converted to float arrays which is a very slow conversion.
Cheers 😉
Exo
matti ·
exonerate wrote: By the way you are alot better off storing your waveforms in actual arrays (not text components) because when you have them in text component they have to be converted to float arrays which is a very slow conversion.
Cheers 😉
Exo
You loose resolution too..
infuzion ·
matti wrote:
exonerate wrote: By the way you are alot better off storing your waveforms in actual arrays (not text components) because when you have them in text component they have to be converted to float arrays which is a very slow conversion.
You loose resolution too..
What?!? I think they're the same resolution since you'll end up using a Text in a Float Array or what have you. As soon as data hits the SM array part, it is converted.
(please dev correct me if I'm wrong)
matti ·
infuzion wrote:
matti wrote:
exonerate wrote: By the way you are alot better off storing your waveforms in actual arrays (not text components) because when you have them in text component they have to be converted to float arrays which is a very slow conversion.
You loose resolution too..
What?!? I think they're the same resolution since you'll end up using a Text in a Float Array or what have you. As soon as data hits the SM array part, it is converted.
(please dev correct me if I'm wrong)
The resolution of a float array converted to a text array is comparable to a signed integer of 21 bits. Might not be a big thing, just thought i should mention it.
Tom7777 ·
exonerate wrote: Yes this is more of an editing issue, you have a lot of text components all on one screen which can each be edited.
By the way you are alot better off storing your waveforms in actual arrays (not text components) because when you have them in text component they have to be converted to float arrays which is a very slow conversion.
Well it's buggy editor behaviour then because they are not in use just static. They should convert only when sent to the float array connection. Thanks for the tip, this way mainly a example of how they can slow down SM a huge amount, maybe something can be done with this to speed things up.
xmidiman ·
exonerate wrote:
infuzion wrote: Loading an OSM with 56 WTs takes over 10 seconds on a Intel quad.
If that's 56 actual wavetables as in wavetable creates, then that is to be expected I think. If you just mean 56 arrays then that does sound slow.
I think what infuzion is refering to is what I posted:
xmidiman wrote: "It takes me about 10 secs exactly to load my project which contains 56 wavetable osc/Float Arrays etc... Just looking for a quicker way about this. Note that I have a Intel Q9450, so anyone else loading this is going to need a smoke break."
To clarify, I have only 5 Float arrays: Supersaw(4096), Saw(2048), Tri(2048), SIne(2048), Feedback osc(2048)
All 5 get generated at loading.
They then are sent from the tables(5) to the wavetable oscs which ends up being a total of 56.
At the moment this is only a 2x osc synth with 2x unison, so it's not looking good for what I had in mind.
I know some of you have to be hurting on the load times too.
*Just for fun I just made those 5 float arrays only 16 samples and still got a 10 secs load.(I verified the array after load)
Removing links from and to the "wave table"(so it doesnt generate anything) and restarting, the project loads in about 5.5 secs. 😕
exonerate ·
xmidiman wrote:
exonerate wrote:
infuzion wrote: Loading an OSM with 56 WTs takes over 10 seconds on a Intel quad.
If that's 56 actual wavetables as in wavetable creates, then that is to be expected I think. If you just mean 56 arrays then that does sound slow.
I think what infuzion is refering to is what I posted:
xmidiman wrote: "It takes me about 10 secs exactly to load my project which contains 56 wavetable osc/Float Arrays etc... Just looking for a quicker way about this. Note that I have a Intel Q9450, so anyone else loading this is going to need a smoke break."
To clarify, I have only 5 Float arrays: Supersaw(4096), Saw(2048), Tri(2048), SIne(2048), Feedback osc(2048)
All 5 get generated at loading.
They then are sent from the tables(5) to the wavetable oscs which ends up being a total of 56.
At the moment this is only a 2x osc synth with 2x unison, so it's not looking good for what I had in mind.
I know some of you have to be hurting on the load times too.
*Just for fun I just made those 5 float arrays only 16 samples and still got a 10 secs load.(I verified the array after load)
Removing links from and to the "wave table"(so it doesnt generate anything) and restarting, the project loads in about 5.5 secs. 😕
Are you using VST parameter arrays? or normal ones?
And just to get this straight, you only have 5 wavetable creates and 56 wavetable reads?
xmidiman ·
exonerate wrote: Are you using VST parameter arrays? or normal ones? And just to get this straight, you only have 5 wavetable creates and 56 wavetable reads?
Looks like I am using the "VSTParameter" normal in each knob/slider if thats where you were getting at?
And correct only 5 wavetable creates and 56 wavetable reads (OSC).
I will break it all out so I guess it will make more sense:
OSC 1
7 Supersaw
2 Pulse(2 saw wavetable reads)
1 Saw
1 Tri
1 Sine
1 Noise
1 Feedback osc
= 14 BUT * 2 for the unison stuff
So total OSC1 = 28 Wavetable Reads
OSC 2
7 Supersaw
2 Pulse(2 saw wavetable reads)
1 Saw
1 Tri
1 Sine
1 Noise
=13 BUT * 2 for the unison stuff
So total OSC2 = 26 Wavetable Reads
Grand total 54! ? where did I get 56 lol...so yeah 54!... Well there is some more actually but its just an LFO for testing using the SM multiosc.
exonerate ·
I mention the VST parameter array, because it sends a trigger on start up, (the normal vst parameter do not) if you have the float array connected to the "create" trigger it will cause the wavetable to update.
But that is obviously not an issue here.
I'd try to narrow down the exact reason for the slow times by reducing the number of wavetable reads and see if that makes a difference, also I guess this will be a pain but I suggest trying normal links instead of the wireless links and see if that makes a difference also.
It's clear to me that the wavetable creates are not the issue here, five is not a lot, so it's either the wireless links or the actual wavetable reads causing the slow down.
Cheers 😉
Exo
infuzion ·
Wireless links are a slow-boot issue, since SM has to search for each end & connect all them:
[old link]
I personally stay away from wireless when possible, except for a few often used static global presets (like font info).
xmidiman ·
infuzion wrote: Wireless links are a slow-boot issue, since SM has to search for each end & connect all them:
I thought about this, but never tried to redo all my connections since I started out non-wireless and then moved to wireless recently. Mainly because the VST loads exactly 10secs just like the OSM right now.
I did make some test OSMs that were massive that was all synced vs un-synced and testing loading as VST, well there is no difference.(I was hoping to find some flaw)
edit: Sometimes you really need to just test it out and not take everyone's word for it right 🙂
I want to make more tests, to figure out what really is the difference, since I really can't find any information other than what everyone puts together here.
Kinda wish it was in a manual? 😉
sunsynth ·
Right...
i have a project with
347000 Moduls
372000 Links and
16000 Wireless Links
When i started with SM i tried to avoid Wireless Links but now i like them...
Only with the use of this magic Links i can build Big and small Sub-Moduls/Slots w/o thousands of cables...
btw: The loading time in SM is OK 4 me
Tom7777 ·
Exactly, wireless links are great, if i hadn't asked for the idea ages ago i probably wouldn't have been able to make alot of the stuff i have done because they would have looked so messy i wouldn't know what was going on, i remember having tons of wires made it hard for me to edit also so i have been using them since they were first added.
I think it's true they slow the load time a bit maybe though but im hoping that will get improved on as with the other stuff like arrays etc that can effect the load time. I noticed in recent versions for the smaller plugins like effects it is much faster then again it could be down to lots of things i guess so one may be slow and another may not when different things are done.
infuzion ·
sunsynth wrote: When I started with SM I tried to avoid Wireless Links but now I like them...
The links are still there, you just don't see them 😉
sunsynth ·
I know infuzion... but i like your humor 😉
xmidiman ·
sunsynth wrote: Right...
i have a project with
347000 Moduls
372000 Links and
16000 Wireless Links
...The loading time in SM is OK 4 me
Can you share how long loading is and what cpu your using? Also how does the OSM compare to the VST in loading times?
infuzion wrote: The links are still there, you just don't see them
This is why I thought it was always ok to use them... I really want to fix these long loads... 🙁 Probably need to do some more testing...(uses up a lot of time)
sunsynth ·
...of course:
1. SM autoloading OSM: 7 sec.
2. Plogue B. autol. VST: 14 sec.
3. Standalone EXE: 7 sec.
I use a little Core 2 Duo E6550 at 2328 MHz not such a Monster like yours 😉
I had much bigger loading times with VST param Arrays and i'm just in the midle of changing all of my Knobs because of Andrew's hint's here!
xmidiman ·
sunsynth wrote: 1. SM autoloading OSM: 7 sec.2. Plogue B. autol. VST: 14 sec.3. Standalone EXE: 7 sec.
Thank you kind sir.
Interesting that the VST takes the longest?
When I'm making things, I try to set my goals to at least meet, if not surpass the current plugins. But right now I don't recall most of the plugins I(we) use taking over 10secs to load.(I would be ok loading an OSM for that long, but not the VST)
I've done some crazy and maybe silly fine tuneing to try to speed things up like...
1. Move all color/border/font/size etc in knobs outside of them and only have 1 main setting for all of them.
2. Any green math that can be done "inside" a knob vs the output of the knob I change.(For example if I have some math after the output, I would figure out the min and max from that math and just set the knob's min max to what the previous setup would result. Although you can't always do this with some type of math becuase of its logrithmic results and such.(make sense?)
3. I've tried taking all SM Code and converting to ASM(with or without edits), deleting all notes in the code, etc.
4. I think I have removed all "dots" in any line in every single module I could find and made them all straight! lol
5. And I can't remember anything else off the top of my head because its almost 4am. 😇
sunsynth wrote: I use a little Core 2 Duo E6550 at 2328 MHz not such a Monster like yours
I have a quantom blaster cpu but well we always have to remember computers like infuzions laptop dont we?!? They need care too! 😊 (joke!)
sunsynth wrote: I had much bigger loading times with VST param Arrays and i'm just in the midle of changing all of my Knobs because of Andrew's hint's here!
Yeah, I only had a couple of the font ones to take out and I will try just about anything now. So I hope more posts go to that thread 🙂
I have some ideas for optimizations I'd like to add but I'd rather someone(or me) verify so I don't look like a fool!
exonerate ·
I've just been playing around with wavetables and load times, I've set up a schematic with 6 wavetable creates all with a wavetable size of 4096, and the load time is pretty slow 8 seconds here, in a very simple schematic, that 8 seconds is pretty much exclusively in the initialization stage.
So I think I may have been wrong before, I think the main culprit is actually the wavetables especially larger ones 1024 and above.
Anyway I have come up with a simple solution to wavetable load times, well basically a hack not a solution 😉 .
What I've done is to delay the wavetable creation to after the actual osm/VST has loaded, which means that for the first few seconds the synth will be able to play no sound, but the actual plugin will load/appear much quicker. 🙂
I think this is a worth while thing to do, at least it will make the plugin appear to load much faster.
Cheers 😉
Exo
exonerate ·
Actually I've just tried that approach on a very complex schematic with a ten second load time and it made no difference. 😕
xmidiman ·
exonerate wrote: What I've done is to delay the wavetable creation to after the actual osm/VST has loaded, which means that for the first few seconds the synth will be able to play no sound, but the actual plugin will load/appear much quicker. I think this is a worth while thing to do, at least it will make the plugin appear to load much faster.Cheers
Hey! Thats exactly what I did / was talking about before 🙂
Maybe in a real situation, you could set it up to at least load the default osc like a saw, and do the others after...But I think the audio will stop.
xmidiman ·
exonerate wrote: Actually I've just tried that approach on a very complex schematic with a ten second load time and it made no difference. 😕
You may want to also try selectors before the actual wave table read in... Seemed to show a difference when I was messing around.
matti ·
I tried the hack on my wavetable oscs and it saved me about 2 seconds on load times.. which altho are taken later when the sequencer totally freezes for the time it takes to calculate the wavetables. The load times are not that bad, but a simple synth of mine now loads in 8 seconds, when synth1 for example manages to load up in just 1 second. Well i guess that's nicely proportional to it's 1/8th of cpu usage too 😀
Btw. selector before a wavetable read crashes quite easy. Be careful.
Tom7777 ·
xmidiman wrote: Interesting that the VST takes the longest?
I noticed and mentioned in another thread -
[old link]
that it contains all the FL (or some FL) stuff so im guessing if it's packing it all into the dll it doubles the time or something. Even if thats not the case that its got lots of FL data it's not needed really to be there anyway. It seems it puts the runtimes in the plugin, probably not needed either (module info), but just the code they use to make it run if you used one, it might do it also for modules that were not even used but im not sure. I think alot could be optimized still though.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker