The current design of sfront does not lend itself to multiple-instance
servers, which Ross is talking about here. sfront is a "process" and assumes
that all static objects occur only once per process. The operating system
can copy static objects for different PROCESSES served out of the same code
(program text, technically speaking) but not, without additional coding, for
different THREADS or different INSTANCES.
I was assuming that even a one-instance sa.dll is better than none. Changing
the design to support multiple instancing would, in practice, almost
necessitate a complete rewrite and would most naturally be done in C++, not
C. Presumably any really commercial implementation of SAOL would do this.
Of course the current sfront implementation allows the orchestra to be as
big, fat, and complex as you like, so one sa.dll could contain within itself
enough patches for a dozen soft synths...
-----Original Message-----
From: Michel Jullian [mailto:mj@exbang.com]
Sent: Thursday, September 02, 1999 1:04 PM
To: Ross Bencina; saol-dev list
Subject: Re: "-plugin" option for SFront (was Re: (vst2 ?) plugin output
option for SFront ?)
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