Greetings,
After another quarantine period, I am pleased to announce (yet) another
maintenance release of my flag-ship toy, Qtractor, an Audio/MIDI
multi-track "bedroom" sequencer for the techno-boy (and girl:).
Probably, the major feature highlight for this release, is the new
optional support for in-place audio clip pitch-shifting through Chris
Cannam's Rubber Band Audio Time Stretcher library. This one alone just
closes the gap on the techno-boy/girl bedroom-studio prospects, so let's
move along, nothing really new to see here :) However, given there were
many inner changes in the audio rendering engine everything might just
sound a lot less glitchy than previous releases. Therefore, everybody is
welcome to upgrade. And please, don't be shy ;)
Qtractor 0.1.3 (frugal damsel) has been released!
Grab it while visiting the project pages:
http://qtractor.sourceforge.nethttp://sourceforge.net/projects/qtractor
Here's some direct links to the most wanted pieces:
http://downloads.sourceforge.net/qtractor/qtractor-0.1.3.tar.gzhttp://downloads.sourceforge.net/qtractor/qtractor-0.1.3-user-manual.pdf
And don't (ever) forget to drop by, over the upstream :)
http://www.rncbc.org
As usual, the complete change log is worth a look too, for the record:
- As one may find convenient sometimes, the global time display
format (frames, time or BBT) may now be changed on the main
transport time spin-box context menu.
- Left-clicking on the track list number column now toggles all
track content clip selection.
- Prevent audio-buffer initialization mashups when editing short
audio clips while playback is rolling and within clip region.
- Audio peak files gets a bit simplified, dropping the peak frame
count from its header; peak waveform graphics are now rendered
as straight lines when over the end of audio file.
- The drop-span option (View/Options.../Drop multiple audio files
into the same track) now also applies when importing tracks (as
in Track/Import Tracks/Audio...) to concatenate multiple audio
clips into one and the same new track.
- Audio and MIDI meter level colors are now user configurable (as
global configuration options, View/Options.../Display/Meters)
- First attempt for Qt4.4 build support, regarding the bundled
atomic primitives, which have changed upstream as advertised
(thanks to Paul Thomas, for spotting this one first time).
- Record monitor switch is now an accessible button option on all
track mixer strips; for visual consistency, the old bus "thru"
switch button has been renamed to "monitor".
- Force track-view position reset to origin on session close.
- Fixed segfault on inserting an external file into files widget.
- Mixer splitter sizes are now better saved/restored when closed.
- Track record monitoring is now a state option, being toggled
from the Track/State/Monitor menu; applies both to audio end
MIDI tracks: when set all input will be pass-through to the
current assigned output bus, including track plug-ins chain.
- Session dialog gets split in its own tab components, between
descriptive, time and view configuration ones.
- Drifting correction among audio and MIDI engines is now back,
but avoided while recording or should it be while looping?
(EXPERIMENTAL REGRESSION)
- Time-stretching percent value gets its semantics inverted,
as thought consistent with ones general sense for relative
stretching ie., lower to shrink and higher to make longer.
this is a major up-side-down change and should affect all
sessions saved with time-stretched audio clips.
- Slack space in main tracks and MIDI clip editor views are now
proportional to viewport width, leaving enough room for drag
and moving content past the current session length, specially
at the lower zoom levels.
- Clip end time is now also shown on tool-tip.
- When armed for recording, MIDI tracks are now monitored and
filtered through their own output bus, thus having the same
behavior as audio tracks; this also implies that all record
armed tracks won't playback their current content material
when recording is engaged and rolling; track mute and solo
states are now honored on record monitoring.
- Audio clip pitch-shifting makes its first appearance, with
the optional help from Chris Cannam's RubberBand library.
- A new MIDI editor tool is available: note/pitch randomize.
- Avoid (re)setting the default session directory if a session
cannot be open or loaded for some reason.
- Another nastiness bites the dust: a subtle but progressive
drifting has been swept away from the audio buffer looping;
zero buffer flushing is now also taken into account, which
was the cause for serious drifting on time-stretched clips.
- A major digital audio processing bug was tamed: audio clip
fade-in/outs are now linearly piece-wise applied, even at
the clip edges, giving a much smoother rendering and thus
mitigating the nasty click-and-pop artifacts that were in
fact due to some early design optimization with a poor and
sloppy implementation.
Cheers && Enjoy
--
rncbc aka Rui Nuno Capela
Is it possible to configure a system (included changes to programs) so
that nothing can interfere with a few RT threads?
I have an audio and video thread in a program, and they are running as
SCHED_FIFO, but so many things can interfere with those two threads,
such as USB plugs/unplugs, cron log rotations, disk access (PIO flash
disk), ssh logins, etc. I really would like to shore up performance
here.
I am not using Ingo's RT patches, but I still see people talking about
turning off things like cron and server processes to prevent xruns when
using Ingo's RT patches. While I have turned off cron, turning off sshd
and the web server aren't options. I want to instead somehow make sure
that neither can every interfere with the AV threads, even if it means
that SSH and web traffic are extremely slow.
Version 1.2 of the free open source Linux software synthesizer
Minicomputer is out. This audiosynthesizer creates complex waveforms and
shapes them in a three stage formant filter. More at
http://minicomputer.sourceforge.net/
or directly at
http://sourceforge.net/project/showfiles.php?group_id=203751
Changes:
1.2 1.May 2008
2 - new: installer/deinstaller
3 - new: installerscript for presets
4 - new: unified behaviour, editor is called now minicomputer and when
started by user, launches t he core and shuts it down too
5 - fix: improved midihandling while using less cpu cycles
6 - fix: backup of memory files should work now
------------------------------------------------------------------------
Industrial synthesizer for Industrial people
The Audio Rollendurchmesserzeitsammler V0.0.1.
http://www.notam02.no/arkiv/src/rollendurchmesserzeitsammler-0.0.1.tar.gz
(Sorry for the long text below. I'm not planning to do
big announcements of further versions of the collector.
There is also more information about how it works, etc.,
in the README file in the source package.)
ABOUT
-----
The Audio Rollendurchmesserzeitsammler is a garbage collector
which provides a general way to efficiently allocate and use memory
inside a realtime audio thread without having to manually free
it later.
Furthermore, there is no write barrier,
no read barrier, no special pointer types or templates (ie. no need to
tell the collector exactly where pointers are), no reference counting,
cyclic dependencies are detected, and finally it is by default
configured to be hard realtime safe.
Finally, The Audio Rollendurchmesserzeitsammler can be a drop in
replacement for Hans Boehm's conservative garbage collector for C
and C++.
(Regarding its realtime safiness, I think CPU caches might theoretically
play an unpredictable role to screw things up, but my limited
observations so far is that it doesn't, or at least doesn't screw
up a lot.)
GARBAGE COLLECTOR TYPE
----------------------
Short: Snapshot mark-and-sweep.
Long: Hard realtime conservative parallel non-moving snapshot-mark-sweep-and-free.
PURPOSE
-------
This collector might be useful for running high level, high performing,
and garbage producing languages such as C#, Clean, Common Lisp, D,
Eiffel, Haskell, Java, Oberon-2, OCaml, Scheme or SML directly inside a
realtime audio thread doing signal processing.
(http://shootout.alioth.debian.org/)
It can also be useful for running less high performing programming
languages which are not doing signal processing directly but would still
be convenient to run inside the realtime audio thread, for example for
handling midi events.
By replacing the garbage collector in a high level language with
the one provided in this package, the language becomes one step closer
to be able to do realtime signal processing directly in the audio thread.
And in some cases, this might very well be all thats needed too.
One example is Stalin, an extremely efficient Scheme compiler.
By only replacing Hans Boehm's garbage collector, which Stalin normally
is using, Stalin's generated code can now run safely inside a realtime
audio thread.
See the provided example stalinwrapper.c / graincloud.scm how to
do that.
The allocator is also so effective, that its not unlikely that in some
cases it might make sense using it in a program
written in C or C++ as well when doing larger computations.
CREDITS
-------
The garbage collector uses TLSF for doing memory alloaction and
deallocation. TLSF is a memory manager library supporting both
bounded allocation time and bounded deallocation time.
http://rtportal.upv.es/rtmalloc/
gcconfig.h is copied from Hans Bohems garbage collector.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
The attached small patch provides somewhat more flexible
jack connections for mplayer, e.g.
mplayer -ao jack:dest=ardour:port="Audio 2"
willl make mplayer connect to the inputs of track "Audio 2".
You can also connect to e.g. system:playback_3,4 if you
set an alias for them first.
When used without 'dest', 'port' behaves as before i.e.
it selects an application. But the obvious way to do this
now is to use 'dest' of course.
Not a perfect solution but it helps.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
Apologies for cross posting
========================
The Music Technology Laboratory, NUI Maynooth is looking for a full-time
technical officer to support its activities in Computer Music and Audio Technologies.
http://humanresources.nuim.ie/technicalofficermusic.shtml
For further enquiries, please contact Music.Department(a)nuim.ie
==============================
Dr Victor Lazzarini
Senior Lecturer, Music
Music Technology Lab
NUI Maynooth
Dear madam/sir:
look:Beautiful China's online store
I recommend to you a very good shopping site <<www.buying8.com>>.
The quality of product is had better, the service is perfect, and
price is had better, the speed of the deliver is very fast.There are
own warehouse and store, there is customer in the whole world, receive
customer very high praise.
MSN: buying8(a)hotmail.com
Email: buying8(a)hotmail.com
Wish we cooperation delectation !
On Thu, 2008-04-17 at 16:14 +0200, Fernando Lopez-Lezcano wrote:
> You mean _complete_ binaries? All of the executable replicated several
> times with different optimizations inside the package? So your intention
> is not to optimize selected portions of the program, but _all_ of it??
No, plase be reasonable :-)
One of the original source files holds the inner, hopefully vectorizable
loops that eats cpu and may or may not contain ugly kludges to get
around the denormals problem unavoidable in cpu's before sse2.
>
> And place the decision logic for which to use in pre and post install
> scripts??
Yes please! (pretty please?)
I would naively think that the package consists of object files with say
engine.o in several versions.
main.o
userinterface.o
networking.o
...
engine.o.586 # plain C, runs everywhere but probably pretty terrible
engine.o.sse # vectorized but has some kludges
engine.o.sse2 # vectorized and no kludges, works for AMD, recomended!
The pre-install script then looks in /proc/cpuinfo and decides which
engine to rename to engine.o, links the objects in a jiffy, strips the
binary and continues installation.
> A downgrade would not affect a current linux system, the kernel
> would just load the proper modules for the new hardware and run without
> problems. All programs I know of would adjust themselves if necessary.
>
This might be because you have the least desireable versions of the
programs? My all-singing-all-dancing kernel is at least three times
bigger than older kernels. This without counting any modules. And it
takes forever to figure out that nothing new has happened since last
reboot :-|
Distributions like Linux-from-Scratch do things differently. Which
brings us back to the gunzip/configure/compile/install way of doing
things Christian suggested from the start ...
I must admit that I hate 'configure' myself. It is darned slow and
checks for a lot of stuff that is senseless when you already know the
target, and then it most likely just arrives at a decision that some
obscure library is missing. Rinse, repeat ...
A partially rpm based distribution could at least tell us to install KDE
first and automagically do that before continuing to install stuff that
depends on that environment.
> Why do you think I, as a packager, will have access to all the possible
> hardware? Nobody does. I don't.
Good question. Who has the hardware and is willing to spend time on
compiling and testing other peoples projects? Who would gain anything
from this except for the end user? I suppose he/she then is the one to
do the lifting, except that he/she probably won't have the guts to up
the optimiser to insane levels, nor the experience to verify that the
application did not break ...
Also it is a lot of wasted time. Some kind of 'man in the middle' would
be nice to have around, which is why people are looking at you :-)
>
> [why did you take the thread off the list?]
I did not intend to, it was send TO: me, so the reply-to-list option
(ctrl-L) was disabled. It is first now that you mention it that I
realize that you also CC'ed the list.
Putting it back now :-)
> -- Fernando
>
>
--
This software package contains libraries and programs that should make
it easier to write LV2 plugins and GUIs.
Download it: http://ll-plugins.nongnu.org/hacking.html
Read documentation: http://ll-plugins.nongnu.org/dox/lv2-c++-tools/
Or read a nice tutorial: http://ll-plugins.nongnu.org/lv2pftci/
To build and install, run
./configure
make
su -c 'make install'
You can pass some options to configure, e.g. --prefix=/usr to install
everything in /usr (the default is /usr/local).
This is a development tool, but I'm sending it to the LAU list as well
in case there are any not-yet-hackers who would like to start writing
effects or synths. It's easy, I promise. Here's the code you would need
to write for a simple gain effect:
#include <lv2plugin.hpp>
#include "gain.peg"
class Gain : public LV2::Plugin<Gain> {
public:
Gain(double rate) : LV2::Plugin<Gain>(p_n_ports) { }
void run(uint32_t nframes) {
for (uint32_t i = 0; i < nframes; ++i)
p(p_out)[i] = p(p_gain) * p(p_in);
}
};
static int _ = Gain::register_class("http://my.plugin/");
And here's the code you would need for a GUI for a synth plugin with a
button that sends a test tone:
#include <lv2gui.hpp>
#include "mysynth.peg"
class MySynthGUI : public LV2::GUI<MySynthGUI, LV2::WriteMIDI<true> > {
public:
MySynthGUI(const std::string& URI) : m_button("Click me!") {
m_button.signal_pressed().connect(mem_fun(*this, &MySynthGUI::send_note_on));
m_button.signal_released().connect(mem_fun(*this, &MySynthGUI::send_note_off));
pack_start(m_button);
}
protected:
void send_note_on() {
uint8_t event[] = { 0x90, 0x40, 0x40 };
write_midi(p_midi, 3, event);
}
void send_note_off() {
uint8_t event[] = { 0x80, 0x40, 0x40 };
write_midi(p_midi, 3, event);
}
Gtk::Button m_button;
};
static int _ = MySynthGUI::register_class("http://my.gui/");
See? Trivial. Read more in the tutorial linked above.
--ll
...for those who do not follow the LV2 mailing list.
1. EVENTS
There is an extension for sending arbitrary events to and from plugin
ports here: http://lv2plug.in/ns/ext/event#EventPort
This extension specifies how to send MIDI events using those ports:
http://lv2plug.in/ns/ext/midi#MidiEvent
MIDI event support is implemented in Elven, Ingen, lv2_jack_host (and
more?) and a couple of experimental plugins (a virtual keyboard, a basic
drum machine, some MIDI utilities, some synths).
There is no published OSC event type spec yet, but there are
experimental hosts that are sending OSC to and from plugins and GUIs
using the event ports.
2. UIS
Here is an extension that defines a framework for embedded LV2 (G)UIs:
http://lv2plug.in/ns/extensions/ui
So far there is only a Gtk+ 2.0 GUI type specified, but others would be
easy to add if someone writes up a spec for them. This is supported by
Elven, Ingen (and more?) and a couple of plugins (e.g. above mentioned
virtual keyboard and synths).
There are also a bunch of other extensions for port grouping, saving and
restoring the internal state of a plugin, and other stuff. See
http://lv2plug.in for more information.