>I realize this Ross, but please let's not start calling each other silly
:-) I
Sorry Michel, there really is no excuse.
>> 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 ?
Perhaps on some platforms. But for windows:
"The default scope of DLL variables is the same as that of variables
declared in the application. Global variables in a DLL source code file are
global to each process using the DLL. Static variables have scope limited to
the block in which they are declared. As a result, each process has its own
instance of the DLL global and static variables by default."
So a dll instance is not a class. My suggestion would be to have sa.c export
a single method: saengine_alloc()
which returns a pointer to an interface (structure of function pointers)
containing a clean up routine (destructor) and whatever other functions are
deemed necessary.
Alternately, SFrontPlugInit() could become SFrontPlugCreate(), and the
SFrontPlugInfo could contain engine state, which would be passed back to
SFrontPlugProcessNextNFrames() to perform processing. Or even better, make
ProcessNextNFrames() a function pointer member of SFrontPlugInfo. It
SFrontPlugInfo is the same for all instances of a plug (which it probably
is) you could have SFrontPlugInfo and SFrontPlugInstance.
greetz
>> 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