Copyright is never legally or politically intended to prevent
inter-operation and in fact using the exact interfaces in the VST 2 plugin
architecture for a SAOL plugin would be perfectly legal - it is only illegal
to simply copy the header file or to cut and paste its code. I should
imagine that reading the VST header file, then retyping it with different
variable names and a different layout, would be quite legal. Of course, I'm
not an attorney, so you should ask a qualified one about this if you're
really planning to do something. I'm copying the VST developers list on
this, so Steinberg is free to reply.
Whether duplicating the VST interface layout or providing another one is
preferred, I think it would be a mistake to not encapsulate the entire
sfront process, including all compilation and driver selection, in a shared
library.
-----Original Message-----
From: Michel Jullian [mailto:mj@exbang.com]
Sent: Wednesday, September 01, 1999 3:41 AM
To: saol-dev list
Subject: "-plugin" option for SFront (was Re: (vst2 ?) plugin output
option for SFront ?)
Thanks, John and Ross for pointing out the legal difficulties with the
-vst2plugin option.
Shall we settle for a -plugin option generating code for sa.dll, a non-vst2
shared library plugin then ?
If so, we'll have to define sa.dll's interface. Since it will be purely a
fixed i/o MIDI-controlled processing engine, it's interface needs not be
more
complicated than the two following functions imho (the SFrontPlug prefix in
the name of the functions will help hosts determine if a dll has the SFront
plugin interface or not, and will distinguish these functions from other
functions in the case of a dll featuring multiple interfaces) :
- SFrontPlugInit() to initialize the plug (preferably with a sample rate
argument overriding the saol sample rate, do you think that's possible John
?), returning a pointer to an SFrontPlugInfo structure telling the host how
many audio inputs and outputs the plug has (and maybe other properties ?).
- SFrontPlugProcessNextNFrames() to have the plug compute a time slice of N
frames. Arguments to this function should comprise N (may be different from
one call to the next), a pointer to a MidiInputEvents structure (compatible
with VST's, pointing to events falling into the time slice, frame-accurately
timestamped relative to the beginning of the time slice), and pointers to
the
audio input and output float buffers.
I probably am forgetting/overlooking things in this very first humble vague
attempt at a specification, interested people please contribute :-)
John Lazzaro wrote:
>
> > Ideas, anybody ? The final word will be John's of course.
>
> Legally, this may be worse than you think -- the code in the
> driver is going to become a part of sfront itself, since
> all driver code gets wrapped into strings that get bundled
> with sfront source code and thus the executable. So, the
> actual code in your driver needs to be under a license
> compatible with the GPL. And from the Stienberg side, anyone
> who downloads sfront -- regardless of whether they ever
> invoke the -vst2plugin option -- is running a program that
> includes their code.
>
> I'm not really following the thread close enough to understand
> the issues completely, but basically drivers shipped with
> sfront need to be compatible with the GPL (note that compatibilty
> means that looser, LGPL licenses are fine).
>
> --jl
-- Greetings, Michel ......................................................................... Michel Jullian Directeur General email mj@exbang.com Exbang Industries S.A. Mas Chauvain route de Villeneuve tel +33(0) 499 529 878 Maurin 34970 Lattes France fax +33(0) 499 529 879 .........................................................................
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:33 EDT