28 Sep
2008
28 Sep
'08
2:08 p.m.
I've been playing with and watching various tutorials for Processing,
the Java framework for generative video and video effects.
http://processing.org/
What blew me away recently, though, was this video from Wesen on
building a "game of life" MIDI sequencer with it (watch the whole thing,
it's worth it):
http://vimeo.com/1824904?pg=embed&sec=1824904
(Of course, Paul reads the same blog that I do, so he'll know about this
already.)
Notice that Processing has its own editor, with controls to compile and
run any program you make in it, single-click. Not much different than an
IDE, I suppose, though I would be hesitant to say that an IDE is better
because it's more powerful, as I would have to disagree: what makes
Processing so powerful and so popular is because it's so specific to its
niche. Combine it with a very thorough (and expandable) framework and it
becomes very powerful.
Why couldn't we make something like that for audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me. Throw in some
GUI-building elements (Cairo-based, perhaps) that can handle
mouse-clicks, keyboard input, and the like, then suddenly people who are
good at math and DSP but not so good at coding might have a shot at
making some great programs.
Consider this a feeler post for a potential project. I am unfortunately
not a great coder, but at this point, I can't help but think that
something badly-coded and working is still better than well-written code
that never actually gets written.
-- Darren Landrum
28 Sep
28 Sep
2:20 p.m.
Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:
Why couldn't we make something like that for
audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me.
Faust, CLAM, SuperCollider, Lua-AV, Common Lisp Music, CSound, (Pd) ..
take your pick.
Ciao
--
Frank
2:23 p.m.
On Sun, Sep 28, 2008 at 6:20 PM, Frank Barknecht <fbar(a)footils.org> wrote:
Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:
And ChucK (http://chuck.cs.princeton.edu/). It also has its editor.
Why couldn't we make something like that for
audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me.
Faust, CLAM, SuperCollider, Lua-AV, Common Lisp Music, CSound, (Pd) ..
take your pick.
2:45 p.m.
Mr.SpOOn wrote:
>> Why couldn't we make something like that
for audio? It would most likely
>> be C++ rather than Java, but the idea of building up DSP networks using
>> a large framework of code, plus some pre-defined functions and settings,
>> and being able to launch our new code with a one-touch button into a
>> JACK client (or whatever), is extremely appealing to me.
> Faust, CLAM, SuperCollider, Lua-AV, Common Lisp
Music, CSound, (Pd) ..
> take your pick.
And ChucK (http://chuck.cs.princeton.edu/). It also
has its editor.
I really wish I could explain why none of those are quite what I see in
my head.
Part of why I don't like any of those is that they create whole new
languages, or use languages I've never touched. ChucK is especially
confusing to me.
Also, processing compiles everything down to a standalone executable
that can be distributed. Can any of those audio options do that?
I also seem to recall SuperCollider and Csound having issues with
certain features, like oversampling, ie, it can't be done. I don't know
about CLM. I know Faust can't as well, but Yann says he has it in his
sights.
Of all of those Lua-AV looks the closest to what I see in my head. I
just wish I could understand why I can't seem to communicate that all of
these options miss the mark, in my opinion. I just don't get them.
There's still too large of a learning curve that has nothing to do with
math or DSP. Maybe Pd would be an option if it were possible for Pd to
compile its patches out as standalone programs, which I understand can
be done on OSX, but not on any other platform. But even then, is Pd
atomic enough that I can graphically build something like a filter from
the most basic of elements like adders, multipliers, and delays and have
it savable as a new Ugen or whatever Pd calls them?
Unfortunately, my 64-bit system keeps me from trying the vast majority
of these options out (that's another complaint I have, but that's
another thread, and one we've already done I might add). I'm going to be
switching to 32-bit soon, but first, I need to get some other work done.
It'll probably happen sometime this week.
How about I pose it this way: what tool will allow me to code any JACK
client I want, with a custom GUI, with complete abstraction, by way of
built-in methods that allow me to set options and define certain
functions (like in that Processing tutorial video), allow the creation
of DSP graphs (which support variable numbers of frames per node from
the get-go, for easy oversampling support) with pre-defined as well as
custom nodes created right there in the same editor, and then allow
one-touch compilation and running, and then make it easy to package up
the code for distribution to anyone who wants it?
If all of that doesn't exist in one place, that's what I would like to
make. It'll be big, and it'll take a while, but it will be worth it.
Bonus points if the entire thing stays C++.
Maybe, finally, somewhere in that ranting, what I envision in my head is
finally coming out.
-- Darren Landrum
3:20 p.m.
Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:
Part of why I don't like any of those is that they
create whole new
languages, or use languages I've never touched.
Some use multi-purpose languages: Lua and Lisp. IMO these languages are
much nicer to work with in this realm than C++ directly, especially for
live coding etc. The fact, that Processing is using a simplified general
purpose language that is stripped from things like memory management is
largely responsible for its success.
Also, processing compiles everything down to a
standalone executable
that can be distributed. Can any of those audio options do that?
Faust can, but: Is it really important? And why would it be important
(taking aside speed issues)?
Of all of those Lua-AV looks the closest to what I see
in my head. I
just wish I could understand why I can't seem to communicate that all of
these options miss the mark, in my opinion. I just don't get them.
There's still too large of a learning curve that has nothing to do with
math or DSP. Maybe Pd would be an option if it were possible for Pd to
compile its patches out as standalone programs, which I understand can
be done on OSX, but not on any other platform.
You're probably thinking of Max/MSP, but Pd cannot export binary
executables. It's not a feature that I consider important anyway.
Interpreted languages rule a big part of the FLOSS world. Exporting
binaries is important for some Max-users because a) they can give their
Max patches to people without Max and b) they can obfuscate their
patches so that other users don't see their patchings tricks. Both a)
and b) are not of much relevance in an open source world.
But even then, is Pd atomic enough that I can
graphically build
something like a filter from the most basic of elements like adders,
multipliers, and delays and have it savable as a new Ugen or whatever
Pd calls them?
Yes: Every Pd patch can be reused in other patches as a so called
abstraction, which is a bit like a module or funciton in a normal
programming language. I have literally thousands of abstractions on my
disk.
Alternatively you can write extensions in various other languages.
C/C++ of course (has to be compiled), Python, Lua, Scheme, etc.
Unfortunately, my 64-bit system keeps me from trying
the vast majority
of these options out (that's another complaint I have, but that's
another thread, and one we've already done I might add). I'm going to be
switching to 32-bit soon, but first, I need to get some other work done.
It'll probably happen sometime this week.
The latest versions of Pd now work on 64-bit systems as well.
How about I pose it this way: what tool will allow me
to code any JACK
client I want, with a custom GUI, with complete abstraction, by way of
built-in methods that allow me to set options and define certain
functions (like in that Processing tutorial video), allow the creation
of DSP graphs (which support variable numbers of frames per node from
the get-go, for easy oversampling support) with pre-defined as well as
custom nodes created right there in the same editor, and then allow
one-touch compilation and running, and then make it easy to package up
the code for distribution to anyone who wants it?
If you skip the compilation part, Pd (or the other environments I
mentioned, Pd is just one example) can do all that. Just bundle the
Pd binary and a sh-script with your Pd application to distribute it, if
you want. (I would prefer an unbundled download as I already have Pd.)
If you dislike graphical coding then I guess Faust is a good option. I
think, having a kind of IDE for Faust similar to the one of Processing
might be useful.
Ciao
--
Frank
4:11 p.m.
Frank Barknecht wrote:
Faust can, but: Is it really important? And why would
it be important
(taking aside speed issues)?
Speed is a large part of it, yes.
Another reason to stick to C++ is for things that need the speed and
low-level abilities, like on-demand sample streaming from disk for
making a sampler.
You're probably thinking of Max/MSP, but Pd cannot
export binary
executables. It's not a feature that I consider important anyway.
Interpreted languages rule a big part of the FLOSS world. Exporting
binaries is important for some Max-users because a) they can give their
Max patches to people without Max and b) they can obfuscate their
patches so that other users don't see their patchings tricks. Both a)
and b) are not of much relevance in an open source world.
I'm pretty darn sure I read that Pd can export patches to some sort of
standalone state on OSX, but I could have misunderstood.
Yes: Every Pd patch can be reused in other patches as
a so called
abstraction, which is a bit like a module or funciton in a normal
programming language. I have literally thousands of abstractions on my
disk.
Okay, one point to Pd. So far, so good.
The latest versions of Pd now work on 64-bit systems
as well.
Pd-vanilla can (and I do have it working), but Pd-extended still cannot.
I've been on their mailing list about this issue, and they insist that
the version being worked on will work 64-bit, but I don't know when that
will happen.
Nevertheless, there are lots of other programs, some not music-related,
that cannot work (or have issues working) in 64-bit, necessitating a
switch. That has little to do with Pd, really.
If you skip the compilation part, Pd (or the other
environments I
mentioned, Pd is just one example) can do all that. Just bundle the
Pd binary and a sh-script with your Pd application to distribute it, if
you want. (I would prefer an unbundled download as I already have Pd.)
Does Pd do oversampling? I seem to recall it can. I keep bringing this
up because several of the things I want to work on, namely lumped
modeling/wave digital filters and non-linear processing, both require
oversampling to work right, largely to avoid frequency warping and
aliasing issues.
If you dislike graphical coding then I guess Faust is
a good option. I
think, having a kind of IDE for Faust similar to the one of Processing
might be useful.
On the contrary, I might even prefer graphical programming if I could
finally get everything working right. Right now, I'm also dealing with
hardware issues (my soundcard went bad), which is one other reason I can
only read about this stuff and ask questions rather than trying it out.
And again, that ignores the fact that Faust does not currently support
oversampling, and neither does Supercollider. I think CLM does, though.
I realize that I seem to be the only one with that itch, but isn't that
the point of open source? I want to make what I want because I have my
own itch to scratch.
A Processing-alike for audio can also integrate and abstract away things
like LASH support, MIDI, and OSC. Something like LASH (session state
saving, see the other current thread) is an important capability in my
world.
Really, the Synthesis Toolkit (STK) is already quite close to the mark,
if it could be made to be easily extensible (it probably already is) and
that whole "integrated editor/compilation control" paradigm could be
brought to it, along with some extra abstractions for LASH, FFTW, and
some other common libraries. We'd also need to add DSP graph
construction, along with that variable frame size thing I mentioned
before (I refuse to say the o***s******* word again in this email). :-)
Okay, that's a big enough email for now. Thanks for letting me rant.
-- Darren Landrum
29 Sep
29 Sep
7:10 a.m.
Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:
Pd-extended is shipped with an old version of Pd.
Yes, you do that with the [block~] object in a subpatch.
Frank Barknecht wrote:
It's a give and take. For some convenience I'll happily give away
some speed. OTOH there are areas where speed matters, those areas
should be optimized (and thus probably be coded in C/C++). The
environments I mentioned can be extended with C in these critical
areas. Anyway speed definitly is not what made Processing popular.
The core objects in Pd are all coded in C. And generally they are
quite fast. Connecting these objects adds a bit of overhead (function
calls etc.), but even that is quite fast in Pd.
Faust can, but: Is it really important? And why
would it be important
(taking aside speed issues)?
Speed is a large part of it, yes.
Another reason to stick to C++ is for things that need the speed and
low-level abilities, like on-demand sample streaming from disk for
making a sampler. The latest
versions of Pd now work on 64-bit systems as well.
Pd-vanilla can (and I do have it working), but Pd-extended still cannot. If you skip
the compilation part, Pd (or the other environments I
mentioned, Pd is just one example) can do all that. Just bundle the
Pd binary and a sh-script with your Pd application to distribute it, if
you want. (I would prefer an unbundled download as I already have Pd.)
Does Pd do oversampling? I seem to recall it can. I keep bringing this up because several of the things
I want to work
on, namely lumped modeling/wave digital filters and non-linear
processing, both require oversampling to work right, largely to
avoid frequency warping and aliasing issues.
One thing with Pd is that it is a block-based realtime system, so some
of the techniques you mentioned (i.e. those that involve feedback
delay lines) can be impossible to implement in Pd using only the
builtin objects (feedback delay lines always have a minimal delay time
of one block in Pd). But you can code these objects as C-externals or
with Faust for Pd.
A Processing-alike for audio can also integrate and
abstract away things
like LASH support, MIDI, and OSC. Something like LASH (session state
saving, see the other current thread) is an important capability in my
world.
Point taken: Session management is an area where Pd isn't especially
good. OTOH C++ out of the box isn't either. ;)
Ciao
--
Frank Barknecht _ ______footils.org__
9:20 a.m.
Frank Barknecht wrote:
One thing with Pd is that it is a block-based realtime
system, so some
of the techniques you mentioned (i.e. those that involve feedback
delay lines) can be impossible to implement in Pd using only the
builtin objects (feedback delay lines always have a minimal delay time
of one block in Pd). But you can code these objects as C-externals or
with Faust for Pd.
Yes, I was wrestling with this logic back when my idea was to make a
Reaktor-alike for Linux. Reaktor handles this, I think, by having a
separate "core" layer that works sample by sample. In other words, when
you're using the Core objects, you're operating at the sample level, and
then when you use the objects you've made with Core, you're at the block
level. That's probably not a bad way to do it.
I think I may have figured out some logic to implement something like a
single-sample delay as a block object. That's one of the things I wanted
to play around with. There's also the possibility of playing around with
templating, where an object can process a vector's worth of data or a
single sample, depending on how it's called.
I've been thinking about the front-end, ie, the editor with the
single-button build and run system to make a pseudo-live-coding
environment for C++. Since nothing to do with this front-end will ever
make it into a JACK application and/or plug-in made with this system,
I'm thinking I could implement the front-end with Python instead of C++
and save myself a lot of headache.
Right now, though, I'm agonizing over a physics class lab assignment due
today that I can't figure out, and running on 3 hours of sleep as a result.
-- Darren
9:58 a.m.
Hallo,
Darren Landrum hat gesagt: // Darren Landrum wrote:
Frank Barknecht wrote:
Note that working on a single-sample level is possible in Pd as well:
Just add a [block~ 1] object into a subpatch. This has an effect on
performance, so it should only be done in small subpatches. It's also no
problem to have a single-sample delay or even a zero sample delay with
Pd. There is a problem however as soon as feedback is involved, where the delay
writer gets part of its input from the delay reader which in turn gets
its input from the delay writer and so on. This is a loop and in Pd you
need to have at least one block (which can be as small as one
sample) delay to break free from the loop.
For details check out Miller's book in chapter:
http://crca.ucsd.edu/~msp/techniques/latest/book-html/node120.html ff.
One thing with Pd is that it is a block-based
realtime system, so some
of the techniques you mentioned (i.e. those that involve feedback
delay lines) can be impossible to implement in Pd using only the
builtin objects (feedback delay lines always have a minimal delay time
of one block in Pd). But you can code these objects as C-externals or
with Faust for Pd.
Yes, I was wrestling with this logic back when my idea was to make a
Reaktor-alike for Linux. Reaktor handles this, I think, by having a
separate "core" layer that works sample by sample. In other words, when
you're using the Core objects, you're operating at the sample level, and
then when you use the objects you've made with Core, you're at the block
level. That's probably not a bad way to do it. Right now, though, I'm agonizing over a physics
class lab assignment due
today that I can't figure out, and running on 3 hours of sleep as a result.
Heh, good luck. ;)
I've just spent three days thinking about a self-made assignement which
involved calculating how to alter a delay reader's speed to get semitone
pitchshifting at the output. It's actually very simple, but sometimes
you just don't see the solution in front of you for a long time ...
Ciao
--
Frank
28 Sep
28 Sep
4:44 p.m.
On Sun, 2008-09-28 at 12:08 -0400, Darren Landrum wrote:
Why couldn't we make something like that for audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me.
SKINI, Chuck, Faust and CSound/SuperCollider spring to mind.
Throw in some
GUI-building elements (Cairo-based, perhaps) that can handle
mouse-clicks, keyboard input, and the like,
oops ...
Processing has wrapped a language with a lot *less* power than
SuperCollider in a front end that is much easier to learn. Its a shame.
But it also seems to be way the world works.
--p
5:15 p.m.
Paul Davis wrote:
Processing has wrapped a language with a lot *less*
power than
SuperCollider in a front end that is much easier to learn. Its a shame.
But it also seems to be way the world works.
So we would rather have a *more* powerful language wrapped in a front
end that is very difficult to learn? We already have that in spades, and
it's proven a good way to scare off people with good ideas who are not
skilled in coding enough (or patient enough) to get the most basic tasks
to work.
What we need is a nice and powerful back-end that is wrapped in an
easy-to-learn front end. The best of both worlds, if it's possible.
My entire point is to design a C++ framework and resultant editor with
only a very specific problem domain in mind: software effects,
synthesis, and perhaps sampling as well. Then abstract everything that's
needed into classes and functions that are well-documented.
I seem to recall you saying once, Paul, that nobody was writing the
Native Instruments type of plug-ins for Linux audio. That statement is
the very thing that got me down this path. It made me wonder what kind
of code frameworks and libraries NI inevitably has created to use
internally, and hoping we could make the same thing, open it all up, and
then see some very powerful synthesizers and effects come out of it.
Everyone on this list seems to think these are all completely solved
problems, and I disagree, with a great deal of passion. What happened to
the days when we were all pumped up with enthusiasm, determined to take
the world of professional audio by storm?
Of course, this also in part gets back to the "small, interoperating
apps" vs. "large monolithic apps" argument, and I don't intend to go
back down that road. We're already well down the first path, but even
then, I still don't see why we can't create the kinds of programs that
can match and even outclass what's available in the "desktop home
studio" space on Windows and Mac.
Geez, the election year must be getting to me. I'm beginning to sound
like a politician.
Oh well, these are my raw and naked thoughts and feelings, and I'll
leave them exposed for all to see and comment and criticize. I really
don't care if they get stomped on or not.
-- Darren Landrum
5:19 p.m.
On Sun, 2008-09-28 at 15:15 -0400, Darren Landrum wrote:
Paul Davis wrote:
Why do we need this?
--p
Processing has wrapped a language with a lot
*less* power than
SuperCollider in a front end that is much easier to learn. Its a shame.
But it also seems to be way the world works.
So we would rather have a *more* powerful language wrapped in a front
end that is very difficult to learn? We already have that in spades, and
it's proven a good way to scare off people with good ideas who are not
skilled in coding enough (or patient enough) to get the most basic tasks
to work.
What we need is a nice and powerful back-end that is wrapped in an
easy-to-learn front end. The best of both worlds, if it's possible.
5:31 p.m.
Paul Davis wrote:
On Sun, 2008-09-28 at 15:15 -0400, Darren Landrum
wrote:
I thought I was clear on this, but I'll restate: We need this so that
people who are not skilled coders, but have other skills, in math and
physics and electronics perhaps, can bring their skills to bear in
making synths and effects while making the coding side as painless as
possible. The end result will hopefully be synths and effects usable by
*musicians* and not just other coders. Click and play, as it were.
Really, I'm in that exact category, so I'm the last person who should be
trying to create a Processing-alike for audio. I'll probably get nowhere
by myself. Oh well, it doesn't seem to be stopping me.
I want my musical skills to be all I need to be able to make music on Linux.
-- Darren
Paul Davis wrote:
Why do we need this? Processing has wrapped a language with a lot
*less* power than
SuperCollider in a front end that is much easier to learn. Its a shame.
But it also seems to be way the world works.
So we would rather have a *more*
powerful language wrapped in a front
end that is very difficult to learn? We already have that in spades, and
it's proven a good way to scare off people with good ideas who are not
skilled in coding enough (or patient enough) to get the most basic tasks
to work.
What we need is a nice and powerful back-end that is wrapped in an
easy-to-learn front end. The best of both worlds, if it's possible.
5:43 p.m.
On Sun, 2008-09-28 at 15:30 -0400, Darren Landrum wrote:
I want my musical skills to be all I need to be able
to make music on Linux.
I want my musical skills to be all I need to be able to make music on
Cello. It doesn't seem to be working out too well, so far :)
To be honest, this is not an avenue that interests me individually. I
view these tools as a lot like table saws, routers and jointers: things
with immense power that make a lot of tasks way faster and simpler than
they would otherwise be, but that do not remove the obligation to
develop a set of tool-specific skills. I've never had much interest in
designing table saws for people who don't want to know how to use table
saws, and I personally don't have a lot of interest in designing
software tools for people who don't want to learn how to use them.
I do see the attraction, however. And also the marketability. I also
promise to discuss this issue in my seminar at the Technical University
here in Berlin, "Designing Tools for Musicians".
--p
6:05 p.m.
Paul Davis wrote:
To be honest, this is not an avenue that interests me
individually. I
view these tools as a lot like table saws, routers and jointers: things
with immense power that make a lot of tasks way faster and simpler than
they would otherwise be, but that do not remove the obligation to
develop a set of tool-specific skills. I've never had much interest in
designing table saws for people who don't want to know how to use table
saws, and I personally don't have a lot of interest in designing
software tools for people who don't want to learn how to use them.
Who said anything about not wanting to learn how to use table saws?
This seems a bad analogy to me. NI's plug-ins don't make me a better
musician. I still have to learn how to use them, but I don't have to
know how to code them myself first. That part's already done. I'm more
than willing to learn how to use a table saw, but I really don't feel
like building my own table saw first. Right now, audio on Linux really
does kinda force the latter, in my opinion.
I'm genuinely enjoying myself debating this, though. :-)
-- Darren Landrum
6:23 p.m.
On Sun, 2008-09-28 at 16:05 -0400, Darren Landrum wrote:
Paul Davis wrote:
if you use a language edited with text files and text editors, you're
going to have learn skills and concepts that are not directly related to
making organized sound.
if you use a visual language (pd, max etc), you will give up a little
bit of power, but not much. you will have learn quite a lot about the
fundamental concepts of those languages to be really powerful with
them.
i would equate either of those two tasks to learning to use a table saw.
and i say this as someone who lost half of his right thumb on a table
saw :)
what processing does (or so it appears to me) is to strip away some
significant elements of what pd or max offers but in turn makes the
learning curve less steep and high. if thats a good tradeoff for some
people, then rock on processing.
audio on linux doesn't force you to confront device driver HALs, or C++,
or even emacs. however, it does leave those options wide open if you
want to go down that route.
--p
To be honest, this is not an avenue that
interests me individually. I
view these tools as a lot like table saws, routers and jointers: things
with immense power that make a lot of tasks way faster and simpler than
they would otherwise be, but that do not remove the obligation to
develop a set of tool-specific skills. I've never had much interest in
designing table saws for people who don't want to know how to use table
saws, and I personally don't have a lot of interest in designing
software tools for people who don't want to learn how to use them.
Who said anything about not wanting to learn how to use table saws?
This seems a bad analogy to me. NI's plug-ins don't make me a better
musician. I still have to learn how to use them, but I don't have to
know how to code them myself first. That part's already done. I'm more
than willing to learn how to use a table saw, but I really don't feel
like building my own table saw first. Right now, audio on Linux really
does kinda force the latter, in my opinion.
6:58 p.m.
Paul Davis wrote:
if you use a language edited with text files and text
editors, you're
going to have learn skills and concepts that are not directly related to
making organized sound.
if you use a visual language (pd, max etc), you will give up a little
bit of power, but not much. you will have learn quite a lot about the
fundamental concepts of those languages to be really powerful with
them.
i would equate either of those two tasks to learning to use a table saw.
and i say this as someone who lost half of his right thumb on a table
saw :)
You and I are definitely not on the same page. Absynth is not by itself
as powerful as Csound is, but its learning curve is a lot less steep.
What I want to do is make something that makes it easier to create
Absynth, GUI and all.
The confusion seems to be on whether or not Absynth is a table saw, or
something that was made with a table saw, to continue an analogy that
keeps getting worse. Here's my take: making music with Absynth (and the
others in the NI stable) are like using a table saw and a jointer to
make a finished piece. Csound, Pd, and Supercollider are more like hand
tools: they'll get you there, but it'll take longer and require more work.
What I want to do is make a set of hand tools that can be directly used
to make the nice power tools. There are certain features that I insist
on these nice power tools having, though.
I've now officially descended into analogy hell.
what processing does (or so it appears to me) is to
strip away some
significant elements of what pd or max offers but in turn makes the
learning curve less steep and high. if thats a good tradeoff for some
people, then rock on processing.
I would continue to argue that Processing actually limits the domain of
what it's designed to do, rather than "strips away all of the power."
It's designed to be extremely good at a few related things. I see a
subtle but important difference between eliminating capability and
limiting the problem domain.
-- Darren Landrum
7:33 p.m.
On Sun, 2008-09-28 at 16:57 -0400, Darren Landrum wrote:
You and I are definitely not on the same page. Absynth
is not by itself
as powerful as Csound is, but its learning curve is a lot less steep.
What I want to do is make something that makes it easier to create
Absynth, GUI and all.
The confusion seems to be on whether or not Absynth is a table saw, or
something that was made with a table saw, to continue an analogy that
keeps getting worse. Here's my take: making music with Absynth (and the
others in the NI stable) are like using a table saw and a jointer to
make a finished piece. Csound, Pd, and Supercollider are more like hand
tools: they'll get you there, but it'll take longer and require more work.
What I want to do is make a set of hand tools that can be directly used
to make the nice power tools. There are certain features that I insist
on these nice power tools having, though.
Sure, I agree with your analogy. It relates to the way that people have
used CSound, pd and supercollider "traditionally". The people who
developed these tools have used them to *make music*. They don't use
them (generally speaking) to *make tools*.
You want a set of people to develop a tool to make tools. Something a
bit like synthmaker or whatever its called, or the way, as you
mentioned, that max can generate a standalone version of a max patch. Or
like processing. That is, you want guys like us to make 1st order tools
to so that other people (perhaps you) can make 2nd order tools for
"musicians" to use. We've all been busy with either "straight to 2nd
order" (complete apps) or "0th order" (synthesis & processing
languages).
The problem with making that appeal in this particular tech niche is
that most of us in here are kind of happy with making the stuff we do
now. We don't see any huge benefits that arise when people get to use
1st & 2nd order tools. Actually, I'm not sure I see much benefit when
people get to use computers, period. This is like the explosion of
desktop publishing when everybody and their buddy thought they
understood typography, typesetting and graphic design. That gray haired
old dudes has just missed the boat on what new technology could do. And
wow, how utterly wrong they were :)
the thing is that about 40 years ago, the first modular synths started
to appear, and people complained about them in exactly the same way that
people complain about supercollider now. then came the minimoog, which
begat the polymoog and then the prophet 5 and the the DX7 and so forth,
until we got synths that nobody had to know anything whatsoever about
synthesis in order to use. and now things have settled down, and there
is some space for the contemporary equivalents of the DX7, but there is
also understanding of the quintessential values of the modular synth
too. and you're talking to a bunch of people who would probably be happy
building modular synths, let alone actually using them.
I would continue to argue that Processing actually
limits the domain of
what it's designed to do, rather than "strips away all of the power."
It's designed to be extremely good at a few related things. I see a
subtle but important difference between eliminating capability and
limiting the problem domain.
i.e. it was designed by coders that haven't yet learnt the first rule of
software development for others: They Will Want More Than You Offer. if
not today, then the middle of next week. more or less every piece of
software that i've seen that has taken an existing problem/solution pair
and said "we'll simplify the problem domain to make the solution better"
has ultimately regretted it or has later expanded the problem domain
back t its original size :) linux is well on its way :))
wow, this is rich material for my upcoming seminar series (*) :)
--p
(*)
http://www.ak.tu-berlin.de/menue/lehre/wintersemester_200809/building_tools…
8:11 p.m.
On Sun, Sep 28, 2008 at 11:32:41PM +0200, Paul Davis wrote:
Actually, I'm not sure I see much benefit when
people get to use computers, period.
:-)
This is like the explosion of
desktop publishing when everybody and their buddy thought
they understood typography, typesetting and graphic design.
Last week we had some festivities here and people
had to be invited. My boss (windows user) worked
for most of the day on the invitation and still
wasn't satisfied with the result. He came to me
with a printed version and said "This looks ugly
(he was right). When you make a stupid slide with
four lines of text for your presentations it looks
good. Can you redo this ?" And of course I did -
ten minutes work using Latex.
Now is there a relation between the fact that Latex
is a 'hard to use' old style, non-wysiwyg tool and
the fact that it produces much better typesetting
than MS word ? I think there is - even if it may
not be simple to exactly find out why.
the thing is that about 40 years ago, the first
modular synths started
to appear, and people complained about them in exactly the same way that
people complain about supercollider now. then came the minimoog, which
begat the polymoog and then the prophet 5 and the the DX7 and so forth,
until we got synths that nobody had to know anything whatsoever about
synthesis in order to use. and now things have settled down, and there
is some space for the contemporary equivalents of the DX7, but there is
also understanding of the quintessential values of the modular synth
too. and you're talking to a bunch of people who would probably be happy
building modular synths, let alone actually using them.
Plus the simple observation that once we had the synths
that nobody needed to understand whatsoever about, most
synth music, with few exceptions, degraded to junk food
quality levels.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
8:26 p.m.
Fons Adriaensen wrote:
Plus the simple observation that once we had the
synths
that nobody needed to understand whatsoever about, most
synth music, with few exceptions, degraded to junk food
quality levels.
Being good at using a modular synth still didn't require knowing how to
design and solder circuit boards along with understanding the quantum
mechanics of how electrons travel through a semiconductor. Making music
by coding one's own software synths *is* a lot like that, though. I
seriously doubt Paganini ever felt he needed to make his own violin in
order to be a better musician.
I'm not trying to fob this off onto someone else. I would actually like
to start this project myself, even though I'm a lousy coder and my code
will probably look horrible. At this point, though, I fail to see the
point, as it appears I would be completely on my own, and nobody would
care what I come up with. So, I may as well stick to just doing whatever
I can on my own, make my music, and stop caring about how, or whether
anyone else would care how.
You've already basically accused me of not being able to play just
because I want to use software synthesis.
-- Darren
9:12 p.m.
On Sun, Sep 28, 2008 at 06:26:15PM -0400, Darren Landrum wrote:
Fons Adriaensen wrote:
You're mixing up things.
Using an analog modular synth did not require any understanding of
the quantum mechanics of semiconductors. But it did require some
understanding how these things worked, the concept of voltage
control etc.
In a similar way, if you want to write DSP code this requires at
least some understanding of coding in one way or another, be it
graphical, but it does not require any understanding of digital
electronics or chip design.
Paganini even if he did not build the violins he used probably
knew quite a lot of the art of violin building. Just like any
organist knows a lot about organ technology even if he can't
actually build the intstrument - this knowledge is essential
in order to understand his instrument and to use it in a non
trivial way.
Also the years of basically motoric training required to get
any decent sound out of a violin has in se nothing to do with
music. But you still need it.
Plus the simple observation that once we had the
synths
that nobody needed to understand whatsoever about, most
synth music, with few exceptions, degraded to junk food
quality levels.
Being good at using a modular synth still didn't require knowing how to
design and solder circuit boards along with understanding the quantum
mechanics of how electrons travel through a semiconductor. Making music by
coding one's own software synths *is* a lot like that, though. I seriously
doubt Paganini ever felt he needed to make his own violin in order to be a
better musician. You've already basically accused me of not being
able to play just because
I want to use software synthesis.
I've not accused you of anything nor do I want to.
I just made an observation that boils down to this:
the result you get from any artistic activity is related
to the effort you put into learning to do it. Even if you
can get some results without much effort that means that
these results can be obtained by anyone cheaply, and thus
the reference level will shift to what is obtained by those
that *do* put in some effort and get better results. Things
that are easy tend to be irrelevant in the end.
There is also some ambiguity in your arguments. Wanting
to use a software synth is not the same as wanting to be
able to write modules for such a synth. And that is again
quite different from the third level, writing software
that would enable another user to write DSP code in a
simple way.
For the latter you need not only be a coder, you also
need to understand some programming language theory.
Maybe even more of it if the language is graphical.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
8:18 p.m.
Do you mean something like SynthEdit for VST ?
I've never worked with it but understood it were
a kind of plug'n-drag your own synth, without coding skills.
Some comparable apps exist:
Ingen, Alsa Modular Synth, Clam, GAlan, any more ??
If you want to code but have it easy,
there is no all-in-one solution,
because that would restrict developers,
(I know, sometimes it's nice to have no choice ;)
But there are same parts that can be combined to simplify
plugin development:
gui-creation:
gkt:
http://phat.berlios.de/
juce
http://www.rawmaterialsoftware.com/juce/
tools to make tools:
http://linux-sound.org/tools.html
Another hint for simple coding: The SndObj Library::
http://music.nuim.ie//musictec/SndObj/main.html
Good luck with all this,
Emanuel
9:18 p.m.
Sorry for starting this entire argument. I'm just tired of getting
nowhere with all of the same tools that everyone else seems to have no
problem with. I have a very bad habit of putting myself under a great
deal of pressure to exceed everyone's expectations of me.
Look, I know that everything I'm asking for exists on the Linux
platform. The problem is, it doesn't all exist in one place, or under a
single language. I'm convinced at this point that starting over from
scratch with a solid design is preferable to trying to use several
disparate tools and somehow glue them all together.
I've already played around with code here and there to try out some
different approaches to this problem, but nothing that I've bothered
keeping around. Starting tonight, I'm going to draft a very detailed
design, create a code hosting account somewhere (probably Google Code),
and get started. I will keep the list apprised of any progress with
regular emails.
It's been pointed out to me that many people on the list seem to think
that I'm trying to get someone else to code this for me. That is not and
never was my intention, and I apologize for any miscommunication on my
part for that. I am a very slow and not very good coder, though, and it
might take a little while to see any progress.
First things first, though. A solid design.
-- Darren
29 Sep
29 Sep
6:13 a.m.
I want my musical skills to be all I need to be
able to make music on
Linux.
28 Sep
28 Sep
6 p.m.
On Sun, Sep 28, 2008 at 3:30 PM, Darren Landrum
<darren.landrum(a)sbcglobal.net> wrote:
I thought I was clear on this, but I'll restate:
We need this so that
people who are not skilled coders, but have other skills, in math and
physics and electronics perhaps, can bring their skills to bear in
making synths and effects while making the coding side as painless as
possible. The end result will hopefully be synths and effects usable by
*musicians* and not just other coders. Click and play, as it were.
It sounds like you either want FAUST, which is a good way to basically
write down mathematics since it is a functional language, and
generates plugins. Or you want a MATLAB/Octave compiler of some kind.
That would certainly be cool.
Obviously you don't see what you need in the tools that are available
but I think you're having a hard time describing exactly what that is.
Languages like CSound, ChucK and SuperCollider really do allow you to
do a lot of things. On-the-fly programming, per-sample control of
audio, simplified languages specifically targeted to audio. Can you
describe exactly what it is these cannot do? Otherwise you can
always write a plugin for any of these in C.
I want my musical skills to be all I need to be able
to make music on Linux.
Well, making music on computers has always required a certain amount
of technical ability. But there are many paradigms for music-oriented
human-computer interaction: the DAW, the special-purpose programming
language, the sequencer, the MIDI synth, the input-output effect
processing, the artificial intelligence automatic accompaniement, the
score follower, the notation generator. All of these are possible in
one way or another on Linux. You haven't explained better what you
mean by "musical skills" and "make music on Linux", so it's hard
to
answer you more exactly.
That the international community persists in using VSTs and
FruityLoops and Cubase and Logic Audio, I have no idea. Probably the
interfaces are just more simple (definitely not true for Logic Audio),
and the availability of (often pirated) VST synths makes things
attractive. Probably marketing also plays a large roll in this.
Granted certain programs like Ableton Live or Serato have few
counter-parts on Linux.
Perhaps it's because programming O-S software is often oriented
towards scratching an itch. The cross-section people who are both
coders and musicians isn't all that large, so only some of the large
set of possible itches will ever get scratched.
Steve
7:02 p.m.
On Sun, Sep 28, 2008 at 03:30:52PM -0400, Darren Landrum wrote:
I thought I was clear on this, but I'll restate: We need this so that
people who are not skilled coders, but have other skills, in math and
physics and electronics perhaps, can bring their skills to bear in
making synths and effects while making the coding side as painless as
possible.
There is a whole world of difference to
- coding a DSP algo that works given a context
that feeds it one or more sample streams and
absorbs one or more output streams,
and
- making a module that basically just performs
that algo but in a context of making music
with it - e.g. something that can be instantiated
and deleted in real time, that control signals,
reacts to asynchronous events, has well defined
timing, etc. etc.
Given the right framework, for the first you only need
to understand the algo.
The second requires another level of understanding, which
can be a lot more complex than the DSP side, and may
require some coding skills in one form or another.
One of the qualities of tools like Supercollider and
Csound is that they manage to even make the second step
managable to people who are not real coders. They do
that by providing an infrastructure that is a lot more
complex than the one to support just DSP algos, but
you are required to learn how that works, at least on
a functional level.
What we need is a nice and powerful back-end that is
wrapped in an
easy-to-learn front end. The best of both worlds, if it's possible.
[Paul D.] Why do we need this? The end result will hopefully be synths and effects
usable by
*musicians* and not just other coders.
Why would a synth or effect produced by a math or DSP
expert be any more 'usable' than one made by a 'coder' ?
I'd expect the DSP to be better - but there it ends.
A 'coder' has in fact a much better chance of making
something usable than someone who only knows the math
and DSP side of things.
I want my musical skills to be all I need to be able
to make music on Linux.
Why do you expect making music on computers to be easy ?
Normally, to make music, you need not only the skills you
refer to above, but also those to play an instrument.
For traditional instruments that takes years of hard work.
What makes you think it should somehow be easy or automatic
when using a computer ?
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
7:43 p.m.
On Sun, Sep 28, 2008 at 11:16:24PM +0200, Paul Davis wrote:
On Sun, 2008-09-28 at 22:58 +0200, Fons Adriaensen
wrote:
There is *no* relation at all between a demo and
actual user experience. A demo is a prepared
show and in showbizz everything is OK as long
as the show goes on. I've done demos that were
completely fake (not audio, CAD software).
The lack of correlation can work in both
ways: I know at least one very usable and
major Linux audio app that crashed every
five minutes when demoed at one of the
first LACs :-)
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
killall -9 jackd
What makes you think it should somehow be easy or
automatic
when using a computer ?
because a demo by an awesomely cool dude from <insert audio tech company
name here> showed me that it could be?
7:20 p.m.
Fons Adriaensen wrote:
Why do you expect making music on computers to be easy
?
Normally, to make music, you need not only the skills you
refer to above, but also those to play an instrument.
For traditional instruments that takes years of hard work.
What makes you think it should somehow be easy or automatic
when using a computer ?
What the heck?! When I said "musical skills," that is *EXACTLY* what I
meant! By musical skills, I mean the skills of being able to play an
instrument or two, knowing music theory, harmony, singing, and whatever
else that really has little to do with computers.
The point is, back when I messed with this stuff on Windows, it was
amazingly easy for me to bring up a DAW, load a softsynth into it, and
start laying things down on the keys. So far, my experience with Linux
audio has been a lot less satisfying.
On the flip side of the coin, I hate vendor lock-in and forced OS
upgrades even more than I hate having to be patient and learn how to
code. That's why I'm here instead of there.
I *was* enjoying this, right up to now...
-- Darren
29 Sep
29 Sep
1:52 p.m.
On Sunday 28 September 2008 17:19:53 Darren Landrum wrote:
Fons Adriaensen wrote:
If you want to use digital audio well (which is what computers can help you to
do), you need to understand digital audio.
If the computer (or maybe rather computation) becomes your instrument of
choice to make music, you have to understand how it works.
That takes learning too.
I think you have to start seeing computation as another instrument to make
music, and then you'll understand it takes time to develop skill at it.
Why do you expect making music on computers to be
easy ?
Normally, to make music, you need not only the skills you
refer to above, but also those to play an instrument.
For traditional instruments that takes years of hard work.
What makes you think it should somehow be easy or automatic
when using a computer ?
What the heck?! When I said "musical skills," that is *EXACTLY* what I
meant! By musical skills, I mean the skills of being able to play an
instrument or two, knowing music theory, harmony, singing, and whatever
else that really has little to do with computers. The point is, back when I messed with this stuff on
Windows, it was
amazingly easy for me to bring up a DAW, load a softsynth into it, and
start laying things down on the keys. So far, my experience with Linux
audio has been a lot less satisfying.
I don't know... it has become fairly easy over the last few years to install
an audio targeted Linux distribution and fire up a DAW, fire up some soft
synths, connect them through JACK and start playing around.
How does this not work for you?
Reading your arguments in the threads of this discussion, you seem to want two
opposite things, which is confusing I find.
I think you'd do well, trying out a bunch of different programs that get close
to what you are looking for, and then maybe look if there is a possibility to
extend them to what you want to have.
Starting something from scratch, will get you on a long development path, on
which all these other programs have already been... So unless you have a
really radically different new approach to audio DSP programming
environments, please start designing something new... but to know whether
your idea is really radically new, you have to look in depth at the existing
ideas...
sincerely,
Marije
2:22 p.m.
2008/9/29 nescivi <nescivi(a)gmail.com>om>:
If the computer (or maybe rather computation) becomes
your instrument of
choice to make music, you have to understand how it works.
That takes learning too.
The question here is: what to learn?
I would not expect a musican to learn programming
in order to record audio nor a synth-sound developer
to learn dsp coding technics.
There are different layers of complexity and approaches
and maybe Darren is right, that
the complexity is not enough "hidden",
I mean in the background of the task to accomplish,
in linux, so that "easier" tasks can soon
become confusing, or flood the banks,
by introducing different technics and requiring
in-depth knowledge.
For example:
If I wanted to write a
synth plugin, I would not expect in
the first place, to worry about things
as realtime privilegs, threads, realtime memory allocation,
server-client handling & communication,
double-buffering, image-rendering etc...
Unless I wanted to do something completely new,
I would hope, to have predefined known working
solutions for most of these requirements.
To have them simplified as much as possible by
a host application, because
otherwise everyone would
have to think about it again and again...
instead, I'd prefere to concentrate on
the actual task.
Maybe LV2 etc. have not gone far enough, in this sence.
My 2 €-Cent,
Emanuel
3:48 p.m.
On Mon, 2008-09-29 at 18:22 +0200, Emanuel Rumpf wrote:
For example:
If I wanted to write a
synth plugin, I would not expect in
the first place, to worry about things
as realtime privilegs, threads, realtime memory allocation,
server-client handling & communication,
double-buffering, image-rendering etc...
yet thousands of VST plugins have been written where people had to worry
about precisely these issues, and a veritable industry has grown up
around it.
does VST address darren's desires? no, it doesn't. but keep in mind that
as time keeps ticking by, what used to be entirely acceptable "barriers
to entry" turn into problems that people want to solve.
--p
4:17 p.m.
Hallo,
Emanuel Rumpf hat gesagt: // Emanuel Rumpf wrote:
2008/9/29 nescivi <nescivi(a)gmail.com>om>:
If we're talking about a "Processing" for audio, then programming is
exactly what the users of such a tool want to learn. They just like
their programming to be less of a chore, i.e. they want Python or Lua
instead of C++ and maybe blocks and patchcords instead of vi/Emacs.
_From my experience with giving some workshops in this area I believe
that a growing number of artists is looking for software that allows
them to build their own specific tools. They are not frightend to learn
certain algorithms and how to deal with technical issues as long as
these issues are "art related". They actually like thinking about things
like DSP algorithms for sound and video, but they don't want to think
about device drivers and freeing memory (too much).
Ciao
--
Frank
If the computer (or maybe rather computation)
becomes your instrument of
choice to make music, you have to understand how it works.
That takes learning too.
The question here is: what to learn?
I would not expect a musican to learn programming
in order to record audio nor a synth-sound developer
to learn dsp coding technics.
4 Oct
4 Oct
12:35 a.m.
Sorry I've been away. I've been catching up on homework and trying to
put a preliminary design together. I should probably let this thread
die, but no doubt this subject will just come up again anyway.
Frank Barknecht wrote:
_From my experience with giving some workshops in this
area I believe
that a growing number of artists is looking for software that allows
them to build their own specific tools. They are not frightend to learn
certain algorithms and how to deal with technical issues as long as
these issues are "art related". They actually like thinking about things
like DSP algorithms for sound and video, but they don't want to think
about device drivers and freeing memory (too much).
I think this gets to the heart of the matter quite nicely. The goal is a
system where the programming is focused on the processing and the
synthesis, but a language that actually compiles to standalone
applications. Though I'm not aiming for it to be cross-platform (I don't
have the tools on any other platforms), I don't see why it couldn't be
made so.
At this point, I want to lay out the complete design, then decide what I
want to finish for the 0.1 release and get to work on it.
-- Darren
28 Sep
28 Sep
5:20 p.m.
On Sun, Sep 28, 2008 at 11:43 AM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sun, 2008-09-28 at 12:08 -0400, Darren Landrum
wrote:
I was skeptical to see the claim that csound "cannot do oversampling"
(not because of some knowledge of oversampling, but rather past
experience with a) how comprehensively synthesis techniques are
represented in csound and b) how easy it is to prototype synthesis
techniques directly in csound). There is an article on csound journal
http://www.csounds.com/journal/issue6/BandLimiting.html describing the
hows and whys of oversampling, and it uses pd rather than csound in
most of the examples(!). This should be informative because not only
does it show how to make a butterworth filter in pd from scratch, but
it gives a good explanation of what oversampling aims at, and how to
implement it in just about any computerized audio processing
environment.
Did I misunderstand what I have found about oversampling, or is it
just another name or special case for bandlimiting of arbitrary
signals?
Why couldn't we make something like that for audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me.
SKINI, Chuck, Faust and CSound/SuperCollider spring to mind.
Throw in some
GUI-building elements (Cairo-based, perhaps) that can handle
mouse-clicks, keyboard input, and the like,
oops ...
Processing has wrapped a language with a lot *less* power than
SuperCollider in a front end that is much easier to learn. Its a shame.
But it also seems to be way the world works.
--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
6:25 p.m.
On Sunday 28 September 2008, Darren Landrum wrote:
Why couldn't we make something like that for
audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me. Throw in some
GUI-building elements (Cairo-based, perhaps) that can handle
mouse-clicks, keyboard input, and the like, then suddenly people who are
good at math and DSP but not so good at coding might have a shot at
making some great programs.
It is in no way finished, but it's a similar idea:
http://tapas.affenbande.org/wordpress/?page_id=91
The webpage says: "ProcessPP is the realisation of a rather silly idea: A
livecoding environment for C++." As its author i can truly admit that this is
a wrong statement (i should fix it). It is not yet the realisation, but it's
an attempt in this direction in its earliest stages. So nothing is decided
really yet..
What it is right now is basically this:
- Hack some code for a process() function for a jack client.
- Hit "Run"
- Hear noise..
You can have several of these functions.. I was planning next to integrate
some midi. So you can write a process_voice function that is called whenever
a note needs to be played. I'm not totally sure yet on how to do this though
that
a] it's flexible
b] it's still easy :)
I just wanted to mention it... Even as unfinished as it is..
:)
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
5924
days inactive
5929
days old
linux-audio-dev@lists.linuxaudio.org
35 comments
11 participants
participants (11)
-
AlgoMantra -
Darren Landrum -
Emanuel Rumpf -
Florian Schmidt -
Fons Adriaensen -
Frank Barknecht -
Justin Smith -
Mr.SpOOn -
nescivi -
Paul Davis -
Stephen Sinclair