Stephen Sinclair wrote: 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

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

Hallo, Fons Adriaensen hat gesagt: // Fons Adriaensen wrote: 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__

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 Fons Adriaensen a écrit :

On Tue, Jan 29, 2008 at 06:25:50PM -0500, Paul Davis wrote: 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.

On Wed, Jan 30, 2008 at 11:16:24AM -0500, Dave Robillard wrote: Port locking was removed recently... 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.

On Thu, Jan 31, 2008 at 10:06:07AM +0100, Stéphane Letz wrote: 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.

Hi Yann, 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.

Hi Yann, I will have some of my own, when I start programming in Faust ! 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. So the generated code should really do that. 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. 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. Interesting stuff (as usual from JOS), thanks for the pointer. 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 a écrit : 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] 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

Hallo, Kjetil S. Matheussen hat gesagt: // Kjetil S. Matheussen wrote: 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__

On Fri, 1 Feb 2008, Albert Graef wrote: Yes. I'm just pointing out the experimental approach which is common for music programming. But it might just be a matter of training. 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) 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.

On Fri, 1 Feb 2008, Darren Landrum wrote: In snd, you do it like this: (define resampler (make-src <various optional options>)) (src resampler rate (lambda (direction) <input-signal>))

Kjetil S. Matheussen wrote: So what you need is an unparser for s-expressions that produces Faust's infix syntax, this shouldn't be hard. 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: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

Le 1 févr. 08 à 19:52, Kjetil S. Matheussen a écrit : The LLVM backend based approach may improve the situation : http:// www.grame.fr/~letz/faust_llvm.html, the day it will work ((-: Stephane

Kjetil S. Matheussen wrote: Beware, I haven't tested that code. :) 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: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

Fons Adriaensen wrote: 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: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag