Nabble - Music-DSP

Re: Lumped modeling and WDFs

2008-10-02T14:04:33Z

Martin Eisenberg wrote:
> And that's true. For instance, a simple RC filter would become a
> 3-port series adaptor with R, C, and source terminating the
> ports. Each time step you'd then read all 1-ports' outputs (which
> depend only on older inputs), feed those to the adaptor network,
> update the 1-ports with the adaptor outputs, and finally get the
> output quantity from both terminal values of the C (or R, as the
> case may be).

That paragraph has actually helped me a lot more than all of the papers
I have found thus far. Thank you.

> Before my first reply I too failed to google up any source. Where
> is that example?

I honestly can't remember. I thought I had saved it but I can't find it
now. However, based upon your first paragraph in this email, I now know
how I was reading it wrong.

> It's nothing too arcane -- if you use only 3-port adaptors and
> let the whole structure "dangle" from any one of the 1-ports, you
> have a binary tree. BCT is about leveraging that fact in
> implementing the computation sequence I described above.

I also got pointed to another DAFX paper on the subject, so hopefully
that will clear things up for me.

Thank you very much for the reply. You've been very helpful in clearing
this up.

Regards,
Darren Landrum

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Lumped modeling and WDFs

2008-10-02T08:41:48Z

From: "Darren Landrum" <darren.landrum@...>

> I guess one of the problems I'm having is conceptual. At first,
> I was under the impression that the inductors, capacitors, and
> resistors were separate components from the port adapters,
> and that a "circuit" went together by putting the port adapters
> in-between the electronic pieces.

And that's true. For instance, a simple RC filter would become a
3-port series adaptor with R, C, and source terminating the
ports. Each time step you'd then read all 1-ports' outputs (which
depend only on older inputs), feed those to the adaptor network,
update the 1-ports with the adaptor outputs, and finally get the
output quantity from both terminal values of the C (or R, as the
case may be).

(Please note that my earlier integrator example is actually wrong
because reading and writing occur separately.)

For larger circuits, while we can implement an N-port adaptor as
a single block in our network, it's convenient to use a chain of
3-ports. That is computable because each internal connection
involves one adapted port. In the above sequence, these adapted
ports are treated along with the 1-ports -- read first, written
last.

So from a bird's view the adaptors encode circuit topology and
the terminating 1-ports endow it with dynamics. (Let's leave
scattering junctions aside for now.)

> However, based on some stuff I've managed to find on the
> web, it appears that the network of components for a part of
> a circuit would actually go inside of an N-port adapter,
> depending on the number of ports needed.

Before my first reply I too failed to google up any source. Where
is that example?

> Another confusing bit is the Binary Connection Tree, a term
> that Google turned up nothing on other than references to
> various DSP papers.

It's nothing too arcane -- if you use only 3-port adaptors and
let the whole structure "dangle" from any one of the 1-ports, you
have a binary tree. BCT is about leveraging that fact in
implementing the computation sequence I described above.

Martin

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Lumped modeling and WDFs

2008-10-01T13:36:19Z

Martin Eisenberg wrote:
> Is realizing the more complex adaptors your problem? With a
> little practice you can read the code directly from a block
> diagram. Do you understand this link in simple cases, e.g. the
> common 2nd-order IIR? Or are you wondering how to join all those
> blocks into a running system? Perhaps you can point out a
> specific block or circuit that you have trouble handling.

I guess one of the problems I'm having is conceptual. At first, I was
under the impression that the inductors, capacitors, and resistors were
separate components from the port adapters, and that a "circuit" went
together by putting the port adapters in-between the electronic pieces.
However, based on some stuff I've managed to find on the web, it appears
that the network of components for a part of a circuit would actually go
inside of an N-port adapter, depending on the number of ports needed.

Unfortunately, nothing is very clear on how this works. The math that
describes the I/C/R components is presented, the math describing the
port adapters is presented, but I'm having difficulty figuring out how
to use it all together.

Perhaps some of my confusion will be alleviated (or added to) if I just
started trying to build some of these pieces in Faust and see what happens.

Another confusing bit is the Binary Connection Tree, a term that Google
turned up nothing on other than references to various DSP papers.
Several comp-sci friends of mine were also unable to tell me what that
might mean.

Thank you very much for your reply.

Regards,
Darren Landrum
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[admin] music-dsp FAQ

2008-09-30T21:00:00Z

Hi,

Just a reminder that if you are new to the list you should read the
music-dsp FAQ. It contains answers to both technical _and_
adminstrative questions that often come up on the list. If your question
appears in the FAQ it is safe to assume that it has been discussed on the
list many times in the past, and you should probably have a look through
the list archives before posting your question to the list.

http://music.columbia.edu/cmc/music-dsp/musicdspFAQ.html

Also of interest to new and not-so-new list members:

The music-dsp list archives
http://music.columbia.edu/cmc/music-dsp/musicdsparchives.html

The music-dsp source code archive
http://www.musicdsp.org

music-dsp books and reviews
http://music.columbia.edu/cmc/music-dsp/dspbooks.html

All this and more at:
http://music.columbia.edu/cmc/music-dsp

Hasta la pasta,
douglas

(this is an automated message sent out on the 1st and 15th of each month)
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Minimum-phase clarifications

2008-09-29T13:58:52Z

From: "Blargg" <gblargg@...>

> Do either of these two links describe methods of generating
> a kernel to feed to the minimum-phase transform, that will
> result on lots of zero/near-zero values at the end? I've had
> trouble understanding them, so I just want to be sure they
> are going to help.
>
> http://www.dspguru.com/howto/tech/minph2.htm
> (the Homomorphic approach)

Except the first, I think all methods on that page rely on the
same ripple positivity constraint. Why the mentioned ripple
adjustment should enforce this constraint I can't say from the
top of my head.

> http://users.ece.utexas.edu/~bevans/papers/2000/minPhase/
>
> I've seen some mention of keeping the stopband ripple
> "positive" helping, but I don't know how it could be negative
> in the first place.

A complex spectrum H(w) may cross the frequency axis, as opposed
to just touching or winding around it. Typically the curve is
straight around the crossing so that the magnitude spectrum |H|
has a kink touching down on the axis, as you've probably often
seen. Negating any lobe between two such crossings to make a
smooth function leads to the so-called zero-phase response.
Negative ripple in a filter means that its zero-phase response is
less than the desired response, a definition that works in any
band.

Why does this matter to us? All the design methods in question
start from a prototype filter whose magnitude is supposed to
equal the *squared* magnitude of the minimum-phase result. But
for that to be possible the prototype magnitude must be smooth --
equivalently, the zero-phase response must be nonnegative.
In your second reference this is ensured in the simplest possible
way, by adding the negative extreme value (and scaling to keep
the passband at nominal gain).

> The second link's method has a first step of doing some kind
> of adjustment to the kernel before making the minimum-phase
> version, but I couldn't make sense of the realdemo.m code.

In the demo code H is the prototype linear-phase spectrum, H1 is
the zero-phase spectrum of H, and HR is the positivized target
magnitude spectrum. As far as I see, the only difference between
code and paper is that the paper assumes you can design prototype
filters to given ripple specifications whereas the code reads off
the ripple values from the given example filter, presumably to be
self-contained.

> Some descriptions talk about poles and zeroes, but I still
> haven't found any code that calculates the poles and zeroes of
> an arbitrary impulse response.

Finding the zeros of an FIR is simple in principle; apply a
root-finder to the polynomial that is the transfer function H(z).
There is standard software for that, though not all codes handle
high degrees (long IRs) well. Best ask for recommendations in
newsgroup sci.math.num-analysis if you want to play with
factoring.

Martin

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Lumped modeling and WDFs

2008-09-29T11:00:59Z

From: "Darren Landrum" <darren.landrum@...>

> I've been trying to track down information about lumped
modeling
> and wave digital filters (WDFs) as a possible method of circuit
> modeling. I found Dr. Julius Smith's textbook on the subject,
and
> I've tracked down some papers here and there. However, even
> though my math is strong, my programming skills could really
> use some help, and I was hoping I might find some examples of
> how the different components (dashpots, springs, masses, and
> ports) might actually get implemented in a programming
> language.

Well, here's a bare-bones inductor (not sure which is the
mechanical analog) in C++:

class Inductor {
float state_;
public:
Inductor() { clear(); }
void clear() { state_ = 0; }
float tick(float in) {
float oldState = state_; state_ = in; return -oldState;
}
};

Is realizing the more complex adaptors your problem? With a
little practice you can read the code directly from a block
diagram. Do you understand this link in simple cases, e.g. the
common 2nd-order IIR? Or are you wondering how to join all those
blocks into a running system? Perhaps you can point out a
specific block or circuit that you have trouble handling.

Martin

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: FAUST and Csound (was Re: programming languages for real-time audio)

2008-09-25T06:21:48Z

I'd definitely like to see this; using faust-built units as
benchmarking test cases is a nice thought. All sorts of caveats of
course (as usual with benchmarks) but it'd be great to have such
music-dsp-specific benchmark data available.

Dan

2008/9/19 victor <Victor.Lazzarini@...>:

> I had some chats with Yann (we keep bumping into each other at various
> conferences) about doing exactly this. I think it is a great idea (and
> possibly
> the only output FAUST does not have at this stage).
>
> One thing this might enable is to benchmark music languages (Csound vs.
> PD vs. SC3), which is something worth doing once and for all (I can see
> a paper in this...)
>
> Victor
>
> ----- Original Message ----- From: "Michael Gogins" <gogins@...>
> To: "A discussion list for music-related DSP" <music-dsp@...>
> Sent: Friday, September 19, 2008 9:22 PM
> Subject: Re: [music-dsp] programming languages for real-time audio
>
>
>> I have considered making a generator so Faust code will compile into
>> plugin Csound opcodes.
>
> --
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>

--
http://www.mcld.co.uk
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Lumped modeling and WDFs

2008-09-24T15:22:44Z

Hello, all.

I've been trying to track down information about lumped modeling and
wave digital filters (WDFs) as a possible method of circuit modeling. I
found Dr. Julius Smith's textbook on the subject, and I've tracked down
some papers here and there. However, even though my math is strong, my
programming skills could really use some help, and I was hoping I might
find some examples of how the different components (dashpots, springs,
masses, and ports) might actually get implemented in a programming language.

I looked through the Music-DSP archives, and I couldn't find anything.
I've found papers that describe the math, but not how to use the math.
If anyone out there has any links or pointers, I would greatly
appreciate it.

Thank you all for your time.

Regards,
Darren Landrum
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Minimum-phase clarifications

2008-09-24T13:46:12Z

I want to clarify my understanding of the minimum-phase transform. The
two main uses I understand it to have for digital audio are:

1) alter the time-domain response so that most of the energy is at the
front, and

2) reduce the number of taps in the filter kernel, to reduce
computation requirements without affecting how well it filters.

I'd like to focus on #2, the performance aspect. If one doesn't need a
linear phase response, there are more possible sets of coefficients
for the FIR that meet one's magnitude requirements, many of which
aren't linear-phase. Some of these sets have fewer non-zero
coefficients at the beginning and/or end, allowing fewer taps and thus
less computation in some applications.

Apparently one way of arriving at a shorter kernel is to generate the
kernel, then make the minimum-phase version of it and chop off the
(near) zeroes at the end. Based on some readings, the method used to
generate the starting kernel is critical in determining how well it
shortens.

Do I have things correct so far? I've not made much progress in
understanding how to generate optimal input kernels. I've implemented
the minimum-phase transform code and fed it several kernels, and I do
seem some shortening (particularly with a sinc windowed by a kaiser
with beta=9), but I get the idea there must be some way of generating
a more optimal input kernel that "bunches up" better with the
minimum-phase transform.

Do either of these two links describe methods of generating a kernel
to feed to the minimum-phase transform, that will result on lots of
zero/near-zero values at the end? I've had trouble understanding them,
so I just want to be sure they are going to help.

http://www.dspguru.com/howto/tech/minph2.htm (the Homomorphic approach)

http://users.ece.utexas.edu/~bevans/papers/2000/minPhase/

I've seen some mention of keeping the stopband ripple "positive"
helping, but I don't know how it could be negative in the first place.
The second link's method has a first step of doing some kind of
adjustment to the kernel before making the minimum-phase version, but
I couldn't make sense of the realdemo.m code. Some descriptions talk
about poles and zeroes, but I still haven't found any code that
calculates the poles and zeroes of an arbitrary impulse response.
Without code to help me visualize them, I can't make much sense of
them and how to adjust them.

If possible, I'd like to end up with an approach that works just as
simply as a windowed sinc or the "remez" method, where I specify the
basic parameters and get a shorter non-linear kernel than the linear
one would have been.

Thanks for any help. I've got more questions to follow, just want to
set the context first.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T10:14:14Z

The shootout does specify the implementation of the language. In the past, I recall seeing some shootouts with different implementations of the same language.

Of course, you are quite correct that the only truly valid benchmark involves performing the exact same task -- take these inputs, give me those outputs -- in the relevant languages.

With respect to software synthesis, I have done just that with all C++, all Java, Lua/C++, Python/C++, and Python/Csound implementations.

The inputs were a sequence of notes generated by the logistic equation, and the outputs were soundfiles synthesized with a simple frequency modulation instrument. The all C++ implementation was faster than the Python/Csound implementation by about one percent, and 3 times faster than the all Java implementation; the others were slightly slower than the all Java.

The Java test was done some years ago, and the results might be different today. All of these tests computed the audio signal one sample frame at a time. Normally, software synthesizers compute blocks of sample frames in each iteration of the inner loops. When Csound is used in this way, it is about 3 times faster than with 1 frame at a time. I would expect a similar speedup if I coded the all C++ and all Java synthesizers this way as well. This block efficiency thing may also be changing, since it depends mostly on how much code and data is hanging around in the fastest cache.

Regards,
Mike

-----Original Message-----

>From: David Cournapeau <cournape@...>
>Sent: Sep 23, 2008 9:25 AM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Tue, Sep 23, 2008 at 9:59 PM, Michael Gogins <gogins@...> wrote:
>>
>> The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.
>
>I guess I did not formulate my email correctly, because this was the
>point I thought I was making :) I think the language shootout is not
>adapted for this, because it is too coarse-grained. The language
>shoutout is nice if you want to know the order of magnitude of the
>languages, but it is not precise enough for anything more
>fine-grained. Typically, would you choose java instead of fortran for
>high performance linear algebra ? I believe a better comparison would
>be some basic dsp implemented with a good C compiler and in ocaml.
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T06:25:49Z

On Tue, Sep 23, 2008 at 9:59 PM, Michael Gogins <gogins@...> wrote:
>
> The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.

I guess I did not formulate my email correctly, because this was the
point I thought I was making :) I think the language shootout is not
adapted for this, because it is too coarse-grained. The language
shoutout is nice if you want to know the order of magnitude of the
languages, but it is not precise enough for anything more
fine-grained. Typically, would you choose java instead of fortran for
high performance linear algebra ? I believe a better comparison would
be some basic dsp implemented with a good C compiler and in ocaml.

cheers,

David
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T05:59:57Z

Software is not written in an abstract language, but in a concrete language. In practice, for critical software, the fastest implementation of the language is always used. So, these differences ARE significant.

The meaningful distinction then, is between the fastest implementation of one language, and the fastest implementation of another language.

Regards,
Mike

-----Original Message-----

>From: David Cournapeau <cournape@...>
>Sent: Sep 23, 2008 8:23 AM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Tue, Sep 23, 2008 at 8:49 PM, Michael Gogins <gogins@...> wrote:
>> Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical.
>>
>> Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth.
>>
>
>Sure, I am well aware of that. But I never said 15 % did not matter. I
>was saying that if you have a "variance" of 200 % for speed between
>two implementations of the same language (and that's certainly true
>for C/C++ considering the compiler as an implementation of the
>language), a difference of 100 % between two languages is not
>meaningful. This is all the more true if you need to squeeze a few %
>of performances
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T05:23:58Z

On Tue, Sep 23, 2008 at 8:49 PM, Michael Gogins <gogins@...> wrote:
> Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical.
>
> Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth.
>

Sure, I am well aware of that. But I never said 15 % did not matter. I
was saying that if you have a "variance" of 200 % for speed between
two implementations of the same language (and that's certainly true
for C/C++ considering the compiler as an implementation of the
language), a difference of 100 % between two languages is not
meaningful. This is all the more true if you need to squeeze a few %
of performances

cheers,

David
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T05:09:51Z

> "If it's not 15% faster, I can't use it." This is the literal,
unexaggerated truth.

15%? Sometimes it's a question of 1%!

> I would say that being 2x slower (or faster) is not statistically significant

I normally code in assembler, as C is generally 3x slower. It's OK for
background routines (calculating filter coefficients, for example), but
for time critical stuff only assembler will do. And yes, I already use
the fastest DSPs the manufacturers provide, so changing chips is not an
option.

Tom

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T04:49:14Z

Csound and other software are not written only for you, they are written for a community of users. In my experience with trading systems, Csound, and other software, there are ALWAYS users for whom even a 15% performance difference is critical.

Critical as in, "If it's not 15% faster, I can't use it." This is the literal, unexaggerated truth.

My salary -- and the profits of my employer -- depends on it. It's also the reason why there is still a "float" version of Csound.

Regards,
Mike

-----Original Message-----

>From: David Cournapeau <cournape@...>
>Sent: Sep 23, 2008 3:41 AM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>On Sat, Sep 20, 2008 at 5:22 AM, Michael Gogins <gogins@...> wrote:
>> Yes, I have examined OCaml and I have played with Faust.
>>
>> Faust may conceivably be useful to some persons. For most people, I think it would be just about as easy to write code using a class library such as the STK. However, I hope that Faust continues to be developed because (a) the code may be easier to read for signal processing tasks, and (c) once written the code may automatically be built into various kinds of plugins.
>>
>> I have considered making a generator so Faust code will compile into plugin Csound opcodes.
>>
>> OCaml as benchmarked with other functional languages compared with C++: slower. See this from http://shootout.alioth.debian.org/u32/benchmark.php?test=all〈=all:
>
>I don't want to go into 'benchmark are meaningless' meme, but I have a
>hard time believing a factor 2-3 mean anything. I mean with the same C
>code/same compiler, you can easily get this factor by running on
>slightly different CPU, specially for floating point, or by slightly
>different compiler options (see for example how ATLAS performances are
>changed by some tiny-looking changes in some options/micro-revision
>changes); you can certainly lose/gain such a factor using a different
>compiler. IOW, I would say that being 2x slower (or faster) is not
>statistically significant.
>
>I am not saying that OCAML is not slower than C++ for dsp (I have no
>idea - I would guess that for real-time, the gc may be a problem), but
>if speed was a criteria, I would not base my judgement on those
>benchmarks.
>
>cheers,
>
>David
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T01:30:26Z

David Cournapeau wrote:

> On Sun, Sep 21, 2008 at 4:39 PM, Erik de Castro Lopo
> <mdsp-erikd@...> wrote:
> >
> > It is not in my opinion a good language for real-time DSP, so I
> > tend to use C for that instead.
>
> We want more :) Did you write anything about your findings on the
> limitations of ocaml for real-time dsp ?

I didn't write anything, but it basically comes down to insufficient
control of the garbage collector.

The other thing is that DSP programming is mainly imperative programming
and although you can do imperative programming in Ocaml, C is a better
imperative language than Ocaml.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Question #70427: Sitting beside women on public transport because
one is forced to
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=70427&dgn=4
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T00:50:59Z

On Sun, Sep 21, 2008 at 4:39 PM, Erik de Castro Lopo
<mdsp-erikd@...> wrote:
>
> It is not in my opinion a good language for real-time DSP, so I
> tend to use C for that instead.

We want more :) Did you write anything about your findings on the
limitations of ocaml for real-time dsp ?

>
> Faust does look interesting.
>

It does. I wondered if this could be applicable to numerical computing
too (they mention matrix/vector as a future direction in some of their
online slides). I think it is a much better alternative to C++
meta-programming for efficient code generation,

cheers,

David
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-23T00:41:00Z

On Sat, Sep 20, 2008 at 5:22 AM, Michael Gogins <gogins@...> wrote:
> Yes, I have examined OCaml and I have played with Faust.
>
> Faust may conceivably be useful to some persons. For most people, I think it would be just about as easy to write code using a class library such as the STK. However, I hope that Faust continues to be developed because (a) the code may be easier to read for signal processing tasks, and (c) once written the code may automatically be built into various kinds of plugins.
>
> I have considered making a generator so Faust code will compile into plugin Csound opcodes.
>
> OCaml as benchmarked with other functional languages compared with C++: slower. See this from http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all:

I don't want to go into 'benchmark are meaningless' meme, but I have a
hard time believing a factor 2-3 mean anything. I mean with the same C
code/same compiler, you can easily get this factor by running on
slightly different CPU, specially for floating point, or by slightly
different compiler options (see for example how ATLAS performances are
changed by some tiny-looking changes in some options/micro-revision
changes); you can certainly lose/gain such a factor using a different
compiler. IOW, I would say that being 2x slower (or faster) is not
statistically significant.

I am not saying that OCAML is not slower than C++ for dsp (I have no
idea - I would guess that for real-time, the gc may be a problem), but
if speed was a criteria, I would not base my judgement on those
benchmarks.

cheers,

David
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

java sound, without hardware device

2008-09-23T00:05:08Z

Hello,

I have some code I've written based on the Java Sound API that takes
multiple sound clips, and mixes them together in an interesting way
and plays the result. I am now trying to run this in a server
environment, where the resulting mix will be recorded to a file
instead of played to line out.

However the server I am trying to run this on does not appear to have
any audio devices installed, and I seem to be running into roadblocks
with Java Sound not being able to allocate any lines if there is not a
Mixer that supports it. (And with no hardware devices I'm getting no
Mixers.)

Does anyone know if this is possible?

Any info would be appreciated -

thanks!
Rory
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-21T00:39:39Z

Darren Landrum wrote:

> Has anyone taken a close look at Ocaml for real-time DSP?

I have. I love Ocaml as a general purpose langauge and as language for
technical computing and as a language for off line DSP.

It is not in my opinion a good language for real-time DSP, so I
tend to use C for that instead.

> By the way, here's the link to Faust, just in case:
>
> http://faust.grame.fr/index.php
>
> I don't recall if it got mentioned yet. It's a functional language for
> DSP that compiled to efficient C/C++ code.

Faust does look interesting.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I'll just say that having programmed in Lisp the shortcomings
of Java are glaringly obvious." -- Erann Gat
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Re: programming languages for real-time audio

2008-09-20T19:03:20Z

On Sat, Sep 20, 2008 at 10:27 AM, Michael Gogins <gogins@...> wrote:
> For a composer, or a researcher, or somebody programming for their own
> purposes, programming ease might well much more important.

It's not just "programming ease", though. I mean, I don't find C or
C++ particularly "hard", per se. But when writing an application it's
often just better to use a dynamic language, hence people's interest
in Python-like environments lately. Then, when you go to do the audio
engine, having to re-write all the data structures in C just to meet
real-time needs seems kind of annoying and even limiting. Equally,
restricting yourself to C in the first place to avoid this problem,
just because you know your application will have an audio output, also
feels limiting.

It's not just "ease", it's convenience, and making better use of both
your time and your mental resources. My solution is usually to do the
complex parts of the application and then control an audio thread in C
using the barest parameter space, trying hard to replicate code as
little as possible. But it'd be nice to just do the audio in the
language of choice, period. With JIT compilers getting better and
better these days, I was wondering if it's getting to the point where
it's possible to do this now.

I think that one day when I have time I'm going to write simple
RtAudio bindings for one of these new JavaScript engines that claim to
be almost as fast as... well.. Java maybe, and just see how much raw
audio processing I can do. And many articles on these new engines
claim to still have room for improvement, so things will only be
getting better I think.

Steve
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Re: programming languages for real-time audio

2008-09-20T11:05:14Z

On Sep 20, 2008, at 2:54 AM, Tim Blechmann wrote:

> On Fri, 2008-09-19 at 21:02 -0700, Graham Wakefield wrote:
>>> Tim Blechmann:
>>>>
>>>
>>> Have you looked at Vessel? It seems very nice and a quick
>>> way to test lua's realtimeness.
>>
>> Yes, I can speak from experience that it performs very well indeed;
>> very low jitter. This was one of the most attractive features of Lua
>> for me, when I first chose to use it.
>
> i hadn't heard of vessel before ... i was just skimming through your
> master thesis, thought ... seems interesting ...
> but i'm curious, did you do any analysis of the worst-case response
> times of the lua interpreter, when running in a real-time thread?
> like,
> is entering/leaving the interpreter lock-free?

Well, standard Lua is entirely single-threaded. The code is very
lean, I gave up worrying about the overhead. Most of the time seems
to be spent in variable lookups. You can extend Lua for multi-
threading with locks, but it doesn't make much sense to do so (can
send refs if you need). There are extensions to Lua for spawning jobs
into secondary threads, such as LuaLanes.

Like most of the other projects that have been discussed, I'm still
using C/C++ for the actual DSP, but Lua for the management,
allocation etc. of the graph nodes, along with timing and everything
else. I wouldn't use Lua to do actual DSP as such except for
prototyping, though apparently the v2 (release early next year?) of
LuaJIT is approaching speeds approaching C... might be worth keeping
an eye on. LuaJIT 1.0 is already pretty fast!

>
>> Also, the allocator used by Lua can be very easily replaced: http://
>> www.lua.org/manual/5.1/manual.html#lua_Alloc
>> For my work I used dlmalloc as a drop-in replacement, which performed
>> very well. It's on my todo list to compare this with TLSF and of
>> course the rollendurchmesserzeitsammler.
>
> unfortunately tlsf is just a single-threaded allocator ...
> therefore it
> is not usable, where the allocator needs to be accessed from multiple
> real-time threads ... well, for most computer music systems, that
> may be
> the case, but we're living in 2008, where most of the personal
> computers
> provide multiple processors ...

If anything, I would expect that in the future we might be looking at
smaller granularity of threading, data-parallel and task-parallel
etc, so I'm keeping tabs on the potential of these kinds of
developments instead (Intel Building Blocks, OpenCL, etc). Figuring
out the real-time safe, low latency ways to do this (including
allocation) is on my plate over the coming year.

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Re: programming languages for real-time audio

2008-09-20T07:27:49Z

>Michael Gogins:
>>
>> Of course, like so many of these research languages, ATS code is
>> compiled to C code before it is compiled to machine language... so even
>> if you like the language you still have to have a C development system...
>> if you have to have a C development system anyway, why not write
>> somewhat faster code in C++ with an existing rich signal processing library?
>>
>
>It's hard to manually do the kind of optimization performed by
>whole-program optimizers such as faust, mlton or stalin.
>Have you looked at the output of those compilers? That's pretty
>extreme stuff.

> Kjetil:

>Anyway, hearing your arguments, it reminds me of old assembler vs. C
>disussions. The simple truth is that developing in a higher level
>language simply is faster, and it frees up your brain to concentrate
>on the algorithms instead of gory low-level details. You can
>try out things more quickly, and if you think you can make
>your stuff run faster if developed directly in C or assember
>later on, you are free to do so.

I agree -- in principle, and in practice. That is, in some contexts I agree
in practice. I find Python productive compared to C++, for example. (Though
the margin is not as huge as I thought it might be. I use both Python and C++
both in my day job and in composing music, so I think factors of learning
curve and knowledge of the languages have pretty much evened out by now.)

I think the question whether programming ease and clarity
makes an effective difference will vary by
person, so it boils down to which objective is more important. C/C++ rules in
this field because for most of the people producing software for other people
to use, final performance is the overriding objective.

For a composer, or a researcher, or somebody programming for their own
purposes, programming ease might well much more important.

Regards,
Mike

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-20T04:22:01Z

Tim Blechmann:

> > Also, the allocator used by Lua can be very easily replaced: http://
> > www.lua.org/manual/5.1/manual.html#lua_Alloc
> > For my work I used dlmalloc as a drop-in replacement, which performed
> > very well. It's on my todo list to compare this with TLSF and of
> > course the rollendurchmesserzeitsammler.
>
> unfortunately tlsf is just a single-threaded allocator ... therefore it
> is not usable, where the allocator needs to be accessed from multiple
> real-time threads ... well, for most computer music systems, that may be
> the case, but we're living in 2008, where most of the personal computers
> provide multiple processors ...

Don't you have to do extermely frequent allocations for this to matter?
I mean, that the TLSF allocator uses mutexes instead of lock-free
teqniques for supporting multiple threads.

Since allocating memory happens relatively seldom, plus that TLSF
only uses about 180 instructions for allocating and freeing,
I don't really think this should make a difference
since the mutex will hardly be used anyway.

> i am not sure about rollendurchmesserzeitsammler, but the last time i
> checked, it was relying on tlsf ... kjetil, do you know how rdmzs would
> perform with multiple real-time threads?

rollendurch is tuned to work with snd-rt, which is single threaded (for
now), so it doesn't support multithreaded access. But it's not very hard
to support.

rollendurch has two memory allocators, which must be configured
at compile time to select which allocator to use: TLSF and
a (very naive) custom-made pool-based allocator.

For TLSF, as mentioned, you must use a mutex around alloc() and free(),
but for the pool-based allocator, it's relatively trivial
to add true multi-threading support just by using
atomic_add and lock-free fifo queues. (see algorithm below)

The pool-based allocator is, as I said, very naive, so it
can't really be used in general. It probably works okay for
about 99% (or more) of normal music algorithm use, but it
wastes an enourmous amount of memory plus that for some
types of code it could "mysteriously" :-) run out of memory
very quickly, or unquickly:

alloc(size):
if pools[size]!=NULL:
ret=pools[size]
pools[size]=pools[size].next
else:
ret=freemem;
freemem+=size
return ret;

free(mem,size):
if (freemem-size)==mem:
freemem-=size
else:
mem.next=pools[size]
pools[size]=mem.next

But it's very fast though. :-)
It should be more than 10 times faster than TLSF. (not
that it seems to matter in my tests though, unfortunately)

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Re: programming languages for real-time audio

2008-09-20T02:54:23Z

On Fri, 2008-09-19 at 21:02 -0700, Graham Wakefield wrote:

> > Tim Blechmann:
> >> btw, from what i heard, recent versions of lua provide a real-time
> >> safe
> >> garbage collector ... does anyone know, how if performs in low-
> >> latency
> >> real-time systems?
> >
> > Have you looked at Vessel? It seems very nice and a quick
> > way to test lua's realtimeness.
>
> Yes, I can speak from experience that it performs very well indeed;
> very low jitter. This was one of the most attractive features of Lua
> for me, when I first chose to use it.

i hadn't heard of vessel before ... i was just skimming through your
master thesis, thought ... seems interesting ...
but i'm curious, did you do any analysis of the worst-case response
times of the lua interpreter, when running in a real-time thread? like,
is entering/leaving the interpreter lock-free?

> Also, the allocator used by Lua can be very easily replaced: http://
> www.lua.org/manual/5.1/manual.html#lua_Alloc
> For my work I used dlmalloc as a drop-in replacement, which performed
> very well. It's on my todo list to compare this with TLSF and of
> course the rollendurchmesserzeitsammler.

unfortunately tlsf is just a single-threaded allocator ... therefore it
is not usable, where the allocator needs to be accessed from multiple
real-time threads ... well, for most computer music systems, that may be
the case, but we're living in 2008, where most of the personal computers
provide multiple processors ...
i am not sure about rollendurchmesserzeitsammler, but the last time i
checked, it was relying on tlsf ... kjetil, do you know how rdmzs would
perform with multiple real-time threads?

cheers, tim

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: Re: programming languages for real-time audio

2008-09-19T21:02:25Z

> Tim Blechmann:
>> btw, from what i heard, recent versions of lua provide a real-time
>> safe
>> garbage collector ... does anyone know, how if performs in low-
>> latency
>> real-time systems?
>
> Have you looked at Vessel? It seems very nice and a quick
> way to test lua's realtimeness.

Yes, I can speak from experience that it performs very well indeed;
very low jitter. This was one of the most attractive features of Lua
for me, when I first chose to use it.

It's also quite configurable: http://www.lua.org/manual/5.1/
manual.html#2.10
Tweaking the pause and step multipliers improved the overhead
significantly when used within an audio process. In Lua~ I have the
collector effectively turned off while running coroutine updates, and
then run a conservative step of gc at the end of each DSP callback,
this reduced the overhead of gc logic slightly, at the expense of
slightly greater memory use.

Also, the allocator used by Lua can be very easily replaced: http://
www.lua.org/manual/5.1/manual.html#lua_Alloc
For my work I used dlmalloc as a drop-in replacement, which performed
very well. It's on my todo list to compare this with TLSF and of
course the rollendurchmesserzeitsammler.

BTW The Vessel application was my MS thesis, but the standalone app
described there isn't in a publicly downloadable state. It is about
95% the same as the lua~ external for Max/MSP, which is downloadable,
and documented here: http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%
7E.htm
Since then, I've been working on a new version which is not only more
efficient (buffer use minimization is the biggest improvement over
lua~, but there are many more), but also operates in the main thread
while dispatching all signal processing events (with sample accuracy)
to the audio thread through wait-free queues. The upshot is that the
articulation of audio events, coroutines, dsp graph changes and so on
can all exist in the same accurately timed script as OpenGL calls,
GUI event handling, and so on. This is part of a joint project with
Wes Smith, called LuaAV, which ought to be in a stable state in the
next week or so. I'll post an update on that if people are
interested. In the meantime, here's a placeholder: http://lua-
av.mat.ucsb.edu/about.html

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T19:35:50Z

Michael Gogins wrote:
> CLAM might be overkill. What's wrong with STK? Then there's SndObj, which is not only C++ but also has Python wrappers.

STK I had completely forgotten about. SndObj I've already played with
and dismissed. STK looks like it has a lot of stuff I need, and it
wouldn't be hard to add everything else. It's worth a shot, anyway.

-- Darren

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T16:54:39Z

CLAM might be overkill. What's wrong with STK? Then there's SndObj, which is not only C++ but also has Python wrappers.

Regards,
Mike

-----Original Message-----

>From: Darren Landrum <darren.landrum@...>
>Sent: Sep 19, 2008 6:09 PM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>Darren Landrum wrote:
>> Michael Gogins wrote:
>>> If you let your personal taste dictate your choice of tool, you most
>>> likely will end up using the wrong tool. Use the tool that will do the
>>> job best.
>>>
>>> I'm not saying that personal differences don't have any role at all.
>>> Suppose that, for some odd reason, my brain was wired so that I just
>>> couldn't deal with languages in which I have to be sure to delete
>>> every object that I allocate. I would be foolish not to use a garbage
>>> collected language, in that case.
>>> In your case, I am simply wondering if this bias of yours is something
>>> you might be able to overcome for the sake of more effective work in
>>> the future. Once again, I remind you that the track record of C/C++ in
>>> signal processing and music programming -- military (most demanding),
>>> research, open source, and commercial -- simply blows every other
>>> language away.
>>
>> Well, I'm also wanting to build these tools mainly for my own use, and
>> intend to release them as open source. As such, I'm actually better off
>> using a sub-optimal tool and actually getting them done, than using an
>> optimal tool that I get too frustrated with and then never get them
>> done. Of course, my secondary goal is to create some (hopefully) nice
>> software synthesizers and effects for Linux music production.
>>
>> I've not got my heart set on Ocaml. I just want to explore some options
>> before I dive in and get too far. Heck, I'd just use Csound if it had
>> one very important capability (oversampling). I could probably build
>> GUIs for Csound instruments (I've investigated the Csound API).
>>
>> I've been doing a lot of research into DSP and the math of DSP, but
>> creating implementations, and more importantly, finished "products", has
>> been very elusive to me, and I'm trying to rectify that, however it may
>> happen.
>
>Forgive the reply to myself, but I do have to say, in all honesty, I'll
>probably end up coding in C++ using CLAM (http://clam.iua.upf.edu/) than
>trying to learn a new language, suitable or not. I just wish there were
>an easier way to make softsynths and the like on Linux for us math-heads
>who aren't such good coders.
>
>-- Darren
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T16:53:30Z

You may be interested in Vessel, which is part of LuaAV. It provides Lua wrappers and coroutine scheduling for DSP classes written in C++ (the synz package). I have examined the code, but I have not tried to run it. Adobe Systems also presented a VST plugin Lua scripting project at one of the Lua conferences a few years ago.

I have worked on something similar myself, but I think I will drop it in favor of pure C++ that is built in a hidden, encapsulated way. As far as the user is concerned, it will be like a scripting language -- hit the button and go.

The idea of Lua remains attractive because it has an extremely small footprint for a powerful language. You can build it right into your libraries and applications. In fact, it comes with Csound on Windows, in the form of LuaJIT.

Regards,
Mike

-----Original Message-----

>From: Tim Blechmann <tim@...>
>Sent: Sep 19, 2008 5:48 PM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>hi all ...
>
>> In your case, I am simply wondering if this bias of yours is something
>> you might be able to overcome for the sake of more effective work in
>> the future. Once again, I remind you that the track record of C/C++ in
>> signal processing and music programming -- military (most demanding),
>> research, open source, and commercial -- simply blows every other
>> language away.
>
>in this discussion, one should distinguish between a signal processing
>language and a real-time scripting language ...
>
>the signal processing code should prbly be written in a language like c
>or c++ for performance reasons ...
>
>personally, i would be interested in a real-time safe scripting
>language, targeting a virtual machine with a jit compiler, though ...
>llvm looks quite interesting, but i am not sure about it's real-time
>safety ... might be an interesting research project ...
>
>btw, from what i heard, recent versions of lua provide a real-time safe
>garbage collector ... does anyone know, how if performs in low-latency
>real-time systems?
>
>best, tim
>
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T15:23:02Z

Darren Landrum:
> I don't recall if it got mentioned yet. It's a functional language for
> DSP that compiled to efficient C/C++ code.

Faust has actually been mentioned a few times in this discussion.

Darren Landrum:
> How about the fact that I really, really hate C/C++ and would rather
> gouge my own eyes out than spend four years teaching myself a language I
> hate when functional languages really suit the way I think and I can
> ramp up on them quickly?

Stalin Scheme is a functional language. You can
think of Scheme as the dynamically typed brother
of ML, which Ocaml is a descendent of.

Michael Gogins:
>
> Of course, like so many of these research languages, ATS code is
> compiled to C code before it is compiled to machine language... so even
> if you like the language you still have to have a C development system...
> if you have to have a C development system anyway, why not write
> somewhat faster code in C++ with an existing rich signal processing library?
>

It's hard to manually do the kind of optimization performed by
whole-program optimizers such as faust, mlton or stalin.
Have you looked at the output of those compilers? That's pretty
extreme stuff.

Anyway, hearing your arguments, it reminds me of old assembler vs. C
disussions. The simple truth is that developing in a higher level
language simply is faster, and it frees up your brain to concentrate
on the algorithms instead of gory low-level details. You can
try out things more quickly, and if you think you can make
your stuff run faster if developed directly in C or assember
later on, you are free to do so.

Tim Blechmann:
> personally, i would be interested in a real-time safe scripting
> language, targeting a virtual machine with a jit compiler, though ...
> llvm looks quite interesting, but i am not sure about it's real-time
> safety ... might be an interesting research project ...

There is a project for compiling faust to llvm. I don't
know if it's usable yet.

Tim Blechmann:
> btw, from what i heard, recent versions of lua provide a real-time safe
> garbage collector ... does anyone know, how if performs in low-latency
> real-time systems?

Have you looked at Vessel? It seems very nice and a quick
way to test lua's realtimeness.

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T15:09:41Z

Darren Landrum wrote:

> Michael Gogins wrote:
>> If you let your personal taste dictate your choice of tool, you most
>> likely will end up using the wrong tool. Use the tool that will do the
>> job best.
>>
>> I'm not saying that personal differences don't have any role at all.
>> Suppose that, for some odd reason, my brain was wired so that I just
>> couldn't deal with languages in which I have to be sure to delete
>> every object that I allocate. I would be foolish not to use a garbage
>> collected language, in that case.
>> In your case, I am simply wondering if this bias of yours is something
>> you might be able to overcome for the sake of more effective work in
>> the future. Once again, I remind you that the track record of C/C++ in
>> signal processing and music programming -- military (most demanding),
>> research, open source, and commercial -- simply blows every other
>> language away.
>
> Well, I'm also wanting to build these tools mainly for my own use, and
> intend to release them as open source. As such, I'm actually better off
> using a sub-optimal tool and actually getting them done, than using an
> optimal tool that I get too frustrated with and then never get them
> done. Of course, my secondary goal is to create some (hopefully) nice
> software synthesizers and effects for Linux music production.
>
> I've not got my heart set on Ocaml. I just want to explore some options
> before I dive in and get too far. Heck, I'd just use Csound if it had
> one very important capability (oversampling). I could probably build
> GUIs for Csound instruments (I've investigated the Csound API).
>
> I've been doing a lot of research into DSP and the math of DSP, but
> creating implementations, and more importantly, finished "products", has
> been very elusive to me, and I'm trying to rectify that, however it may
> happen.

Forgive the reply to myself, but I do have to say, in all honesty, I'll
probably end up coding in C++ using CLAM (http://clam.iua.upf.edu/) than
trying to learn a new language, suitable or not. I just wish there were
an easier way to make softsynths and the like on Linux for us math-heads
who aren't such good coders.

-- Darren
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T14:48:41Z

hi all ...

> In your case, I am simply wondering if this bias of yours is something
> you might be able to overcome for the sake of more effective work in
> the future. Once again, I remind you that the track record of C/C++ in
> signal processing and music programming -- military (most demanding),
> research, open source, and commercial -- simply blows every other
> language away.

in this discussion, one should distinguish between a signal processing
language and a real-time scripting language ...

the signal processing code should prbly be written in a language like c
or c++ for performance reasons ...

personally, i would be interested in a real-time safe scripting
language, targeting a virtual machine with a jit compiler, though ...
llvm looks quite interesting, but i am not sure about it's real-time
safety ... might be an interesting research project ...

btw, from what i heard, recent versions of lua provide a real-time safe
garbage collector ... does anyone know, how if performs in low-latency
real-time systems?

best, tim

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T14:42:03Z

Michael Gogins wrote:
> If you let your personal taste dictate your choice of tool, you most likely will end up using the wrong tool. Use the tool that will do the job best.
>
> I'm not saying that personal differences don't have any role at all. Suppose that, for some odd reason, my brain was wired so that I just couldn't deal with languages in which I have to be sure to delete every object that I allocate. I would be foolish not to use a garbage collected language, in that case.
>
> In your case, I am simply wondering if this bias of yours is something you might be able to overcome for the sake of more effective work in the future. Once again, I remind you that the track record of C/C++ in signal processing and music programming -- military (most demanding), research, open source, and commercial -- simply blows every other language away.

Well, I'm also wanting to build these tools mainly for my own use, and
intend to release them as open source. As such, I'm actually better off
using a sub-optimal tool and actually getting them done, than using an
optimal tool that I get too frustrated with and then never get them
done. Of course, my secondary goal is to create some (hopefully) nice
software synthesizers and effects for Linux music production.

I've not got my heart set on Ocaml. I just want to explore some options
before I dive in and get too far. Heck, I'd just use Csound if it had
one very important capability (oversampling). I could probably build
GUIs for Csound instruments (I've investigated the Csound API).

I've been doing a lot of research into DSP and the math of DSP, but
creating implementations, and more importantly, finished "products", has
been very elusive to me, and I'm trying to rectify that, however it may
happen.

Regards,
Darren Landrum
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

Re: programming languages for real-time audio

2008-09-19T14:14:03Z

If you let your personal taste dictate your choice of tool, you most likely will end up using the wrong tool. Use the tool that will do the job best.

I'm not saying that personal differences don't have any role at all. Suppose that, for some odd reason, my brain was wired so that I just couldn't deal with languages in which I have to be sure to delete every object that I allocate. I would be foolish not to use a garbage collected language, in that case.

In your case, I am simply wondering if this bias of yours is something you might be able to overcome for the sake of more effective work in the future. Once again, I remind you that the track record of C/C++ in signal processing and music programming -- military (most demanding), research, open source, and commercial -- simply blows every other language away.

Regards,
Mike

-----Original Message-----

>From: Darren Landrum <darren.landrum@...>
>Sent: Sep 19, 2008 4:51 PM
>To: A discussion list for music-related DSP <music-dsp@...>
>Subject: Re: [music-dsp] programming languages for real-time audio
>
>Michael Gogins wrote:
>> Of course, like so many of these research languages, ATS code is
>compiled to C code before it is compiled to machine language... so
>even if you like the language you still have to have a C development
>system... if you have to have a C development system anyway, why not
>write somewhat faster code in C++ with an existing rich signal processing
>library?
>
>How about the fact that I really, really hate C/C++ and would rather
>gouge my own eyes out than spend four years teaching myself a language I
>hate when functional languages really suit the way I think and I can
>ramp up on them quickly?
>
>Okay, that's all a bit of exaggeration, but you get my point. Besides, I
>have no real experience with Ocaml. Just because I got pretty good at
>one functional language (Faust) doesn't mean I'd be any good at another.
>
>Also, Ocaml has no readily available LV2 or JACK interfaces, or anything
>like that. As for DSP code libraries, well, I have yet to find one of
>those I want to use in any language. Ocaml can use C libraries, which
>may ease construction of things like LV2 plugins, as well as allow the
>use of libraries like libsamplerate, libsndfile, and libfftw3.
>
>I guess "try it out and see" is the only real option here.
>
>Thanks for the reply!
>
>Regards,
>Darren Landrum
>--
>dupswapdrop -- the music-dsp mailing list and website:
>subscription info, FAQ, source code archive, list archive, book reviews, dsp links
>http://music.columbia.edu/cmc/music-dsp
>http://music.columbia.edu/mailman/listinfo/music-dsp

Re: FAUST and Csound (was Re: programming languages for real-time audio)

2008-09-19T13:54:00Z

On Fri, Sep 19, 2008 at 4:51 PM, victor <Victor.Lazzarini@...> wrote:
> I had some chats with Yann (we keep bumping into each other at various
> conferences) about doing exactly this. I think it is a great idea (and
> possibly
> the only output FAUST does not have at this stage).
>
> One thing this might enable is to benchmark music languages (Csound vs.
> PD vs. SC3), which is something worth doing once and for all (I can see
> a paper in this...)

Some time I'd love to do this for ChucK as well. While it's got a lot
of cool Ugens (e.g., STK), it's actually currently quite difficult to
write new ones. Having FAUST output them would make it way easier.

Steve
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp