Most Excellent!
I've installed the new code set, and after copying the changes I had
already done, sfront has compiled, and created a correct sa.c for the
'min' example, creating a correct soundfile.
I will document the WIN32 changes in due course (they are very minor) -
and can set up a page on my website with VC++v5 project files.
However, I have one proposal regarding the LIBDIR mechanism. I don't
like the way it is hard-coded into the sfront executable. As I am
especially interested in the file format code and real-time audio
things, the library files are on my list of files to fiddle with. I
would much prefer to read LIBDIR from an environment variable (such as
"SFRONT_LIBDIR"), or even have an sfront commandline flag as well as an
override. Without this, it is impractical to post an exectutable for
download as users would have to reproduce my file path.
I propose a simple wrapper function:
const char *get_sfront_libpath(char *errmsg /* = NULL*/);
which will typically call getenv, and/or check the commandline. In a
Windows GUI application, it could use the registry; Macintosh users
would doubtless have a different mechanism again. The argument errmsg
is, obviously, for a useful error message return if the path can't be
found (where the function return value would also be NULL) - if the
caller is confident there will be no error, or doesn't care, the arg can
be NULL, otherwise it should be a pointer to an array of, say, 128 chars
(there could be a symbol for that, such as LIBDIR_ERRMSG_BUFSIZE).
This function can itself hard-code a path if programmers really want to
do that.
I will go the environment var route myself, for my own work - a
commandline flag should really be implemented by the 'core team', as it
impacts on the public interface that much more obviously. Given the
moveable feast that is Linux audio, I think it will be useful there too.
Great work on sfront, folks - this thing will run and run!
Richard Dobson
John Lazzaro wrote:
>
> Hi Richard,
>
> Actually, I'm doing the final testing right now for a new
> sfront version that (I think) catches all the %1$ problems --
> expect a posting to saol-devs/saol-users list later tonight when
> I do the release. This will also have linux soundcard support under
> OSS (audio in/out and MIDI in) as well as be more compatible with
> saolc with regards to rate-semantics of core opcodes in certain
> conditions that are vaguely described in the FDIS.
>
> --jl
>
> P.S. My language lawyer friends are a bit murky on the ANSI-ness
> of the %1$ -- basically, its a part of the ANSI spec that came
> out too late for the K&R ANSI edition (which describes the "draft"
> standard), but perhaps gcc (as well as Sun's cc) supports functionality
> over and above what the ANSI spec requires ...
-- Test your DAW with my Soundcard Attrition Page! http://wkweb5.cableinet.co.uk/rwd (LU: 6th July 1999) CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 14th June 1999)
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:26 EDT