I'm forwarding this message from Ross to the list, where it's clear from the
context that it was meant to be sent. I think I agree with most of what you
say, Ross, but I am waiting to hear from others to get the general feeling on
this plugin question. Michel Jullian
--
attached mail follows:
Here are my thoughts:
I think that the VST2 license and GPL are incompatible conceptually. Anyone using the VST2sdk should be downloading it directly from steinberg and acknowledging steinberg's license that way. Unless a special dispensation >from steinberg can be obtained (and I doubt it) if sfront required the vst2 sdk you would need to require the user to download it from steinberg.
Much as I think VST2 is a usefull and no doubt defacto standard for creating audio plugins on certain platforms, it is by no means the only plugin format available and isn't ideal from a number of perspectives. That said, I agree that it would be nice to be able to build a vst2 plug using sfront. It would also be nice to be able to build an embeddable code module that could be used as the basis of an app, a csound ugen, a direct-x plugin etc. etc.
Here's how I would do it (IMHO, easier said than done, with all due respect, etc...), also bear in mind that I don't quite understand how sfront is doing this at the moment:
Sfront should be able to generate the following (decoupled) outputs:
1. A generic "signal generation / processing engine" 2a. A header file with #defines for properties of the engine (number of i/o channels, buffer format, etc) 2b. (optional) A shell that hosts the engine to create an executable including file io etc.
As I understand it sfront currently spits out 1 and 2b as a merged unit.
I would propose that 1. (the generated engine) can provide information about itself at runtime (reflectivity), VST would need this to determine properties etc. The engine should have a well defined set of entry points and perhaps only a single function in the global namespace, eg:
typedef struct sfront_engine{ void (init*)(void); ??/* All the necessary callbacks to pump data in and out of an sfront instance... *./ }
sfront_engine* new_epelele_engine();
In this scheme, generating a VST plugin would involve linking the engine with some VST glue code (which would theoretically use 2a - header info to build the appropriate wrapper - perhaps this is not necessary).
To summarise, sfront should be entirely usable to generate code that can be run stand-alone, embedded in another app, or wrapped into a plugin. However, if sfront is going to remain a maintainable entity the burden of pluginwrapper development shouldn't be considered a "core" sfront responsibilty - that should be the job of a separate "kit" or tool.
Thanks for the airtime,
Ross.
Michel Jullian writes: >Unless SFront outputs the text of Steinberg's license agreement the first time >the -vst2plugin option is used, with a "press Y to agree, any other key to >abort" sort of thing ? (I would quite understand if John was reluctant to do >this though) > >Otherwise maybe a non-vst2 sfront-format dll, which could be loaded by >sequencers directly or via a sfront-format to vst2 adapter (as in below, first >paragraph) would be the only legal/practical solution ? > >Or maybe the non-vst2 option could be implemented as a first step, leaving us >time to sort out the vst2 questions. > >Ideas, anybody ? The final word will be John's of course.
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:33 EDT