From the original SynthMaker forum (2004–2014), with its members’ names and dates.
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 ·
infuzion wrote: 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 ·
Andrew J wrote: 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 ·
Eska wrote: ..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: THE "How to speed up VST loading?" thread
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 ·
infuzion wrote: 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 ·
infuzion wrote: 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 ·
Acrobat wrote: infuzion wrote: 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?
infuzion ·
aliasant wrote: Acrobat wrote: infuzion wrote: 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?
I do not want to sound sarcastic, but that is what DirectX, .NET, Visual C++, Flash, Java, & urm... many of your programs run on; an EXE/DLL/script that calls other DLLs. You'll have to have a standard of putting the DLL somewhere, & having an installer to check for the right version of the DLL & install it if need be. There are indeed drawbacks to an external DLL though.
aliasant ·
infuzion wrote: .... that is what DirectX, .NET, Visual C++, Flash, Java, & urm... many of your programs run on; an EXE/DLL/script that calls other DLLs. You'll have to have a standard of putting the DLL somewhere, & having an installer to check for the right version of the DLL & install it if need be. There are indeed drawbacks to an external DLL though.
Yes. And do we like them? Any of them? Having to constantly chase updates for all of these apps? Conflicting dlls and bogged down systems.
Just because it is what others do doesnt mean its the right way to go 😉
And isnt this one of the main reasons Pluggo and Reaktor VST plugins never really made it?
infuzion ·
aliasant wrote: And isnt this one of the main reasons Pluggo and Reaktor VST plugins never really made it?
Actually, you can use Max/MSP5 plugs if you d/l the "distributable"/DLL. You have to buy Reaktor to use any of those plugs so that is not a good comparison. I think DirectX, .NET, Visual C++, Flash, Java has a much bigger userbase because they allow the DLLs to be d/l for free, & can be programed with for free as well.
Tzarls ·
I don´t fully understand your request, Infuzion. Let´s use some example to clarify:
I have a basic schematic. Let´s say Midi In, go to splitter, go to osc, go to env, go to amp, go to stream2mono (can you believe I forgot the primitive´s name?), go to the outer world.
According to your request, you want to have your exported vst as a bunch of dlls. One, for example, with all the instructions needed to handle incoming MIDI messages. The othe DLL that has all the functionality related to oscillators, etc. etc. etc.
The, when the vts is loaded, it starts processing. First, in the main dll, it finds a call to MIDI related functions. Ok, call appropriate DLL. Then it finds the need for an osc. Ok, call the other DLL. And on and on and on.
Is this what you are asking for or I´m getting it wrong?
infuzion ·
Tzarls wrote: Is this what you are asking for or I´m getting it wrong?
Right now as of v1.1.7 (maybe 1.1.6), your exported VST (which is a DLL in itself) contains 3 things: 1) Your OSM, encrypted 2) the "vst.DLL" that you find inside your SM install folder 3) "wrapper" code, that lets your OSM, vst.DLL, & the VST interface so they all can talk to the VST host, run, allocate memory, etc.
What I want is my exported VST to contain only 2 items: 1) My OSM, encrypted 2) "wrapper" code, that lets my OSM, vst.DLL, & the VST interface so they all can talk to the VST host, run, allocate memory, & load an external "vst.DLL" if not already loaded.
For example, when you run a program built with MS Visual Basic/.NET, those run-time libraries are not wrapped inside your .EXE, but are called to run as external .DLLs. I want SM to do the same.
Clear enough?
aliasant ·
But theres to many problems. Compability problems being my major concern apart from me hating the idea to have to install something to run a vst plugin.
I guess that last part is just a very strong emotional thing I have... If a Vst plug needs something other then the plugin.dll itself to run it aint a real vst plugin. At least that is how I always felt about Max/Pluggo plugs. No matter how nice they sounded having these "not really real vst plugs" in my plugin folder felt wrong. I dont think Im alone in this and I think it would scare away a lot of potential customers both for our plugins and for SM itself as a platform. Again. That is just feelings. The compability problems is a much bigger real issue.
As it is now every VST that is made with SM will run perfectly stable if it did that when it was created.
If we use an external .dll that will not be the case and old plugins might not run or might even crash a machine if run with a newer dll. And the other way around.. Newer SM plugins wont run with old .dll so the user has to compromize. Does he want to use his old favourite SM plugs or trash them and only use this new cool one that Infuzion.inc made ? 😉
There might be ways around this. Maybe like Direct X and others do. Having the newest .dll's placed next to older version but again that is not a nice solution. I just cant see the benefits of this with todays modern and screaming fast machines not to speak of tomorrows machines.
MichaelBenjamin ·
i suppose the harddisk space is not important, so if its just about ram usage: why not keeping the vst.dll inside as it is for compatibility and add some check for the ram - if that vst.dll is already in memory it doesnt need to be loaded again. so the first time you load a sm plug, it will be as is, and the next instances would be faster, since the vst.dll doesnt need to be loaded again. but that aside i think current loading times are really ok for me, let alone hd space, so that would not be the most urgent problem.
trogluddite ·
aliasant wrote: Newer SM plugins wont run with old .dll so the user has to compromize.
Could be a lot of hassle for us developers too - lots of end users emailing us 'why doesn't your plugin work any more?" - then having to keep links to the latest dll. and keeping our plugins up to date each time malc does a new release. I find "New Update for Java/Quicktime/Windows/Firefox/etc.etc." annoying enough already.
Right now, SM seems more stable than ever - I haven't had a crash for nearly two months (apart from when I screw up my ASM programming!) - and that's on a project with over 30,000 primitives and 40,000 links. SM is also getting a much better reputation these days too - see SOS reveiew of AMs KickLab, SM as part of FL, SM included on Computer Music cover disk etc.
Reliability has been Malc's big project for the last few updates, and he has done incredibly well - so, as the old saying goes... "If it ain't broke, don't fix it!"
Tzarls ·
Isn´t vst.dll the wrapper itself? I thought it was some kind of SM in plugin version, without all the interface and toolbox etc. It would the load the embedded schematic and serve as a negotiator between the host and the schematic.
infuzion ·
trogluddite wrote: Right now, SM [editor] seems more stable than ever - I haven't had a crash for nearly two months... SM is also getting a much better reputation these days too - see SOS reveiew of AMs KickLab... Reliability has been Malc's big project for the last few updates, and he has done incredibly well - so, as the old saying goes... "If it ain't broke, don't fix it!"
That is actually part of the problem; was not that long ago that SM was cruddy. I agree with you; I'm do not want to use any SM-VSTs unless they were re-rendered in the past months. But if the VST.DLL was not wrapped inside of their projects, then one could just copy over the bug-fixed DLLs without the need for the author to re-render. So if we had detached DLLs, the Outsim could quickly fix existing exports but just providing the updated DLL. Case in point: Max/MSP runtime; no need for the patch authors to resend a new export, just let them know to d/l from Cycling'74.
MichaelBenjamin wrote: i suppose the harddisk space is not important, so if its just about ram usage: why not keeping the vst.dll inside as it is for compatibility and add some check for the ram - if that vst.dll is already in memory it doesnt need to be loaded again. so the first time you load a sm plug, it will be as is, and the next instances would be faster, since the vst.dll doesnt need to be loaded again.
I agree with you with computers becoming incredibly faster; I beginning to think it would be cheaper for me to ditch SM & just buy an i5/i7 laptop & run a resource-hog like Reactor or Max/MSP. However, with faster CPUs, comes the desire to load more VSTs at once. So even a faster HD would be counter-balanced by this. Plus, it is always desirable to have VSTs load ASAP in live situations, which is part of my target market.
Acrobat ·
One point to add to the discussion: I have a particular project going on, where I decided to ban BMP, PNG images and use just primitives for the graphic interface, totally custom and original interface: wonderful results, it takes just 46Kbytes of OSM .... .....but AGAINST 1047Kbytes when rendered! Almost ALL the file size is the basic SM .DLL plus a few kbytes of the schematic added. Loads up in a millisecond, anyway. 😉 A.
infuzion ·
Acrobat wrote: Loads up in a millisecond, anyway. 😉 A.
On what kind of system? Though HD speed is becoming a moot point, you still have to test on an older system, with a project of several SM plugs to test the "worst case scenario".
It is like a project I was working on, when the project lead was saying the OSM was only taking 15% of CPU... on his quad-core.
Acrobat ·
infuzion wrote: Acrobat wrote: Loads up in a millisecond, anyway. 😉 A.
On what kind of system? Though HD speed is becoming a moot point, you still have to test on an older system, with a project of several SM plugs to test the "worst case scenario".
Right, but my project has lots of interactive vector GUI but very afew audio procesing, almost avoiding SELECTORS. If you keep on this specifics, the loading time is almost instantaneous on every system, guaranteed. To my relatively long experience, it's always the selectors and multiplexers that raise the loading time. Nothing else. That's because the audio path gets nested, so SM needs to compute every possible case before giving you the plug itself.
Anyway I still work on a single processor Intel 3.4+a big rumorous fan. Cheers, A. 😉
P.S. ah of course loading wavetables or samples increase loading time too...
MichaelBenjamin ·
Acrobat wrote: That's because the audio path gets nested, so SM needs to compute every possible case before giving you the plug itself.
i dont think sm precalculates every possible selection on load, since with bigger schematics you easily get cpu spikes and at some point asio stream interruption when switching lots of selectors/big code chunks. so i would rather guess the recalculation is done on the fly and does not affect load time on startup.
MegaHurtz ·
MichaelBenjamin wrote: Acrobat wrote: That's because the audio path gets nested, so SM needs to compute every possible case before giving you the plug itself.
i dont think sm precalculates every possible selection on load, since with bigger schematics you easily get cpu spikes and at some point asio stream interruption when switching lots of selectors/big code chunks. so i would rather guess the recalculation is done on the fly and does not affect load time on startup.
Although code really goes easy all the time..
infuzion ·
Acrobat wrote: To my relatively long experience, it's always the selectors and multiplexers that raise the loading time. Nothing else.
I'm not 100% sure of "Nothing Else" slowing down loading time, but I did strongly recommend to McBarGig to reduce Selectors for the preset loading time drag for his monster VSTs.
On the other hand, I'm switching to an SSD; loading time won't be too much of an issue as long as I don't have 200 VSTs on my drive, so loading time is an issue of the past soon. On the other other hand, since it is only a 40Gb SSD, I do have to worry about not filling it up... therefore I still want smaller file sizes 😉 :P
attic ·
Be-careful if you use Kapersky Antivirus with that SSD, it trashed an OCZ SSD that I used for a year. Until the fateful install of Kapersky it was a screaming fast upgrade. Kapersky treated it as just another drive and you cant do that with a SSD.
Acrobat ·
infuzion wrote: Acrobat wrote: To my relatively long experience, it's always the selectors and multiplexers that raise the loading time. Nothing else.
I'm not 100% sure of "Nothing Else" slowing down loading time, but I did strongly recommend to McBarGig to reduce Selectors for the preset loading time drag for his monster VSTs.
Sorry mister you are right as loading many wave tables slows down too, btw you mean multiplexers don't contribute? 🙂
MichaelBenjamin ·
and why would a ssd that contains no moving parts be trashed by some virus scanner besides this being another hint that all permanent active anti virus software resembles more torture than anything else for a computation machine in general?
attic ·
why would a ssd that contains no moving parts be trashed by some virus scanner
I really don't know what may have happened, but when the drive failed Kapersky had just been installed and decided that my boot sector was fishy, after kapersky messed with the boot sector it refired the computer and the computer could not find an operating system. The odd thing is that the drive would no longer except any kind of write but ended up readable just not writable. I was able to recover my data with some drive recovery software, but the drive would never except a write after that. You couldn't make a new partition, you couldn't do anything. I have recovered many hardrives and built many machines so it wasn't that I didn't try just about everything that could have been tried. It almost seemed more like a controller board problem and the nand blocks were recoverable. Someone suggested it had something to do with the virus software messing with the alignment but I don't see how that would have made the drive unwritable. It was a 1st generation Ocz with no trim.
I now run an Intel SSD and it is great but the Ocz stuff seemed to be slightly faster on my system. The Ocz required more care and a higher tech knowledge level to maintain. In a nutshell the Ocz seemed slightly faster than this Intel drive but the Intel drive has trim and is convenient to set up and to maintain. The Intel drive has not exhibited any problems with kapersky. I do recomend SSDs in general as they really speed up your machine, but I think that there are some undocumented bugs in a particular drive.
samlauncher ·
Hey guys m looking for best exporters plz help….
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker