Tim Blechmann wrote:
hi all,
just in case people are curious, about the future of nova ...
i started prototyping a new audio engine, code named `supernova', which
is based on the codebase of nova, but with a completely different
design ...
features:
- audio server with a node-based design, similar to scsynth
- asynchronous scripting of the server via osc
- synchronous sample-accurate scripting, based on an embedded
server-side scripting language
- multi-core support for the audio computation
- strong distinction between `audio rate', `control rate' (once per
dsp
block), `events' (synchronous sample-accurate scripting)
the development is done with git:
http://tim.klingt.org/git?p=nova-server.git;a=summary
git://tim.klingt.org/nova-server.git
the multi-core dsp scheduler is already working fine, i already heard a
hello-world sine wave oscillator ...
Cool! This sounds like a great move. I haven't had time to jump in and
help on Nova like I originally hoped to, but I think if the code base
was more easily navigated it would be easier to help out on weekend size
projects. Since you are doing a bit of a redesign, I wanted to at least
get a conversation going about a few thoughts I had after last spending
a few days in the source...
(On a quick side note, I think it is worth studying Apple's CoreAudio
system. I'm a linux guy, but I have to admit that they did a very good
job with that audio library. It's graph based, simple to use and simple
to extend. Checkout the Impromptu live-coding system that puts a little
scheme interpreter on top of CoreAudio for a good example of how easy it
can be to play with.)
I think it should be a major goal to simplify the design of the system.
Using a generic graph API to structure the processing graph would help a
lot here, but I think de-coupling various components of the system and
then limiting the interfaces as much as possible should be the goal.
You know this system way better than anyone, but maybe if I throw out an
outline of what I'm imagining then you can see what you think and
comment on it:
* A base node class that lets you add and remove edges to other nodes,
and probably access a per-node property hash for parameterization and
communication to the "outside world". All the audio and control nodes
would derive from this guy.
* All the stuff that is processing the graph in order to do DSP
scheduling could also be completely decoupled from the user defined
graph API. You hand it a graph and it generates it's own DSP processing
chain for scheduling. The graph would be observable so any updates on
node properties or changes in the graph would be sent to the scheduler.
* For starters I would not include any languages, scripts, osc or
anything. Just create the cleanest, simplest DSP processor possible.
This could and would be used for many things, and forcing Nova to do
this first and to define a clean API to interact with the nodes and with
the graph overall will simplify everything else.
* Supporting Chuck style, sample synchronous scripts will be really
awesome, but I think it's important to not let it bleed into the DSP
chain API. The scripts should either run inside a DSP node, or run in
an external script runner that can call methods on graphs and nodes.
* One of the difficulties I had in Nova was pulling apart the PD type
language from the actual DSP stuff. It would be so nice to just have a
big library of DSP nodes that could be chained together and run. On top
of that any number of languages, scripting APIs, gui manipulators could
be developed to create and manipulate DSP graphs.
You really have some great code in the Nova source, and I bet with some
refactoring and simplification you could get a lot more developers to
join in because it would be easier to figure out and to jump in. For
example, implementing a new DSP node should be as simple as creating one
class in one file. I would start a branch with the goal of using the
least amount of code possible to support fully functional DSP graphs.
You already have this going, so it's probably a matter of pulling it
away from all the other stuff connected to it.
As for the GUI, I think either the Qt GraphicsView or the Clutter
library are the best option. They can both be rendered in OpenGL, and
they both support object level grouping, events, transformations, and
animation. 3D manipulation is rarely useful for anything practical so
GL is really only good for effects, not functionality. Having a fancy
GUI can get people interested in the project though, so maybe getting
some generic shaders setup to do glowing and pulsing and burning would
get people excited...
Be great to hear what you guys think.
Cheers,
Jeff
_______________________________________________
nova-dev mailing list
[email protected]
http://klingt.org/cgi-bin/mailman/listinfo/nova-dev
http://tim.klingt.org/nova
