(another victim of the reply button : forwarding Michael's msg to the list)
attached mail follows:
What you say below is correct about Noise.dll loading sa.dll.
What happened to the Java interface I posted for Noise.dll? When you run
javah on the Java interface, a C interface is automatically generated. This
in turn implies a simpler C interface that doesn't mess with Java proxies. I
left out the callbacks for VST dlls; these too would go into the "simpler C
interface" but would be essentially as Michel describes them.
In other words: javac compiles Silence.Noise.Noise.java to
Silence.Noise.Noise.class. javah compiles Silence.Noise.Noise.class to
Silence_Silence_Noise.h. I, the programmer, copy Silence_Silence_Noise.h to
Silence_Silence_Noise.c and implement the stubs using hooks I make into
sfront. I also add Michel's VST 2 hooks. I then compile
Silence_Silence_Noise.c together with the sfront sources to produce
Noise.dll. Silence.Noise.Noise.class then loads Noise.dll to implement its
native methods, such as "compile", with which it compiles saol, sasl, mid,
and mp4 files into sa.c, then runs the C compiler to compile and link sa.c
to whatever.dll. Noise.dll then loads whatever.dll to implement some of its
abstract functions, which in turn are implementations of other native
functions in Silence.Noise.Noise.class, such as "play". Other executables
can load whatever.dll and call its methods as well (such as VST hosts).
Whew! Sounds complicated, doesn't it? But in practice, it's quite simple.
Much simpler than writing sfront itself, thank God! A Java program using an
instance of Noise simply calls myNoise.compile("music.mp4"), then
myNoise.play(). Later on, a VST host could also use the VST 2 plugin
music.dll.
Here's the Java interface documentation, the Java file itself, and the
javah-generated header file, for the curious.
-----Original Message-----
From: Michel Jullian [mailto:mj@exbang.com]
Sent: Thursday, September 02, 1999 4:34 AM
To: Michael Gogins
Subject: Re: "-plugin" option for SFront (was Re: (vst2 ?) plugin output
option for SFront ?)
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.
-- 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