[linux-audio-dev] modular sequencing environment/synth // any projects to dig in?

Dave Robillard drobilla at connect.carleton.ca
Wed Jul 5 19:44:49 UTC 2006


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:
> > -----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:
[snip]
> 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-





More information about the Linux-audio-dev mailing list