6 Mar
2003
6 Mar
'03
3:35 p.m.
I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers, so it can be used both as
synth and as effect processor. Modular tasks separation allow to extend
possibilities in simple way. Modules can be connected between each other via
channels.
Features:
Audio Input/Output:
- OSS
- JACK
MIDI Input/Output:
- OSS
- ALSA
Plugin's compatability:
- native modules
- LADSPA
This is first pre-beta release. It is a big subject for changes and improvements,
so please send your wishes and bugreports.
Roman
-------------------------------------------
-------- mailto: wormpost(a)mail.ru ---------
-------------------------------------------
6 Mar
6 Mar
3:45 p.m.
Hi Roman:
And the URL is ... ?
Best regards,
== Dave Phillips
The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm
The Linux Soundapps Site at http://linux-sound.org
Roman Kaljakin wrote:
I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers, so it can be used both as
synth and as effect processor. Modular tasks separation allow to extend
possibilities in simple way. Modules can be connected between each other via
channels.
Features:
Audio Input/Output:
- OSS
- JACK
MIDI Input/Output:
- OSS
- ALSA
Plugin's compatability:
- native modules
- LADSPA
This is first pre-beta release. It is a big subject for changes and improvements,
so please send your wishes and bugreports.
Roman
-------------------------------------------
-------- mailto: wormpost(a)mail.ru ---------
-------------------------------------------
--
3:46 p.m.
Hi Roman,
An url would be nice?
-- Matthijs
http://devdsp.net - news and resources for computer musicians
On Thu, Mar 06, 2003 at 10:26:43PM +0300, Roman Kaljakin wrote:
I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers, so it can be used both as
synth and as effect processor. Modular tasks separation allow to extend
possibilities in simple way. Modules can be connected between each other via
channels.
Features:
Audio Input/Output:
- OSS
- JACK
MIDI Input/Output:
- OSS
- ALSA
Plugin's compatability:
- native modules
- LADSPA
This is first pre-beta release. It is a big subject for changes and improvements,
so please send your wishes and bugreports.
Roman
-------------------------------------------
-------- mailto: wormpost(a)mail.ru ---------
-------------------------------------------
18 Mar
18 Mar
8:55 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
Roman Kaljakin wrote:
I am pleased to announce Octavian - a realtime software
synthesizer for GNU\Linux
operating system.
Octavians's design is like analog modular synthesizers,(...)
Well, here we have another modular synth framework. :-)
Hi Roman, i realy like parts of your ui design. just looked at the
screenshots so far, but i think i will try octavian soon.
I would have reacted earlier to your announce, but i was somewhat busy
and didn't follow lad traffic very regulary.
Sseems we have a little problem.
Ok, maybe problem is not exactly the right term, let's put it this way:
Right now, there is beast, there is gAlan, there is ams, and of course
there is also pd, jmax, etc. and lately Octavian, and, rats, there maybe
a zillion of other apps out there that i do not yet know of (authors of
such apps, please append your project to my list:-) )
While each of this projects may have unique approaches to certain
problems, or use different metaphors for similar things, i guess it is a
valid assumption, that they all have _very_ similar goals in terms of
functionality. At least that was my impression after talking with Stefan
(beast) and Torben (gAlan).
The Big Question(tm):
How can we avoid redundant work?
My (somewhat utopious) suggestion:
maybe we should think in components that use/modify a common
datastructure/model.
This has almost (but not completly) nothing to do with merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
11:11 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003 13:40:26 +0100
Lukas Degener <AFBLukas(a)gmx.de> wrote:
The Big Question(tm):
How can we avoid redundant work?
Well, at least gAlan has the "sheets" concept, providing the equivalent of
programming subroutines, separating it from the pack.
---scott
11:32 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
Hallo,
Scott Thomason hat gesagt: // Scott Thomason wrote:
Well, at least gAlan has the "sheets"
concept, providing the
equivalent of programming subroutines, separating it from the pack.
Not from Pd/jMax ;)
But galan is cool.
ciao
--
Frank Barknecht _ ______footils.org__
12:20 p.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
--- Lukas Degener <AFBLukas(a)gmx.de> wrote: > Roman Kaljakin wrote:
Sseems we have a little problem.
Ok, maybe problem is not exactly the right term, let's put it this way:
Right now, there is beast, there is gAlan, there is ams, and of course
there is also pd, jmax, etc. and lately Octavian, and, rats, there maybe
a zillion of other apps out there that i do not yet know of (authors of
such apps, please append your project to my list:-) )
There's SpiralSynthModular (SSM), which I use most frequently (I've not tried
Beast/BSE, nor Octavian).
While each of this projects may have unique approaches
to certain
problems, or use different metaphors for similar things, i guess it is a
valid assumption, that they all have _very_ similar goals in terms of
functionality. At least that was my impression after talking with Stefan
(beast) and Torben (gAlan).
The Big Question(tm):
How can we avoid redundant work?
My (somewhat utopious) suggestion:
maybe we should think in components that use/modify a common
datastructure/model.
Here's my take on this...
----
1. A unified Plugin API
All of the above softsynths have their own plugin format, for various reasons.
LADSPA (http://www.ladspa.org) has helped with this, making much excellent code
available for all these softsynths. However, the (intentional) simplicity of
LADSPA has prevented the various formats being replaced entirely.
The Generalized Music Plugin API discussions
(http://www.freelists.org/archives/gmpi) are working towards a more
encompassing API, but it looks to be a long way off.
----
2. A single codebase for building, representing and running graphs (AKA
networks, patches) of plugins.
Almost all of these softsynths are pretty much exactly the same 'under the
hood' - just a connected bunch of plugins executed in a particular order. The
only real obstacle to unifying this is the plugin API issue above.
I'd certainly like to see a unified engine for LADSPA - I've been on-and-off
planning one, but SSM is so close to what I'd like that I'm not motivated
enough :/
My thoughts on engine-things so far (this is all a bit of a brain dump,
apologies:)
No GUI - all functionality exposed through various forms of
Inter-Process Communication (IPC):
Graph State Query and Manipulation (command set for adding
plugins, making connections etc).
Audio I/O - JACK (http://jackit.sf.net) would be the choice here
Control - something like the LADSPA Control
Protocol (http://www.op.net/~pbd/lcp.html)
would be good.
Built-in support for subpatches:
The graph itself could be kept 'flat', with some sort of
abstract representation of subpatches on top of it. Including
ability to 'register' subpatches as plugins.
The thought of being able to set up, for example, a mixer
channel out of multiple LADSPA plugins, register it as a plugin,
and then add sixteen of them to a graph to make a mixer has a
certain appeal :)
----
3. Separation of graph/engine and any UI.
Any UI would communicate with the engine using IPC - this would allow
multiple views of the network - e.g. a wiring diagram for setting up,
a set of knobs'n'sliders (real or virtual) arranged nicely for
performance, commandline scripting, or any combination...
-
Mike
This has almost (but not completly) nothing to do with
merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
1:18 p.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
Hi,
Have any of these soft synths that use boxes and user-based connectivity
(SSM, Octavian, gAlan, Beast, etc.) addressed the issues of polyphony yet?
Mark
-----Original Message-----
From: linux-audio-user-admin(a)music.columbia.edu
[mailto:linux-audio-user-admin@music.columbia.edu]On Behalf Of Mike
Rawes
Sent: Tuesday, March 18, 2003 8:11 AM
To: linux-audio-user(a)music.columbia.edu
Cc: alsamodular-devel(a)lists.sourceforge.net
Subject: Re: [linux-audio-user] Modular synths of the world, unite and
take over :-)
--- Lukas Degener <AFBLukas(a)gmx.de> wrote: > Roman Kaljakin wrote:
Sseems we have a little problem.
Ok, maybe problem is not exactly the right term, let's put it this way:
Right now, there is beast, there is gAlan, there is ams, and of course
there is also pd, jmax, etc. and lately Octavian, and, rats,
there maybe
a zillion of other apps out there that i do not
yet know of (authors of
such apps, please append your project to my list:-) )
There's SpiralSynthModular (SSM), which I use most frequently
(I've not tried
Beast/BSE, nor Octavian).
While each of this projects may have unique
approaches to certain
problems, or use different metaphors for similar things, i
guess it is a
valid assumption, that they all have _very_
similar goals in terms of
functionality. At least that was my impression after talking
with Stefan
(beast) and Torben (gAlan).
The Big Question(tm):
How can we avoid redundant work?
My (somewhat utopious) suggestion:
maybe we should think in components that use/modify a common
datastructure/model.
Here's my take on this...
----
1. A unified Plugin API
All of the above softsynths have their own plugin format, for
various reasons.
LADSPA (http://www.ladspa.org) has helped with this, making much
excellent code
available for all these softsynths. However, the (intentional)
simplicity of
LADSPA has prevented the various formats being replaced entirely.
The Generalized Music Plugin API discussions
(http://www.freelists.org/archives/gmpi) are working towards a more
encompassing API, but it looks to be a long way off.
----
2. A single codebase for building, representing and running graphs (AKA
networks, patches) of plugins.
Almost all of these softsynths are pretty much exactly the same 'under the
hood' - just a connected bunch of plugins executed in a
particular order. The
only real obstacle to unifying this is the plugin API issue above.
I'd certainly like to see a unified engine for LADSPA - I've been
on-and-off
planning one, but SSM is so close to what I'd like that I'm not motivated
enough :/
My thoughts on engine-things so far (this is all a bit of a brain dump,
apologies:)
No GUI - all functionality exposed through various forms of
Inter-Process Communication (IPC):
Graph State Query and Manipulation (command set for adding
plugins, making connections etc).
Audio I/O - JACK (http://jackit.sf.net) would be the choice here
Control - something like the LADSPA Control
Protocol (http://www.op.net/~pbd/lcp.html)
would be good.
Built-in support for subpatches:
The graph itself could be kept 'flat', with some sort of
abstract representation of subpatches on top of it. Including
ability to 'register' subpatches as plugins.
The thought of being able to set up, for example, a mixer
channel out of multiple LADSPA plugins, register it as a plugin,
and then add sixteen of them to a graph to make a mixer has a
certain appeal :)
----
3. Separation of graph/engine and any UI.
Any UI would communicate with the engine using IPC - this would allow
multiple views of the network - e.g. a wiring diagram for setting up,
a set of knobs'n'sliders (real or virtual) arranged nicely for
performance, commandline scripting, or any combination...
-
Mike
This has almost (but not completly) nothing to do
with merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
2:20 p.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003, Mark Knecht wrote:
Hi,
Have any of these soft synths that use boxes and user-based connectivity
(SSM, Octavian, gAlan, Beast, etc.) addressed the issues of polyphony yet?
AlsaModularSynth: ams --poly n, where n is an integer.
In the voice allocation algorithm it checks for the envelopes invloved
in the patch to decide whether a voice is "free" again and can be reallocated.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
2:53 p.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
Thanks Matthias - I have not looked much at ams. Now I have a reason.
Cheers,
Mark
-----Original Message-----
From: linux-audio-user-admin(a)music.columbia.edu
[mailto:linux-audio-user-admin@music.columbia.edu]On Behalf Of Dr.
Matthias Nagorni
Sent: Tuesday, March 18, 2003 10:12 AM
To: linux-audio-user(a)music.columbia.edu
Subject: RE: [linux-audio-user] Modular synths of the world, unite and
take over :-)
On Tue, 18 Mar 2003, Mark Knecht wrote:
Hi,
Have any of these soft synths that use boxes and user-based
connectivity
(SSM, Octavian, gAlan, Beast, etc.) addressed the
issues of
polyphony yet?
AlsaModularSynth: ams --poly n, where n is an integer.
In the voice allocation algorithm it checks for the envelopes invloved
in the patch to decide whether a voice is "free" again and can be
reallocated.
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
19 Mar
19 Mar
2:42 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Tue, 18 Mar 2003 16:11:20 +0000 (GMT)
Mike Rawes <mike_rawes(a)yahoo.co.uk> wrote:
1. A unified Plugin API
All of the above softsynths have their own plugin format, for various reasons.
LADSPA (http://www.ladspa.org) has helped with this, making much excellent code
available for all these softsynths. However, the (intentional) simplicity of
LADSPA has prevented the various formats being replaced entirely.
Most of synth (i.e. SpiralSynthModular, AlsaModularSynth, Octavian) have LADSPA
support already. LADSPA is good for filters, but not for oscillators and other
voltage controlled (in modular synths) modules.
2. A single codebase for building, representing and
running graphs (AKA
networks, patches) of plugins.
It might be looks like as a toolkit... maybe.
Almost all of these softsynths are pretty much exactly the same 'under the
hood' - just a connected bunch of plugins executed in a particular order. The
only real obstacle to unifying this is the plugin API issue above.
I'd certainly like to see a unified engine for LADSPA - I've been on-and-off
planning one, but SSM is so close to what I'd like that I'm not motivated
enough :/
My thoughts on engine-things so far (this is all a bit of a brain dump,
apologies:)
No GUI - all functionality exposed through various forms of
Inter-Process Communication (IPC):
Graph State Query and Manipulation (command set for adding
plugins, making connections etc).
Audio I/O - JACK (http://jackit.sf.net) would be the choice here
Control - something like the LADSPA Control
Protocol (http://www.op.net/~pbd/lcp.html)
would be good.
Built-in support for subpatches:
The graph itself could be kept 'flat', with some sort of
abstract representation of subpatches on top of it. Including
ability to 'register' subpatches as plugins.
The thought of being able to set up, for example, a mixer
channel out of multiple LADSPA plugins, register it as a plugin,
and then add sixteen of them to a graph to make a mixer has a
certain appeal :)
----
3. Separation of graph/engine and any UI.
Any UI would communicate with the engine using IPC - this would allow
multiple views of the network - e.g. a wiring diagram for setting up,
a set of knobs'n'sliders (real or virtual) arranged nicely for
performance, commandline scripting, or any combination...
-
Mike
This has almost (but not completly) nothing to do
with merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
5:22 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Wed, 19 Mar 2003 09:33:05 +0300
Roman Kaljakin <wormpost(a)mail.ru> wrote:
On Tue, 18 Mar 2003 16:11:20 +0000 (GMT)
Mike Rawes <mike_rawes(a)yahoo.co.uk> wrote:
I know - that's why I said it has helped :)
1. A unified Plugin API
All of the above softsynths have their own plugin format, for
various reasons. LADSPA (http://www.ladspa.org) has helped with
this, making much excellent code available for all these softsynths.
However, the (intentional) simplicity of LADSPA has prevented the
various formats being replaced entirely.
Most of synth (i.e. SpiralSynthModular, AlsaModularSynth, Octavian)
have LADSPA support already. LADSPA is good for filters, but not for oscillators
and other
voltage controlled (in modular synths) modules.
There's no reason why you can't do oscillators in LADSPA:
http://blop.sf.net
One thing you can't do is sampler-type stuff as there's no file I/O -
although there is a stomp-box type sampler out there:
http://www.dexterssandbox.com/sooperlooper
-
Mike
5:50 a.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 09:18:15 +0000, Mike Rawes wrote:
Agreed. LADSPA is fine for CV controlled stuff, filters are just as
CV-ey as oscs.
- Steve
LADSPA is good
for filters, but not for oscillators and other
voltage controlled (in modular synths) modules.
There's no reason why you can't do oscillators in LADSPA:
http://blop.sf.net 
21 Mar
21 Mar
6:41 p.m.
New subject: [linux-audio-user] Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 09:41:49AM +0000, Steve Harris wrote:
On Wed, Mar 19, 2003 at 09:18:15 +0000, Mike Rawes
wrote:
Agreed. LADSPA is fine for CV controlled stuff, filters are just as
CV-ey as oscs.
I think the only drawback of ladspa are the Control outs which dont have
timestamps. (And the lack of User Interfaces provided by the plugins,
but this can be fixed by subsheets containig the plugins.)
LADSPA is
good for filters, but not for oscillators and other
voltage controlled (in modular synths) modules.
There's no reason why you can't do oscillators in LADSPA:
http://blop.sf.net
- Steve
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
7920
days inactive
7935
days old
linux-audio-user@lists.linuxaudio.org
14 comments
12 participants
participants (12)
-
Dave Phillips -
DevDSP Info -
Dr. Matthias Nagorni -
Frank Barknecht -
Lukas Degener -
Mark Knecht -
mik -
Mike Rawes -
Roman Kaljakin -
Scott Thomason -
Steve Harris -
torbenh＠gmx.de