30% faster if you split one plugin in several smaller ones?
can you explain me how this should be possible? I doubt this test is representative.
I am really no vst expert but there has to be a tradeoff for SE's framework flexibility instead of a single purpose vst, and a tradeoff for multiple plugs instead of one?
I'm also no VST expert - in fact I've never developed any VST or VSTi at all - so this is just plain guesswork...: can you explain me how this should be possible? I doubt this test is representative.
I am really no vst expert but there has to be a tradeoff for SE's framework flexibility instead of a single purpose vst, and a tradeoff for multiple plugs instead of one?
I agree that there must be some overhead in running several DLLs instead of one, but as long as the patch has only a subset of the features found in the synth, I think it's likely that that might compensate for the multi-DLL overhead. I haven't got the faintest clue how bserrano constructed neither the HeliosII nor the Modular patch, but I can see that the patch only contains parts of the synth. Even if a part of a VST(i) isn't in use, the plugin has to have some bit of code running to check that.
I really like the idea of separate modules - it makes it possible to create unusual signal paths without investing time and/or money in buying and learning some extra modular synth.
Statistics: Posted by bsork — 21 Aug 2008, 08:45
]]>
I am really no vst expert but there has to be a tradeoff for SE's framework flexibility instead of a single purpose vst, and a tradeoff for multiple plugs instead of one?
Statistics: Posted by amiga909 — 17 Aug 2008, 12:20
]]>
The same patch with HeliosII use about 30% more.
Cheers...
Statistics: Posted by bserrano — 16 Aug 2008, 23:25
]]>
. Just assemble them in Usine to build your own machine, and save a lot CPU.
What dou you think?
cpu: every SE .dll has some cpu overhead. you have to load the SE engine for every plugin. make a simple delay with SE. compare plugin loading time, filesize and cpu meter with eg. mda delay (or any other basic delay).What dou you think?
-> rather try to build subpatches with usine modules to have synth basic parts.
or use a modular vsti like Zebra or Vaz. much more effective than using loads of SE plugs.
the good thing about your idea is that Usine has dedicated in+output pins for vst params, this really let's you go much further than with a host like energyXT.
still I dont think this opens new perspectives for vst dev's. to deliver basic modules like an oscillator/lfo/env is a matter for the host (usine).
of course: if you can progress in synth/fx patching using basic SE plugs in Usine, go for it
if you want a cpu effective solution, look for a single vst that can do the job.
Statistics: Posted by amiga909 — 04 Aug 2008, 17:40
]]>
a very, very good idea...
I think about something about optimization and cpu :
DLL versus usine module (i think about the SDK here), who is best optimised ?
anyway, a good start to this fabulous concept.
ps : if only we have a C++ SDK, i could put my hands on....but i know usine need to be stable enough (in coding interface terms) before.
Statistics: Posted by martignasse — 03 Aug 2008, 23:54
]]>
Not limited to Synthedit I think.
I meant: plugins done specially for Usine! (since no else soft can do half the same). Hot stuff in SE-plugins buiders heads.Bet that other builders will follow soon...
Statistics: Posted by Vincent — 03 Aug 2008, 23:14
]]>
]]>
And screenshot: http://bserrano.free.fr/Usine-Modular.png
In some words: SynthEdit developpers are thinking to DLLs that are parts of synths. Just assemble them in Usine to build your own machine, and save a lot CPU.
What dou you think?
Statistics: Posted by Vincent — 03 Aug 2008, 16:31
]]>