5 Jul
2006
5 Jul
'06
5:44 p.m.
On Wed, 2006-07-05 at 18:36 +0000, carmen wrote:
On Wed Jul 05, 2006 at 07:06:06PM +0200, Niklas Klügel
wrote:
[snip]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oi,
I am currently writing on a modular synth with great emphasis on
sequencing (but allowing tight interaction between both parts)
in a comparable modular way (pattern creation/algortihmic
composition/chord filters etc),
I wrote some parts of the core of the application but I am not really
keen on coding something that has been done several times before;
that's why I thought about
joining/"forking" a more complete modular synthesizing environment and
adding the core components I need/have. The point is, that I don't
know enough about
the existant modular synthesizers to evaluate how modular their
sourcecode is written so that my modifications are easily applicable
in their source.
Here are some parts/functionalities that I already have (partially)
implemented and would like to add to the core:
- - the main graph of interconnected modules supports heterogene module
types for example it could support FAUST code-pieces represented in
modules as well as ladspa-modules,
the subgraph created by interconnected modules of the same type is the
sent to the type-specific "compiler" creating executable signal paths
- - the executable graph of interconnected modules is analyzed and split
up in parts that can be executed in parallel, locks in the necessary
parts are added and the whole graph can be
executed in several threads
- - modules are mainly connected using a zoomable patch-matrix; the
zoomlevel corresponds to the level of typing (of connections)
this sound really neat. depending on how far along you are with your engine, you may want
to keep it around, or someone else might want to pick it up. here are the active projects
on linux: ingen: previously known as om-synth. only supports
LADSPA & LV2 plugins. C++/Gnome-Canvas (Dave hates QT). theres an OSC API so you could
easily roll your own frontend. currently LADSPA is really lacking in plugins that process
MIDI/OSC, or mangle/record/playback any sort of control data, or even audio. it mainly has
a ton of filters...
source: svn co http://codeson.net/svn
LV2 should hopefully solve these limitations Om/Ingen suffered at the
hands of LADSPA. MIDI processing plugins will be available, and making
samplers and loopers and all that fun stuff LADSPA isn't very good at
should be more feasible. Ingen isn't going to progress much in the next
month or two though, I'm busy in Ardour-land...
The graph is "compiled" in a sense - it's traversed to generate a flat
array that is actually executed in the process callback, so generating
some parallel-executable structure instead of an array is doable without
any major changes. There's no parallelism right now mostly because I
don't think it's possible to do so and have the process callback still
be hard realtime (anyone with an idea otherwise please let me know).
That said, feel free to take a look. "Node" (src/libs/engine/Node.h) is
the important (pure abstract) interface. Anything that implements that
can run in a patch (graph). so faust support or whatever should be easy
(in the case of compiled stuff like Faust the compilation would happen
inside the Node class unbeknownst to everything else). I did LV2
support in a half hour, it's not difficult to add new Node types.
Drop me a line via email or IRC if it looks like something you can work
with.
Cheers,
-DR-