First, a few questions for VST-Plugins: Is the sample block size always the
same for each call to process or processReplacing? Can one reliably discover
the size before beginning processing? Can the size be ensured to be a power
of 2?
Next, for SAOL-DEV, I have succeeded in doing the following:
1. Encapsulating C compilation in the sfront executable: typing "sfront -orc
mymusic.saol -sco mymusic.sasl -aout dsound" causes sound, without further
ado, to emerge from the PC speakers. This is done by shelling out to run a C
compiler and loading a SAOL orchestra plugin it makes. Minor, perhaps, but
it simplifies using sfront and makes it more like using Csound. This takes
one new C++ class, SAOLCompiler, and about a dozen simple patches to the
sfront source code.
2. Putting this SAOLCompiler object into an ActiveX control, Noise, proving
that the whole business can be accomplished from a shared library (DLL), and
enabling one to click on a button called "compile," a few seconds after
which sound emerges from the PC speakers.
Kudos to John Lazzaro - you can click on a "stop" button and restart the
sound! It seems that the sfront code is effectively re-entrant, though not
as yet multiply instantiable.
(Note that there are bugs in the DirectSound driver, so playback is not
good.)
Next: add to Noise a basic GUI for editing SAOL and SASL text, a soundfile
playback control, and a Java interface. This will complete the first phase.
This development is under the GNU General Public License, version 2, because
sfront is. If anyone wants me to email them a zip file of my project, let me
know.
After the first phase of Noise, I will try a VST 2 plugin interface. The
design of the sfront main loop seems to indicate that if the VST 2 host's
sample block size equals sfront's ((srate / krate) * outchannels *
sizeof(float)), handling the VST 2 host's MIDI channel events should be
fairly straightforward.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:35 EST