(f* reply button. Here it is again for the whole list)
Michael Gogins wrote:
...
> 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.
I agree with you Michael, it would be a mistake not to do your Noise.dll.
People, just imagine loading a plugin into a sequencer track and being able to
edit interactively both the plugin structure (in SAOL) and its inputs (MIDI
score and/or audio, realtime or recorded). Noise.dll will rule !
However (I would like to make this clear for people who might follow this
discussion more remotely), Noise.dll does _not_ dispense us from sa.dll (or
whatever the extension will be on the target platform), the pure C shared
library generated by SFront via the -plugin option. Michael will correct me if
I am wrong, but Noise.dll itself will (via SFront and a C compiler such as gcc
or lcc) generate sa.dll and load it. Compatible sequencers (such as our SBS
Sequencer hopefully) will also be able to generate maybe (via SFront and a C
compiler again), and in any case to load, sa.dlls directly.
Which brings us back to the need of specifying an interface for sa.dll. Could
John or somebody else familiar with sa.c please tell us whether sa's computing
engine could be driven via a simple two-functions interface such as the one I
sketched in an earlier post (quoted below for convenience) ?
-----
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 will add the following precision : although MIDI events' time stamps will be
frame-accurate, it obviously will not be required that they be taken into
account before the following k-pass.
Thanks for feedback.
-- 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:34 EDT