Ross Bencina wrote:
>
> Michel wrote:
> >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) ?
>
> Let's face it, it's possible to reduce anything like this into a well
> defined interface. But to propose an interface without a clear understanding
> of the current implementation is silly - just asking John to confirm isn't
> enough. Someone is going to have to do some serious analysis and design if
> sa.dll is going to be robust and generally usefully.
I realize this Ross, but please let's not start calling each other silly :-) I
threw in what, having heard Michael and yourself, I thought was the minimal
interface necessary and sufficient for future interfacing of sa.dll with a
vst2 adapter dll. I hoped an sfront specialist would jump in and tell us if
this truly minimal interface can be implemented without a major rewriting of
sfront, and Michael's post seems to confirm it can.
> IMHO you're going to need more that 2 functions. For a start you will need a
> factory interface to spawn off multiple instances of the saengine (multiple
> instances of the same plugin).
Doesn't the operating system take care of this ? I believe the OS makes
multiple copies in ram of the dll code when you load it several times, am I
mistaken ?
> As stated perviously it would be nice to have
> some sort of reflection mechanism so that a user of sa.dll can query it to
> find out info about the channel confiuration (mono, stereo etc.), perhaps a
> list of global ksigs (they could be mapped to VST properties for example)
> etc.
That's what the SFrontPlugInfo structure is for.
> If there is sample playback involved are you going to allow the user of
> sa.dll to swap the wavetables at runtime or is that hardcoded when sa.dll is
> compiled?
If you mean "are the samples hardcoded into sa.exe by SFront", i have been
wondering this as elpelele's sa.exe is about the same size as its samples. So
I tried to run it without the sample files present and I got a "samplefile not
found" error. Therefore wavetables are read in at runtime. Thus nothing
prevents the user from replacing a sample file by another one (with the same
name) at runtime, and then either telling sa.dll to reload its sample (via
MIDI), or reloading sa.dll.
> >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:35 EDT