Plug VSTi parts and buid your synth directly in Usine!

[Vincent]

Unfortunately in french, but very exciting: http://nay-seven.com/detail.php?forumid=3&id=817&page=1
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?

[stanlea]

Nice idea. Not limited to Synthedit I think. But the first shots are promising.

[Vincent]

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...

[martignasse]

yes,

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.

[amiga909]

. 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).

-> 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.

[bserrano]

Performances are really correct! http://bserrano.free.fr/Modular.png

The same patch with HeliosII use about 30% more.

Cheers...

[amiga909]

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?

[bsork]

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...:

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.