Welcome to the 0.9beta12 release of Ardour. We are now moving ever
closer to a 1.0 release. This release includes an incredible number of
changes and improvements since beta11. We expect some instabilities
compared to beta11 to remain - please test, collect debug traces,
etc. etc.
+++++ FIRST IMPORTANT NOTICE +++++
Although beta12 will load sessions created by earlier versions of
Ardour, if it is allowed to save a session at any time, that session
will immediately be INCOMPATIBLE WITH ALL PRIOR VERSIONS OF ARDOUR.
If you have important sessions, you are advised to back up the session
state files (generally called <session-name>/<session-name>.ardour).
I repeat: if you care about being able to use prior versions of Ardour
on your existing sessions, you MUST BACKUP YOUR SESSION STATE FILES.
Please rest assured that after 1.0 appears, no incompatibility,
forward or backwards, will be tolerated in any future version.
+++++ SECOND IMPORTANT NOTICE +++++
Why the change in the session files? At some point as work on beta12
was in progress, we realized that Ardour's panning model was
fundamentally broken. Not just the mathematics of the pan law, but the
actual software architecture of panning. Fixing this has required a
massive set of changes to Ardour's basic data flow and a lot of subtle
and not-so-subtle changes to a lot of code. On the plus side, we now
have a completely modular panning architecture that will make it
trivial, mostly, to use plugins for panning in the future.
++++++ THIRD IMPORTANT NOTICE ++++++
ardour/ksi is no longer built by default. The changes to libardour are
massive and widespread, and I do not have the resources to spend time
getting ardour/ksi to catch up with them. I will reenable default
building if and when ardour/ksi compiles again. I wish I could spend
time on this, but the work is just too much at a time when I
desperately need to get Ardour to a reasonable 1.0 release.
+++++ FOURTH IMPORTANT NOTICE +++++
This version of ardour will NOT compile with gcc 2.95. we are now
using the standard C++ class "stringstream", which has no support in
gcc2.95. i will accept patches that attempt to use the gcc class
"strstream", but i am not willing to spend time on this myself.
Changes since 0.9beta11
------------------------
A) PANNING
* panning control is per-stream
code is now supporting the notion of the "number of active
streams" within various parts of a signal processing
"route". this is different and orthogonal to the number of
inputs and outputs the route has. if you put a 1in/2out
plugin into a 1in/1out route (which arguably should not be
possible), then before the plugin there is 1 active stream,
and afterwards there are 2.
* panner linkage
- panners for all streams/channels can be moved
together or in opposing motion.
* new "bar controllers" for controlling panning to
a stereo output, 1 per data stream
* dbl-click on the bar controller to get numerical
entry, then Return or Tab to get back
to graphics.
B) AUTOMATION
----------
* gain and pan automation now totally separated
- you can playback pan automation while
doing touch automation on gain.
* if playing automation, and playhead goes past
the last control point, value remains
at that level.
* one button for gain automation state and one for
pan automation state per mixer strip
* ignore the automation mode for now
* touch automation for panning now works.
* hide all automation control points, display them
only as mouse pointer moves through them
* automation values reflected after transport stop
or locate if automation is not off, or when
automation is turned on.
C) PLUGIN GUIs
-----------
* use bar controllers (see Panning above) instead of sliders
D) OTHER MAJOR FUNCTIONALITY
-------------------
* initial support for win32/x86 VST plugins as native objects
in Ardour
* Added exclusive solo operation (ctrl-alt click on solo button)
which sets that track to be the only soloed track. it has a
momentary counterpart (ctrl-alt middle-click) which temporarily
exclusively solos the track while the mouse button is pressed.
BTW, middle-clicking mute buttons is momentary mute as well.
* Added seamless looping. this can be enabled in the options editor
(misc tab). why is this an option you ask? well, our current
looping scheme simply does a transport reposition at the end of the
loop, and while completely sample accurate, there can be a time gap
between the end of the loop and the beginning. This happens due to
the slow-sync jack transport system, to allow all clients to
reposition in sync (including ardour). However, if you need truly
seamless looping with no gap, you can enable this option which will do
it within ardour only -- you must disable ardour as the jack
transport/time master for it to work. In the near future, the Jack
transport system may acquire a notion of looping, and at that time,
seamless may be used at any time.
Note that for full compatibility with other transport aware apps, the
normal (non-seamless) looping with ardour as jack transport master is
required and is still quite usable, so don't be discouraged from using it.
* drag-n-drop from a file manager implemented for
placing audio files into audio tracks
* LADSPA Presets are now saved in RDF format in
~/.ladspa/rdf/ardour-presets.n3. Ardour will also
read any other RDF files saved in that location.
* region list redesigned
* mouse wheel events now scroll canvas, not change mouse mode
* always store to current snapshot file, do not make read-only
anymore (might cause problems on older sessions with
snapshots if editing the snapshot)
* mouse shuttle mode (the return of "scrub")
a new widget replaces the ffwd/rev buttons to provide
continuous speed control in forward and reverse directions.
* Added option to update actively recording regions with waveforms.
Much cooler than just the pink boxes, eh? On by default, you
can turn it back to the plain pink boxes from the display tab
of the options window.
B) MINOR IMPROVEMENTS + BUG FIXES
------------------------------
* correct handling of JACK transport API when transport master
* improved handling of SMPTE timecode
- SMPTE frames-per-second can be edited from the options editor
- SMPTE offset (what absolute time with respect to audio frame
zero is SMPTE 0:0:0:0) can be edited from the options
editor
- correct drop frame calculations
* fix for "Destroy Last Capture" bug, plus a correction for
a thinko that caused a segv if DLC done twice between
captures.
* recent session dialog doesn't have "subtrees" for sessions
with just a single state (snapshot)
* xfade editor changes
- "shade under line"
- fix left offset of wave display
* buttons/arrows on editor vertical scrollbar now work
* template selector hidden in new session dialog if the user
has no templates
* fix problem with exporting caused by JACK transport fixes
* MMC buttton relabelled "External MIDI Control", and moved
to MIDI tab of Options editor, along with "Send MMC"
* Better implemented the momentary mute and solo operations so that
the previous state is restored on mouse-release.
* added "lock", "unlock", "normalize", "reverse" to region context
menu
* add new operation to return captured regions to their "captured"
location (does not work for embedded/imported regions). the
operation is in the region context menu as "Original position".
* fixes for region naming when handling external audio files
* redesign new session dialog to use a tabbed notebook
* make sure option editor's "follow playhead" button is in-sync
with follow playhead setting
* fix long-standing bug with MIDI request pool running out of
memory.
* fix export of 100% zeroes in 32 bit integer sample files
* added MMC command when in master MMC mode for transport
startup (Deferred Play)
* correct design flaw in creating regions from session file.
(fixes some odd behaviour when undoing close to
start of working on a session, because regions did
not have the correct history set up)
* limited shuttle speed when mouse departs the control box.
* keep JACK shutdown/kick message on top of editor window
* use "e" and "p" to position edit/playhead wherever mouse is
* fixes for transport button madness
* fix for autoloop indicator region visibility
* made the horizontal scrollbar be a standard one
* included new fader pixmaps from ryan (precursor to new theme)
* ExportDialog saves Track information. It doesn't restore it yet though.
* LRDF enumerations are displayed in a combo box in the PluginUI.
* Updated gtk-ardour Russian translation and added new libardour Russian translation.
* Recent Sessions dialog doesn't display sessions that have been deleted.
* Trying to sample a file in the AudioLibrary that has been moved or deleted won't crash.
* fix catastrophic, stupid, unbelievable and just plain ridiculous
bug in editor constructor that left edit_cursor and
playhead_cursor with random values when Editor::set_state()
was called.
* move "optimization flags" setting into a global autoconf file,
and call AM_OPT_FLAGS from most configure scripts
* increase size of UI request pool
* increase size of UI request ringbuffer
* finally get all tracks connected to ins+outs
when using "auto-connect" options.
(previously only the first N tracks
would be connected, where N was the
number of physical i/o's on
your audio interface)
* prevent GTK from loading its default
RC files at all costs.
* fix gcc 3.3 "bug" in libsoundtouch
* start to use the new BarController widget in plugin GUIs
* fixed the declick on transport stop. yes, it probably never
worked, which is why you heard clicks on stopping. this also
fixes the problem where plugins are interrupted briefly on stop...
now reverb tails are undisturbed on transport stop.
* Audition port names are looked up at runtime.
* Library UI uses the new jftw in libpbd.
* The plugin selector is now sortable by clicking on the different column
titles.
* "stop at session end" option is now saved
* "splash/about window" design changes - unfinished, and wow is it
ugly. but its also more flexible, and i'll finish it RSN.
* several dialog windows forced to float over the editor
* "wait for loading" message removed
* when adding multiple tracks, GUI runs between each track
(causes ugly flashing of mixer window, however)
* Select context menu now contains
"Select all in track"
"Select all"
"Invert in track"
"Invert all"
(invert is known not to work on automation tracks)
* incorrect handling of stereo streams through routes fixed.
* check for adequate version of JACK
* fix recursive call to DiskStream::set_name() that caused a crash
when renaming a track
* fix PortInsert to do a pure wire-level copy - no gain, no pan
* count cycles for plugins
* make sends meter correctly
* clean up (longstanding) late initialization of several variables
(thanks valgrind!)
* convert error log to popup messages, mostly
* run Gtk::Main event loop while embedding/linking an external file
(and use the "watch/wait" cursor too)
* add a half-working detent for panner bar controllers
* try to improve operation of gain/pan automation buttons
* Added spanish translation. Thank you Alex Krohn.
* change pan line colors
* fix display of slide/splice mode
* clicks on track canvas views do not select track
* pack IO CLists in IOSelector in a scrolled window (needs theme name)
* select next IO port after making connection to current one
(speeds and smooths UI interaction when doing IO setup)
* Added spanish translation of ardour.1.
* test plugin configuration and display a dialog if its incorrect
(even when loading ... work in progress)
* Added russian translation of man page.
* Added valgrind shortcut for ardour into gtk_ardour. (arval).
* correct problem with lack of playback in rec-enabled
tracks when not using s/w monitoring
* apply gain to s/w monitored rec-enabled tracks
* fix nasty thread synchronization bug related to
allocation+use of session-wide pan automation
buffers
* provide (not very good) warning if rec-enable attempt
made on a track with no input connections
* more tooltips
* pan muting via context menu
* fix potential segfault in ::~Session caused by
double delete of playlists
* MIDI control for panning added back (untested)
hi *,
i've got a strange issue with libsndfile.
in foo (http://foo.sf.net) the SFM_RDWR mode is used, because target
soundfiles are created independently of the write process before, then
the file gets opened with SFM_RDWR to determine the target soundfile's
parameters (samplerate, channels...).
with SF_FORMAT_AIFF | SF_FORMAT_FLOAT (and SF_FORMAT_DOUBLE, btw., 2
channels) i notice a strange behavior: directly after creating the
file (without sf_writing anything) the number of frames of the file is
4 (SF_FORMAT_DOUBLE: 2 frames). this doesn't happen neither with the
SF_FORMAT_PCM_* things, nor with SF_FORMAT_WAV. with just 1 channel
the values are 6 resp. 3.
when reopening the file for writing (SFM_RDWR mode), there is no
difference between seeking to (0, SEEK_SET) and (0, SEEK_END), both
seek to 0. surprisingly, seeking to (4, SEEK_SET) doesn't return an
error.
after writing 512 frames after seeking (in all three cases) and having
closed the file, the number of frames is now 511 (1022 with 1
channel).
am i missing something, or is this a bug in libsndfile? attached my
test prog.
bests,
martin
The latest version of the realtime Linux Security Module is now
available on SourceForge...
http://prdownloads.sourceforge.net/realtime-lsm/realtime-lsm-0.1.1.tar.gz?d…
This release handles changes to the capabilities structure introduced
in Linux 2.6.6, but still works with earlier 2.6 kernels. There are
no functional changes. Unless you are running 2.6.6, there is no need
to upgrade. Changes in the 2.6.6 kernel makefiles affect the
procedure for building the realtime-lsm. Please consult the INSTALL
instructions for details.
The realtime LSM is an installable kernel module that enables realtime
capabilities for any 2.6 kernel without needing to directly patch the
kernel. It was written by Torben Hohn and Jack O'Quin, who make no
warranty concerning the safety, security or even stability of your
system when using it. It is provided under the provisions of the GPL.
--
joq
Hi all,
the conference is just over, and here comes the next annual event: The
LinuxTag, Europe's largest expo about our beloved operating system, takes
place in (guess!) Karlsruhe from June 23rd-26th, 2004.
Just like in the last..uhm..3 years, we are going to put up a "Linux Audio"
booth there, demonstrating some of the current software, helping people with
issues and generally "spreading the good word".
If you are interested in helping with this, please contact me by mail (or
here on the list, though I sometimes don't read it for days) and let me know
about your availabilities, specific points of interest, possible hardware you
are going to bring etc.
We'll be granted a free booth of roughly 5x3m which we'll fill in with some
MIDI gear, active speakers, PCs/Notebooks etc. It was always fun the last years
(including the famous KaLug party on Saturday at the university campus),
and it would be cool to see of last year's helpers again (I know Jörn has
already agreed he'll come again).
For more info, please read http://www.linuxtag.org .
So, any takers?
Thanks for reading,
Frank
Hi all,
the reason of this mail is searching for opinions about an API for input /
output plugins.
Besides I see around the LADSPA API for sound processing but nothing similar
for input / output.
From some months I'm playing around with audio I/O libraries: I met too much
libraries but no one really complete satisfacting my needs( thinking to
latency and other advanced issues having on djing programs as an example).
Not talking about driver complete support: PortAudio does not support ALSA,
libao does not support Win,MacOsX and so on...
Playing with plugins about some program I had another problem: I played with
Alsaplayer ( very nice and powerful program! ) trying to reuse its plugins. I
found although, that using them means including ( with hardcode ) lot of the
Alsaplayer code. I played with Xmms too: this time the work is easier and
there are all sort of plugins but mostly are thinked for merely playback
withouth latency control... ;-(
However, what about writing an advanced API for I/O plugins, completely
detached from other programs ( as Xmms ), potentially multiplatform, to suit
the needs of the big part of audio programs? I mean, a plugin written for a
certain API ( i.e. ALSA, OSS, Jack, OsX etc... ) will be usable for all other
applications with all advantages of a plugin architecture and standard
code... Input plugins are important too: I see lot of apps rewriting
continuosly Ogg, Mp3 or Wav support in any kind of flavour, but not always
reusable code. About writing it once for all?
I wanna know: there are people interested in this? My discussion is out of
any order, not clever, low level? There is disadvatages on this idea?
Suggestions?
If there is a reason: Plugin API For Input Output ( PAFAIO ) sounds well???
Hoping in some answers.... Cheers,
--
J_Zar
Gianluca Romanin
----------------
see you at OpenJay.Org
Hi,
msAlsaSeq, an ALSA driver for the Linux version of Grame's MidiShare
(http://www.grame.fr/MidiShare/), is now available in MidiShare cvs
(http://www.grame.fr/MidiShare/SCPP/dev.html). You can find it in the
development branch (-r dev) in the src/linux/drivers/alsa directory.
The driver lets you connect to ALSA devices and other ALSA sequencer
clients from MidiShare applications. It can be used instead of the
msRawMidi, msRawSerial and msInetDriver clients if you're running ALSA
instead of plain ol' OSS (which you should ;-). It also allows you to
map ALSA client ports to corresponding MidiShare ports. A manpage is
included.
Please direct comments and bug reports to the midishare-dev list or
Dr.Graef(a)t-online.de.
Enjoy!
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.musikwissenschaft.uni-mainz.de/~ag
When you set the channel count >2 do the output channels have
a specific spatial positioning defined? Or would it make more
sense to output B-format and run it through one of the Ambisonics
plugins to get a specific speaker layout?
jlc
Hi,
and what do you think about gstreamer? I have been two months reading
LAD's list and nobody had commented nothing about those libs. Either in
ZKM's conference.
I have done some tests with gstreamer and I really like it. Maybe the
doc is not very updated and completed, but there are a lot of public
plugins to learn and there is alsa, oss, jack and LADSPA support.
Bye,
Jorge
Good question. I had already read that and was curious myself. Also, how about
2.6.6-mm1? I want to upgrade to Fedora Core 2 and a new kernel so I can quit
pissing off Paul D. and the guys with my 2.96 gcc ;-)
Jan
On Mon, 10 May 2004 16:50 , Robert Jonsson <robert.jonsson(a)dataductus.se> sent:
>Hi,
>
>As a service to all readers, here's an excerpt of the Changelog concerning
>latency: ;)
>
>akpm(a)osdl.org>
> [PATCH] Add mpage_writepages() scheduling point
>
> From: Jens Axboe axboe(a)suse.de>
>
> Takashi did some nice latency testing of the current kernel (with -mm
> writeback changes), and the biggest offender in general core is
> mpage_writepages().
>
>akpm(a)osdl.org>
> [PATCH] ia32: 4Kb stacks (and irqstacks) patch
>
> From: Arjan van de Ven arjanv(a)redhat.com>
>
> Below is a patch to enable 4Kb stacks for x86. The goal of this is to
>
> 1) Reduce footprint per thread so that systems can run many more threads
> (for the java people)
>
> 2) Reduce the pressure on the VM for order > 0 allocations. We see real life
> workloads (granted with 2.4 but the fundamental fragmentation issue isn't
> solved in 2.6 and isn't solvable in theory) where this can be a problem.
> In addition order > 0 allocations can make the VM "stutter" and give more
> latency due to having to do much much more work trying to defragment
>
>akpm(a)osdl.org>
> [PATCH] reiserfs: scheduling latency improvements
>
>akpm(a)osdl.org>
> [PATCH] unmap_vmas latency improvement
>
> unmap_vmas() will cause scheduling latency when tearing down really big vmas
> on !CONFIG_PREEMPT. That's a bit unkind to the non-preempt case, so let's do
> a cond_resched() after zapping 1024 pages.
>
>
>So... humbly asking, is it time yet to make the switch? :-)
>
a collegue pointed me to this post about a high resolution time
patch for the 2.6.5 kernel. i'm not 100% if it has been mentioned
here before, nor of how much interest it is, but just in case.
http://lwn.net/Articles/81400/
maarten