Dynamic Linking of DLLs for exports

[infuzion]

Split up the SM engine in a few DLLs:
* General/green
* Graphics
* Audio
* MIDI
That way, is someone (like me) wants to make a small MIDI widget with no graphics, everything else that is unused doesn't have to added to the VST/exe.

Either that, or just have all the SM support stuff in a seperate DLL so the VST/exes will be smaller.
cheers

[infuzion]

Either that, or just have all the SM support stuff in a seperate DLL so the VST/exes will be smaller.
cheers

Re-up request to split the SM-support DLL from the VST DLL, so the second & multiple SM VSTs would be faster to load.
I remembered my request when I saw the second post here:
http://www.kvraudio.com/forum/viewtopic ... sc&start=0

I just get annoyed by how long SM stuff takes to load, so that always turned me off of them.

[MichaelBenjamin]

i think as long as you dont use massive after load triggers with arrays, sm plugins load quite fast since the last 2-3 updates. in general sm plugs take about a second to load, which is ok imo. but more optimizing to the exported vst dll, so that it only compiles what is needed, surely, approved.

[Andrew J]

Interesting idea!

On the issue of slow loading, I still have issues with a plugin with lots of automation and I'm guessing this is to do with large green arrays (e.g. I've got one with 171 parameters & 30 programs which takes 9 seconds to load). Anyone have any thoughts on that before I go and start a new topic on that?

-Andrew

[infuzion]

On the issue of slow loading...start a new topic on that?

Start a new topic please

[Eska]

I have currently 4 VST-Arrays with 520 parameters for the synths and one with 280 parameters for the softpads in the actual version of QUODfm (update in 2 days) . Loads in 5,5 sec on my Lap and 3 sec on my E6600(SATA) , so there might be some other reason for the slow loading.

[infuzion]

..Loads in 5,5 sec on my Lap and 3 sec on my E6600(SATA) , so there might be some other reason for the slow loading.

That is slow. I think this tip will help, & please put all questions & tips about what we as OSM programmers can do NOW here:
viewtopic.php?f=12&t=6550

Splitting off the DLL will only speed up all loadings of SM-VSTs after the first SM-VST load, as well as save memory, HD space, etc.

[Tom7777]

Nice idea, +1 vote

[infuzion]

Splitting off the DLL will only speed up all loadings of SM-VSTs after the first SM-VST load, as well as save memory, HD space, etc.

Now that SM plugs are getting more popular, how about another look at not wrapping the DLL inside every VST please?

[sunsynth]

Yeah - a very good idea - this runtime thingy like the vbrun.dll etc. in the system folder... +++1

Also an 'intelligent' compilation what libs are really needed (GUI, Midi etc.) maybe useful 2
as u mentioned before infuzion

[aliasant]

As long as this wont turn into something like Reaktor or Pluggo were the user first has to install some lib/dll before installing his SM plugin. That would not be good but perhaps the plugin can have a built in checklist that runs the first time its launched. If there is a libfile /SM.dll thing then fine if there is none installed previously then a popup asking the user to download and install the SM.dll.
That should just be a popup window with 1 cancel and 1 ok button. No more interaction from the user and this will only happen the first time the user installs an SM plugin. The "SM.dll" should be downloaded automaticaly and installed and this shouldnt take more then a few seconds ... as long as the user has a connection of course.

I just hate the idea of forcing the user to "Go to this url.. look for this thing...... download the right version..... install it using the right system.... blablabla... Then install my plugin .."

Or is there another way of doing this?
I mean.
The SM.dll thing has to be somewere in the users system.
Now its wrapped inside each plugin but if its not it has to find another way to get into the right place.
Or we have to include that as a seperate file next to the plugin and ask the user to put it in the right place.

Another big problem with have a seperate .dll file is updates.
What happens if a user is using say 5 different SM plugs and they are all written using different versions of SM.
The the user installs a new SM plugin that wants to update that .dll to the latest version and that then breaks the compability with some of the users older SM plugs. What then?


Im all for optimizing it but to take it out of the VST.dll is more problems then its worth.
It is also quite a small file.
Sure 5 years ago it might have made a difference but today storage aint a problem anymore.
Hell. I have an SDHD card in my Digital camera that is 16Gb and runs 40Mb/sec! And that is just an average SDHD card.

[trogluddite]

Yeah, I agree with Aliasant - it would be a shame to lose SMs hard-won stability (thanks Malc) for the sake of a few Meg of memory and 5 seconds of studio time. By way of illustration, here's a little bedtime story from my studio...

"Loading" time for new guitar riff...
1) Find guitar lead that doesn't crackle - 5mins
2) Tune Guitar - 10mins (plus 5mins to find tuner, discover battery dead, go find new PP3 battery, install new battery...)
3) Create Cubase track/routing/fx chain - 10mins (Which amp would sound best?, what was that cool flanger plugin called again?...)
4) Find guitar pick - 10mins (It was down the back of the sofa - sure I bought ten last week)
5) Press Record - 2mins (allowing for; getting tangled in guitar lead, tripping over wah-wah pedal, knocking mouse/keyboard on the floor etc. etc.)
6) Try to remember the fantastic killer riff I was going to record....

Loading time for SM plugin...
A few seconds! - Is that really such a big problem?

Back when I first started doing this, the latency on my soundcard was longer than it takes most plugins to load these days - I guess human impatience grows exponentially faster than Moore's Law

[Acrobat]

Now that SM plugs are getting more popular, how about another look at not wrapping the DLL inside every VST please?

That's the correct request, IMO...

[MichaelBenjamin]

if it adds more files on harddisk and possible installation / updating problems, i would be against it.
however, if the included vst.dll would be somehow self-reducing/optimizing depending on the actual used parts in the schematic i would vote for it. there is nothing better than one file for one function/program.

[aliasant]

Now that SM plugs are getting more popular, how about another look at not wrapping the DLL inside every VST please?

That's the correct request, IMO...

It sounds great but how would that really work?