Discussion:
[LAD] Prototyping algorithms and ideas
Darren Landrum
2008-01-23 18:22:28 UTC
Permalink
Okay, I'll see if I can make up for my awful post from before with a
constructive question.

If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.

Thank you for the help.

-- Darren
Lars Luthman
2008-01-23 18:34:42 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
There are a couple of scripting languages designed for audio processing
and synthesis, for example Csound, SuperCollider and Chuck. For more
high-level algorithms you could maybe use a modular synth (Ingen, AMS
etc).


--ll
Paul Davis
2008-01-23 18:37:18 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
write a LADSPA plugin and load it into JackRack
victor
2008-01-23 19:10:33 UTC
Permalink
or write a Csound plugin... just as easy...
----- Original Message -----
From: "Paul Davis" <***@linuxaudiosystems.com>
To: "Darren Landrum" <***@sbcglobal.net>
Cc: <linux-audio-***@lists.linuxaudio.org>
Sent: Wednesday, January 23, 2008 6:37 PM
Subject: Re: [LAD] Prototyping algorithms and ideas
Post by Paul Davis
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
write a LADSPA plugin and load it into JackRack
_______________________________________________
Linux-audio-dev mailing list
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Stéphane Letz
2008-01-23 18:50:06 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
-- Darren
Have a look at Faust: http://faust.grame.fr/

Stephane
Rui Nuno Capela
2008-01-23 19:15:37 UTC
Permalink
Post by Stéphane Letz
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
-- Darren
Have a look at Faust: http://faust.grame.fr/
yeah, one cannot make it more prototypal than with faust, look! just try
the online compiler to spit out the code (eg. ladspa)

too much rabbits with just one stick, eh? :)
--
rncbc aka Rui Nuno Capela
***@rncbc.org
Darren Landrum
2008-01-23 19:21:07 UTC
Permalink
Post by Stéphane Letz
Have a look at Faust: http://faust.grame.fr/
Oh, hey! I'd forgotten about Faust. I might have to give that one a go.
Thanks!

And thanks to all the other replies. Csound was already on my short
list, but I'm having troubles getting it working on my AMD64 system for
some reason, probably my fault.

-- Darren
Hernán Ordiales
2008-01-23 19:35:46 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
I used to use matlab (or similar/equivalent scripting languages like
octave or python + scipy + matplotlib +...) but now the CLAM
framework[1] is my first option. You have the best of both worlds,
visual prototyping and direct coding (and realtime capable), indeed
you can make very nice visual prototypes...

[1] http://clam.iua.upf.edu

best,
--
Hernán
http://h.ordia.com.ar
GnuPG: 0xEE8A3FE9
Darren Landrum
2008-01-23 22:58:24 UTC
Permalink
Post by Hernán Ordiales
I used to use matlab (or similar/equivalent scripting languages like
octave or python + scipy + matplotlib +...) but now the CLAM
framework[1] is my first option. You have the best of both worlds,
visual prototyping and direct coding (and realtime capable), indeed
you can make very nice visual prototypes...
[1] http://clam.iua.upf.edu
That one I *didn't* know about. That's almost like Reaktor! I'll
definitely be giving that one a go. Thanks!

-- Darren
Albert Graef
2008-01-24 00:38:26 UTC
Permalink
Post by Darren Landrum
Post by Hernán Ordiales
[1] http://clam.iua.upf.edu
That one I *didn't* know about. That's almost like Reaktor! I'll
definitely be giving that one a go. Thanks!
Yes, CLAM is nice. If I'm not mistaken, a new version is around the
corner. And it interfaces to Faust (see my previous reply), via LADSPA.

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Arnold Krille
2008-01-23 20:55:41 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Taking the role of Frank Barknecht:

PD!

Have fun,

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Frank Barknecht
2008-01-23 21:44:45 UTC
Permalink
Hallo,
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
PD!
Pd (as the real me writes it ;) is really damn cool for prototyping.
For one you get the graphical representation which at least I can
think better in, but then also the interface to write C-extension
(externals) is very simple, almost LADSPA-like. With a little template
one can test and develop algorithms very fast.

Ciao
--
Frank Barknecht _ ______footils.org__
Arnold Krille
2008-01-24 11:01:56 UTC
Permalink
Post by Frank Barknecht
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
PD!
Pd (as the real me writes it ;)
Sorry, I didn't do any playing around with it lately, so I misspelled the
name. *flush*
Post by Frank Barknecht
is really damn cool for prototyping.
Yep! And one can easily include ladspa-plugins already on the market and
produce a gui for one's own effectrack. /me did so last summer for a
foh-effects-stack on a gig...
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Albert Graef
2008-01-24 00:33:04 UTC
Permalink
Post by Darren Landrum
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
As long as the DSP doesn't need any tight feedback loops, Pd [1] or some
such patching environment is probably the easiest way to go.

[1] http://puredata.info/

For more advanced stuff, or if you need to build your own custom DSP
components, use Faust [2]. It's the most advanced DSP programming
language available right now. Also, it's a real DSP language which
allows you to program to the bare metal, instead of just patching
together some ready-made components. I guess that's what you want.

[2] http://faust.grame.fr/

Faust is a purely functional language (signals are streams of samples,
DSPs are functions operating on those, which can easily combined in
various ways using Faust's block diagram operators). It compiles to C++,
output code is very good (comparable to carefully hand-crafted code),
and it interfaces nicely to different environments like Jack, LADSPA,
Pd, Max/MSP, VST, SC3, to name just a few. There's also a script to
generate ready-to-use Pd patches from Faust programs which makes testing
pretty easy. Also, you can compile your Faust programs online on the
Faust website if you don't want to bother installing the Faust compiler
(which is quite easy, though, it should readily compile on any Linux box).

For more information, see Yann Orlarey et al's LAC/ICMC 2006 paper and
my LAC 2007 paper (the latter is specifically about the Faust-Pd
interface). You can find these and a lot more on the Faust website [3].
Julius Smith from CCRMA has a tutorial and various examples [4,5], and
you can find some further Faust examples like guitar effects, various
synthesis algorithms and even a KCS decoder on my Q website [6]. The
Faust distribution also includes a lot of examples. (There's no book on
Faust yet, so right now you'll have to find your way using the examples,
the quick reference guide included in the Faust distribution, and the
various tutorials available.)

[3] http://faust.grame.fr/pubs.php
[4] http://ccrma.stanford.edu/realsimple/faust/
[5] http://ccrma.stanford.edu/realsimple/faust_strings/faust_strings.html
[6] http://q-lang.sourceforge.net/examples.html#Pd

Faust has a learning curve, especially if you never used a functional
programming language before. But it's definitely worth it, and it's
addictive. ;-) Once mastered, you can program fairly complex DSPs in a
few lines, and you don't have to worry about those nasty block wrapover
issues which make programming non-trivial DSPs directly in C a pita. And
since the output code is just plain C++ (the compiled DSP algorithm
itself is actually C, being wrapped up in a C++ class for tidyness), you
can easily integrate it into your own programs once you're done prototyping.

To whet your appetite, here are a few Faust examples. A simple chorus
effect:

chorus(dtime,freq,depth,phase,x)
= x+level*fdelay(1<<16, t, x)
with {
t = SR*dtime/2*(1+depth*tblosc(1<<16, sin, freq, phase));
};

Or how about a generic biquad filter:

filter(b0,b1,b2,a0,a1,a2) = f : (+ ~ g)
with {
f(x) = (b0/a0)*x+(b1/a0)*x'+(b2/a0)*x'';
g(y) = 0-(a1/a0)*y-(a2/a0)*y';
};

Note that ~ is Faust's feedback loop operator; the local f function is
the feedforward, g the feedback part of the filter. x' means signal x
delayed by one sample. Pretty easy. And here's how you use that
definition to define a low shelf filter, straight from Robert
Bristow-Johnson's Audio EQ Cookbook. f0 is the shelf midpoint frequency,
g the desired gain in dB. S is the shelf slope parameter, we always set
that to 1 here:

low_shelf(f0,g) = filter(b0,b1,b2,a0,a1,a2)
with {
S = 1;
A = pow(10,g/40);
w0 = 2*PI*f0/SR;
alpha = sin(w0)/2 * sqrt( (A + 1/A)*(1/S - 1) + 2 );

b0 = A*( (A+1) - (A-1)*cos(w0) + 2*sqrt(A)*alpha );
b1 = 2*A*( (A-1) - (A+1)*cos(w0) );
b2 = A*( (A+1) - (A-1)*cos(w0) - 2*sqrt(A)*alpha );
a0 = (A+1) + (A-1)*cos(w0) + 2*sqrt(A)*alpha;
a1 = -2*( (A-1) + (A+1)*cos(w0) );
a2 = (A+1) + (A-1)*cos(w0) - 2*sqrt(A)*alpha;
};

You can find these examples and a lot more in my Faust guitar effects
collection (see ref. [6] above). Also make sure to take a look at Julius
Smith's examples, he's Da Man. :)

HTH,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Frank Barknecht
2008-01-24 14:11:24 UTC
Permalink
Hallo,
Post by Albert Graef
[2] http://faust.grame.fr/
Faust is a purely functional language (signals are streams of samples,
DSPs are functions operating on those, which can easily combined in
various ways using Faust's block diagram operators).
Another very new contender is Vessel, a (micro)sound synthesis
package for Lua:
http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm
http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/Wakefield_MSThesis_MAT07_Vessel.pdf

A Linux/Pd version is in the works. Check the lua-av mailing list for
status: http://zydeco.mat.ucsb.edu/mailman/listinfo/lua-av but it's
alrady producing sound. Vessel is not quite Free Software yet because
of a dependency on a non-free package (synz) that may become free in
the near future.

Lua has some nice functional properties as well and may be a bit
easier to learn than Q or Lisp. It's big with game programmers
already.

Maybe Vessel can be married with Faust as well, like the Q/Faust
coupling?

Ciao
--
Frank Barknecht _ ______footils.org__
Albert Graef
2008-01-24 21:04:18 UTC
Permalink
Post by Frank Barknecht
Another very new contender is Vessel, a (micro)sound synthesis
http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/lua%7E.htm
http://www.mat.ucsb.edu/%7Ewakefield/lua%7E/Wakefield_MSThesis_MAT07_Vessel.pdf
Looks like that thesis was done at CREATE (UCSB). Interesting, thanks
for pointing that out! I know Lua a bit (heck, it even runs on my HP 50g
calculator, which is quite an amazing feat), but I didn't know about the
synthesis package.
Post by Frank Barknecht
Maybe Vessel can be married with Faust as well, like the Q/Faust
coupling?
Faust can be made to work in any environment which provides some means
to integrate (via static or dynamic linking or whatever) basic dsp
components processing a stream of samples, and can provide some way to
exchange control variable values. So if Lua or Vessel itself provides
these tie-ins then it should be possible, but of course someone needs to
write the C++ template for it. ;-)

Cheers,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Kjetil S. Matheussen
2008-01-24 11:28:45 UTC
Permalink
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
For quick and interactive, imperative or functional,
realtime or non-realtime, development of dsp routines,
clm is your choice:
http://ccrma.stanford.edu/software/clm/

and in realtime:
http://www.notam02.no/arkiv/doc/snd-rt/

Lots of example code:
http://snd.cvs.sourceforge.net/snd/cvs-snd/clm-ins.scm?view=log
http://snd.cvs.sourceforge.net/snd/cvs-snd/animals.scm?view=log
http://snd.cvs.sourceforge.net/snd/cvs-snd/dsp.scm?view=log
+ many other files.


If you don't need tight feedback loops (As Albert calls it),
you might want to look at pd, csound, supercollider, etc. instead.

If you _really_ like functional programming and aren't
afraid to learn a really different syntax, faust might probably
be a very good alternative. I don't think you'll get the kind of tight
interactive development environment with it as the other systems
though. ie. you have to write code, compile up, run test, etc.,
while in the other systems, you can just write code and test directly.
Kjetil S. Matheussen
2008-01-24 11:44:38 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Darren Landrum
Okay, I'll see if I can make up for my awful post from before with a
constructive question.
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Thank you for the help.
For quick and interactive, imperative or functional,
realtime or non-realtime, development of dsp routines,
http://ccrma.stanford.edu/software/clm/
http://www.notam02.no/arkiv/doc/snd-rt/
http: //snd.cvs.sourceforge.net/snd/cvs-snd/clm-ins.scm?view=log
http: //snd.cvs.sourceforge.net/snd/cvs-snd/animals.scm?view=log
http: //snd.cvs.sourceforge.net/snd/cvs-snd/dsp.scm?view=log
+ many other files.
I also forgot to mention that in clm you have the choice between
using c, common lisp, forth, ruby or scheme:
http://ccrma.stanford.edu/software/snd/snd/sndclm.html#oscildoc
Stephen Sinclair
2008-01-24 12:44:05 UTC
Permalink
Post by Darren Landrum
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Since everyone else is having a go, I guess this is the thread to
mention Chuck...
http://chuck.cs.princeton.edu/

Real-time programming for those who decided patch cords "aren't for them". ;-)
Also, nice in the fact that you can do per-sample computations easily,
if you need to, but it's not required.
Oh, the options you now have...!

Steve
Darren Landrum
2008-01-24 16:36:28 UTC
Permalink
Post by Stephen Sinclair
Post by Darren Landrum
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Since everyone else is having a go, I guess this is the thread to
mention Chuck...
http://chuck.cs.princeton.edu/
Real-time programming for those who decided patch cords "aren't for them". ;-)
Also, nice in the fact that you can do per-sample computations easily,
if you need to, but it's not required.
Oh, the options you now have...!
I am certainly NOT lacking for options. I've actually played around with
chuck before, too.

So far, the ones holding my interest the most are CLAM and Faust. CLAM
because it has a graphical editor, and Faust because, well, not only can
it prototype, but its output can be used in the final code, too. I also
like the functional aspect of it, I can think more like a mathematician. :)

Thank you all for the replies.

-- Darren
Fons Adriaensen
2008-01-25 15:39:35 UTC
Permalink
Post by Stephen Sinclair
Post by Darren Landrum
If you wanted to quickly prototype an idea for a DSP routine, how would
you go about it? It would need to work in real-time, but it wouldn't
really need to be super-efficient for testing ideas.
Since everyone else is having a go, I guess this is the thread to
mention Chuck...
http://chuck.cs.princeton.edu/
I've been having a look at ChucK. I like the language, and
in particular the 'strong timing' aspects of it. But:

- While it seems to have a range of not-so-trivial 'instrument'
units, it's lacking in fundamental operators, and of those
that exist some are not really well defined,

- The implementation is horribly inefficient. The basic
processing call for a unit is a function handling a single
sample - lots of overhead.
Post by Stephen Sinclair
Real-time programming for those who decided patch cords "aren't for them". ;-)
Also, nice in the fact that you can do per-sample computations easily,
How ? I seem to have missed something...

I've been searching for real-time audio processing tool that would
permit rapid prototyping, for at least two years now, and I haven't
found anything that up to the requirements.

Which is no surprise. It is a ***VERY HARD*** problem.

Ciao
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Stephen Sinclair
2008-01-25 17:57:19 UTC
Permalink
Post by Fons Adriaensen
Post by Stephen Sinclair
Also, nice in the fact that you can do per-sample computations easily,
How ? I seem to have missed something...
Because you can wait in a 1-sample loop?

Yes, it will use your whole CPU for a loop like that, but this thread
is about prototyping. Obviously you'd rewrite in C for a real
application.
I never claimed chuck is perfect, but I've been liking it a lot
lately. Sure, it can have performance issues depending on how you use
it, but the nice thing is having the option to abuse it that way when
necessary.

Steve
Fons Adriaensen
2008-01-28 18:28:27 UTC
Permalink
Post by Stephen Sinclair
Post by Fons Adriaensen
Post by Stephen Sinclair
Also, nice in the fact that you can do per-sample computations easily,
How ? I seem to have missed something...
Because you can wait in a 1-sample loop?
Yes, it will use your whole CPU for a loop like that, but this thread
is about prototyping. Obviously you'd rewrite in C for a real
application.
I never claimed chuck is perfect, but I've been liking it a lot
lately. Sure, it can have performance issues depending on how you use
it, but the nice thing is having the option to abuse it that way when
necessary.
This is one of the things I wanted to create a 'rapid prototype'
for recently. I needed a jack client implementing:

- a delay line,
- allowing high-quality fractional-sample delays,
- at least 12 outputs, for each two controls: delay, gain,
- smooth 'crossfading' between two control sets, both delay
and gain, controlled by a GUI or by OSC.

It should not take more than 20% CPU on a 2G P4
(other things have to run at the same time).
If you know how to get this faster than by actually
writing it in C++, please let me know !
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Frank Barknecht
2008-01-29 17:12:20 UTC
Permalink
Hallo,
Post by Fons Adriaensen
- a delay line,
- allowing high-quality fractional-sample delays,
- at least 12 outputs, for each two controls: delay, gain,
- smooth 'crossfading' between two control sets, both delay
and gain, controlled by a GUI or by OSC.
It should not take more than 20% CPU on a 2G P4
(other things have to run at the same time).
If you know how to get this faster than by actually
writing it in C++, please let me know !
I think, Pd is faster to write such a thing. A version is attached. I
omitted the crossfading and OSC control as that requires some
externals or abstractions. But it's not hard to do as well.

Ciao
--
Frank Barknecht _ ______footils.org__
Georg Holzmann
2008-01-29 18:16:46 UTC
Permalink
Hallo!
Post by Frank Barknecht
Post by Fons Adriaensen
- a delay line,
- allowing high-quality fractional-sample delays,
- at least 12 outputs, for each two controls: delay, gain,
- smooth 'crossfading' between two control sets, both delay
and gain, controlled by a GUI or by OSC.
It should not take more than 20% CPU on a 2G P4
(other things have to run at the same time).
If you know how to get this faster than by actually
writing it in C++, please let me know !
I think, Pd is faster to write such a thing. A version is attached. I
omitted the crossfading and OSC control as that requires some
externals or abstractions. But it's not hard to do as well.
In pd (or other rt-alternatives) you do that in 5 minutes and in C/C++
you need a day or more ...

So the most important lesson I had to learn when prototyping
algorithms+ideas: don't use C or C++ ! Only if there is really no other
solution (which is not often the case) !
And don't think about optimization too early ... ;)

BTW: I'm using python (scipy/numpy) for algorithm prototyping (sometimes
I have to use octave/matlab, because its somehow a "standard" in
DSP-world) and for writing/testing realtime algorithms pure data.

LG
Georg
Yann Orlarey
2008-01-29 22:36:30 UTC
Permalink
Hi Fons,

Here is a quick solution using Faust :

import("filter.lib");

line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
with { g = vslider("gain (dB)", -60, -60, 4, 0.1) : db2linear :
smooth(0.995);
d = nentry("delay (samp)", 0, 0, 1000, 0.1) :
smooth(0.995); };

process = hgroup("", par(i, 10, line(i)) );

The first line imports a library of filters (written in Faust by Julius
Smith) that includes several fractional delays based on Lagrange
interpolation.

Then we define a 'line' that combines in sequence (':' operator) a gain
and a fractional delay encapsulated in a vertical layout. Here we use
fdelay2 a fractional delay with a second order Lagrange interpolation.
It can be replaced by fdelay3 or fdelay4 if better interpolations are
needed.

The gain value g is defined by a vertical slider (in dB) which is
converted in a linear value and then filtered to avoid clicks during
rapid movements. The delay value d is defined by a numerical entry box
also filtered to avoid clicks. The parameter m is the maximum size of
the delay and should be a power of 2.

The last line defines process, the equivalent of main in C, as a
parallel composition of 10 lines.

A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
(Intel Core 2 CPU T7400 @ 2.16GHz) is approximately of 2%.

Cheers

Yann
Post by Fons Adriaensen
Post by Stephen Sinclair
Post by Fons Adriaensen
Post by Stephen Sinclair
Also, nice in the fact that you can do per-sample computations easily,
How ? I seem to have missed something...
Because you can wait in a 1-sample loop?
Yes, it will use your whole CPU for a loop like that, but this thread
is about prototyping. Obviously you'd rewrite in C for a real
application.
I never claimed chuck is perfect, but I've been liking it a lot
lately. Sure, it can have performance issues depending on how you use
it, but the nice thing is having the option to abuse it that way when
necessary.
This is one of the things I wanted to create a 'rapid prototype'
- a delay line,
- allowing high-quality fractional-sample delays,
- at least 12 outputs, for each two controls: delay, gain,
- smooth 'crossfading' between two control sets, both delay
and gain, controlled by a GUI or by OSC.
It should not take more than 20% CPU on a 2G P4
(other things have to run at the same time).
If you know how to get this faster than by actually
writing it in C++, please let me know !
Paul Davis
2008-01-29 23:25:50 UTC
Permalink
Post by Yann Orlarey
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
I think they call that "game, set and match".
Fons Adriaensen
2008-01-30 14:08:31 UTC
Permalink
Post by Paul Davis
Post by Yann Orlarey
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
I think they call that "game, set and match".
Not really, but still I'm impressed :-)

- Even fdelay4 is not up to the task. There are
gain variations of more than 6dB for a 20 kHz
signal, Fs = 48 kHz. Even stranger, they are
not symmetric w.r.t. the fraction of the delay,
e.g. 10.3 samples shows a different gain than
9.7. Which makes me suspicious.

- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps

MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.

- The apps also autosave their state to $HOME/.***rc.
Any way to disable this ?

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Dave Robillard
2008-01-30 16:16:24 UTC
Permalink
Post by Fons Adriaensen
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
Hear hear. This setting really must be moved into Jack. Let the user
specify the auto-connect ports (or none). Apps doing ignorant things
like connecting to the first n "physical" ports is useless a lot of the
time anyway, even if you do want auto-connect (e.g. I would set them up
to auto-connect to a mixer app)

-DR-
Fons Adriaensen
2008-01-31 00:46:20 UTC
Permalink
Post by Dave Robillard
Post by Fons Adriaensen
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
Hear hear. This setting really must be moved into Jack.
Port locking was removed recently...
Post by Dave Robillard
Let the user specify the auto-connect ports (or none).
Apps doing ignorant things like connecting to the
first n "physical" ports is useless a lot of the
time anyway, even if you do want auto-connect
(e.g. I would set them up to auto-connect to a
mixer app)
There could be some 'standard' environment variables
defining which ports (if any) can be assumed to be
'general purpose audio playback'. In my case as well
this would be a software mixer input, or a least a
'monitoring management' app.
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Stéphane Letz
2008-01-31 09:06:07 UTC
Permalink
Post by Fons Adriaensen
Post by Paul Davis
Post by Yann Orlarey
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
I think they call that "game, set and match".
Not really, but still I'm impressed :-)
- Even fdelay4 is not up to the task. There are
gain variations of more than 6dB for a 20 kHz
signal, Fs = 48 kHz. Even stranger, they are
not symmetric w.r.t. the fraction of the delay,
e.g. 10.3 samples shows a different gain than
9.7. Which makes me suspicious.
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
- The apps also autosave their state to $HOME/.***rc.
Any way to disable this ?
Ciao,
If you want to change that kind behaviour for now, you'll have to
install faust, edit and correct the jack-gtk.cpp wrapper file (located
in faust/architecture). Then install faust again (since "install" copy
the architecture files at proper locations) and recompile your jack-
gtk faust programs.
We may improve the jack-gtk.cpp wrapper file later on to add auto-
connect and state location options.

Stephane
Fons Adriaensen
2008-02-01 15:26:16 UTC
Permalink
Post by Stéphane Letz
Post by Fons Adriaensen
- The apps also autosave their state to $HOME/.***rc.
Any way to disable this ?
If you want to change that kind behaviour for now,
...
One man's 'kind behaviour' is another one's bug.
Just received a mail from on of the people (not
a programmer - a _real_ _user_) I work with here
and who has started using Faust.

He wrote he had discovered a bug: default
values given to sliders etc. only work the
first time a program is run. And he's right....

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Stéphane Letz
2008-01-30 06:20:36 UTC
Permalink
Post by Yann Orlarey
Hi Fons,
import("filter.lib");
line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
smooth(0.995);
smooth(0.995); };
process = hgroup("", par(i, 10, line(i)) );
The first line imports a library of filters (written in Faust by Julius
Smith) that includes several fractional delays based on Lagrange
interpolation.
Then we define a 'line' that combines in sequence (':' operator) a gain
and a fractional delay encapsulated in a vertical layout. Here we use
fdelay2 a fractional delay with a second order Lagrange interpolation.
It can be replaced by fdelay3 or fdelay4 if better interpolations are
needed.
The gain value g is defined by a vertical slider (in dB) which is
converted in a linear value and then filtered to avoid clicks during
rapid movements. The delay value d is defined by a numerical entry box
also filtered to avoid clicks. The parameter m is the maximum size of
the delay and should be a power of 2.
The last line defines process, the equivalent of main in C, as a
parallel composition of 10 lines.
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
Cheers
Yann
And for the "dynamic" part of the process like having an
environnement that would allow to directly define, compile on the fly
and execute Faust plug-ins, we are investigating using LLVM. See
http://www.grame.fr/~letz/faust_llvm.html, although to be honest, the
"hard part" has not yet really started...

Stephane
Fons Adriaensen
2008-01-31 00:21:07 UTC
Permalink
Hi Yann,
Post by Yann Orlarey
...
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop (Intel
Many thanks for this. I'm very happy you point me back
to Faust, as despite the comments below I am really
impressed by what it achieves. Enough to organise a
demo yesterday afternoon for two of the researchers
I work with. They are not programmers, but both will
start learning to use Faust.

Here are my comments, some of them posted before.

1. The auto-connection issue. If I would install (or
some day, update) Faust at home or at my normal working
place, build the examples to test the installation, and
run 'osc', this would send a continuous, maximum level,
1kHz signal to a power amp feeding an HF speaker that
doesn't much like signals of this frequency, and even
less at a power level at least 20 dB above its maximum
continuous rating. It would be destroyed instantly, and
I would be happy to escape without permanent hearing
damage. Please don't assume you can safely connect to
the first N physical ports. At least make it an option,
and one that needs explicit user action to be enabled.
The code attached below solves this.

2. It's not possible to run a more than one instance
of a JACK client since all instances have the same
name, there is no -name option, and they don't use
the API that automatically generates unique names.
This also is solved by the code attached below.

3. All the recursive filters I tested will generate
denormals if the input is stopped or disconnected.
On Intel systems this can easily push the CPU load
up to crash levels. Solving this requires changes
to all the Faust sources defining these filters.
BTW, some other systems, e.g. SC3, have the same
problem.

4. The fdelay() functions are not usable for the
application I posted. All of them have significant
HF loss if the delay is not integer, and as a result,
will generate amplitude and maybe also phase modulation
if the delay value is not static. Strangely, fdelay4()
is not any better than fdelay2(), and fdelay3() is even
worse.

5. There may be quality issues with some of the libs.
The 'bandfilter' for example behaves very strangely.


Alternative main() for jack-gtk.

The code below solves two problems.

1. Auto-connection of ports requires a one-time user
action. Ports will be connected only if the environment
variables FAUST2JACK_INPUTS and FAUST2JACK_OUTPUTS are
defined, e.g. in ~/.bash_profile. They should be defined
as e.g.

export FAUST2JACK_INPUTS=system:capture_%d
export FAUST2JACK_OUTPUTS=system:playback_%d

Both are used as format strings in snprintf().

2. Use jack_client_open() instead of jack_client_new().
This will automatically generate a unique client name
in case there is a conflict. Creation of the UI is
delayed until the JACK connection is established, so
the correct name will also be shown in the window title.


Ciao,


--------------------------------------------------------------

int main(int argc, char *argv[] )
{
//gtk_init (&argc, &argv);

UI* interface;
jack_client_t* client;
char buf [256];
char rcfilename[256];
jack_status_t jackstat;
char *home;
char *pname;
char *jname;

jname = basename (argv [0]);
client = jack_client_open (jname, (jack_options_t) 0, &jackstat);
if (client == 0) {
fprintf (stderr, "Can't connect to JACK, is the server running ?\n");
exit (1);
}
if (jackstat & JackNameNotUnique) {
jname = jack_get_client_name (client);
}

jack_set_process_callback(client, process, 0);
jack_set_sample_rate_callback(client, srate, 0);
jack_on_shutdown(client, jack_shutdown, 0);

gNumInChans = DSP.getNumInputs();
gNumOutChans = DSP.getNumOutputs();

for (int i = 0; i < gNumInChans; i++) {
snprintf(buf, 256, "in_%d", i);
input_ports[i] = jack_port_register(client, buf, JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
}
for (int i = 0; i < gNumOutChans; i++) {
snprintf(buf, 256, "out_%d", i);
output_ports[i] = jack_port_register(client, buf, JACK_DEFAULT_AUDIO_TYPE, JackPortIsOutput, 0);
}

interface = new GTKUI (jname, &argc, &argv);
DSP.init(jack_get_sample_rate(client));
DSP.buildUserInterface(interface);

home = getenv ("HOME");
if (home == 0) home = ".";
snprintf(rcfilename, 256, "%s/.%src", home, jname);
interface->recallState(rcfilename);

if (jack_activate(client)) {
fprintf(stderr, "Can't activate JACK client\n");
return 1;
}

pname = getenv("FAUST2JACK_INPUTS");
if (pname && *pname) {
for (int i = 0; i < gNumInChans; i++) {
snprintf(buf, 256, pname, i + 1);
jack_connect(client, buf, jack_port_name(input_ports[i]));
}
}

pname = getenv("FAUST2JACK_OUTPUTS");
if (pname && *pname) {
for (int i = 0; i < gNumOutChans; i++) {
snprintf(buf, 256, pname, i + 1);
jack_connect(client, jack_port_name(output_ports[i]), buf);
}
}

interface->run();
jack_deactivate(client);

for (int i = 0; i < gNumInChans; i++) {
jack_port_unregister(client, input_ports[i]);
}
for (int i = 0; i < gNumOutChans; i++) {
jack_port_unregister(client, output_ports[i]);
}

jack_client_close(client);
interface->saveState(rcfilename);

return 0;
}


--------------------------------------------------------------
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Yann Orlarey
2008-01-31 17:29:58 UTC
Permalink
Hi Fons,

Thanks for your useful and constructive comments. I have updated the
jack-gtk.cpp architecture file with your suggested main. It provides a
flexible solution that should make both the auto-connection and
manual-connection people happy ;-) Moreover it solves the unique name
problem.
Post by Fons Adriaensen
Hi Yann,
Post by Yann Orlarey
...
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop (Intel
Many thanks for this. I'm very happy you point me back
to Faust, as despite the comments below I am really
impressed by what it achieves. Enough to organise a
demo yesterday afternoon for two of the researchers
I work with. They are not programmers, but both will
start learning to use Faust.
Great ! Benvenuti ! If they have programming questions (I am sure pretty
they will have some at the beginning ;-)) they are welcome, as well as
suggestions and contributions.
Post by Fons Adriaensen
Here are my comments, some of them posted before.
1. The auto-connection issue. If I would install (or
some day, update) Faust at home or at my normal working
place, build the examples to test the installation, and
run 'osc', this would send a continuous, maximum level,
1kHz signal to a power amp feeding an HF speaker that
doesn't much like signals of this frequency, and even
less at a power level at least 20 dB above its maximum
continuous rating. It would be destroyed instantly, and
I would be happy to escape without permanent hearing
damage. Please don't assume you can safely connect to
the first N physical ports. At least make it an option,
and one that needs explicit user action to be enabled.
The code attached below solves this.
2. It's not possible to run a more than one instance
of a JACK client since all instances have the same
name, there is no -name option, and they don't use
the API that automatically generates unique names.
This also is solved by the code attached below.
As I said above I have update the CVS with the revised jack-gtk.cpp
architecture file. The faust server is not updated yet, but it will be
soon...
Post by Fons Adriaensen
3. All the recursive filters I tested will generate
denormals if the input is stopped or disconnected.
On Intel systems this can easily push the CPU load
up to crash levels. Solving this requires changes
to all the Faust sources defining these filters.
BTW, some other systems, e.g. SC3, have the same
problem.
This is a real problem but it should be solved on modern intel cpu by
enabling the FTZ mode.
Post by Fons Adriaensen
4. The fdelay() functions are not usable for the
application I posted. All of them have significant
HF loss if the delay is not integer, and as a result,
will generate amplitude and maybe also phase modulation
if the delay value is not static. Strangely, fdelay4()
is not any better than fdelay2(), and fdelay3() is even
worse.
Is fdelay *that* bad or do you have a very demanding application ? For the worst cases (x.5 delays) the amplitude response for fdelay4 is down about 2 dB at 15 kHz and 7 dB at 20 kHz (for a 44.1 kHz sampling rate).

This is consistent with your observed 6 dB drop at 20 kHz for a 48 kHz sampling rate. But please note that all the gain drop is concentrated at very high frequencies. Moreover, with a sampling rate of 96 kHz instead of 48 KHz, the gain falls to only -1/4 dB at 20 KHz.

BTW, Julius has updated 'filter.lib' to correct one of the coefficients of fdelay2 and added Thiran allpass interpolators (http://ccrma.stanford.edu/~jos/pasp/Thiran_Allpass_Interpolators.html) with very flat frequency response.
Post by Fons Adriaensen
5. There may be quality issues with some of the libs.
The 'bandfilter' for example behaves very strangely.
That's right, we should revise it. I must confess that until recently
most of our development efforts have been put on the compiler and quite
few on the libraries. But with a growing community things are changing...
Post by Fons Adriaensen
Alternative main() for jack-gtk.
The code below solves two problems.
1. Auto-connection of ports requires a one-time user
action. Ports will be connected only if the environment
variables FAUST2JACK_INPUTS and FAUST2JACK_OUTPUTS are
defined, e.g. in ~/.bash_profile. They should be defined
as e.g.
export FAUST2JACK_INPUTS=system:capture_%d
export FAUST2JACK_OUTPUTS=system:playback_%d
Both are used as format strings in snprintf().
2. Use jack_client_open() instead of jack_client_new().
This will automatically generate a unique client name
in case there is a conflict. Creation of the UI is
delayed until the JACK connection is established, so
the correct name will also be shown in the window title.
Ciao,
--------------------------------------------------------------
int main(int argc, char *argv[] )
{
//gtk_init (&argc, &argv);
UI* interface;
jack_client_t* client;
char buf [256];
char rcfilename[256];
jack_status_t jackstat;
char *home;
char *pname;
char *jname;
jname = basename (argv [0]);
client = jack_client_open (jname, (jack_options_t) 0,
&jackstat);
if (client == 0) {
fprintf (stderr, "Can't connect to JACK, is the server running ?\n");
exit (1);
}
if (jackstat & JackNameNotUnique) {
jname = jack_get_client_name (client);
}
jack_set_process_callback(client, process, 0);
jack_set_sample_rate_callback(client, srate, 0);
jack_on_shutdown(client, jack_shutdown, 0);
gNumInChans = DSP.getNumInputs();
gNumOutChans = DSP.getNumOutputs();
for (int i = 0; i < gNumInChans; i++) {
snprintf(buf, 256, "in_%d", i);
input_ports[i] = jack_port_register(client, buf,
JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
}
for (int i = 0; i < gNumOutChans; i++) {
snprintf(buf, 256, "out_%d", i);
output_ports[i] = jack_port_register(client, buf,
JACK_DEFAULT_AUDIO_TYPE, JackPortIsOutput, 0);
}
interface = new GTKUI (jname, &argc, &argv);
DSP.init(jack_get_sample_rate(client));
DSP.buildUserInterface(interface);
home = getenv ("HOME");
if (home == 0) home = ".";
snprintf(rcfilename, 256, "%s/.%src", home, jname);
interface->recallState(rcfilename);
if (jack_activate(client)) {
fprintf(stderr, "Can't activate JACK client\n");
return 1;
}
pname = getenv("FAUST2JACK_INPUTS");
if (pname && *pname) {
for (int i = 0; i < gNumInChans; i++) {
snprintf(buf, 256, pname, i + 1);
jack_connect(client, buf,
jack_port_name(input_ports[i]));
}
}
pname = getenv("FAUST2JACK_OUTPUTS");
if (pname && *pname) {
for (int i = 0; i < gNumOutChans; i++) {
snprintf(buf, 256, pname, i + 1);
jack_connect(client, jack_port_name(output_ports[i]), buf);
}
}
interface->run();
jack_deactivate(client);
for (int i = 0; i < gNumInChans; i++) {
jack_port_unregister(client, input_ports[i]);
}
for (int i = 0; i < gNumOutChans; i++) {
jack_port_unregister(client, output_ports[i]);
}
jack_client_close(client);
interface->saveState(rcfilename);
return 0;
}
--------------------------------------------------------------
Thanks again !

Cheers

Yann
Fons Adriaensen
2008-01-31 18:24:25 UTC
Permalink
Hi Yann,
Post by Yann Orlarey
Great ! Benvenuti ! If they have programming questions (I am sure pretty
they will have some at the beginning ;-)) they are welcome, as well as
suggestions and contributions.
I will have some of my own, when I start programming in Faust !
Post by Yann Orlarey
As I said above I have update the CVS with the revised jack-gtk.cpp
architecture file. The faust server is not updated yet, but it will be
soon...
Using the _%d does not allow arbitrary port names, so it's not
the most flexible solution, but at least it permits to do what
happened automatically before, if you want it.
Post by Yann Orlarey
This is a real problem but it should be solved on modern intel cpu by
enabling the FTZ mode.
So the generated code should really do that.
Post by Yann Orlarey
Is fdelay *that* bad or do you have a very demanding application ?
The application is demanding in the sense that it's a psycho-acoustic
experiment - we want to find out if, and in which conditions, the
listener would be able to detect the 'crossover' (which is part of
a larger system). So we must avoid any processing artefacts that
_could_ be suspected to influence the results.

The real problem is not the static FR error, but the modulation
it introduces when the delay is not static. For example, when
it changes by 100 samples per second, the HF part of the signal
is amplitude modulated by 100 Hz. This is much more perceptible
than a constant FR error. A constant bandwidht interpolator with
the same frequency response would probably be acceptable.
Post by Yann Orlarey
For the worst cases (x.5 delays)...
For fdelay4(), the worst case is not x.5 but close to x.3.
It uses the interval [1...2], which is asymmetric. Using
the 'center' [1.5...2.5] would give a discontinuity at x.5
for most inputs.
Post by Yann Orlarey
BTW, Julius has updated 'filter.lib' to correct one of the
coefficients of fdelay2 and added Thiran allpass interpolators
(http://ccrma.stanford.edu/~jos/pasp/Thiran_Allpass_Interpolators.html)
with very flat frequency response.
Interesting stuff (as usual from JOS), thanks for the pointer.
Post by Yann Orlarey
Post by Fons Adriaensen
5. There may be quality issues with some of the libs.
The 'bandfilter' for example behaves very strangely.
That's right, we should revise it. I must confess that until recently most
of our development efforts have been put on the compiler and quite few on
the libraries. But with a growing community things are changing...
Also the 'pink noise' in tester has significant power spectrum
errors.

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Albert Graef
2008-02-01 04:02:13 UTC
Permalink
Yann Orlarey wrote:
[denormals issues]
Post by Yann Orlarey
This is a real problem but it should be solved on modern intel cpu by
enabling the FTZ mode.
It would be useful if the Faust guide had a brief explanation of
denormals, along with instructions on how to enable FTZ with gcc and the
Intel compiler, and other workarounds. Or maybe it's time to start a
Faust FAQ? This problem is surely going to bite a lot of dsp newbies who
start playing with Faust on the "wrong" system.

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Yann Orlarey
2008-02-01 07:14:39 UTC
Permalink
Post by Albert Graef
[denormals issues]
Post by Yann Orlarey
This is a real problem but it should be solved on modern intel cpu by
enabling the FTZ mode.
It would be useful if the Faust guide had a brief explanation of
denormals, along with instructions on how to enable FTZ with gcc and the
Intel compiler, and other workarounds. Or maybe it's time to start a
Faust FAQ? This problem is surely going to bite a lot of dsp newbies who
start playing with Faust on the "wrong" system.
Albert
Right. The interactions with the various gcc flags are not very easy to
understand. The FTZ mode is supposed to be enabled by the -ffast-math
flag. But alone this flag is not enough.

Here are various tests I did on karplus32.dsp to figure out the right
combination of gcc flags to avoid denormals.

The first thing is to modify Karplus32 to produce denormals by
commenting out " :+(leak)" line 21 :
trigger(n) = upfront : release(n) : >(0.0); // : +(leak);

Then compile karplus32.dsp only with "-O3". If you play with the
modified karplus32, after few seconds (~30s) of inactivity it starts
using 100% of the CPU.

Now if you recompile karplus32.dsp using "-O3 -ffast-math" you will
still have denormals because you need to be in sse mode. Being in sse
mode "-O3 -march=native -mfpmath=sse" is not enough and still produces
denormals.

The minimal combination to activate FTZ mode seems to be :

"-O3 -march=native -mfpmath=sse -ffast-math"

when you are on a sse capable cpu. Here it works, you don't have
denormals any more :-).

Yann

PS : from the gcc manual about -ffast-math : "This option should never
be turned on by any ‘-O’ option since it can result in incorrect output
for programs which depend on an exact implementation of IEEE or ISO
rules/specifications for math functions."
Paul Davis
2008-02-01 15:00:09 UTC
Permalink
Post by Yann Orlarey
"-O3 -march=native -mfpmath=sse -ffast-math"
when you are on a sse capable cpu. Here it works, you don't have
denormals any more :-).
Ardour takes manual control of FTZ and DAZ flags, and also offers DC
offsets (adding a very very tiny value to every sample) as ways to
control denormals. Our experience (or our users' experience) has been
that FTZ is better than DAZ, but that neither reduces denormal effects
as much as a DC offset. It is still possible to see denormal-induced
performance slowdowns even when FTZ is in effect, although the magnitude
is reduced.

code can be found in libs/pbd/fpu.cc (its hairy code, inline asm for x86
and x86_64, linux & OS X)

--p
Tim Goetze
2008-02-01 16:01:35 UTC
Permalink
[Paul Davis]
Post by Paul Davis
Post by Yann Orlarey
"-O3 -march=native -mfpmath=sse -ffast-math"
when you are on a sse capable cpu. Here it works, you don't have
denormals any more :-).
Ardour takes manual control of FTZ and DAZ flags, and also offers DC
offsets (adding a very very tiny value to every sample) as ways to
control denormals. Our experience (or our users' experience) has been
that FTZ is better than DAZ, but that neither reduces denormal effects
as much as a DC offset. It is still possible to see denormal-induced
performance slowdowns even when FTZ is in effect, although the magnitude
is reduced.
On this Core2 (6600) chip, this:

#ifdef __SSE3__
_MM_SET_DENORMALS_ZERO_MODE (_MM_DENORMALS_ZERO_ON);
#endif

#ifdef __SSE__
_MM_SET_FLUSH_ZERO_MODE (_MM_FLUSH_ZERO_ON);
#endif

along with -mfpmath=sse -msse -msse3 reliably eliminates denormals
completely. DSP code runs at full speed with no more need for DC,
noise, Nyquist or other signal injection.

Flush-to-zero alone did not bring a palpable improvement when I
evaluated the different options. On this chip that is, of course.

Cheers, Tim
Albert Graef
2008-02-01 03:39:06 UTC
Permalink
Post by Fons Adriaensen
3. All the recursive filters I tested will generate
denormals if the input is stopped or disconnected.
Yes, same as with most other dsp software. And, as usual, the solution
is to add a little noise in the right places, or cut off a signal which
goes below a certain threshold.

Denormals are a pita. I'm not aware of any general solution (except
buying the right cpu), do you know one? You can't just add noise
automatically to every x~y block...

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
2008-01-24 20:47:58 UTC
Permalink
Post by Kjetil S. Matheussen
If you _really_ like functional programming and aren't
afraid to learn a really different syntax, faust might probably
be a very good alternative. I don't think you'll get the kind of tight
interactive development environment with it as the other systems
though. ie. you have to write code, compile up, run test, etc.,
while in the other systems, you can just write code and test directly.
That's true, I'm the first one to admit that as I already use the
Faust/Pd combination in courses, and the students complain about this
all the time. ;-) We definitely need to work on that. This might need
some cooperation from Pd (right now, Pd doesn't seem to like reloading
externals on the fly, at least I haven't figured that out yet).

The Pd/Q interface works much better in that respect since it already
allows hot-swapping the running Q script, and you can trigger that,
e.g., from Emacs. A similar trick could be done with Faust plugins, too,
by making a generic Faust external which just acts as a container, and
loads the real plugin on its own behalf.

CLAM is supposed to offer nice Faust integration (via LADSPA) already,
but I haven't tried it yet. I'm looking forward to use that combination
in one of my next audio programming courses, though.

CLM and snd are also nice for prototyping purposes, of course, as are
all the others mentioned in this thread. But for me the special thing
about Faust is that it's purely functional to boot and has a formal
semantics. Your programs read like mathematical specifications, and
that's what they are. I won't even mention the expression syntax, as I
don't want to invite the 5625342th parens-versus-infix flamefest. Oops,
now I did it. :)

Faust isn't perfect either. For one thing, it still lacks multirate
processing. And my pet peeve: the lack of a unary minus operator. ;-)

What an interesting thread. Keep it going. :)

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Kjetil S. Matheussen
2008-01-27 18:44:00 UTC
Permalink
Post by Albert Graef
Post by Kjetil S. Matheussen
If you _really_ like functional programming and aren't
afraid to learn a really different syntax, faust might probably
be a very good alternative. I don't think you'll get the kind of tight
interactive development environment with it as the other systems
though. ie. you have to write code, compile up, run test, etc.,
while in the other systems, you can just write code and test directly.
That's true, I'm the first one to admit that as I already use the
Faust/Pd combination in courses, and the students complain about this
all the time. ;-) We definitely need to work on that. This might need
some cooperation from Pd (right now, Pd doesn't seem to like reloading
externals on the fly, at least I haven't figured that out yet).
The Pd/Q interface works much better in that respect since it already
allows hot-swapping the running Q script, and you can trigger that,
e.g., from Emacs. A similar trick could be done with Faust plugins, too,
by making a generic Faust external which just acts as a container, and
loads the real plugin on its own behalf.
CLAM is supposed to offer nice Faust integration (via LADSPA) already,
but I haven't tried it yet. I'm looking forward to use that combination
in one of my next audio programming courses, though.
CLM and snd are also nice for prototyping purposes, of course, as are
all the others mentioned in this thread. But for me the special thing
about Faust is that it's purely functional to boot and has a formal
semantics. Your programs read like mathematical specifications, and
that's what they are. I won't even mention the expression syntax, as I
don't want to invite the 5625342th parens-versus-infix flamefest. Oops,
now I did it. :)
Faust isn't perfect either. For one thing, it still lacks multirate
processing. And my pet peeve: the lack of a unary minus operator. ;-)
What an interesting thread. Keep it going. :)
Okay. :-)

The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.

For example, when I made the san dysth softsynth,
I thought in imperative terms, a sort of state machine where a set of
variables change value for each sample. In an imperative languages, its
straight forward to make such a routine, but in purely functional
languages the code must be transformed first. And doing that
tranformation can be very hard, even impossible, if you quite don't
know how your dsp function is supposed to work yet.

When I actually implemented san dysth,
I did a lot of trying and failing before eventually getting something
which sounded somewhat okay. Its not a great synth
mathematic-vice, and I don't know very well what I'm doing regarding
signal processing. But if I hadn't had a programming environment
which supports imperative operators, there would most likely
never have been a san dysth softsynth at all. So I may think that for a
person who have a more experimental approach to signal processing,
faust isn't a good choice, at least not for prototyping.

Well, after being finished writing the softh synth I made block diagrams
of the signal processing routine:
http://www.notam02.no/~kjetism/sandysth/ so I would probably not
have that much a problem writing san dysth in faust now. But the
original implementation worked (and still works) like this:

"
func get_one_sample:
if val <= -1
inc_addval=true
elseif val <= 1
inc_addval = false
elseif addval > max-add-val
periodcounter = period
inc_addval = false
elseif addval < -max-add-val
periodcounter = period
inc_addval = true
elseif 0 == (--periodcounter)
periodcounter = period
inc_addval = not inc_addval

drunk-change = random( max-drunk-change )
addval = filter( das_filter, inc-addval == true
? drunk-change
: -drunk-change
)
val += addval
return val

out( vol * src( sr, rate, get_one_sample) )
"

("src" is a resampler function)


It would be interesting to see how the routine would
look like in faust, if you have the time. :-)
(I think it should be a straight forward job though
when looking at the block diagrams on the san dysth
homepage.)
Frank Barknecht
2008-01-28 09:56:46 UTC
Permalink
Hallo,
Post by Kjetil S. Matheussen
The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.
I think, Lua (with Vessel, see my other post) may be a good compromise
of both worlds. (It may have not enough parenthesis for your taste. ;)

Actually as I recently had a quick look at Rick Taube's SAL language
syntax for working with Common Music, I was amazed at how similar SAL
looks and feels to straight Lua code. I even wondered, if inventing a
new domain specifc language like SAL was necessary.

Ciao
--
Frank Barknecht _ ______footils.org__
Albert Graef
2008-02-01 05:44:48 UTC
Permalink
Post by Kjetil S. Matheussen
The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.
Yep, it takes some discipline, but you also get to reap the benefits
(clear semantics, better output code).
Post by Kjetil S. Matheussen
It would be interesting to see how the routine would
look like in faust, if you have the time. :-)
I don't have the time to really work out all the details of your example
right now, but looking at http://www.notam02.no/~kjetism/sandysth/, the
-1 or 1 decider should be easy to do:

max_add = hslider("Max add", 0, 0, 100, 1);
d(y,f,pc) = e(y,f,pc) ~ _;
e(y,f,pc,d) = select2(abs(y) < 1, -1*sgn(y),
select2(abs(f) <= max_add/100, -1*sgn(f),
select2(pc==1, d, -1*d)));
sgn(x) = (x>0)-(x<0);

process = d;

(Note that Faust's select2 is a bit different from if-then-else, it has
the branches reversed.)

Faust takes a bit of a different mindset. Instead of thinking in terms
of a memory cell to be changed, imagine a signal that changes over time,
then it's actually quite easy. Of course we've all been raised on a von
Neumann diet, so it takes some time to relearn how to do certain things.
But for me this is what makes Faust so much fun to use. :)

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Kjetil S. Matheussen
2008-02-01 16:38:20 UTC
Permalink
Post by Albert Graef
Post by Kjetil S. Matheussen
The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.
Yep, it takes some discipline, but you also get to reap the benefits
(clear semantics, better output code).
Yes. I'm just pointing out the experimental approach which is
common for music programming. But it might just be a matter
of training.
Post by Albert Graef
Post by Kjetil S. Matheussen
It would be interesting to see how the routine would
look like in faust, if you have the time. :-)
I don't have the time to really work out all the details of your example
right now, but looking at http://www.notam02.no/~kjetism/sandysth/, the
max_add = hslider("Max add", 0, 0, 100, 1);
d(y,f,pc) = e(y,f,pc) ~ _;
e(y,f,pc,d) = select2(abs(y) < 1, -1*sgn(y),
select2(abs(f) <= max_add/100, -1*sgn(f),
select2(pc==1, d, -1*d)));
sgn(x) = (x>0)-(x<0);
process = d;
(Note that Faust's select2 is a bit different from if-then-else, it has
the branches reversed.)
Thanks, that was simple. I'll try figuring out the rest myself.
But what about resampling? The main main signal usually needs to
be resampled up 5-10 times to get a decent sound. Can I do that
with faust? Something like:

process = resample(5,d)
Post by Albert Graef
Faust takes a bit of a different mindset. Instead of thinking in terms
of a memory cell to be changed, imagine a signal that changes over time,
then it's actually quite easy. Of course we've all been raised on a von
Neumann diet, so it takes some time to relearn how to do certain things.
But for me this is what makes Faust so much fun to use. :)
Yes, its something else. I think I'll try to incorporate faust
into snd. It shouldn't be so much work, and it'll provide a
dynamic programming environment for faust, plus that faust can use
snd-rt's realtime engine for proper scheduling and connections
with ladspa/pd/midi/clm/cm/etc., and snd-rt can call faust
fucntions to get a convenient speed boost for dsp processing. A few
modifications to the faust syntax will be necesarry though to make
it work in s-expressions, but it shouldn't be so hard.
Darren Landrum
2008-02-01 16:50:18 UTC
Permalink
Post by Kjetil S. Matheussen
Thanks, that was simple. I'll try figuring out the rest myself.
But what about resampling? The main main signal usually needs to
be resampled up 5-10 times to get a decent sound. Can I do that
process = resample(5,d)
I'm quite curious about this as well. How do tools like Faust and CLAM
handle up- and down-sampling?

-- Darren
Kjetil S. Matheussen
2008-02-01 16:55:56 UTC
Permalink
Post by Darren Landrum
Post by Kjetil S. Matheussen
Thanks, that was simple. I'll try figuring out the rest myself.
But what about resampling? The main main signal usually needs to
be resampled up 5-10 times to get a decent sound. Can I do that
process = resample(5,d)
I'm quite curious about this as well. How do tools like Faust and CLAM
handle up- and down-sampling?
In snd, you do it like this:

(define resampler (make-src <various optional options>))
(src resampler rate (lambda (direction) <input-signal>))
Kjetil S. Matheussen
2008-02-01 16:53:06 UTC
Permalink
Post by Kjetil S. Matheussen
fucntions to get a convenient speed boost for dsp processing. A few
modifications to the faust syntax will be necesarry though to make
it work in s-expressions, but it shouldn't be so hard.
The last sentence was extremely bad formulated. I ment that
the syntax for accessing faust needs to be different, because
programming in snd is s-expressions based. So what is needed
is a preprocessor for faust which runs inside snd, which
translates the snd/faust code code into faust code, then
execute the faust compiler to compile, and after that
dynamically compile and link that code again into snd. This
whole operation shouldn't take more than a few ms.
I have already made such a system for C, and it was
relatively easy to do.
Albert Graef
2008-02-01 18:45:19 UTC
Permalink
Post by Kjetil S. Matheussen
The last sentence was extremely bad formulated. I ment that
the syntax for accessing faust needs to be different, because
programming in snd is s-expressions based.
So what you need is an unparser for s-expressions that produces Faust's
infix syntax, this shouldn't be hard.
Post by Kjetil S. Matheussen
This whole operation shouldn't take more than a few ms.
Hmm, the Faust compiler needs its time, as does the C++ compiler. I
don't think that you can achieve that right now.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Kjetil S. Matheussen
2008-02-01 18:52:44 UTC
Permalink
Post by Albert Graef
Post by Kjetil S. Matheussen
The last sentence was extremely bad formulated. I ment that
the syntax for accessing faust needs to be different, because
programming in snd is s-expressions based.
So what you need is an unparser for s-expressions that produces Faust's
infix syntax, this shouldn't be hard.
Exactly. Thats easy. My "unparser" for C also interprets
strings as C code, which can also be done for faust code,
so that way you also have a way to get full power from
the destination language.
Post by Albert Graef
Post by Kjetil S. Matheussen
This whole operation shouldn't take more than a few ms.
Hmm, the Faust compiler needs its time, as does the C++ compiler. I
don't think that you can achieve that right now.
Ouch. I thought the Faust compiler was quite fast? (I've just
used the online compiler)
And I didn't think about C++. How much time does
the faust compilation and c++ compilation take?
More than 1 second on a fairly modern machine?
But even if its many seconds, I think its worth doing. :-)
Stéphane Letz
2008-02-01 19:04:42 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Albert Graef
Post by Kjetil S. Matheussen
The last sentence was extremely bad formulated. I ment that
the syntax for accessing faust needs to be different, because
programming in snd is s-expressions based.
So what you need is an unparser for s-expressions that produces Faust's
infix syntax, this shouldn't be hard.
Exactly. Thats easy. My "unparser" for C also interprets
strings as C code, which can also be done for faust code,
so that way you also have a way to get full power from
the destination language.
Post by Albert Graef
Post by Kjetil S. Matheussen
This whole operation shouldn't take more than a few ms.
Hmm, the Faust compiler needs its time, as does the C++ compiler. I
don't think that you can achieve that right now.
Ouch. I thought the Faust compiler was quite fast? (I've just
used the online compiler)
And I didn't think about C++. How much time does
the faust compilation and c++ compilation take?
More than 1 second on a fairly modern machine?
But even if its many seconds, I think its worth doing. :-)
The LLVM backend based approach may improve the situation : http://
www.grame.fr/~letz/faust_llvm.html, the day it will work ((-:

Stephane
Albert Graef
2008-02-01 19:40:40 UTC
Permalink
Post by Stéphane Letz
The LLVM backend based approach may improve the situation : http://
That will enable you to skip the C++ compilation, but Faust still does a
lot of stuff behind the scenes, rewriting expressions to normal form,
optimizing code, etc. I found that Faust itself can take seconds to
compile a source with no more than a few dozen lines. That has improved
a lot during the 0.9.9.x series, but still...

But I agree with Kjetil that having an interactive interface via snd
would still be useful. Who cares if it takes a few seconds after editing
the source until you can actually use the component? It's not as if we
want to use Faust for live coding on the stage, do we? ;-)

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef
2008-02-01 18:37:33 UTC
Permalink
Post by Kjetil S. Matheussen
Thanks, that was simple.
Beware, I haven't tested that code. :)
Post by Kjetil S. Matheussen
But what about resampling? The main main signal usually needs to
be resampled up 5-10 times to get a decent sound. Can I do that
process = resample(5,d)
I want that, too. :) There's no (easy) way to do resampling inside Faust
right now, because Faust doesn't support multirate processing yet. I
know that Yann has this on his TODO list, as we already discussed it
last summer. Once multirate processing is there, adding samplerate
conversion (either programmed in Faust or by calling an external C
routine) shouldn't be a big deal any more.

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Fons Adriaensen
2008-02-01 18:46:24 UTC
Permalink
Post by Albert Graef
Post by Kjetil S. Matheussen
But what about resampling? The main main signal usually needs to
be resampled up 5-10 times to get a decent sound. Can I do that
process = resample(5,d)
I want that, too. :) There's no (easy) way to do resampling inside Faust
right now, because Faust doesn't support multirate processing yet. I
know that Yann has this on his TODO list, as we already discussed it
last summer. Once multirate processing is there, adding samplerate
conversion (either programmed in Faust or by calling an external C
routine) shouldn't be a big deal any more.
Won't be easy I'd think. Both resampling and fractional
sample delay lead to the same problem with different
constraints - interpolation. And you can't do high quality
interpolation without delay: the simple fact is that
the value halfway between two samples depends on _all_
the samples, past and future. The dependency goes down
with distance and you can ignore it at some point. Yet
for good results at 48 kHz you need at least something
like 24 samples forward and back. There is no such thing
as 'instant' resampling, which is what you would want
if it's part of a language. Any resample operator would
need to have an 'arbitrary' delay built-in...

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Albert Graef
2008-02-01 20:25:16 UTC
Permalink
Post by Fons Adriaensen
Won't be easy I'd think. Both resampling and fractional
sample delay lead to the same problem with different
constraints - interpolation.
Sure. But what I meant is that it will then at least be possible to
interface to such algorithms, whereas now there's no way to deal with
streams at different rates within the same Faust program.

Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: ***@t-online.de, ***@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Kjetil S. Matheussen
2008-01-25 16:51:23 UTC
Permalink
Post by Fons Adriaensen
I've been searching for real-time audio processing tool that would
permit rapid prototyping, for at least two years now, and I haven't
found anything that up to the requirements.
That is interesting. Which requirements do you miss
from snd-rt? (I have a list myself, but it may not
contain the same as the one you have...)
Kjetil S. Matheussen
2008-01-28 13:45:29 UTC
Permalink
Post by Frank Barknecht
Post by Kjetil S. Matheussen
The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.
I think, Lua (with Vessel, see my other post) may be a good compromise
of both worlds.
Vessel/Lua seems very nice, but it doesn't seem to offer sample by
sample processing. And even if it did, it would be terrible slow.
Faust or snd-rt are better options for doing those kind of tasks.
Post by Frank Barknecht
(It may have not enough parenthesis for your taste. ;)
Yeah. :-)
It amazes me, though, that people use s-expression as an argument
against languages. Even people with phd in computer science seems
to think that s-expression is a valid argument against using a
language. If they have spent 30 years of programming, how hard
can it be then to use a couple of weeks getting used to s-expressions?
Doesn't make sense to me.
Post by Frank Barknecht
Actually as I recently had a quick look at Rick Taube's SAL language
syntax for working with Common Music, I was amazed at how similar SAL
looks and feels to straight Lua code. I even wondered, if inventing a
new domain specifc language like SAL was necessary.
I didn't know SAL was a domain specific language? I thought SAL was
just a synactical frontend for scheme and common lisp?
h***@gmx.at
2008-01-28 22:50:35 UTC
Permalink
I came across osw today, I don't know if it fits the bill but I think
it hasn't been mentioned. http://osw.sourceforge.net/

Best Regards
Philipp
Kjetil S. Matheussen
2008-01-29 19:17:37 UTC
Permalink
Post by Fons Adriaensen
Post by Stephen Sinclair
Post by Fons Adriaensen
Post by Stephen Sinclair
Also, nice in the fact that you can do per-sample computations easily,
How ? I seem to have missed something...
Because you can wait in a 1-sample loop?
Yes, it will use your whole CPU for a loop like that, but this thread
is about prototyping. Obviously you'd rewrite in C for a real
application.
I never claimed chuck is perfect, but I've been liking it a lot
lately. Sure, it can have performance issues depending on how you use
it, but the nice thing is having the option to abuse it that way when
necessary.
This is one of the things I wanted to create a 'rapid prototype'
- a delay line,
- allowing high-quality fractional-sample delays,
- at least 12 outputs, for each two controls: delay, gain,
- smooth 'crossfading' between two control sets, both delay
and gain, controlled by a GUI or by OSC.
It should not take more than 20% CPU on a 2G P4
(other things have to run at the same time).
If you know how to get this faster than by actually
writing it in C++, please let me know !
Quick version for snd-rt below. It use about 10% on my
xp2800, but its easy to optimize so that it use a lot less
by making the dsp function call "out" and "in" only one
time. (that optimization requires two more lines of code,
but the version below is the straight forward one)

I'm not quite sure what you mean by "smooth 'crossfading'" though,
but at least the gain values are interpolated to avoid clicks
when changing values. I'm not sure if that was what you ment.

Guess its time to learn scheme now Fons? ;-)
Oh well, hopefully someone will find this interesting.
To run it, just paste the text below into the terminal snd-ls
was started from.


(define-rt-vector-struct das-delay
:delay (make-delay 20000)
:gain (make-glide-var 0 0.001))

(definstrument (mdelay num-delays)
(letrec* ((das-delays (map make-das-delay (iota num-delays)))
(instrument (<rt-play>
(lambda ()
(for-each (lambda (das-delay)
(out (* (read-glide-var (=> das-delay :gain))
(delay (=> das-delay :delay) (in)))))
das-delays))))
(exit (lambda ()
(-> instrument stop)
(-> d hide)))
(d (<dialog> "multi delay" exit
"Close" exit
"Stop" (<- instrument stop)
"Start" (<- instrument play))))
(for-each (lambda (n das-delay)
(set! (mus-length (=> das-delay :delay)) 1)
(<slider> d (<-> "gain " n) 0 0 2
(lambda (val)
(write-glide-var (=> das-delay :gain) val))
100)
(<slider> d (<-> "delay " n) 1 1 20000
(lambda (val)
(set! (mus-length (=> das-delay :delay)) val))
1))
(map number->string (iota num-delays))
das-delays)
(-> d show)))

(define mdel (mdelay))
Kjetil S. Matheussen
2008-01-29 19:27:50 UTC
Permalink
Post by Kjetil S. Matheussen
To run it, just paste the text below into the terminal snd-ls
was started from.
Or not. snd-ls hasn't the define-rt-vector-struct macro yet.
To run it, start latest snd and then evaluate (load-from-path
"snd_conffile.scm") and after that the code. Well.
Kjetil S. Matheussen
2008-01-30 08:45:35 UTC
Permalink
Post by Yann Orlarey
Hi Fons,
import("filter.lib");
line(i) = vgroup("line %i", *(g) : fdelay2(1024, d))
smooth(0.995);
smooth(0.995); };
process = hgroup("", par(i, 10, line(i)) );
The first line imports a library of filters (written in Faust by
Julius
Smith) that includes several fractional delays based on Lagrange
interpolation.
Then we define a 'line' that combines in sequence (':' operator) a
gain
and a fractional delay encapsulated in a vertical layout. Here we use
fdelay2 a fractional delay with a second order Lagrange interpolation.
It can be replaced by fdelay3 or fdelay4 if better interpolations are
needed.
The gain value g is defined by a vertical slider (in dB) which is
converted in a linear value and then filtered to avoid clicks during
rapid movements. The delay value d is defined by a numerical entry box
also filtered to avoid clicks. The parameter m is the maximum size of
the delay and should be a power of 2.
Wow, that is cool. I wonder about making some faust inspired macros
for snd-rt to make user interfaces more integrated.

I think the snd-rt program below should do the same
as the faust version now, although I'm not too sure about the
correctnes of the delay interpolation and filtering. They both
sounds the same though, I think:

(set! (rt-safety) 0)
(definstrument (line n dialog)
(let ((del (make-delay 1 :type mus-interp-lagrange
:max-size 20000))
(length (make-glide-var 0 100))
(gain (make-glide-var 0 0.005)))
(<slider> dialog (<-> "gain " n) 0 0 2
(lambda (val)
(write-glide-var gain val))
100)
(<slider> dialog (<-> "delay " n) 1 1 20000
(lambda (val)
(write-glide-var length val))
1)
(<rt-play>
(lambda ()
(set! (mus-length del) (read-glide-var length))
(out 0 (* (read-glide-var gain)
(delay del (in 0))))))))

(letrec* ((exit (lambda ()
(rte-silence!)
(-> dialog hide)))
(dialog (<dialog> "Delay line stuff" exit
" exit " exit
"Stop" rte-pause
"Start" rte-continue)))
(for-each (lambda (n) (line n dialog))
(map number->string (iota 10)))
(-> dialog show))



The faust program uses 2.1% percent cpu on my xp2800, while
the snd-rt program now uses 3.8% percent cpu. The reason
for the speed increase for the snd-rt program is because
the scheme list traversals and vector accesses is
removed from the dsp code. Instead the scheduler just runs
10 realtime instances. To run the program, just paste the
code above into snd-ls' terminal.
Kjetil S. Matheussen
2008-01-30 21:47:37 UTC
Permalink
Post by Kjetil S. Matheussen
The faust program uses 2.1% percent cpu on my xp2800, while
the snd-rt program now uses 3.8% percent cpu. The reason
Ouch. That was not entirely correct. I forgot to subtract
the cpu usage spent by jacklib in the faust program. I'm
sorry, that was not intended.

The correct numbers should be:
faust: 1.4% cpu usage
snd-rt: 3.8% cpu usage

(or thereabout, its just average measurements by eye
looking at what jackdmp reports now and then, not
very scientifically.)
Kjetil S. Matheussen
2008-01-30 22:00:32 UTC
Permalink
Post by Fons Adriaensen
Post by Paul Davis
Post by Yann Orlarey
A fully functional jack application can be easily generated using the
faust2jack command or by pasting the above code in the online faust
compiler (http://faust.grame.fr). The performances on my Vaio laptop
I think they call that "game, set and match".
Not really, but still I'm impressed :-)
- Even fdelay4 is not up to the task. There are
gain variations of more than 6dB for a 20 kHz
signal, Fs = 48 kHz. Even stranger, they are
not symmetric w.r.t. the fraction of the delay,
e.g. 10.3 samples shows a different gain than
9.7. Which makes me suspicious.
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
We discussed this two years ago. I both respect and understand
your reasons to take your position on this issue, but I still
strongly disagree with you, and I also think its a bit sad
that you use such strong wording about an issue which there
clearly are two different views upon. Its also sad if you
destroy your equipment, but you are actually
yourself to blame if it happens.

And just to repeat my position: Unless someone can make
it probable that most people prefer jack applications not
to autoconnect by default, all jack programs should
autoconnect by default.

Anyway, this is a jack-dev issue, and there are various
ways to fix the jack server so that it will be possible
to turn off autoconnect [1] for those who prefer so.

However, you (the non-autoconnect people) must push this new
API or functionality into jack, because the rest of us are
satisfied with the current situation where almost all jack
clients autoconnect by default, and therefore its unlikely
for us to find the motivation to push this.


[1] One simple hack you can do is simply just to create some
new dummy ports and set those as being the system default
instead of the real system default.
That hack shouldn't take more than a few hours to
implement. If you feel so strongly about this issue,
you should make such a modification to jack.
Note, this is just a hack to fix the problem temorarily,
not a long-term solution.
Joern Nettingsmeier
2008-01-31 08:43:18 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Fons Adriaensen
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
We discussed this two years ago. I both respect and understand
your reasons to take your position on this issue, but I still
strongly disagree with you, and I also think its a bit sad
that you use such strong wording about an issue which there
clearly are two different views upon. Its also sad if you
destroy your equipment, but you are actually
yourself to blame if it happens.
And just to repeat my position: Unless someone can make
it probable that most people prefer jack applications not
to autoconnect by default, all jack programs should
autoconnect by default.
i don't understand this position - can you clarify?
iiuc, autoconnection here means "connect to the soundcard in/outs" by
default without asking, not "restore something the user has stored in a
configuration", right?
the latter is ok for me (because i can turn it off), the former is
highly irritating - i have never actually been tempted to destroy
equipment, but then my jack graphs aren't usually as complex as fons' :)
the worst thing i've done so far is yank out virtual connections by the
bundle to let off steam :)

to me, autoconnect-by-default doesn't make much sense - jack is about
the possibility of complex graphs and multiple stages of signal
processing, so the assumption "let's hook ourselves up to the soundcard,
it has to be what the user wants" is false most of the time.

i agree that user-friendliness should be a concern as well, but not at
the cost of extra quirks for the pro user. maybe jack clients could
display a pop-up informing the user s/he needs to connect manually (and
how), or at least each jack client should provide a switch to turn off
autoconnection.

regards,

jörn
--
jörn nettingsmeier

home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621

Kurt is up in Heaven now.
Kjetil S. Matheussen
2008-02-01 16:14:10 UTC
Permalink
Post by Joern Nettingsmeier
Post by Kjetil S. Matheussen
Post by Fons Adriaensen
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
We discussed this two years ago. I both respect and understand
your reasons to take your position on this issue, but I still
strongly disagree with you, and I also think its a bit sad
that you use such strong wording about an issue which there
clearly are two different views upon. Its also sad if you
destroy your equipment, but you are actually
yourself to blame if it happens.
And just to repeat my position: Unless someone can make
it probable that most people prefer jack applications not
to autoconnect by default, all jack programs should
autoconnect by default.
i don't understand this position - can you clarify?
iiuc, autoconnection here means "connect to the soundcard in/outs" by
default without asking, not "restore something the user has stored in a
configuration", right?
Yes.
Post by Joern Nettingsmeier
the latter is ok for me (because i can turn it off), the former is
highly irritating - i have never actually been tempted to destroy
equipment, but then my jack graphs aren't usually as complex as fons' :)
the worst thing i've done so far is yank out virtual connections by the
bundle to let off steam :)
to me, autoconnect-by-default doesn't make much sense - jack is about
the possibility of complex graphs and multiple stages of signal
processing, so the assumption "let's hook ourselves up to the soundcard,
it has to be what the user wants" is false most of the time.
i agree that user-friendliness should be a concern as well, but not at
the cost of extra quirks for the pro user.
Don't say "pro user" when you actually mean a person who very often
either has a very complicated jack setup, or someone who has connected
their monitors directly to their loudspeakers. I consider myself
a pro user, but don't do either of that (except for connecting
monitors directly to loudspeakers a few times when not having
a mixer available). But this was discussed two years ago, its
all in the archives, I think.
Post by Joern Nettingsmeier
maybe jack clients could
display a pop-up informing the user s/he needs to connect manually (and
how), or at least each jack client should provide a switch to turn off
autoconnection.
Well, I think popups are the most irritating thing possible.
The simple solution is just to make jack aware, somehow, that
sometimes the client softwares wants to autoconnect, and that
there must be a way to turn that off. Its just a missing
functionallity in jack.
Krzysztof Foltman
2008-02-01 16:23:13 UTC
Permalink
Post by Kjetil S. Matheussen
The simple solution is just to make jack aware, somehow, that
sometimes the client softwares wants to autoconnect, and that
there must be a way to turn that off.
And a way tell where exactly it should be autoconnected, if it's
enabled. In certain cases, it's not system:playback_1 and 2, it may be a
different pair of outputs or even a non-physical port. See Dave
Robillard's mail.

Krzysztof
Kjetil S. Matheussen
2008-02-01 16:27:02 UTC
Permalink
Post by Kjetil S. Matheussen
The simple solution is just to make jack aware, somehow, that
sometimes the client softwares wants to autoconnect, and that
there must be a way to turn that off.
And a way tell where exactly it should be autoconnected, if it's enabled. In
certain cases, it's not system:playback_1 and 2, it may be a different pair
of outputs or even a non-physical port. See Dave Robillard's mail.
Yes, thanks. I forgot that.
Fons Adriaensen
2008-02-01 17:02:01 UTC
Permalink
Post by Kjetil S. Matheussen
Don't say "pro user" when you actually mean a person who very often
either has a very complicated jack setup, or someone who has connected
their monitors directly to their loudspeakers. I consider myself
a pro user, but don't do either of that (except for connecting
monitors directly to loudspeakers a few times when not having
a mixer available). But this was discussed two years ago, its
all in the archives, I think.
Well, for the record, I am a professional user in every sense
of the word you could imagine. I'm being paid to design and
develop audio systems running on Linux, and that is my main
source of income.

If the processing required to drive the speakers (be it crossover
for bi- or tri-amplification, AMB rendering, WFS rendering, any
other spatialisation method, room correction, or any combination)
is done in software, then it is quite normal that the audio card's
outputs are driving the power amps with nothing in between.
It's perfectly safe if you use the right equipment (that will not
produce heavy transients when switched on or off).

I invite you to come to Parma and design a 176-channel volume
control, to be put between the sound cards and the amps, that
I can turn down when starting an app that might autoconnect.
If it works, and if it doesn't make a mess of the calibrated
gains for each channel, and if you can convince the users of
this system that they need it, you will be paid very well and
then you can consider yourself a professional.
Post by Kjetil S. Matheussen
Well, I think popups are the most irritating thing possible.
The simple solution is just to make jack aware, somehow, that
sometimes the client softwares wants to autoconnect, and that
there must be a way to turn that off.
Jack has no way at all to tell if any connection request is
legitimate or not. There are occasions when I want to connect
to the amps directly. The simple solution is that all clients
should be configurable to autoconnect or not, and if they
do, to which ports. A simple environment variable tested by
all apps will do (e.g. something similar to 'EDITOR' which
is used by most apps that need to start a text editor).

Any app that directly connects to the sound card, without
even offering the option not to do so, is like a musician
walking into a studio and plugging his synth directly in
the the control room's power amps. Even if he promises not
to do that again next time, there's a good chance he won't
be welcome anymore.
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Arnold Krille
2008-02-01 17:53:18 UTC
Permalink
Post by Fons Adriaensen
I invite you to come to Parma and design a 176-channel volume
control, to be put between the sound cards and the amps, that
I can turn down when starting an app that might autoconnect.
If it works, and if it doesn't make a mess of the calibrated
gains for each channel, and if you can convince the users of
this system that they need it, you will be paid very well and
then you can consider yourself a professional.
Another requisite: The volume-control has to have a linear response over the
whole frequency spectrum you use and must not add any noise and has to have
reproducible overall-volume-settings. That is where it really starts to get
complicated... ;-)

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Fons Adriaensen
2008-02-01 18:11:05 UTC
Permalink
Post by Arnold Krille
Another requisite: The volume-control has to have a linear response over the
whole frequency spectrum you use and must not add any noise and has to have
reproducible overall-volume-settings. That is where it really starts to get
complicated... ;-)
The one solution that will work is fully digital,
MADI in, MADI out.

One less serious alternative: a giant motor-driven
bank of 176 high-precision potentiometers. We would
need an exra rack for that...

Anything analog and not passive would also have
to ensure there won't be any transients on power
up/down, including accidental ones.

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Arnold Krille
2008-02-01 18:36:44 UTC
Permalink
Post by Fons Adriaensen
Post by Arnold Krille
Another requisite: The volume-control has to have a linear response over
the whole frequency spectrum you use and must not add any noise and has
to have reproducible overall-volume-settings. That is where it really
starts to get complicated... ;-)
The one solution that will work is fully digital,
MADI in, MADI out.
Could also be a patch in jackd adding a DBUS-controlled volume control to the
hw-output-routines. But that would add effects processing whereas jack is
thought to concentrate on just pushing audio around.

Have a nice weekend,

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Paul Davis
2008-02-01 21:08:32 UTC
Permalink
Post by Arnold Krille
Post by Fons Adriaensen
Post by Arnold Krille
Another requisite: The volume-control has to have a linear response over
the whole frequency spectrum you use and must not add any noise and has
to have reproducible overall-volume-settings. That is where it really
starts to get complicated... ;-)
The one solution that will work is fully digital,
MADI in, MADI out.
Could also be a patch in jackd adding a DBUS-controlled volume control
Please STOP all this discussion of coupling DBUS to JACK. JACK is a
cross-platform tool. It is currently dependent on nothing but ANSI C and
POSIX, though on OS X and Windows it does have to work aroudn the fact
that those platforms' POSIX support isn't 100% usable for the same
purposes as on Linux. That isn't go to change.

By all means talk about adding things to the JACK API that make things
possible, but not in the context of DBUS, or CoreAudio, or ASIO or
whatever platform-specific goat floats your boat.

--p
Nedko Arnaudov
2008-02-02 21:29:04 UTC
Permalink
I want to clarify some things,
Post by Paul Davis
Post by Arnold Krille
Post by Fons Adriaensen
Post by Arnold Krille
Another requisite: The volume-control has to have a linear response over
the whole frequency spectrum you use and must not add any noise and has
to have reproducible overall-volume-settings. That is where it really
starts to get complicated... ;-)
The one solution that will work is fully digital,
MADI in, MADI out.
Could also be a patch in jackd adding a DBUS-controlled volume control
As Marc already said jack dbus.patch is not adding functionality to jack
server (server - as the things that serves audio for jack apps) and
will never do that. This is from perspective of the scope of jackdbus
project.

Technically jackdbus is not replacement for the traditional command line
interface. It is alternative interface. Also it is *optional* feature,
[auto]detected and configurable by using the configure script.

I don't see jackdbus replacing the traditional command line interface
anytime soon (if at all). Also this is *not* a goal of the jackdbus
project.
Post by Paul Davis
Please STOP all this discussion of coupling DBUS to JACK. JACK is a
cross-platform tool. It is currently dependent on nothing but ANSI C and
POSIX, though on OS X and Windows it does have to work aroudn the fact
that those platforms' POSIX support isn't 100% usable for the same
purposes as on Linux. That isn't go to change.
There are D-Bus implementations for Windows and MacOS X. Whether they
are usable and/or useful for JACK is another question. Technically it is
possible. I don't spend my time with those operating system and I dont
have required attitude to decide. Nor I have motivation to code for
these platforms.
Post by Paul Davis
By all means talk about adding things to the JACK API that make things
possible, but not in the context of DBUS, or CoreAudio, or ASIO or
whatever platform-specific goat floats your boat.
I completely agree on this.




As for the "volume control in jack" feature, I'd prefer to keep jack
clean of it. If it gets there, as a "control" feature, it will be in
such place, that it can be made accessible though both libjack and dbus
interfaces.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Arnold Krille
2008-02-02 22:02:35 UTC
Permalink
Post by Nedko Arnaudov
As for the "volume control in jack" feature, I'd prefer to keep jack
clean of it. If it gets there, as a "control" feature, it will be in
such place, that it can be made accessible though both libjack and dbus
interfaces.
Me too! I don't really want master-volume-control in jack because its effects.
And jack should concentrate on pushing audio around, not doing effects.

@Paul: I understand that you don't really want dbus and jack mixed.
_If_ jack was ever to get something like a volume-control, would it be okay if
it is controllable by a message system inside jack like Midi (or OSC in the
future)?
Which would be like jack supplying the ports and the transport and then also
providing a client as it is already done with the audio-ports of the hw.

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Fons Adriaensen
2008-02-04 08:15:55 UTC
Permalink
Post by Paul Davis
Please STOP all this discussion of coupling DBUS to JACK. JACK is a
cross-platform tool. It is currently dependent on nothing but ANSI C and
POSIX, though on OS X and Windows it does have to work aroudn the fact
that those platforms' POSIX support isn't 100% usable for the same
purposes as on Linux. That isn't go to change.
I agree. If and when jack gets a 'remote control' interface
I very much hope it will be OSC over UDP and/or TCP.
It's an audio tool after all.
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Marc-Olivier Barre
2008-02-02 20:24:21 UTC
Permalink
Post by Arnold Krille
Could also be a patch in jackd adding a DBUS-controlled volume control to the
hw-output-routines. But that would add effects processing whereas jack is
thought to concentrate on just pushing audio around.
Volume is certainly not something jackd cares about, and there's no
way dbus would fit *inside* jackd. dbus' place is *beside* jackd (as
any controller should be) and should not worry about volumes. Jack
clients should.

dbus for windows and OSX exist at a very early stage only, so let'
keep our dear jackd cross platform...
__________________
Marc-Olivier Barre,
MarcO'Chapeau.
Kjetil S. Matheussen
2008-01-30 22:26:39 UTC
Permalink
Post by Dave Robillard
Post by Fons Adriaensen
- My usual grunge: unless you want me accidentally
destroy some very expensive equipment which is not
even mine, the generated JACK apps
MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
Hear hear. This setting really must be moved into Jack. Let the user
specify the auto-connect ports (or none).
Yes, exactly. And by default, the auto-connect ports are
the same as the physical ones. Those with special setups
are also the ones who must make special configurations.
Fons Adriaensen
2008-01-31 15:44:12 UTC
Permalink
Post by Kjetil S. Matheussen
Yes, exactly. And by default, the auto-connect ports are
the same as the physical ones. Those with special setups
are also the ones who must make special configurations.
The ones I complain about are those that don't even
allow you to configure them permanently for no
autoconnect.

One bad example, sadly, is Ardour. Even if I remove
the auditioner ports and save the session they come
back and autoconnect to my power amps (*) next time
the session is loaded. And it's all too easy to
activate the auditioner - and accidental double
mouse click instead of single one is all that's
required.

(*) Which are in a rack in a separate room. The
connection is digital. The gain controls on the
amps need a screwdriver to adjust them. I'm not
going to run to the racks, and turn down 16
level in once case, 176 in the other, to be on
the safe side each time a start an app (and after
that I'd have to recalibrate them again...).

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Wolfgang Woehl
2008-01-31 17:39:56 UTC
Permalink
Post by Fons Adriaensen
One bad example, sadly, is Ardour. Even if I remove
the auditioner ports and save the session they come
back and autoconnect to my power amps (*) next time
the session is loaded.
Seems to be an assumption buglet. Dangerous indeed.

qjackctl's patchbay lets you work around these surprises:

Define a patchbay profile that has your physical sinks marked as
exclusive. No more clients autoconnect.
Connect your central jack mixer socket to that exclusive physical
socket.
Add more sockets for ardour, alsaplayer, mplayer ... and connect all
those to your central mixer or whatever mechanism you have in place.

Patchbay "documentation" is on http://www.rncbc.org/drupal/node/19

I think the concept is pretty neat and maybe the frugality of this
very documentation has prevented (audio) distros from embracing it
more. Throw in oss bridging, a set of default audio applications as
mixer channels and as sockets in the patchbay ... The one central
audio mixer people are longing for? It's right there.
Post by Fons Adriaensen
going to run to the racks, and turn down 16
level in once case, 176 in the other, to be on
192 amp lines? What are you up to :)

Wolfgang
Arnold Krille
2008-01-31 18:01:27 UTC
Permalink
Post by Wolfgang Woehl
Post by Fons Adriaensen
One bad example, sadly, is Ardour. Even if I remove
the auditioner ports and save the session they come
back and autoconnect to my power amps (*) next time
the session is loaded.
Seems to be an assumption buglet. Dangerous indeed.
How fast is qjackctl? Ii is not an acl in jack directly, it will just
disconnect the connections as fast as it can after getting to know them. But
that could be 200 periods after the 5kHz tone destroyed Fons' speaker...

It is maybe a first solution, but in this regard I would prefer the inclusion
of ACLs in jackd.

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Wolfgang Woehl
2008-01-31 18:25:56 UTC
Permalink
Post by Arnold Krille
How fast is qjackctl? Ii is not an acl in jack directly, it will
just disconnect the connections as fast as it can after getting to
know them. But that could be 200 periods after the 5kHz tone
destroyed Fons' speaker...
Oh, thanks. I wasn't aware of this.

Wolfgang
Wolfgang Woehl
2008-01-31 19:24:56 UTC
Permalink
Post by Arnold Krille
It is maybe a first solution, but in this regard I would prefer the
inclusion of ACLs in jackd.
Do you happen to know whether this has been discussed? Or if someone
put ideas about it somewhere? I'm getting nowhere with google ...

Wolfgang
Arnold Krille
2008-01-31 20:43:22 UTC
Permalink
Post by Wolfgang Woehl
Post by Arnold Krille
It is maybe a first solution, but in this regard I would prefer the
inclusion of ACLs in jackd.
Do you happen to know whether this has been discussed? Or if someone
put ideas about it somewhere? I'm getting nowhere with google ...
That was discussed this month on either lad or lau or ardour or somewhere on
irc. Strange enough I can't find the correpsonding emails here in my kmail.
But I remember paul being not so repellent on the idea/patch(?) as before...

And
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2008-January/020456.html
seems to kind of summarize it...

Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...
Fons Adriaensen
2008-01-31 18:31:18 UTC
Permalink
Post by Wolfgang Woehl
192 amp lines? What are you up to :)
Making lots of noise :-)
No, seriously, the 176-channel one is a Wave Field Synthesis system.
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Kjetil S. Matheussen
2008-02-01 17:28:55 UTC
Permalink
Post by Fons Adriaensen
Well, for the record, I am a professional user in every sense
of the word you could imagine. I'm being paid to design and
develop audio systems running on Linux, and that is my main
source of income.
If it works, and if it doesn't make a mess of the calibrated
gains for each channel, and if you can convince the users of
this system that they need it, you will be paid very well and
then you can consider yourself a professional.
You can be as much of a professional user as you want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Post by Fons Adriaensen
A simple environment variable tested by
all apps will do (e.g. something similar to 'EDITOR' which
is used by most apps that need to start a text editor).
Any app that directly connects to the sound card, without
even offering the option not to do so, is like a musician
walking into a studio and plugging his synth directly in
the the control room's power amps. Even if he promises not
to do that again next time, there's a good chance he won't
be welcome anymore.
We agree about this. Snd has the environment variable
SND_AUTOCONNECT_PORT, or something, but a common name for
all programs would be much better.
Fons Adriaensen
2008-02-01 17:55:11 UTC
Permalink
Post by Kjetil S. Matheussen
You can be as much of a professional user as you want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Which again means it should be configurable.

BTW, JSB may turn in his grave, but I _do_ like the
sound of sandysth... I still have to go through the
works to understand the algorithm...
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Kjetil S. Matheussen
2008-02-01 18:34:15 UTC
Permalink
Post by Fons Adriaensen
Post by Kjetil S. Matheussen
You can be as much of a professional user as you want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Which again means it should be configurable.
Absolutely. I think a new function for jack would be
better than an environment variable though:

int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);

The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
Post by Fons Adriaensen
BTW, JSB may turn in his grave, but I _do_ like the
sound of sandysth... I still have to go through the
works to understand the algorithm...
Thank you very much. :-) I don't understand the algorithm
myself, so if someone else understood it, that would
be great. I think its quite similar to green noise,
which I read about later, created by moore at ucsd if
I remember correctly.
Paul Coccoli
2008-02-03 18:54:07 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Fons Adriaensen
Post by Kjetil S. Matheussen
You can be as much of a professional user as you want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
Which again means it should be configurable.
Absolutely. I think a new function for jack would be
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
If I understand your API above correctly, jackd would need to know
what playback ports it would allow autoconnection to, right? For
example, I'd like to be able to tell jackd that I have a pair of
physical outs connected to my power amp, and I will allow client to
auto-connect to those:

jackd [normal options] --allow-autoconnect --main-monitors
alsa_pcm:playback_3,alsa_pcm:playback_4

One instance where I've found auto-connect useful is with a simple
sample auditioner I wrote that uses gstreamer with the jack sink. I
want the auditioner to require as few clicks as possible, so I can
quickly start it up and check out a bunch of samples without having to
think about connecting it, etc.

In most other situations, I find auto-connect to be completely annoying.
Kjetil S. Matheussen
2008-02-03 19:26:12 UTC
Permalink
Post by Paul Coccoli
In most other situations, I find auto-connect to be completely annoying.
And this api will help you turn it off, if you want to.
Bob Ham
2008-02-04 13:52:32 UTC
Permalink
Post by Kjetil S. Matheussen
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
Even less hassle is for clients to do nothing at all and leave the whole
business entirely for jackd. I suggest the following function instead:

int jack_set_autoconnect(jack_client_t *, int autoconnect);

This enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.

Bob
--
Bob Ham <***@bash.sh>
Kjetil S. Matheussen
2008-02-04 14:14:54 UTC
Permalink
Post by Bob Ham
Post by Kjetil S. Matheussen
int jack_autoconnect_playback (jack_client_t *,
int portnum,
const char *source_port);
int jack_autoconnect_record (jack_client_t *,
int portnum,
const char *destination_port);
The reason is that this API will make it easier
for programs to make autoconnection configurabe.
Autoconnecting the old way (which includes finding
the physical ports and/or checking environment variables
for ports to connect to, etc.) is a lot more
hassle than just calling the functions above.
Even less hassle is for clients to do nothing at all and leave the whole
int jack_set_autoconnect(jack_client_t *, int autoconnect);
This enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1?

But how do libjack know the order of ports? By just
using creation order? Well, I guess that will work.



How about this interface then?

void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);

And then a typical playback client would work like this:

jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Fons Adriaensen
2008-02-04 14:32:23 UTC
Permalink
Post by Kjetil S. Matheussen
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Or this one:


jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
connected = jack_autoconnect (2, out_port);

(one less call !!!)

Where jack_autoconnect() would use environment variables,
read .rc files, invoke the Buddha, or consult Paul Davis or
the oracle of Delphi to find out which ports to use, but
without requiring any special support from jackd itself.

In other words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.

It may end up one day in libjack or in some other place
from where it can be reused.
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Bob Ham
2008-02-04 15:40:12 UTC
Permalink
Post by Kjetil S. Matheussen
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
connected = jack_autoconnect (2, out_port);
In other words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get client authors who say "Well,
I have to implement insanely-annoying-automatic-port-connection because
I have to cater for the people who don't use $your_system" By bringing
autoconnection into JACK itself, there's a standardised, authorised,
proven, approved method.

Bob
--
Bob Ham <***@bash.sh>
Fons Adriaensen
2008-02-04 15:56:00 UTC
Permalink
Post by Bob Ham
Post by Fons Adriaensen
In other words, ** you could write this function today **.
The functionality you want does not require any changes
to jack.
The problem is, you're still going to get client authors who say "Well,
I have to implement insanely-annoying-automatic-port-connection because
I have to cater for the people who don't use $your_system" By bringing
autoconnection into JACK itself, there's a standardised, authorised,
proven, approved method.
It's none of those, and it's crippled.

People who think that calling one (1, uno) function is a problem
should not be writing any form of applications, because they won't
get very far. Typically you need tens, hundreds, thousands. Raising
sheep may be a better occupation for them.

I will respect the opinions, tastes, and personal preferences of anyone
who demonstrates a minimal amount of engagement, but _not_ of someone who
is so blatantly lazy as you suggest (I don't mean you, but the people you
refer to), and stupid enough to admit it.

Ciao,
--
FA

Laboratorio di Acustica ed Elettroacustica
Parma, Italia

Lascia la spina, cogli la rosa.
Bob Ham
2008-02-04 15:08:57 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Bob Ham
Even less hassle is for clients to do nothing at all and leave the whole
int jack_set_autoconnect(jack_client_t *, int autoconnect);
This enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1?
Yes, sorry. The "int autoconnect" parameter would be a boolean
indicator; 1 to enable autoconnecting, 0 to disable it. It would
probably be sensible to have a complementary jack_get_autoconnect()
function to return the value as well.
Post by Kjetil S. Matheussen
But how do libjack know the order of ports? By just
using creation order? Well, I guess that will work.
Indeed. This is how most client-side autoconnecting seems to work at
the moment. Clients simply get "a list" of hardware ports from the
server and connect them in sequence against the client's own ports.
Post by Kjetil S. Matheussen
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Sorry; I obviously wasn't specific enough about the semantics of the
toggle function.

What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally. The
flag that gets toggled would be a property of the engine, not the
client.

In terms of autoconnecting, clients would do quite literally nothing at
all. The above code would be rewritten as follows:

jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);

Clients would never call the new function unless they were control
interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some
gnome-jack-autoconnect-switch applet.

This removes from client authors the burden of implementing
autoconnection, and enables a convenient interface for controlling
autoconnect behaviour.

Bob
--
Bob Ham <***@bash.sh>
Kjetil S. Matheussen
2008-02-04 15:25:33 UTC
Permalink
Post by Bob Ham
Post by Kjetil S. Matheussen
Post by Bob Ham
Even less hassle is for clients to do nothing at all and leave the whole
int jack_set_autoconnect(jack_client_t *, int autoconnect);
This enables a control interface that can present the user with a simple
system-wide toggle switch that would dictate whether or not ports are
automatically connected.
I'm not sure what you mean by the last sentence.
Is the "autoconnect" variable either 0 or 1?
Yes, sorry. The "int autoconnect" parameter would be a boolean
indicator; 1 to enable autoconnecting, 0 to disable it. It would
probably be sensible to have a complementary jack_get_autoconnect()
function to return the value as well.
Post by Kjetil S. Matheussen
But how do libjack know the order of ports? By just
using creation order? Well, I guess that will work.
Indeed. This is how most client-side autoconnecting seems to work at
the moment. Clients simply get "a list" of hardware ports from the
server and connect them in sequence against the client's own ports.
Post by Kjetil S. Matheussen
How about this interface then?
void jack_enable_autoconnect(jack_client_t *);
void jack_disable_autoconnect(jack_client_t *);
jack_client_t *client=...
jack_enable_autoconnect(client);
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
jack_disable_autoconnect(client);
Sorry; I obviously wasn't specific enough about the semantics of the
toggle function.
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally. The
flag that gets toggled would be a property of the engine, not the
client.
In terms of autoconnecting, clients would do quite literally nothing at
jack_client_t *client=...
jack_port_t *out_port[0]=jack_port_register(client,...);
jack_port_t *out_port[1]=jack_port_register(client,...);
Clients would never call the new function unless they were control
interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some
gnome-jack-autoconnect-switch applet.
This removes from client authors the burden of implementing
autoconnection, and enables a convenient interface for controlling
autoconnect behaviour.
Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.

The ideal way, if we follow this thread of thinking, would
be to add another type of jack_port_register function, which
does not autoconnect:

jack_port_register_no_autoconnect(client,...);

However, this new API will break a lot of current programs
which are using the old jack_port_register function instead.
Infact I don't think there is any (sane) way to make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.
Bob Ham
2008-02-04 16:22:40 UTC
Permalink
Post by Kjetil S. Matheussen
Post by Bob Ham
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally.
Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.
As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice.
Post by Kjetil S. Matheussen
Infact I don't think there is any (sane) way to make your
proposal work without creating lots of mess with ports
in old programs who are autoconnecting when it shouldn't.
Backward compatibility (*mumble*) would be maintained by making ports'
default autoconnect bit negative; ie, having to set JackPortAutoconnect
to enable autoconnecting rather than set JackPortNoAutoconnect to
disable. Alas, this means the client author once again has to do
something.

Bob
--
Bob Ham <***@bash.sh>
Kjetil S. Matheussen
2008-02-04 16:29:01 UTC
Permalink
Post by Bob Ham
Post by Kjetil S. Matheussen
Post by Bob Ham
What I am suggesting is not to toggle autoconnecting for individual
clients, but to toggle autoconnecting for *all* clients, globally.
Thanks for clearing up. But I'm pretty sure your idea is too
simple. We also need a way to create ports which are not
autoconnected.
As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice.
No, as I wrote later, (I have problems with my smtp-server), it won't.
(fons' jack_autoconnect function would though, I think thats a good one)
Krzysztof Foltman
2008-02-04 15:03:02 UTC
Permalink
Post by Bob Ham
Even less hassle is for clients to do nothing at all and leave the whole
int jack_set_autoconnect(jack_client_t *, int autoconnect);
This is fine for simple clients that have two outputs that are always
connected to default playback ports, and two inputs that are always
connected to default capture ports. However, it is of little use in the
more complex cases, where ports come and go, some ports may be mono,
there may be 8 synth output ports and 8 soundcard playback ports.

What I could propose is API like this:

int jack_port_add_tag(jack_port_t *, const char *tag, int priority);
void jack_port_remove_tag(jack_port_t *, const char *tag);
const char **jack_port_get_tags((jack_port_t *);
jack_port_t **jack_get_ports_by_tag(jack_client_t *, const char *tag);
void jack_port_tags_free(const char **);
void jack_port_list_free(jack_port_t **);

and perhaps:

typedef void (*PortTagListUpdateCallback)(jack_port_t *t, void *data,
const char *tag, int was_added);
void jack_set_tag_callback(PortTagListUpdateCallback, void *data);

Example tags (some are for physical ports, some are for application ports):

- related to channels: mono, stereo, stereo-left, stereo-right, 5.1,
5.1-left-front, 5.1-right-front, 5.1-left-rear, 5.1-right-rear,
5.1-center-front, 5.1-surround (so a left stereo channel would have
"stereo" and "stereo-left")

- related to purpose: default-out (system:playback_1/2 or first
unconnected mixer input, a mixer will specify the higher priority),
physical-out (physical soundcard), physical-out-2, physical-out-3,
reverb (inputs and outputs of reverb effect), chorus, fx-1, fx-2 (for
global fx)

- related to port purpose: midi-in, kbd (and kbd-2 etc.), drums,
ctlsurface, guitar (for audio capture for guitar), mic (audio capture
for mic), synth (for synth application's midi port AND audio output),
drummachine (for drum machine's midi port and audio output)

- related to relationship to other ports -
audio-output-for:system:midi_capture_1 etc.

- related to application name (name:hydrogen)

Then a definable, prioritized set of JACK-wide rules (provided by
default, but configurable via some sort of GUI) could make reasonable
autoconnection possible.

I guess the autoconnection mechanism could be separate from JACK itself,
as there may be some uses for both simple autoconnection mechanisms
(which only deal with things like connecting instrument outputs to audio
out, and instrument inputs to one predefined MIDI port) as complex
auto-patchbay systems (where you could juggle between 4 different drum
machines, 3 synths and 5 main mixers and have everything working :) ).
And the complex systems might be written at some time in the future or
not at all. The patchbay system (with automatic connection based on
tags) might be a part of session handling as well.

Okay, the system looks very complex so perhaps it is a bit scary. Still,
it's just 6-7 functions in the API, and the only one to be used by
most non-patchbay clients is jack_port_add_tag. Not THAT scary. On the
other hand, perhaps 99.9% of audio application users have at most 2
inputs, 2 outputs and 1 MIDI, and building a complex tagging system for
2 people total is pointless.

Krzysztof
Loading...