I am forwarding this as it may be of interest to the rest of the list.
-- 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 .........................................................................
attached mail follows:
> I quite understand. What kind of general performance increase do you think can > be reasonably expected in the end BTW ?
10X to 100X faster than what you get now with sfront. Basically, here's where the biggest wins will come:
-- analyzing all the a-rate and k-rate statements for subexpressions that are slower than the rate of the statement, and moving them to different rates.
-- analyzing all the opcode calls, to see which parameters are really constants. Then, custom-generate C code that special-cases the parameters.
-- analyzing all the constants to see which ones are really integer and not float, especially indexes for arrays.
-- block processing may in fact also be a good idea for compiled code, but its a trickier question than for interpeters -- the extra memory you use may blow up the cache.
-- a lot of the core opcodes are really slow right now, and can be optimized.
-- finally, doing processor-specific things, like using the SIMD units on PIII's, ect.
That said, it may very well be that interpeters can get a lot of these advantages too -- its hard to predict in the end just how much of a gain we'll get over a highly-optimized interpeter like Giorgio is working on.
> The whole point of this event passing stuff being optimizing realtime > performance, it has to be MIDI hasn't it ?
No, look at the "gliss" example that I ship with sfront. It's a piano being glissandoed up and down the keyboard, using the "real-time" interface to sfront. The upsweep uses the MIDI driver, while the downsweep uses the SASL driver. Look at the sa.c that gliss generates, and you'll see the MIDI and SASL control ports -- also read:
http://www.cs.berkeley.edu/~lazzaro/sa/sfman/devel/driver/index.html#control
(in particular the "draft copy" link) for more details. The big advantage of using SASL is you get to use labelled control lines to change parameters inside of a specific instance of an instrument (there are other advantages too ...). The disadvantage is, you'll need to generate your own driver (like sfront/src/lib/csys/gliss.c for the gliss example) that knows the names of the SAOL instrs and its parameters. So, in the most general case, you'd need to have a program that generated the C program control driver to match the SAOL program, then use sfront to bundle them all together into an sa.c file (this would require one change to sfront as it now exists, namely being able to specify drivers on the command line).
You probably can get away with a stereotypical SAOL file, that always uses the same few names for key instrs, and have a standardized driver that talks to that template, but its unclear how many of the advantages you'd lose over the custom driver. On the bright side, your custom driver could easily map NoteOff velocity into a labelled control variable :-).
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:36 EDT