.Sem and .Sep files needed for end user?

[Sonic Assault]

Actually, its Windows that requires that the third party SE modules are extracted separately - they are like any other .dll file you find littering your hard drive. Except with SE .sep and .sem files you know exactly where they are, and you don't have to go on a bloody redundant .dll file hunt after deleting the program.

That's the stupi -- err, actually, it's a pretty clever workaround to a flaw...

By the way, jafo

[BFunKu]

Just out of curiosity How come SynthMaker doesn't render it's own .dll files like SE then if Windows needs them to run the particular VST? Aren't SM Modules really No different than SE Modules just that they can only be loaded in their own program obviously? You could copy and paste Code from SynthMaker's coding system into C++ and vice-versa right? A lot of the SM modules are actually based on a lot of C++ Code(PreFab) as far as I can see from comparing different elements.

[stefancrs]

Just out of curiosity How come SynthMaker doesn't render it's own .dll files like SE then if Windows needs them to run the particular VST? Aren't SM Modules really No different than SE Modules just that they can only be loaded in their own program obviously? You could copy and paste Code from SynthMaker's coding system into C++ and vice-versa right? A lot of the SM modules are actually based on a lot of C++ Code(PreFab) as far as I can see from comparing different elements.

SE can work with are third party libraries, called as external modules. This is not doable in SM, and all "third party modules" are created internally within SM.

You can't really copy-paste SM code into a C++ project or vice versa, it takes some translation work too, because even though the syntax is similar, it's not anywhere near the same.

[whyterabbyt]

You could copy and paste Code from SynthMaker's coding system into C++ and vice-versa right?

SM's code module is closer to a cut down version of C than C++, I'd say; there's a huge amount of stuff that normal C++ code would use that has no SM equivalent.

A lot of the SM modules are actually based on a lot of C++ Code(PreFab) as far as I can see from comparing different elements.

'based on' as in 'ported from'. But (C and) C++ are probably the most common languages you'll find for DSP code examples, that's why. Not because the languages are close. If SM Code looked like Pascal, the code would still be being ported from those same C and C++ examples.

[dover666]

You could copy and paste Code from SynthMaker's coding system into C++ and vice-versa right?

SM's code module is closer to a cut down version of C than C++, I'd say; there's a huge amount of stuff that normal C++ code would use that has no SM equivalent.

A lot of the SM modules are actually based on a lot of C++ Code(PreFab) as far as I can see from comparing different elements.

'based on' as in 'ported from'. But (C and) C++ are probably the most common languages you'll find for DSP code examples, that's why. Not because the languages are close. If SM Code looked like Pascal, the code would still be being ported from those same C and C++ examples.

and i'd think as a general rule, algrebra looks like algebra, even on silicon.... goodnight folks.

[chuck death]

Hm, those modules are needed to run the instruments. So please dont remove them, they are simply C+ code. They should be in the same folder as the corresponding dll. file, so I think you can move them to a subfolder.

Moving them doesn't matter, if the SE vst/vsti can't find its files it will automatically recreate them the next time you use it.

About the subfolder thing, the SEP/SEM files must be in the same folder as the VST/VSTi and the folder must have the same name. If they aren't the plugin will again create them automatically.