Re: Commandline Options in output sa.c

From: John Lazzaro (lazzaro@CS.Berkeley.EDU)
Date: Sun Jan 30 2000 - 13:31:34 EST


> It sounds like your idea will be a bit more universal than mine. Have
> you (or anyone else) started a list of what commandline options will be
> available in the resulting sa.c program?

No, basically, the command-line is a shared resource, so if I'm
going to support using it at all, I have to figure out a way for
all the drivers to share it. What I'm thinking of right now is
something like:

If you're a control driver with name "foo", meaning that to be
invoked in sfront the user does:

sfront -cin foo

Then you have the right to all ./sa options of the form:

 -cin_foo_xxxxx [par1] [par2] ...

where all of the par's are strings that can't start with "-"
and can't have spaces in them. And then using some interface
yet to be determined, csys_setup() sets to see all of the
options destined for it, which it can use or ignore as it
likes.

This has the advantages of:

 -- can also be used for -ain, -aout, and any other future kind
of drivers, without polluting the "name space" ...

 -- lets the main sfront program add any command-line switches it
wants, without worrying that a control driver grabbed it ...

> Also, I am still putting the finishing touches on my control driver.
> Currently, it dynamically creates a SASL score.

Great -- this is the sort of thing the control driver is supposed to
be able to do, although in some ways the control driver interface
isn't quite ready yet to do some functions programs like yours might
need to [see below] ...

> Is there anyone else that is working on something like this?

I've heard from people trying to implement a CLI with the control
driver interface, so that you could start the ./sa program and
get a shell prompt, which you could then type SASL commands into
and real real-time audio out of. As it currently stands, the control
driver interface isn't quite ready for this -- the biggest problem
is that the control driver needs to know all of the variable names
of the SAOL program, and the internal ./sa token numbers the names
map to. Right now, the control driver would need to search the sa.c
file it lives in to figure this out! So some functionality is on the
way to support CLI type apps in the control driver too, which should
be almost enough to support a true SA_access_unit streaming application
(the major caveat would be the "table" command ...),

                                                                --jl



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:51 EST