Hey guys!
In many DAWs it is not possible to use a vocoder, because it requires two
inputs - a modulator and a carrier. So in order for this to work you either
have to allow routing in the mixer (which none of the linux daws are capable
of, as far as I know) or else use vocoder as an external programm.
While the latter is a partial solution, it is not always desirable. Having
Vocoder as just a plugin inside a DAW is something that I personally always
needed.
I wanted to suggest a Vocoder with built-in Modulator.
This can be accomplished in two methods:
a. The user loads a wave file from the plugin's GUI, a wave file that would
act as a modulator.
b. The plugin has a set of predefined waves and/or a set of oscillators with
basic waveforms (like the famous Orange Vocoder VST).
There are two Vocoders on Linux that I know of - the LADSPA Vocoder (and its
LV2 port, done by a different programmer) and the Vocoder, created by the
guys of the Rakarrack team.
Both vocoders are definetely very capable tools.
I wanted to ask whether
1. modifying them in a manner I specified above is a difficult task
2. and whether someone would want to take it up.
Additionally, how difficult is it to include several features that would
make this vocoder more like an instrument rather than just a plugin that
does only one job, namely filter, fine tune for the modulator and LFO.
Louigi Verona.
================
| FAUST 0.9.24 |
================
GRAME - Centre National de Creation Musicale - is happy to announce
the release of FAUST 0.9.24. This version fixes several bugs,
and introduces some new possibilities in the language.
-------------
About FAUST :
-------------
FAUST (Functional Audio Stream) is a functional programming
language specifically designed for real-time signal processing and
synthesis. A distinctive characteristic of FAUST is to be fully
compiled. The FAUST compiler translates DSP specifications into
very efficient C++ code that works at sample level. It targets
high-performance signal processing applications, libraries and
audio plug-ins for a variety of audio platforms and standards. A
same FAUST specification can be used to easily generate native
JACK or ALSA applications, as well as CSOUND, LADSPA, MAX/MSP, PD,
Q, SC and VST plugins.
The Faust distribution can be downloaded at:
http://sourceforge.net/projects/faudiostream
Two mailing lists are available:
https://lists.sourceforge.net/lists/listinfo/faudiostream-develhttps://lists.sourceforge.net/lists/listinfo/faudiostream-users
In order to test FAUST without installing it, please refer to the
Online Faust Compiler:
http://faust.grame.fr
------------
What's new :
------------
- Explicit substitutions. The language has been extended with new
expressions type : exp[x1=def1; x2=def2; ...] allowing explicit
substitutions in the lexical environment of an expression. This
extension allows for instance, to customize an existing component
by replacing some of its internal definitions without having to
modify its source code. This extension is particularly useful to
promote better code reuse.
- Improved mathematical description (--mathdoc option) and support
for two new languages : German (-mdlang de) and Italian (-mdlang
it)
- Support for floating point numbers in scientific notation and
better precision for floating point constants. The precision used
to print a floating point constant in the generated C++ code is no
more limited to 6 digits. It is now dynamically adjusted to find
the minimal number of digits that will produce the same internal
representation when read back. This approach guarantees accuracy
without sacrificing for readability.
- All expressions are now systematically represented in polynomial
forms. For example x*x will be replaced by x^2. If x is a complex
expression the later form has several advantages, in particular to
limit CSE.
- Lazy semantics to select2 and select3 : the code generated for
select2 and select3 is now based on conditional expressions
((cond)?exp1:exp0 ) instead of tables. The resulting code is more
efficient as the stateless parts of the branches are not computed
every time but only when really needed.
- new --task-graph option. It produces a graphical representation
of the internal DAG of task in dot format (Graphviz
http://www.graphviz.org/). This DAG is useful for example to
understand the potential parallelism of a program as analyzed by
the Faust compiler
- Two new tools : faust2graph and faust2graphviewer. These tools
make use of the --task-graph option in order to produce the
graphical representation, as a PDF file, of the internal DAG of
tasks of a Faust program (require Graphviz).
- new reduce.lib library. It provides various operations on block
of samples based on a high order 'reduce(op, n)' fold-like
function. Moreover the music.lib library has been extended with
break-point functions and multiple decorrelated random and noise
generators. New flanger and stereowidth control have been added to
the effect.lib library.
- new iPhone architecture. It consists in a iphone-cocoa.cpp
architecture file and an Xcode template project to be used to
produce the applications. Use "make iphone" in the example folder
to build the examples for the iPhone.
- improved cross plateform compatibility and brand new visual
studio 2008 project to build Faust on windows machines.
----------
Bug Fixes:
----------
- Report error when non-integer table size is detected during
compilation
- Corrected partial application of power operator. Now ^(n) is
equivalent to \(x).(x^n) and not anymore to \(x).(n^x)
- Added missing faustpower definition when power function is
used only in table content.
- Fixed lock-free implementations of PopHead and PopTail functions on
work stealing queues in --scheduler mode
- Corrected missing dependencies in the internal DAG of tasks
- Added missing cache code to slow shared expressions used delayed
- Added missing cache code to foreign functions
----------------
Acknowledgments:
----------------
Many persons have been contributing to the FAUST project by
providing code for the compiler, architecture files, libraries,
examples, documentation, scripts, bug reports, ideas, etc.
I would like to thank them and especially: Fons Adriaensen, Tiziano
Bole, Baktery Chanka, Thomas Charbonnel, Damien Cramet, Etienne
Gaudrin, Albert Graef, Stefan Kersten, Victor Lazzarini, Matthieu
Leberre, Mathieu Leroi, Kjetil Matheussen, Remy Muller, Sampo
Savolainen, Nicolas Scaringella, Stephen Sinclair, Travis Skare,
Julius Smith, as well as my colleagues at GRAME, in particular :
Dominique Fober, Stephane Letz and Karim Barkati, and from the
ASTREE project : Jerome Barthelemy (IRCAM), Alain Bonardi (IRCAM),
Raffaele Ciavarella (IRCAM), Pierre Jouvelot (Ecole des
Mines/ParisTech), Laurent Pottier (U. Saint-Etienne)
Yann Orlarey
GRAME
Hi LADs,
Following up on the LAC Tools round-table, I've started a wiki page:
http://wiki.linuxaudio.org/wiki/tools_comparison
Since I've not taken part in the discussion, I'm missing a few footnotes
and explanation for keys in the context (eg. batch, sync). Could you
please enlighten me, or just fill in the missing content there.
IMHO it'd also make sense to do a 2nd table with orthogonal practical
information, for instance:
audio: JACK,ALSA,..
midi: JACK,ALSA,ALSA-seq
audio-file-formats: pcm,mp3,gig,mid,..
control: OSC,TCP,pipe,MMC,..
interop/sync: jack-transport,MTC
plugins (if applicable): LV2,LADSPA,VST,AU,..
Come to think of it, those could be integrated in the apps-database as
tags for each tool, similar to:
http://wiki.linuxaudio.org/apps/categories/jack_transport
but let's get the categories/tags straightened out before starting on an
implementation and posting it to LAU. What do you think?
Cheers!
robin
Greetings;
Can someone go look at lists.linuxaudio.org? The bottom line of the message
is timing out.
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"Live or die, I'll make a million."
-- Reebus Kneebus, before his jump to the center of the earth, Firesign
Theater
Hi everyone,
We have a new post in our department, which might interest some of you.
http://www.publicjobs.ie/publicjobs/en/star/goToJobDetails.do?id=419
Unfortunately, given my involvement in the selection process, I can't
answer any queries related to this post, but
my colleague Gordon Delap will be most happy to do so.
Maynooth is an interesting place to be at the moment, so I hope some
of you will find this worth a go.
All the best
Victor
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack audio graph.
guitarix provide a jack midi input port to connect a midi controller
(midi learn) and a (3 channel) jack midi output port, feed by a
(scalable) mix of the tuner and a beat-detector.
Release 0.08.0 comes with a bunch of major changes :
* new portmap window
* new BiQuad Filter
* new Moog Filter
* new Flanger
* new post processing tube3
* new two 10 band parametric EQ's
* new oversample mode selector(1x -8x)
* fix some bugs in midi out
* reworked tuner interface (show frequency(hz))
* new configure options (see ./waf --help for more info)
have fun
________________________________________________________________________
guitarix is licensed under the GPL.
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
please report bugs and suggestions in our forum here:
http://sourceforge.net/apps/phpbb/guitarix/
________________________________________________________________________
For capture, guitarix uses the great 'jack_capture'
(version >= 0.9.30) written by Kjetil S. Matheussen.
If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
zita-convolver library, and,
for up/down sampling we use zita-resampler,
both written by Fons Adriaensen.
If you don't have it installed, get it here:
http://www.kokkinizita.net/linuxaudio/index.html
We use the marvellous faust compiler to build the amp and effects and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
________________________________________________________________________
For faust users :
All used Faust dsp files are included in /guitarix/src/faust,
the resulting cc files are in /guitarix/src/faust-cc
The tools we use to convert (post-processing and plot)
the resulting faust cpp files to the needed include format,
stay in the /guitarix/tools directory.
________________________________________________________________________
regards
Hermann Meyer, James Warden, Andreas Degert
Patrick Shirkey wrote:
>...
> Wanda da Bizzarre Bunny Rocks!!!! Very heavy dynamics they are
> achieving. How were the ears after that set? Or maybe a better question
> is how many heads exploded during that set?
None. Stefan Janssen was at the mixer, which meant that we could walk around safely without earplugs.
Great set indeed !
Cheers,
Marc
I have an idea in mind for an application that would involve a core
audio callback responsible for playing several sounds at the same
time, each being streamed in by some as-yet-undetermined means.
Before I get too far into it, I have a few questions about the best
method for ensuring that the audio callback is not interrupted for
lengthy disk access, etc. Obviously I am not planning on doing the
main disk I/O in the callback, but I am thinking about the best means
for the callback to communicate with the rest of the application.
Possibly I might like to support having some of these streams come
from external processes, opened through popen() for example.
So, the idea for an RT audio callback is that it should not wait on
data, (whether it comes from a file or process), but continue
processing the other streams if audio data is not immediately
available. There are a few ways to do this in Linux:
1) Have a secondary thread responsible for passing data to the audio
callback through a wait-free ring buffer.
2) Read from a pipe, FIFO, or socket from another process (e.g.
popen), using select() or poll() to check when there is actually data
to read.
3) Read from a file, using select()?
4) The async I/O API.
5) Interprocess shared memory, presumably using a semaphore of some
kind. I guess this is similar to (1) but for inter-process
communication.
The question is, which one of these methods is the most "real-time
friendly"? Under what conditions, if any, can I be sure a read() will
not block? Is there any advantage to threads vs. processes? Using
async I/O I suppose I could avoid either one. Are there any general
guidelines somewhere for dealing with I/O in audio applications?
thanks in advance,
Steve
Hi,
i have another question to RME experts (hi Florian!).
the system i need to build should have 8 AES inputs and 24 AES outputs.
For that, i see two basic approaches 1) using two RME AES-32 (*) cards
in world-clock synch and 2) using a RME hammerfall with 24 ADAT
input/outputs and then several 8ch ADAT<->AES converters such as the
Aphex 144 (+), which costs about 400€ each 8ch unit.
Option 1 seems to me simpler and cheaper but i ignore if is feasible and
reliable: Have anyone had good experiences using two clock-synced RME
cards with jack?
Are there other options apart from 1 and 2?
Thanks a lot!
P
* http://www.rme-audio.de/en_products_hdsp_aes32.php
+ http://www.aphex.com/144.htm
hi *!
the lac2010 presentation recordings are now available at
http://www.linuxproaudio.org/lac2010/ - kudos to faberman for
very-close-to-realtime post-production!
let me take the opportunity to thank all stream team people (many of
them members of the linux video community, who put in many hours of
volunteer work to cover our beloved little annual meeting)!
check out their works and websites, join their projects, send them beer!
christian thäter, germany (http://lumiera.org/)
- cam operator, vision mixing
florian faber, germany
- post production, archive, software support, club mate
frank neumann, germany
- cam operator, emcee
herman robak, norway (http://developer.skolelinux.no/~herman/)
- director of photography, cams, vision mixing, hardware
marc-olivier barre, france (http://marcochapeau.org/)
- relay operator
yours truly, germany (http://stackingdwarves.net)
- vision mixing, technical supervisor, relay operator
raffaella traniello, italy (http://www.g-raffa.eu/,
http://vimeo.com/raffatraniello)
- cam operator
robin gareus, france (http://gareus.org/)
- hardware, setup, technical support
thijs koerselman, the netherlands (http://www.vauxlab.com)
- cam operator
wouter verwijlen, the netherlands (http://www.wouterverwijlen.nl)
- cam operator
and of course major kudos to marc groenewegen and everyone at hku for a
great conference!
best,
jörn