18 Mar
2003
18 Mar
'03
1:27 p.m.
How about having all apps implement Open Sound Control (some of them already have, such as
pd, csound etc.)?
Then you could control them all from one source (i.e. RTMix). Then, suddenly there would
be no redundancy ;-)...
Ico
From: Lukas Degener <AFBLukas(a)gmx.de>
Date: 2003/03/18 Tue AM 08:54:55 EST
To: linux-audio-dev(a)music.columbia.edu
Subject: [linux-audio-dev] 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
18 Mar
18 Mar
2:34 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
How about having all apps implement Open Sound
Control (some of them already have, such as pd,
csound etc.)?
Then you could control them all from one source
(i.e. RTMix). Then, suddenly there would be no
redundancy ;-)...
I'm new to LADSPA, but isn't that what LADSPA control
protocol does? I think it would be better if there was
something like that, but the plugin can work with or
without the gui.
Say I wanted to make a snazzy analogue modelled
filter. Someone else wanted to integrate it into their
modular. They could do that and make it just another
module and keep the look of their app consistent. When
their app is running the gui-less version of the
plugin, all their app needs to do is have a mechanism
for controlling the important paremeters, in this
case, cutoff, resonance and so forth.
one question i have is how does the licensing work?
provided the program is linked to the LADSPA lib, the
plugin and the app don't need to match licensing, eh?
i could have a commercial host w/ gpl client or vice
versa? mix bsd and gpl?
__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
3:50 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
I'm new to LADSPA, but isn't that what LADSPA control
protocol does?
Dunno. have to do some reading. What is Open Sound Control?
Say I wanted to make a snazzy analogue modelled
filter. Someone else wanted to integrate it into their
modular. They could do that and make it just another
module and keep the look of their app consistent. When
their app is running the gui-less version of the
plugin, all their app needs to do is have a mechanism
for controlling the important paremeters, in this
case, cutoff, resonance and so forth.
As pointed out before, i think it's not so much a problem of reusing
modules.
This should work already, just have ladspa for them.
The point is, that there are some things that e.g. are possible in
gAlan, which aren't possible in
ams and vice versa. Those things are not that much related to a certain
module, but rather to the way this modules are used.
It would therefor be great (but difficult) if we could come up with an
abstraction of the whole problem, or adaequat parts of it.
An ideal scenario (in my eays) would be:
- you have a patch (or want to creat one)
- you choose the components that you think are best for this job,
- you let them all work on the same patch instance at the same time.
A (maybe) possible way to do this:
- we try to modell as much functionality of our apps as possible, by
using apis already available (ladspa and friends)
- we find a common abstraction for all that is left after that. (*)
e.g. for ams that would meen: Forget about parameters, we use control
ports like ladspa, we have the midi control center replaced
by some "intelligent" mcv modules, module uis would could also become
special modules, that only have control io and are bind to some widget(s).
I don't know enough about the design of the other projects to make any
statements here. But something similar should be possible,
And finaly, we would have to think about what a "patch" realy is, and
define an api interface for editing/displaying it (*)
(*) this are the tricky parts, i think ;-)
one question i have is how does the licensing work?
provided the program is linked to the LADSPA lib, the
plugin and the app don't need to match licensing, eh?
i could have a commercial host w/ gpl client or vice
versa? mix bsd and gpl?
Hmm... maybe lgpl for modules?
Well its not realy an interesting question as long there is nothing to
put a licens on.
I'm sure we would find a solution for that.
Regards,
Lukas
5:28 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 08:35:30 +0100, Lukas Degener wrote:
Its a synthesis focused message passing protocol. Generally run over UDP.
Pretty popular in the academic world. It could/should be a canditate for
the low level DSP / UI interaction, if you wanted to seperate the code.
- Steve
I'm new to LADSPA, but isn't that what LADSPA control
protocol does?
Dunno. have to do some reading. What is Open Sound Control? 
9:12 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
Steve Harris writes:
On Tue, Mar 18, 2003 at 08:35:30 +0100, Lukas Degener
wrote:
http://cnmat.cnmat.berkeley.edu/OSC/
gives its spec.
there is a (free) c++ library with network classes for both udp and tcp
transport ("fraunhofer" branch). still under development, but working
in a (non-free) VR system at fraunhofer IMK:
http://wiretap.stetson.edu/cgi-bin/viewcvs.cgi/libOSC%2B%2B/?only_with_tag=…
best regards,
martin
--
martin pabel-voelkel (martin(a)rumori.de)
/* home is where your home directory is */
Dunno. have to do some reading. What is Open
Sound Control?
Its a synthesis focused message passing protocol. Generally run over UDP.
Pretty popular in the academic world. It could/should be a canditate for
19 Mar
19 Mar
12:54 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
I'm new to
LADSPA, but isn't that what LADSPA control
protocol does?
Dunno. have to do some reading. What is Open Sound Control?
5:22 a.m.
New subject: [linux-audio-dev] OpenSoundControl. WAS: Modular synths of the world, unite and take over :-)
Ivica Bukvic writes:
uses it), but it does so in a much more efficient
fashion since it has
timestamps and one can thus send events that are to happen in future
prematurely in order to assure their timely execution.
Also, events can be bundled together so that they are executed at the
same time.
Typical example of a OSC-type message would be:
Timestamp: /midi/<channel>/noteon <pitch> <velocity>
AFAIK a timestamp can only be prepended an OSC-bundle (which contains
OSC messages or recursively bundles again), but not a single message?
so the only way to set a certain execution time is by sending a
bundle:
#bundle <timestamp> <sizecount> /midi/<channel>/ and so on...
there is another way if we use the "timetag" data type, which is also
defined:
/midi/<channel>/noteon <pitch> <velocity> <timetag>
but then the timetag information is defined by the semantics of the
OSC address (AKA channel), not by the protocol.
implementation (OSC-kit is available in a form of a
lib, so the
implementation is a breeze). Hope this helps!
i could not found any hint about the license of matt wright's library,
he always says "OpenSource", which is not necessarily "free". will
ask him about this.
martin
--
martin pabel-voelkel (martin(a)rumori.de)
/* home is where your home directory is */
5:42 a.m.
New subject: [linux-audio-dev] OpenSoundControl. WAS: Modular synths of the world, unite and take over :-)
Martin Voelkel writes:
i could not found any hint about the license of matt
wright's library,
he always says "OpenSource", which is not necessarily "free". will
ask him about this.
o.k. each file says:
>
Permission to use, copy, modify, distribute,
and distribute modified versions
of this software and its documentation without fee and without a signed
licensing agreement, is hereby granted, provided that the above copyright
notice, this paragraph and the following two paragraphs appear in all copies,
modifications, and distributions.
<<
could this be treated as "free"? don't know enough about those
licensing issues...
martin
--
martin pabel-voelkel (martin(a)rumori.de)
/* home is where your home directory is */
6:30 a.m.
New subject: [linux-audio-dev] OpenSoundControl. WAS: Modular synths of the world, unite and take over :-)
On Wed, Mar 19, 2003 at 10:33:40 +0100, Martin Voelkel wrote:
Martin Voelkel writes:
I think that the "without fee" part causes problems with the GPL, but
IANAL.
- Steve
i could not found any hint about the license of
matt wright's library,
he always says "OpenSource", which is not necessarily "free". will
ask him about this.
o.k. each file says:
>
Permission to use, copy, modify,
distribute, and distribute modified versions
of this software and its documentation without fee and without a signed
licensing agreement, is hereby granted, provided that the above copyright
notice, this paragraph and the following two paragraphs appear in all copies,
modifications, and distributions.
<<
could this be treated as "free"? don't know enough about those
licensing issues...
20 Mar
20 Mar
2:20 a.m.
New subject: [linux-audio-dev] OpenSoundControl. WAS: Modular synths of the world, unite and take over :-)
AFAIK a timestamp can only be prepended an OSC-bundle
(which contains
OSC messages or recursively bundles again), but not a single message?
so the only way to set a certain execution time is by sending a
bundle:
#bundle <timestamp> <sizecount> /midi/<channel>/ and so on...
Yes, you are right. However, nothing wrong with sending one-message
bundle :-).
i could not found any hint about the license of matt
wright's library,
he always says "OpenSource", which is not necessarily "free". will
ask him about this.
See the source code of OSC-kit. It's included in there. Basically it's
free for use as long as it is not used for commercial purposes (the
license must be included in the source code). Otherwise, it must be
licensed.
Hope this helps!
Ico
19 Mar
19 Mar
5:29 a.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 11:41:38 -0500, Ivica Bukvic wrote:
As you can see OSC is very powerful and already
present in a number of
apps. While LADSPA protocol might be also very useful, it implies that
the module or synth is presented in a LADSPA plugin form, while OSC can
also manipulate self-standing apps (and there is no reason why LADSPA
plugin could not benefit from it as well).
In this case if would be the host that relayed the OSC to the plugin, for
various reasons.
- Steve
18 Mar
18 Mar
5:25 p.m.
New subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
On Tue, Mar 18, 2003 at 10:25:47 -0800, Thomas Webb wrote:
I'm new to LADSPA, but isn't that what LADSPA
control
protocol does? I think it would be better if there was
something like that, but the plugin can work with or
without the gui.
LCP is mostly hypothetical. There are some sample UIs and a sample host
implmentation bu thats about it.
one question i have is how does the licensing work?
provided the program is linked to the LADSPA lib, the
plugin and the app don't need to match licensing, eh?
i could have a commercial host w/ gpl client or vice
versa? mix bsd and gpl?
There is no LADSPA lib, its just a .h file. The plugins can even be under
a GPL licence I belive, the GP doesn't have such strict conditions for
manual runtime linking.
- Steve
7856
days inactive
7858
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
ico＠fuse.net -
Ivica Bukvic
-
Lukas Degener -
Martin Voelkel -
Steve Harris -
Thomas Webb