Hi guys, I was wondering if it is possible to use rubberband to analize
the transients of a sample. I have looked at the vamp example plugin,
but i couldn't really get into it. What other libs exist for this task?
I've downloaded the aubio vamp plugin to play arround, but I'd rather
like to solve the problem with rubberband, since I already use it for
stretching in TerminatorX.
thanx,
Gerald
Hi guys, I'm proud to announce Terminator 3.83pre for testing
(http://www.set-germany.org/TerminatorX/terminatorX-3.83pre.tar.gz).
Changes: support for rubberband, filehandling exclusively through
sndfile, some bugs fixed and i hope none introduced :)
Rubberband is used for timestretching the samples. Each turntable has
now an extra 'tempo' knob to stretch/shrink the sample without change of
pitch. Furthermore a tempo sync option was introduced to sync clients
tempo to that of the master: Select a master -> Select one or more
clients -> Press play (load some samples before ) and turn the master
tempo knob and note the automatic change of the tempo of the clients.
Note that the tempo is actually just the stretch factor of the entire
sample since the samples aren't analized for their transients (that's
the next feature!).
To simplify the code, i decided to rely totaly on sndfile
(http://www.mega-nerd.com/libsndfile/). That means only the formats
understood by sndfile are supported.
I tried to contact Alexander König, but he hasn't answered. Maybe we
should pull up a sourceforge project?
Looking foreward to answers, ideas and complaints.
Yours,
Gerald
Hi, some of you might like to know...
All the discussion of tempo maps and sync in the Jack lists forced me
to get off my butt and finally fix MusE's midi sync in.
(Someone asked recently in the Jack lists if there are any apps
which sync properly. Here is one answer).
Until now, MusE responded to midi sync by calculating the sync's tempo.
Then, this tempo together with the sample rate and current frame,
determined what 'tick' MusE was currently at. And of course, ticks drive a
midi engine to produce the notes at particular times.
Because a tempo value was used, sub-tick (frame) resolution
was available. Trouble is, that was the problem, a too-lofty goal.
It used a complicated 24-stage clock tempo filter while playing,
and a simpler three-stage filter while idling in stop mode.
This meant it could not respond to fast changes in tempo, even a
simple step. It was prone to drift, even without tempo changes.
Considering incoming tempo can drift slightly, I had originally
recorded the incoming tempos to a list so I would have
and exact record of the whole 'time line'.
But the whole idea of using tempo seemed odd.
So my idea was to 'direct drive' (increment) the midi engine's
tick counter by the incoming sync messages.
Drift between master and slave has been essentially eliminated.
Response is instantaneous.
The only slight drawback is the resolution.
I've abandoned any notion of using a tempo or tempo map,
or to obtain sub-tick (frame) resolution, during external sync.
At standard 24 ticks per quarter note, resolution is 1/3 of a
64th note. Not too shabby, acceptable for music.
Now I'm thinking, this is probably how sync was designed to be used,
considering simple old 80's hardware - (what clock filtering?).
Extreme stress tests with a Roland TR-505 which has an
adjustable 'analog' tempo pot, and a complete song in the app,
with extra 'tick' tracks driving external synths:
Rock solid and stable, even when going absolutely nuts
with the tempo knob! No noticeable resolution effects.
In our SVN repo now.
Tim.
================
| FAUST 0.9.10 |
================
GRAME - Centre National de Creation Musicale - is happy to announce
the release of FAUST 0.9.10. This version introduces several new
possibilities. It is the first official release to offer full
parallelization of the C++ code to exploit multicore architectures,
as well as automatic generation of mathematical documentation.
-------------
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 :
------------
A) C++ Code Generation
------------------
The Faust compiler translates Faust programs in C++. Several new
options have been added to control how the C++ code is generated,
in particular :
- control of the floating point precision : single (default),
double, quad
- code re-organization in simple loops to facilitate automatic
vectorization
- automatic parallelization based on OpenMP
- automatic parallelization based on a specific "Work-Stealing"
algorithm
B) Mathematical Documentation
-----------------------------
Using formal methods the Faust compiler can produce automatically a
complete mathematical documentation of a Faust program. This
mathematical documentation is generated in Latex. It includes
equations, block-diagrams and listings. The documentation can be
customized by the user via <mdoc>...</mdoc> tags inserted in Faust
programs.
This documentation can be used to :
- preserve on the long term a Faust program in a purely
mathematical form, independently from Faust or any other
programming language
- bring some help to understand and debug a FAUST program by giving
the equations of each output signals according to the input signals
and the user interface parameters.
C) Language Extensions
----------------------
- Sequential composition operator (A:B) has been restricted to
expressions so that outputs(A) = inputs(B). This restriction has
several advantages. It improves error detection, makes the code
easier to understand and provides nicer and simpler formal semantic
( A:B is B o A)
- User interface labels can now contain metadata. For example the
label "volume[unit:dB][tooltip:control the output volume of the
reverb]" contains two metadata, a unit definition and a tooltip
message than can be exploited by an architecture file to fine tune
the user interface.
- User interface labels can contain absolute and relative pathnames
to better control the hierarchical structure of the user interface.
For example the label "../volume" points to place the widget one
group higher in the hierarchy.
D) New Audio Architectures
--------------------------
Several new audio architectures have been included, in particular
Action Script, CoreAudio, CSOUND, Chuck, Pure, SND-RT, for a total
of about 20 different plateforms now supported :
- Action Script
- Alsa
- ChucK
- CoreAudio
- CSOUND
- Jack
- LADSPA
- Matlab
- MaxMSP
- Octave
- OSS
- PortAudio
- Pure
- PureData
- Q
- Sndfile
- Snd-RT
- SuperCollider
- SynthFile
- VST
- VSTi (mono)
---------------
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, Thomas Charbonnel, Damien Cramet, Etienne Gaudrin, Albert
Graef, Stefan Kersten, Victor Lazzarini, Matthieu Leberre, Mathieu
Leroi, Kjetil Matheussen, Remy Muller, 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 aqualung people!
your player has been discussed as an interesting way to pave the path of
ambisonics towards world dominance, because it's cross-platform, hooks
up to jack and allows for easy integration of ladspa plugins (where we
could slip in an ambi decoder to make an easy-to-use ambi player for the
rest of us).
problem is: it won't load files with more than 2 channels.
initially, we'd need four channels for first-order b-format, and later 9
and 16 channels could be interesting. the dolby crowd might appreciate six.
how difficult would it be to implement the following?:
* make the number of jack output ports N configurable (because obviously
jack ports can't show up and go away while the program and any playlist
runs, because that makes for messy routing)
* output the channels of each soundfile in the playlist to those N
channels, padding with silence or omitting channels as needed.
this would make a spiffy .amb file player and instantly increase your
user base by at least 20 :-D
corner cases such as automatic resampling will not be important, at
least initially.
if desired, different formats could be dealt with based on number of
channels and/or additional metadata and file format guesses, and played
out to different sets of jack ports for appropriate handling. like so:
configure 2 ports for stereo: aqualung:stereo.[L|R]
configure 4 ports for ambisonics: aqualung:ambi.[W|X|Y|Z]
configure 6 ports for dolby 5.1: aqualung:5-1.[L|C|R|LS|RS|LFE]
in this simple case, aqualung could guess the correct routing based on
channel number alone. later, it would be cool to be able to configure
rule sets for routing rather than hardcoding them, such as:
suffix .amb > route to ambi
no of channels 4 > route to ambi
WAVEX flag enterprise > route to holodeck (you get the idea)...
wdyt?
btw, please remove the cc: to sursound, since it's a moderated list - i
will summarize your replies accordingly.
best,
jörn
Hey all,
I've been dev-ing MIDI/audio programs in C++ & Python for a while, but I'm
struggling with one concept:
How to approach time. If i want to "schedule" events for the future, what
is the "correct"
way to do this?
I've read some docs about Jack's timebase & transport system, ideally I
want to support that,
but I dont seem to grasp the "whole".
I could write a class that has a "MIDI clip" inside it, and then play back
multiple
of these clips from thier classes. Or should I approach more along the
lines of each
MIDI clip being inside a std::vector<MidiClip>?
How does eg: Seq24, Ardour, RoseGarden etc approach the time management?
I've attempted to read docs/sources, but the projects are too big for me to
understand
how the "time-system" works.
Hope somebody could shed some light on this, -Harry
PS: If there's a tutorial or simple example I could read, please say, I've
googled but not found
any tutorial on the subject.
In writing arpage, I find that qtractor and seq24 provide good BBT data.
Ardour was ok, but Hydrogen didn't do so well.
-- sent from mobile
On Jan 22, 2010 1:40 PM, "Olivier Guilyardi" <list(a)samalyse.com> wrote:
On 01/21/2010 03:28 PM, torbenh wrote: > On Thu, Jan 21, 2010 at 07:48:20AM
-0500, Paul Coccoli wrot...
I think that Harry's question was more about time as he rephrased it in his
2nd
post, than about event queuing, although this is of course linked.
But in regard to time, what about Beat-Bar-Tick which seems to be important
to him?
How many applications support (set or handle) the Beat-Bar-Tick related jack
transport position fields?
In general, how reliable are these fields?
--
Olivier
_______________________________________________ Linux-audio-dev mailing list
Linux-audio-dev@lists...
Hi,
I search for a free and open source sound/music lib to integrate sound and music in a game.
The game runs on Lin/Win32/OSX so it has to be crossplatform.
I know openAL, but this is too big and tons of people have problems with it.
Anything slimmer around?
Nils
