1.0.9: SM VERY LAGGY with large files

Tom7777 · 12 Jan 2008

Indeed i still get huge slowdown with big projects, it gets really annoying to me and makes development hard and sometimes things move by mistake etc when i don't want them too, i think the devs did a great job with plugin load times so im hoping speeding up working with big projects will be the next big focus 🙂

Tom7777 · 9 Feb 2008

Bump 😉

infuzion · 21 Feb 2008

For the public: Malc had emailed that synchronized modules can help add to the lag in opening, editing, etc.

For the file in question, it did have lot of sync'd modules, but even after unsyncing what I could find (which took about 40 minutes), the said file was still laggy. Malc is looking into it.

MyCo · 21 Feb 2008

I've noticed, that this lagging depends on how deep the edited module is in a schematic. If you edit it on the top level, that's no problem, but if it is 10 levels deep in sub schematics, it can get realy bad 😈

stefan · 21 Feb 2008

infuzion wrote: For the public: Malc had emailed that synchronized modules can help add to the lag in opening, editing, etc.

For the file in question, it did have lot of sync'd modules, but even after unsyncing what I could find (which took about 40 minutes), the said file was still laggy. Malc is looking into it.

I thought you'd be able to use Shift+Ctrl+Alt+S for such duties?

infuzion · 21 Feb 2008

MyCo wrote: ...but if it is 10 levels deep in sub schematics, it can get realy bad

Anther reason to use fewer sub-modules 😉

But for the file that made me open the bug report, it took literally 70 (seventy) seconds or so to go from the outside to one level in. About every climb up or down took about a minute. Every change, over a minute.

I'm curious how bad it can or cannot become with editing in FL with alot of things loaded and running....

infuzion · 21 Feb 2008

stefan wrote: infuzion wrote: For the public: Malc had emailed that synchronized modules can help add to the lag in opening, editing, etc.

I thought you'd be able to use Shift+Ctrl+Alt+S for such duties?

I didn't know that shortcut at the time; it wasn't documented anywhere that I know. I created that wiki page to share that shortcut after malc shared it with me.

Perhaps a button for it would be better...

stefan · 21 Feb 2008

infuzion wrote: stefan wrote: infuzion wrote: For the public: Malc had emailed that synchronized modules can help add to the lag in opening, editing, etc.

I thought you'd be able to use Shift+Ctrl+Alt+S for such duties?

I didn't know that shortcut at the time; it wasn't documented anywhere that I know. I created that wiki page to share that shortcut after malc shared it with me.

Perhaps a button for it would be better...

Aha, my bad 🙂

infuzion · 21 Feb 2008

stefan wrote: I created that wiki page to share that shortcut after malc shared it with me.

Aha, my bad[/quote]Which is why I made that WIKI page, in hopes that super-SMers like you would add their secret shortcuts 😉

infuzion · 7 Mar 2008

Back on topic & perhaps related: I also got SM to become very laggy immediately when I increased the amount of presets available in my fork of the Multi-Env-Beats from 3 to 122. When I didn't touch SM after that, the system CPU was more or less normal. But as soon as I did any editing, be it moving an item or moving into another module, the CPU pegged at 100% (usually much less), & took about a full second to go to each step. So sliding a primitive along by selecting it then hitting the right-arrow key 10 times took like 10 seconds.

edit: I did do some editing of the Preset Manager, but really only some small file size optimizations (simpler), & the Counter loops from max to 1 instead of stopping at max. Some miner GUI changes. The fundamentals for the Preset Manager stayed the same.

Sorry, but this is simply not acceptable, since I expect to have 50 presets for the Multi-env alone, & atleast 3 of these envs in my OSMs, & 100 patches for the entire OSM, if not more.

files sent Thanks for your time!

Acrobat · 7 Mar 2008

I had the same impression: that the lag is mostly related to VST presets, I think it is in particular related to VSTArray presets.. and points in MultiEnv are made thru VSTArrays, if I remember well..

sunsynth · 7 Mar 2008

Hmm,

i have a strange behaviour from my own Preset manager build from scratch (the original behaves identical):

I save my preset on change and autoload it in my standalone project onload...

the file is 7 kb in size without any unused data in it but: if i open it in SM the file grows up 10 times and it has 2 x Float Array (260) numbered 1 to 260 plus other small ones in it If i exit SM and restart SM it crashes... 😝 If i use it with the smaller saved preset it starts OK

SUNsynth

infuzion · 7 Mar 2008

Acrobat wrote: ...I think it is in particular related to VSTArray presets...

I'm thinking that might be it also. I'm already suspicious of any arrays in SM; they seem to generate more page faults.

I did another test: 1) Downloaded the MSCB from the WIKI v0.7.1.1 2) Built a simple synth using SM's MIDI to Poly, Preset Manager, Multi Osc, 2 filters, OSC signal running through 1 MSCE's In/Out, 2x2 MSCEs' "env"-out feeding each filter (total of 5 envelopes). 3) Boosted the number of patches to 99. 4) Editing started to seem sluggish, though not nearly as bad as my posting above. Perhaps because the 3 arrays in the WIKI version have only 64 rows/MAX ENV POINTS, while mine have 100 rows. 5) Made as a VSTi. 6) In my host, it ran OK for the first few patches (which already had envelope data from the WIKI), but when I selected patch 55 or so, the envs had no data, host froze, & system CPU pegged at 100%. 😠

-- Anyone else have problems sluggish/always-100%CPU while editing an OSM, VST, lag issues with arrays (in particular VST Parameter Array) please?

Tom7777 · 8 Mar 2008

One thing i notice slows down SM alot is if you have lots of text modules with wave arrays etc in the same module, the more you have the slower things get which is quite annoying, but just lots of stuff in general, i have focused on smaller projects recently due to SM getting really annoying to use on larger projects. For me atm its cpu and large projects which are the problem with SM stuff but im hoping these will get sorted. 😉

Acrobat · 8 Mar 2008

infuzion wrote: -- Anyone else have problems sluggish/always-100%CPU while editing an OSM, VST, lag issues with arrays (in particular VST Parameter Array) please?

Yeah but not those "100% s" related to denormals... 😉

infuzion · 9 Mar 2008

Tom7777 wrote: i have focused on smaller projects recently due to SM getting really annoying to use on larger projects. For me atm its cpu and large projects which are the problem with SM stuff but I'm hoping these will get sorted.

I agree with you being afraid to use SM for large projects for these issues. However, I do not think SM is worth it for small professional projects either, since the overhead of a wrapped 1Mb DLL & somewhat expensive OSMs are too much for small projects. The SM DLL is over twice as big as some larger synths like Helix! In my thinking of live-computer music, you need to the most out of little RAM & CPU as possible. Also, many hosts have enough built-in plug-ins for many needs.

So, if SM can't handle big projects (this thread here & that there), & is too big for small ones (IMHO), then SM is useless for me in my aspiration to produce semi-pro synths. I too hope these get sorted, because it is nearly a deal-breaker for me. Sorry if sound mean, but that is my viewpoint.

Acrobat, perhaps there are also denormal issues; you can test that yourself please by d/l the WIKI file. The said lag is just by opening & editing, before notes are played. Mostly a green-data or memory issue perhaps.

malc · 14 Mar 2008

Hi infuzion,

I tried the file that you sent me. The 'laggyness' is caused by the time needed to redraw the main module in that file. I'll explain more in a private email (as your schematic is private) but I think that it's useful for people to know that if the they create modules that take a long time to draw then this can make schematic editing really slow down.

The preset array shouldn't affect editing performance unless of course it contains data that causes your schematic to do alot of processing or drawing.

If anyone has a specific example of slow editing then just send me the schematic and I can take a look. Infuzion sent me his and I could fairly quickly tell him what the issue was.

It's almost impossible to investigate these kind of issues without an example.

Cheers!

Malc

infuzion · 15 Mar 2008

Thanks for the suggestions malc, I've added them. I still see some very minor slugishness when I use several of those envelopes, but nothing to worry about right now.

I'll do better with checking files before sending them. cheers

infuzion · 8 Oct 2008

This still happens in v1.1.2 😠

Granted, the project I'm working on is quite large: 2Mb zipped, over 265,000 primitives, 318,000 links, 1629 synced modules... but I'd think a desktopwith a Core2Duo & 2Gb 800MHz Ram should be able to handle it.

stefan wrote: infuzion wrote: ... Malc had emailed that synchronized modules can help add to the lag in opening, editing, etc.

I thought you'd be able to use Shift+Ctrl+Alt+S for such duties?

I just tried that with only 2 versions of the almost-same files, fresh opening of SM, no editing, & a no-report crash on SM. 😠 😠

Note: I'm not sure if I can send said file for testing, since I'm just the 2nd tier editor. I have little free time for SM, & the editing lagginess & crashing is eating up that time faster than I expected. Not to mention making SM un-fun.

Tom7777 · 8 Oct 2008

Yeah i notice this also, i basically haven't done any big projects in SM for a while now due to stuff like this, at the moment i just open it and work on basic things hoping that things will get fixed but they don't seem to be unfortunately, so at the moment even though i still check out SM stuff i put my main focus on other things 🙁

For an example of something that slows SM down is having a page of Text module arrays, even if they are not connected it slows SM down loads.

But i find once a project gets to a certain size when building normally things just go downhill in terms of the programs work speed, dragging things lags and wires go to the wrong place or deleted by mistake and copying pasting things im waiting around etc so i just don't bother with large projects now to be honest in SM.

infuzion · 8 Oct 2008

Tom7777 wrote: For an example of something that slows SM down is having a page of Text module arrays, even if they are not connected it slows SM down loads.

There are alot of float arrays, but only very few Text Areas fortunately.