I've been looking around for a library to read and write SFZ files,
which is an open sampler format released by Cakewalk:
http://www.cakewalk.com/DevXchange/sfz.asp
Finding none, I thought I might try my hand at writing a library for
this myself, as there is no embedded wave information like with Gig
files. SFZ is simply a text file to be parsed.
Now, I know about writing a good header file, and its associated class,
and all that, but I have no knowledge of how to write it as a dynamic
library. Google searches on every possible permutation have been
worthless to me as well.
I would prefer to write it in C++, as that's what I know, and even then,
not too well, hence why I thought I'd start with something simple like
parsing a text file. If anyone has any advice, recommendations, or
ideas, I'll happily listen and learn. I have yet to think too much about
how the data will be stored in the class, and what methods to make
available to access it, so if anyone knows any best practices there, I'd
really like to know. Consider this a feeler post.
I'd ultimately want this for a future project, which you can guess at by
now.
Thank you for the help!
Regards,
Darren Landrum
I am doing some preliminary testing of CUDA for audio, Version 2 (final)
has been out for a couple of days, and this is also what I am using.
In order to get anything done, one will always have to do something else
first, here: Get some data transferred to the board. Surprisingly this
appears to be ten times harder than getting the data back, at least for
very small data sets representative of a bunch of on/off events or a
milliseconds worth of samples.
For 1024 bytes the transfer will take about 0.2 ms. That is 20% of the
available time if we use a time granularity of a single millisecond.
OTOH this appears to be mostly an intial constant, (much) more data can
be transferred in the exact same amount of time if that is what is
needed.
Now my card (8400GS) is neither the latest nor greatest and I therefore
wonder if anybody with better equipment is experiencing the same
phenomenon? This card does not support aynchronous transfers, which
otherwise might have been the thing to use here.
mvh // Jens M Andreasen
Howdy! Vacation time is now gone and the rentrée is upon us, at least on
this hemisphere side of the globe ;) Silly season, beloved August,
summertime it is. And before it's too late, I'm proud
to announce that a new alpha has summoned to the challenge:
Qtractor 0.2.1 (fainty diva) has been released!
Release highlights:
- Gradient eye-candy (NEW)
- DSSI multi-instance plug-in issue fixed
- Clip waveform/piano-roll rendered while recording (NEW)
- MIDI pitch-bend, omni-channel filtering and recording fixes
- Play-head positioning in the thumb-view (NEW)
- And many few more (see change-log below:)
For the clueless:
Qtractor is an audio/MIDI multi-track sequencer application written
in C++ with the Qt4 framework [1]. Target platform is Linux, where the
Jack Audio Connection Kit (JACK) for audio [2] and the Advanced Linux
Sound Architecture (ALSA) for MIDI [3] are the main infrastructures
to evolve as a fairly-featured Linux desktop audio workstation GUI,
specially dedicated to the personal home-studio.
Author:
Rui Nuno Capela <rncbc at rncbc dot org>
Weblog:
http://wwww.rncbc.org
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) [15] version 2 or later.
Features:
- Multi-track audio and MIDI sequencing and recording.
- Developed on pure Qt4 C++ application framework [1] (no Qt3 nor KDE
dependencies).
- Uses JACK [2] for audio and ALSA [3] sequencer for MIDI as multimedia
infrastructures.
- Traditional multi-track tape recorder control paradigm.
- Audio file formats support: OGG (via libvorbis [6]), MP3 (via libmad
[7], playback only), WAV, FLAC, AIFF and many, many more (via linsndfile
[4]).
- Standard MIDI files support (format 0 and 1).
- Non-destructive, non-linear editing.
- Unlimited number of tracks per session/project.
- Unlimited number of overlapping clips per track.
- XML encoded session/project description files (SDI).
- Point-and-click, multi-select, drag-and-drop interaction (drag, move,
drop, cut, copy, paste, delete, split)
- Unlimited undo/redo.
- Built-in mixer and monitor controls.
- Built-in connection patchbay control and persistence (a-la QjackCtl [13]).
- LADSPA [5], DSSI [11] and native VSTi [12] plug-ins support.
- Unlimited number of plug-ins per track or bus.
- Plug-in presets, programs and chunk/configurations support.
- Audio/MIDI clip fade-in/out (linear, quadratic, cubic).
- Audio clip time-stretching (WSOLA-like or via librubberband [9]),
pitch-shifting (via librubberband [9]) and seemless sample-rate
conversion (via libsamplerate [8]).
- Audio/MIDI track export (mix-down, merge).
- Audio/MIDI metronome bar/beat clicks.
- MIDI clip editor (piano roll).
- MIDI instrument definitions (a-la Cakewalk(tm) [15])
- JACK transport sync master.
- MMC control surface enabled.
- Configurable keyboard shortcuts.
Requirements:
- mandatory
libqt4 [1]
libjack [2]
libasound [3]
libsndfile [4]
LADSPA [5]
- optional
libvorbis [6]
libmad [7]
libsamplerate [8]
librubberband [9]
liblo [10]
DSSI [11]
VST-SDK [12]
Download:
http://downloads.sourceforge.net/qtractor/qtractor-0.2.1.tar.gz
Change-log:
0.2.1 2008-08-30 The Faint Diva
- Gradient eye-candy now featured for clips, tracks and mixer strips
widget backgrounds, disabled on configure time (--disable-gradient).
- MIDI pitch-bend/wheel events are now captured/recorded properly;
in fact, there was this ancient bug, now squashed, as all MIDI
clips weren't being stored at all if there weren't a single note
event captured.
- MIDI channel translation is finally in effect on monitored tracks,
specially the ones set in omni-channel input mode.
- MIDI open files dialog gets a few more file filter types now.
- Playhead position is now shown, updated and can be also set on the
main toolbar session thumb-view (shift-click to set the playhead).
- The floating selection, as shown for a clipboard pasting operation,
has been corrected regarding time scale (horizontal zoom) changes,
while in the main track-view. Also fixed final position snapping
precision (spotted in bug #2055846).
- Current tempo and snap-per-beat setting now survive session cycling.
- DSSI plugins implementing run_multiple_synths (eg. fluidsynth-dssi)
are now formally supported according to the DSSI spec (hopefully);
note that previously one could only have one DSSI plugin instance
loaded in session in any given time, otherwise a sudden crash was
in sure demand when either plugin got activated (fixes bug #2048198).
- Audio plugin outputs now overrides each other when the number
of output ports does not match the number of mix-down audio
channels and thus fixing a nasty crash bug in the process.
- All custom font sizes are now set relative to default global font.
- Changing loop points by dragging on the time rulers is now mapped
as undoable/redoable commands as it ought to be ever since.
- Drop-span option (View/Options.../Drop multiple audio files
into the same track) now takes into effect the current session
snap-per-beat setting when concatenating multiple audio clips.
- All plugins get their default bank/program selected on insertion.
- Make record armed tracks muted for playback, a needed regression
to let both audio and MIDI tracks behave consistently regarding
input monitor switching through output.
- Fixed a pretty old and shameless bug regarding MIDI clip recording,
in which cases the queue start time offset was not taken into account,
with captured events being recorded with erratic long delays.
- Almost complete refactoring of the clumsy audio peak file classes,
possibly making it even clumsier but straight neverthless, with the
noble and final aim to build it in-flight and draw the waveforms
while recording is rolling.
- Recording clips get their initial name labels drawn while fade-in/out
handles are dropped as found pretty useless while recording.
- Escape key now closes connections and mixer widgets as found usual.
Disclaimer:
Qtractor is (still) in some alpha stage of development, although already
functional it surely has a plenty of lurking bugs. It also lacks some
features that some might find critical in the application field. All is
(still) not lost, as the following are among the ones planned to be
worked on in the times to come (not in any particular order):
- Automation and MIDI controller mapping.
- Session/project templates.
- Puch-in/out and loop recording (takes).
- Audio clip cross-fading.
- Audio effect send/return aux. inserts.
- Clip locking, muting, normalize (gain).
- LV2 plug-in support.
- JACK MIDI support.
- Tempo and key signature map.
- Paste-repeat command.
- MIDI SysEx manager.
- MIDI event list editor.
- MIDI editor (piano roll) draw mode.
- MIDI groove/swing quantize.
- OSC interface.
- Scripting.
- Etc. etc.
References:
[1] Qt4 (core, gui, xml), C++ class library and tools
for crossplatform development and internationalization
http://www.trolltech.org/products/qt/
[2] JACK Audio Connection Kit
http://jackaudio.org/
[3] ALSA, Advanced Linux Sound Architecture
http://www.alsa-project.org/
[4] libsndfile, C library for reading and writing
files containing sampled sound
http://www.mega-nerd.com/libsndfile/
[5] LADSPA, Linux Audio Developer's Simple Plugin API
http://www.ladspa.org/
[6] libvorbis (enc, file), Ogg Vorbis audio compression
http://xiph.org/vorbis/
[7] libmad, High-quality MPEG audio decoder
http://www.underbit.com/products/mad/
[8] libsamplerate, The secret rabbit code, C library
for audio sample rate conversion
http://www.mega-nerd.com/SRC/
[9] librubberband, Rubber Band Audio Time Stretcher,
an audio time-stretching and pitch-shifting library
http://breakfastquay.com/rubberband/
[10] liblo, Lightweight OSC implementation
(needed for DSSI GUI support)
http://liblo.sourceforge.net/
[11] DSSI, an API for soft synth plugins with custom user interfaces
http://dssi.sourceforge.net/
[12] VST SDK, Steinberg's Virtual Studio Technology (see README.VST)
http://www.steinberg.net/
[13] QjackCtl - JACK Qt GUI Interface
http://qjackctl.sourceforge.net
[14] GNU General Public License
http://www.gnu.org/copyleft/gpl.html
[15] Cakewalk (by Roland), powerful and easy-to-use tools
for Windows-based music and sound production
http://www.cakewalk.com/
Cheers && Enjoy.
--
rncbc aka Rui Nuno Capela
rncbc at rncbc dot org
http://www.rncbc.org
Kryz, your mail-severs seems to be down and when I checked out if you
had a running WWW, I got this message:
"Chwilowo nic tu nie ma" [We are not here yet]
So, back to the list ... This time corrected as per second mail:
On Tue, 2008-08-26 at 11:12 +0100, Krzysztof Foltman wrote:
> Jens M Andreasen wrote:
> > I am doing some preliminary testing of CUDA for audio, Version 2 (final)
> > has been out for a couple of days, and this is also what I am using.
>
> Does it require the proprietary drivers and/or Nvidia kernel module?
>
Yes, and not only that. The proprietary drivers distributed with say
Mandrake, Ubuntu et al won't work either. Uninstall that, change your X
setup to vesa (to stop recursive nvidia installer madness) and then get
your CUDA driver and compiler from:
http://www.nvidia.com/object/cuda_get.html
> What kind of things is the gfx card processor potentially capable of
> doing? Anything like multipoint interpolation for audio resampling
> purposes? Multiple delay lines in parallel? Biquads? Multichannel
> recording to VRAM?
Multichannel recording by itself would be a waste of perfectly good
floating point clock-cycles, but anything that you can map to a wide
vector (64 to 196 elements) is up for grabs. A 196 voice multi timbral
synthesizer perhaps or 64 channel-strips with basic filters and
compressor/noise-gate for remix. The five muladds needed for a single
biquad filter times the number of bands you need to equalize on fits the
optimal programming model quite well.
The linear 2D interpolator is also available and even cached. Perhaps
not the worlds most useful toy for audio-resampling, but could find its
way into some variation of wave-table synthesis. It can be set up to
wrap around at the edges, which I find kind of interesting.
Random access to main (device) memory is - generally speaking - a bitch
and a no-go if you cannot wrap your head around ways to load and use
very wide vectors.
There are some 8096 fp registers to load into though, so all is not
lost. Communication, permutation and exchange of data between vector
elements OTOH is then fairly straight forward and cheap by means of a
smallish shared memory on chip.
The more you can make your algorithm(s) look like infinitely brain-dead
parallel iterations of multiply/add, the better they will make use of
the hardware. The way I see it, the overall feel of your strategy should
be something like "The Marching Hammers" animation (from Pink Floyd: The
Wall.)
> Is it possible to confine all the audio stream transfer between gfx
> and audio cards to kernel layer and only implement control in user
> space? (to potentially reduce xruns, won't help for control latency
> but at least it's some improvement)
>
Yuo you mean something like DMA? Yes I would have thought so but this is
apparently not always the case, Especially not on this very card that I
have here. :-/
The CUDA program running on the device will have priority over X though.
So no blinking lights (nor printfs) before your calculation is done. For
real-time work, I reckon this as a GoodFeature (tm)!
Potentially this can also hang the system if you happen to implement the
infinite loop (so don't do that ...)
> Would it be possible to use a high level language like FAUST to
> generate CUDA code? (by adding CUDA-specific backend)
>
The problem would be to give Faust a good understanding of the memory
model and how to keep individual vector elements away from collectively
falling over each other.
But I must admit that I am not too familiar with what Faust is actually
doing? Would it be of any help to you with a library of common higher
level functionality like FFT and BLAS?
---8<---------------------------------------------
- "CUBLAS is an implementation of BLAS (Basic Linear Algebra
Subprograms) on top of the NVIDIA(r) CUDA(tm) (compute unified
device architecture) driver. It allows access to the computational
resources of NVIDIA GPUs. The library is self-contained at the API
level, that is, no direct interaction with the CUDA driver is
necessary."
------8<................................
But observe that:
... - "Currently, only a subset of the CUBLAS core functions is
implemented."
/j
> Krzysztof
>
Hi,
After the latest Intel announcment that they are indeed working
seriously on wireless electricity uses resonance to transmit hte energy
sources I am wondering if anyone has ideas on whether that would affect
audio quality as resonance is an important part of the ambience of live
sound.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
Hi,
One of the other technologies demoed last weekend by Intel was so called
mind control hardware which is effectively a little cap that picks up
electrical signals from the brain and can be used to control
software/hardware depending on the thoughts/actions of the wearer. I
have seen video games where this is used to great affect to for example
light a fire by meditating and the deeper the meditation the
warmer/brighter the fire becomes.
Does anyone know of any development that is going on in Linux Audio
circles that applies this technology?
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
I've been thinking about the same thing. Specifically I wanted to try and
use an OCZ NIA for drum input into hydrogen. I've seen a few videos of them
people demoing the unit, but don't personally know anyone that's tried one.
There is no linux support afik either for them. I'd be interested if you
make any progress to hear about it.
Nathanael
Hello all,
Does anyone know of a counting semaphare class/module
in Python ? Given the lock provided by the built-in
thread module it seems impossible to implement this
(it does support multiple waiters which I don't need,
but definitely is not counting). This also means that
whatever is defined in the threading module can't be
what I want.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
O tu, che porte, correndo si ?
E guerra e morte !
Hi Dan,
why don't you answer on the mailing list?
Dan Mills wrote:
> On Fri, 2008-08-22 at 20:26 +0200, Olivier Guilyardi wrote:
>>
>> In Jackbeat I perform sample rate conversion using libsamplerate in the realtime
>> thread. I have recently realized that might be a mistake in regard to
>> performance. The SRC is used on audio samples which sample rate might differ
>> from the external (Jack) one, and also as a simple pitch shifter.
>
>
> <Snip>
>
>> In this regard, I thought about setting a (or several) non-RT helper thread(s)
>> up, where the heavy stuff would happen, and feed the converted content into the
>> RT thread through a ringbuffer. I understand that this approach would require
>> implementing a sync callback for the helper threads to get ready (fill buffers,
>> etc...) whenever the transport position changes.
>
> That is a fairly common approach, one thread per core is good. I have
> code that reads audio, sample rate converts it, time-stretches it if
> appropriate and sticks it in a ring buffer. The realtime thread does not
> pay any attention to the transport at all, it just handles the realtime
> controls (some mixing and routing in my case).
I am unsure what you mean by "core".
> One thing you do want to watch is that the disk IO threads should
> probably run at a realtime priority (just lower then the one for the
> audio thread), otherwise a make -j10 on the kernel can result in
> ringbuffer under run.
Disk IO is another problem to me. I would prefer to focus on computation load
here, that is: helper threads that performs audio conversion/transformation,
etc.... I assume that the thread priority you advise also concerns this though.
> There are a few details to making everything work right when you have
> more playbacks then available cores, and the approach does not work well
> if you need to vary things like timestretch in realtime.
Ah right, thanks, I had forgotten about this. Indeed, the good side of my
current approach (where the SRC is performed in the realtime thread) is that it
gives the user a good experience when varying the pitch: the effect is
immediate. So I'm not operating on live audio input, but I do handle live
"control" input, and in this regard the audio sample content is not exactly
known in advance anymore (since it is transformed according to realtime user
requests).
>> I'm asking this because the SRC computation load currently has an impact on the
>> output quality (ticks, xruns) with many tracks or on slower systems, and I'm
>> thinking about adding real pitch and time shifting using Rubberband in the near
>> future, which is certainly going to be a lot heavier.
>
> If you need to be able to vary the timestrtch in real time with a file
> playing, any ring buffer after the timestretcher will need to be short,
> otherwise it is fairly straightforward.
That worries me a bit. If my ringbuffer is really short, for responsive user
control, and the time stretching performed in a non-RT thread, isn't this going
to make things worse?
What about the following idea:
Say I make a Converter object, which performs time stretching. It doesn't know
anything about threading.
I also have a Reader object, with an internal ringbuffer, it reads raw audio
data, converts it using the Converter, and fills its ringbuffer with the
converted content.
The Reader objects exposes read(double time_ratio, int nframes) to the realtime
thread. When this function gets called, the Reader checks if it has data time
stretched according to this time ratio in its internal ringbuffer. If it does it
simply returns it. Otherwise, it calls the Converter on the fly, discarding the
irrelevant data in the ringbuffer, and causing a sudden small overhead.
Once the time ratio has stopped varying (the user has stopped playing with the
knob), the ringbuffer rapidly gets filled with data at the right time ratio, and
the overhead vanishes.
> Volatile is your friend as is pthread_mutex_trylock (Particularly handy
> if you have a vector of disk readers and a small handful of threads
> servicing them).
Thanks, I knew little about volatile, I've read some more about it, and already
fixed a possible bug in my code. Yes, I recently read about
pthread_mutex_trylock being acceptable in the realtime thread on the jack-devel
mailing list.
Regards,
--
Olivier Guilyardi / Samalyse
Hi,
Does anyone have a suggestion or a part number for a small mic that can
be fitted onto an embedded board that also has good quality input levels?
I have a few options already but someone here might be able to suggest
one that they have worked with and had good results from.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd.
