> I am at a point in my "runtime" control system (which I am calling
> Orbit) where I am adding some control events, and I was thinking that
> something of the code that I need is already a part of what sfront can
> generate.
I could be wrong here, but if I understand correctly, it sounds like
if the SASL table mechanism in the sfront SASL control driver was
actually functional, using that mechanism would be the shortest path
to doing what you want -- which seems to specifying computations for
SAOL to do on the fly, via the control driver mechanism.
Here's a more detailed account of what I mean:
SASL table comands:
http://www.cs.berkeley.edu/~lazzaro/sa/book/control/sasl/index.html#table
Basically lets you update an existing global table, or create
a new one, through a SASL command. All of the wavetable generators
could be used to generate the table -- so you're really specifying
a computation using a SASL table command, the computation of
initializing a table, which is potentially a very compressed
representation (a few parameters in a generator can specify a very
large table, which is generated in the SAOL code as part of decoding).
The sorts of things you need to do in Orbit:
[excerpted from your message]
> The module that I am working on is an envelope generator.
> Some of the other event modules that are planned for the initial release
> are oscillator generators and fractal generators.
Could be done by having Orbit generate tables on the fly, and have
SAOL code play back the tables, either using core opcodes like
oscil/loscil/doscil/koscil, or by writing your own routines using
tableread(), tablewrite(), ect.
If Orbit can live with this sort execution model, there's a lot
you get "for free" -- most notably compatiblity with all SAOL decoders,
instead of an sfront-specific thing. It also lets you prototype
the ideas by writing SASL files, and running sfront on them -- unlike
the SASL control driver interface, sfront itself _does_ currently
support the SASL table command. Then, when the tables become functional
in the SASL control driver, you should be able to plug your system in
and be up in running quickly.
Note that if you go this route:
> I would like
> to know where I could start to investigate what sfront is doing so that
> I may take advantage of your code, and make the control module more
> integrated with how sfront works.
Orbit would be doing something sfront _doesn't_ do -- namely, you'd
be synthesizing wavetable generator commands on the fly. But not
executing those commands -- i.e. computing the values of the table --
that you'd leave to sfront.
Would this work for you?
Also ...
> Also, on another note, is it possible to have the "event" loop in sa.c
> write the SASL code to a file, prior to dispatching/processing the
> event.
I agree, this sort of logging would be very useful for debugging ...
and running in a sort of "batch mode" to archive a performance in
its frozen state. I'm note sure that when this logging it turned
on, you'd be able to get glitch-free audio streaming ...
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:51 EST