Hope you don't mind my copying this to the list, some other people may find
this useful.
Your suggestions are a helpful starting point. My implementation is
beginning as a C++ "wrapper" for the C stuff anyway. I'll get that working
first, then if no commercial implementation or true runtime compiler is
working by then, I may try to change the wrapper into a class with instance
members as you suggest. You understand, I'm more interested in playing the
thing than in writing it.
Here's where the glory of a standard shines: I can junk my whole project
without a second thought if SAOL shows up at 24/96 in my next sound card,
and all my existing orcs keep right on singing.
-----Original Message-----
From: Ross Bencina [mailto:rossb@audiomulch.com]
Sent: Friday, September 03, 1999 1:20 AM
To: Michael Gogins; Saol-dev; mj@exbang.com
Subject: Re: "-plugin" option for SFront (was Re: (vst2 ?) plugin output
option for SFront ?)
Michael Gogins wrote:
>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.
I would agree that 1 is better than none, but unless you have an MP box,
running multiple instances in separate threads/processes is probably going
to cost as much performance as adding a level of indirection (see below).
Also I think a commercial version would largely be written in asm.
Just looked at the code... there would be a fair amount (but not an
impossible amount) of work converting sfront to access globals via an
explicit "this" ptr, and even if you did (either explicitly using C or
implicitly using C++) people running a single instance might take a
performance hit from pointer indirection if you made global mods...
There are good reasons not to export a C++ interface from the dll: On most
if not all platforms there is no standard name mangling / calling
conventions for C++ objects (method pointers). And generating C++ from
sfront seriously limits it's applicability...
That said, it seems like the easiest thing to go would be to have sfront
_optiononally_ spit out a C++ class that wraps the whole shebang (everything
in sa.c). All of the functions would effectively be declared inline so you
don't have to modify sfront to generate prototypes or separate
class/namespace definitions. Here's how to do it:
//1. put this at the top of sa.c (after the externs for system functions):
class SaPlugin{
public:
//2. put this at the end of sa.c:
};
//3. move in place initialisation for the globals such as:
short *asys_obuf = NULL; /* pointer to output sample buffer */
long asys_osize = 0; /* size of output buffer */
long obusidx = 0;
//into system_init:
short *asys_obuf; /* pointer to output sample buffer */
long asys_osize; /* size of output buffer */
long obusidx;
...
void system_init(void){
asys_obuf = NULL;
asys_osize = 0;
obusidx = 0;
};
This would initialise these variable properly whether they were C globals or
C++ instance variables, and would be backward compatible with the non class
based c generated code.
// 4. Replace main(argv,argc) with the SFrontPlug*() functions
Note that I'm not proposing this as an "object oriented" solution, trying to
set up proper c++ constructors and destructors, private or protected
variables etc.. Just wrap the whole thing in a class (a C++ struct might
even capture the intent better), then everything that what was once a global
variable becomes an instance variable and you can stamp out multiple
instances without impacting most of the code (so generating the non class
version will be just as easy).
What do you think?
Ross.
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:35 EDT