21 Feb
2009
21 Feb
'09
3:37 p.m.
If one were to build a "kernel" to a digital audio workstation that was
itself a bare-bones LV2 host, could things like audio tracks, midi
tracks, and mixer channels and the like be built as LV2 plug-ins?
I've been thinking a lot about a comment made a while back about how
monolithic applications are very ill-suited to the open-source method of
development. So I got to thinking about how an operating system works
(at a high level; my meager coding skills are no matches for people
well-versed in operating systems) and began to ask some questions.
This "kernel" would have to handle things like audio routing, and
message passing between two "processes" (the LV2 plug-ins), and would
jockey the audio in and out of the plug-in graph. It would need to
support the GUI and event extensions, and probably a few others, at the
very least.
The hope might be that if such a kernel could be made, it might then be
a lot easier for many people to contribute the small pieces that would
make for a usable application. Please feel free to consider this
mindless brainstorming if you'd like.
-- Darren
21 Feb
21 Feb
3:55 p.m.
On Sat, Feb 21, 2009 at 2:37 PM, Darren Landrum <
darren.landrum(a)sbcglobal.net> wrote:
If one were to build a "kernel" to a digital
audio workstation that was
itself a bare-bones LV2 host, could things like audio tracks, midi
tracks, and mixer channels and the like be built as LV2 plug-ins?
this has been many people's dream. its part of the reason why systems like
PureData exist.
there are some rather hard problems along the way. transport is one of them
- this has effects on components of a DAW in ways that are not immediately
obvious, and its one reason why you will have a hard time making a purely
modular system usable as an HDR. conceptually speaking, modular systems
patch together using data flow; adding a timeline creates a new kind of
dependency that is othorgonal to the actual flow of data between the
"nodes". the consequences of moving data from one node to another are easily
expressed, highly constrained and generally very encapsulatable. by
contrast, the consequences of moving between points on a timeline do not
have these properties.
I've been thinking a lot about a comment made a while back about how
monolithic applications are very ill-suited to the
open-source method of
development.
i'm not sure i'd agree with this anyway, but even if i did, it doesn't mean
that the answer is to immediately ditch any semblance of "monolithic-ness".
it could be that the right answer is a host with plugins that finds the
right balance
between modularity and monolithic-ness.
So I got to thinking about how an operating system works
which operating system?
This "kernel" would have to handle things
like audio routing, and
message passing between two "processes" (the LV2 plug-ins), and would
jockey the audio in and out of the plug-in graph. It would need to
support the GUI and event extensions, and probably a few others, at the
very least.
hmm... does this sound anything like JACK?
if you want to understand why this is hard (not impossible, just hard), go
read the ardour source code and find all the places where *unexpected*
inter-object dependencies appear. then figure out how to remove them. if you
can do that, you'll be able to make a modular system work. if not, you'll at
least understand why nobody has else has been able to do it so far.
22 Feb
22 Feb
4:46 p.m.
On Sat, 2009-02-21 at 14:55 -0500, Paul Davis wrote:
On Sat, Feb 21, 2009 at 2:37 PM, Darren Landrum
<darren.landrum(a)sbcglobal.net> wrote:
If one were to build a "kernel" to a digital audio workstation
that was
itself a bare-bones LV2 host, could things like audio tracks,
midi
tracks, and mixer channels and the like be built as LV2
plug-ins?
if you want to understand why this is hard (not
impossible, just
hard), go read the ardour source code and find all the places where
*unexpected* inter-object dependencies appear. then figure out how to
remove them. if you can do that, you'll be able to make a modular
system work. if not, you'll at least understand why nobody has else
has been able to do it so far.
Exactly as hard as Jack doing transport...
Anyway, just because the signal flow aspect of things is patching
doesn't mean transport has to be. There's no fundamental reason this is
any harder than it is to solve in Ardour. Objects are objects at the
end of the day. You could even do it by controlling the transport over
wires if you wanted to (messages are messages at the end of the day) but
it would be a huge mess you would want to hide from the user anyway, so
not a lot of point.
There's no technological reason this is infeasible or particularly
difficult, it's just a lot of work.
-dr
10:40 p.m.
Do plugins have any more sense of time than your average herd of cows?
In goes sunlight and green grass, and out comes a healthy amount of milk
and fresh manure ..
The only kinds of "plugins" that has a sense of time in our world are
those who are recording either audio or midi, and these are those we
would normally prefer to define as our toplevel hosts.
/j
On Sun, 2009-02-22 at 15:46 -0500, David Robillard wrote:
On Sat, 2009-02-21 at 14:55 -0500, Paul Davis wrote:
On Sat, Feb 21, 2009 at 2:37 PM, Darren Landrum
<darren.landrum(a)sbcglobal.net> wrote:
If one were to build a "kernel" to a digital audio workstation
that was
itself a bare-bones LV2 host, could things like audio tracks,
midi
tracks, and mixer channels and the like be built as LV2
plug-ins?
if you want to understand why this is hard (not
impossible, just
hard), go read the ardour source code and find all the places where
*unexpected* inter-object dependencies appear. then figure out how to
remove them. if you can do that, you'll be able to make a modular
system work. if not, you'll at least understand why nobody has else
has been able to do it so far.
Exactly as hard as Jack doing transport...
Anyway, just because the signal flow aspect of things is patching
doesn't mean transport has to be. There's no fundamental reason this is
any harder than it is to solve in Ardour. Objects are objects at the
end of the day. You could even do it by controlling the transport over
wires if you wanted to (messages are messages at the end of the day) but
it would be a huge mess you would want to hide from the user anyway, so
not a lot of point.
There's no technological reason this is infeasible or particularly
difficult, it's just a lot of work.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev 
10:51 p.m.
Just to be pedantic for a moment, every audio plugin needs to be
intimately familiar with time, because sound is a time bound
phenomena, you almost always need to have an incremental (even if
looped) index into an array somewhere, or some concept of a phase, and
also frequency usually plays a role as well, and frequency is a
measurement in the domain of time. Actually almost everything an audio
plugin does is time dependent.
On Sun, Feb 22, 2009 at 6:40 PM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
Do plugins have any more sense of time than your
average herd of cows?
In goes sunlight and green grass, and out comes a healthy amount of milk
and fresh manure ..
The only kinds of "plugins" that has a sense of time in our world are
those who are recording either audio or midi, and these are those we
would normally prefer to define as our toplevel hosts.
/j
On Sun, 2009-02-22 at 15:46 -0500, David Robillard wrote:
On Sat, 2009-02-21 at 14:55 -0500, Paul Davis
wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Sat, Feb 21, 2009 at 2:37 PM, Darren Landrum
<darren.landrum(a)sbcglobal.net> wrote:
If one were to build a "kernel" to a digital audio workstation
that was
itself a bare-bones LV2 host, could things like audio tracks,
midi
tracks, and mixer channels and the like be built as LV2
plug-ins?
if you want to understand why this is hard (not
impossible, just
hard), go read the ardour source code and find all the places where
*unexpected* inter-object dependencies appear. then figure out how to
remove them. if you can do that, you'll be able to make a modular
system work. if not, you'll at least understand why nobody has else
has been able to do it so far.
Exactly as hard as Jack doing transport...
Anyway, just because the signal flow aspect of things is patching
doesn't mean transport has to be. There's no fundamental reason this is
any harder than it is to solve in Ardour. Objects are objects at the
end of the day. You could even do it by controlling the transport over
wires if you wanted to (messages are messages at the end of the day) but
it would be a huge mess you would want to hide from the user anyway, so
not a lot of point.
There's no technological reason this is infeasible or particularly
difficult, it's just a lot of work.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
11:01 p.m.
So there is our answer: one extra input on every "timeline" dependent
plugin, telling it the logical transport time/state. That plus a gui
with pretty pictures of waveforms or midi notes or automation lines
gives us what we have been talking about, right? Or am I missing
something?
On Sun, Feb 22, 2009 at 6:55 PM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
On Sun, 2009-02-22 at 18:51 -0800, Justin Smith wrote:
Actually almost everything an audio plugin does
is time dependent.
But not to the wall clock!
/j
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
11:14 p.m.
Yes you are missing that, either we would have an intelligent host
commanding an unruly herd of time time-tracks, or we would just have a
single master pretty much in terms with its own inconsistencies.
In a fight between a single 24 track Studer and an array of synchronized
Nagra's, I know what combination of poison I would pick :-D
/j
On Sun, 2009-02-22 at 19:01 -0800, Justin Smith wrote:
So there is our answer: one extra input on every
"timeline" dependent
plugin, telling it the logical transport time/state. That plus a gui
with pretty pictures of waveforms or midi notes or automation lines
gives us what we have been talking about, right? Or am I missing
something?
On Sun, Feb 22, 2009 at 6:55 PM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
On Sun, 2009-02-22 at 18:51 -0800, Justin Smith wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev Actually almost everything an audio plugin does
is time dependent.
But not to the wall clock!
/j
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
11:17 p.m.
What is a Studer, and what is a Nagra?
On Sun, Feb 22, 2009 at 7:13 PM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
Yes you are missing that, either we would have an
intelligent host
commanding an unruly herd of time time-tracks, or we would just have a
single master pretty much in terms with its own inconsistencies.
In a fight between a single 24 track Studer and an array of synchronized
Nagra's, I know what combination of poison I would pick :-D
/j
On Sun, 2009-02-22 at 19:01 -0800, Justin Smith wrote:
So there is our answer: one extra input on every
"timeline" dependent
plugin, telling it the logical transport time/state. That plus a gui
with pretty pictures of waveforms or midi notes or automation lines
gives us what we have been talking about, right? Or am I missing
something?
On Sun, Feb 22, 2009 at 6:55 PM, Jens M Andreasen
<jens.andreasen(a)comhem.se> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
On Sun, 2009-02-22 at 18:51 -0800, Justin Smith wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev Actually almost everything an audio plugin does
is time dependent.
But not to the wall clock!
/j
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
11:41 p.m.
On Sun, 2009-02-22 at 19:17 -0800, Justin Smith wrote:
What is a Studer, and what is a Nagra?
They are both famous Swiss made tape-recorders. The Nagra was used in
the field by pretty much every radio station and in film synchronized
with camera (using real film, not video.) using EBU/SMPTE. It weighs way
too much to be truly portable.
I have a never ending love/hate relation to it ...
The 24 track Studer was one of the more expensive multitrackers of its
time. We instead used danish Lyrec, giving equalent quality for half the
price.
/j
23 Feb
23 Feb
5:33 a.m.
On Mon, Feb 23, 2009 at 04:40:58AM +0100, Jens M Andreasen wrote:
On Sun, 2009-02-22 at 19:17 -0800, Justin Smith
wrote:
Still feel them on my shoulder... In fact the weighty part
was not so much the Nagra itself, but the batteries.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
What is a Studer, and what is a Nagra?
They are both famous Swiss made tape-recorders. The Nagra was used in
the field by pretty much every radio station and in film synchronized
with camera (using real film, not video.) using EBU/SMPTE. It weighs way
too much to be truly portable.
8:17 a.m.
On Mon, 2009-02-23 at 10:33 +0100, Fons Adriaensen wrote:
Still feel them on my shoulder... In fact the weighty
part
was not so much the Nagra itself, but the batteries.
It could have been worse as you can see in this post from:
http://www.tomshardware.co.uk/forum/page-47189_32_0.html
:)
--8<--------------------------------------
Hello,
I'd really like to get a mono portable Nagra. I don't have a lot of
money to spend and I just wish to record an upright piano (with one
dynamic mic).
Till now, I've been logging around my 55 lb TEAC open reel recorder,
getting great results but my back can't take it anymore .. If you have
a Nagra, in good and well maintained cond, then please let me know.
Ideally, I'd like to deal with the regular, reputable posters here.
Thank you for your time. You can reply here or to my email
****(a)yahoo.com
Thanks!
1:56 a.m.
On Mon, 2009-02-23 at 05:58 +0100, Jens M Andreasen wrote:
On Sun, 2009-02-22 at 23:49 -0500, David Robillard
wrote:
That there are several possible timebases (all of which, by the way, are
relevant in audio depending on context) is not an argument that plugins
have nothing to do with time.
-dr
Um... no.
Ehh ...
I see time relative to the wall clock. What time is yours? 
2:10 a.m.
Dave, just askin'. :)
Alex
On Mon, Feb 23, 2009 at 7:56 AM, David Robillard <dave(a)drobilla.net> wrote:
On Mon, 2009-02-23 at 05:58 +0100, Jens M Andreasen
wrote:
--
Parchment Studios (It started as a joke...)
On Sun, 2009-02-22 at 23:49 -0500, David
Robillard wrote:
That there are several possible timebases (all of which, by the way, are
relevant in audio depending on context) is not an argument that plugins
have nothing to do with time.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Um... no.
Ehh ...
I see time relative to the wall clock. What time is yours? 
21 Feb
21 Feb
4:19 p.m.
On Sat, Feb 21, 2009 at 02:37:24PM -0500, Darren Landrum wrote:
If one were to build a "kernel" to a digital
audio workstation that was
itself a bare-bones LV2 host, could things like audio tracks, midi
tracks, and mixer channels and the like be built as LV2 plug-ins?
Sure. They output/read data when asked to do so. Which directly reminds
me of "host synchronization is crucial for a successful plugin API." ;)
We had this discussion two or three weeks ago in #lad, and I claim the
foremost question to audio production on Linux is a decent plugin API
which enables others to write neat plugins. (Think of Cubase. While it
is quite fine, the various VST plugins make the salt...)
One of the key requirements for such an API (and it looks like LV2 could
be that API) is host synchronization. A delay would need to know about
the tempo, so it can output the echos exactly at 1/4, 2/4 or whatever
the user will choose. "213.8ms" isn't the way musicians/producers think.
Synth plugins would also need to know about transport or at least
something like "next bar started" (event?). Think of a synthesizer which
outputs louder on the first note of the bar, a panner starting at 100%
left on the first note or something similar.
This "kernel" would have to handle things
like audio routing, and
message passing between two "processes" (the LV2 plug-ins), and would
jockey the audio in and out of the plug-in graph. It would need to
support the GUI and event extensions, and probably a few others, at the
very least.
You describe the LV2 host. It routes audio from and to LV2 plugins.
Along the graph. It would need a GUI, yes. And automation. And total
recall, so when I open the project, all the LV2 plugins have exactly the
state they had when I pressed "Save".
Looks like LASH is going to be used for that, though I don't know why
the LV2 API shouldn't simply offer a get_config() and set_config()
function. (don't know if LV2 has functions, what I describe here is VST
chunks)
Anyway, if LASH will do the trick, be my guest. Separate API or
integrated into LV2 doesn't make much difference, does it?
The hope might be that if such a kernel could be made,
it might then be
a lot easier for many people to contribute the small pieces that would
make for a usable application.
Exactly my point. Once there is a suitable plugin API, nobody would ever
need to think about how to get MIDI data in/out, audio in/out, timings,
total recall... in other words: every audio application would simply be
a LV2 plugin. The EQ, the compressor, the synth, the analyzer, the
finalizer and so on.
No new application would directly interface with jack, won't neither do
jack_midi nor ALSA midi, but simply LV2.
I like that idea, probably because it's just the way Cubase does it with
VST(i).
A last remark: what you call a "kernel" could be ardour or qtractor one
day. There's no use and no need in getting rid of the real OS, let the
Linux kernel do the hardware handling for you, implement your LV2 host
and do everything else in a LV2 plugin.
Could be that easy ;)
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
4:34 p.m.
Adrian Knoth wrote:
A last remark: what you call a "kernel"
could be ardour or qtractor one
day. There's no use and no need in getting rid of the real OS, let the
Linux kernel do the hardware handling for you, implement your LV2 host
and do everything else in a LV2 plugin.
I was never suggesting that this *replace* the OS kernel. I was merely
using that as an analogy.
Otherwise, everything you say sounds really good. I do think in the end,
however, that Paul is right and that there is a good reason none of this
has happened yet.
-- Darren
22 Feb
22 Feb
4:50 p.m.
On Sat, 2009-02-21 at 14:37 -0500, Darren Landrum wrote:
If one were to build a "kernel" to a digital
audio workstation that was
itself a bare-bones LV2 host, could things like audio tracks, midi
tracks, and mixer channels and the like be built as LV2 plug-ins?
I've been thinking a lot about a comment made a while back about how
monolithic applications are very ill-suited to the open-source method of
development. So I got to thinking about how an operating system works
(at a high level; my meager coding skills are no matches for people
well-versed in operating systems) and began to ask some questions.
This "kernel" would have to handle things like audio routing, and
message passing between two "processes" (the LV2 plug-ins), and would
jockey the audio in and out of the plug-in graph. It would need to
support the GUI and event extensions, and probably a few others, at the
very least.
The hope might be that if such a kernel could be made, it might then be
a lot easier for many people to contribute the small pieces that would
make for a usable application. Please feel free to consider this
mindless brainstorming if you'd like.
This is a long term goal of http://drobilla.net/software/ingen
LV2 was a very large step towards achieving it...
GUI is there, events are there, signal flow is there, but having
"tracks" brings in a whole host of new issues that are not yet there.
... yet :)
-dr
7 p.m.
Ingen works well on my setup, but the idea of adding midi and audio tracks
as 'plugins' sounds rather appealing. (Would be cool to simply add tracks,
and have them autoorganise into a neat arrangement in the GUI. Starting from
the top down?)
Given the multi layer framework of Ingen, i would think there are many
advantages to this.
(Strings on patch layer 1, Woodwinds on patch layer 2, etc..)
Sounds like a worthy direction as a 'complete' modular system too.
Would future Ingen include a LASH component, either working with the current
LASH app, or as 'the' LASH app in its own right, with the ability to save
settings from LASH capable external apps?
Alex.
On Sun, Feb 22, 2009 at 10:50 PM, David Robillard <dave(a)drobilla.net> wrote:
On Sat, 2009-02-21 at 14:37 -0500, Darren Landrum
wrote:
--
Parchment Studios (It started as a joke...)
If one were to build a "kernel" to a
digital audio workstation that was
itself a bare-bones LV2 host, could things like audio tracks, midi
tracks, and mixer channels and the like be built as LV2 plug-ins?
I've been thinking a lot about a comment made a while back about how
monolithic applications are very ill-suited to the open-source method of
development. So I got to thinking about how an operating system works
(at a high level; my meager coding skills are no matches for people
well-versed in operating systems) and began to ask some questions.
This "kernel" would have to handle things like audio routing, and
message passing between two "processes" (the LV2 plug-ins), and would
jockey the audio in and out of the plug-in graph. It would need to
support the GUI and event extensions, and probably a few others, at the
very least.
The hope might be that if such a kernel could be made, it might then be
a lot easier for many people to contribute the small pieces that would
make for a usable application. Please feel free to consider this
mindless brainstorming if you'd like.
This is a long term goal of http://drobilla.net/software/ingen
LV2 was a very large step towards achieving it...
GUI is there, events are there, signal flow is there, but having
"tracks" brings in a whole host of new issues that are not yet there.
... yet :)
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
9:24 p.m.
On Mon, 2009-02-23 at 01:00 +0200, alex stone wrote:
Ingen works well on my setup, but the idea of adding
midi and audio
tracks as 'plugins' sounds rather appealing. (Would be cool to simply
add tracks, and have them autoorganise into a neat arrangement in the
GUI. Starting from the top down?)
Given the multi layer framework of Ingen, i would think there are many
advantages to this.
(Strings on patch layer 1, Woodwinds on patch layer 2, etc..)
It's extremely unlikely anything would be better than the existing
graphviz arrangement (short of some kind of limitations on routing
between tracks to enforce this 'layer' model which is completely out of
the question for obvious reasons)
The whole point/advantage of using something like Ingen for this is no
specifics need to be built in to the system. This will be really cool
for some things and open up new possibilities... but probably not very
good for traditional recording regardless. There's always Ardour if you
want a traditional timeline, and the two play nicely together.
Would future Ingen include a LASH component, either
working with the
current LASH app
Yes, just havn't gotten around to it. The release will have LASH
support.
or as 'the' LASH app in its own right, with
the ability to save
settings from LASH capable external apps?
... and a kitchen sink too! Most definitely not ;)
-dr
5534
days inactive
5536
days old
linux-audio-dev@lists.linuxaudio.org
20 comments
8 participants
participants (8)
-
adi＠drcomp.erfurt.thur.de -
alex stone -
Darren Landrum -
David Robillard -
Fons Adriaensen -
Jens M Andreasen -
Justin Smith -
Paul Davis