Ardour 2.3 released

Another month has crept up on us, and the next release of Ardour is here. 2.3 includes major new features in the area of tempo management and feature analysis, a dozen or so important-to-useful bug fixes, another dozen or so improvements and provisional LV2 (LADSPA version 2) support.

Binary releases for OS X Intel and PPC will be announced on our OS X-focused IRC channel. We will make a more public release for OS X once we have AudioUnit GUIs working acceptably.

Feature Analysis

Ardour now has a framework for performing various kinds of "feature analysis" on the audio that you record or import in a session. It can use those features during editing. In 2.3, we have added a percussive onset analysis that can now be used to split regions automatically, move the playhead around and more.

There's more though. In this release, Ardour's new Rhythm Ferret can be used to do dynamic analysis of regions in a manner similar to the shady private eye seen in some proprietary systems. This is an unfinished feature in 2.3, but it does have some uses already and will improve before 2.4.

I would like to thank Chris Cannam, known for his work on Sonic Visualiser and Rosegarden, for his efforts in creating the Vamp plugin standard for feature analysis, and for coding up the specific analysis plugins that Ardour is using. Chris also provided hands-on guidance as I started to incorporate Vamp usage into Ardour. By the way, all users of Ardour should install Sonic Visualiser. Its an invaluable tool.

Tempo Management

Possibly the most useful new feature in Ardour for a long time, at least for those working with musical time while editing, is the ability to define the length of a bar (and thus the tempo) from a region or the current edit range. It sounds a bit esoteric until you try it - this feature is the key to working with BBT (bars|beats|ticks) structured sessions where the tempo is not fixed in advance (i.e. almost all recording sessions). Select a region, press "9" and the new tempo is set up. Place the playhead/marker and the mouse at the appropriate locations, press "0", and similarly, the new tempo is set up. Didn't get it quite right? Move the mouse and press "0" again.

In addition, you can now "glue" regions to their current musical time position, measured in bars|beats|ticks. This means that if you then change the tempo, regions glued in this way will stay in the same position relative to musical time. If the region is at 4|1|0 and you change the tempo, it will still be at 4|1|0 even though that may be earlier or later according to an absolute time.

Contributors

Contributors to this release: Chris Cannam, Audun Halland, Doug Mclain, Nick Mainsbridge, Jörn Nettingsmeier & your happy overworked grunt Paul. Huge thanks also to Josh Parmenter for taking care of the PPC build.

Changes since 2.2

Significant New Features

  • audio analysis framework
  • rhythm ferret
  • tab-to-transient
  • new glue-region-to-musical-time option
  • set-tempo-from-region and set-tempo-from-edit-range
  • new boost-region-gain and cut-region-gain operations
  • LV2 support

Improvements

  • waveforms are outlined
  • a real splash screen
  • keybinding changes
  • ctrl-click on nudge buttons moves playhead
  • add a Restore Defaults button to the theme manager
  • beautification of multi-duplicate dialog, tempo dialog, meter dialog
  • keep verbose canvas cursor within the editor canvas visible area
  • provide instructional hint for the shortcut editor
  • fix keybindings on OS X to allow use of arrow keys with modifiers
  • OS X native version now finds control surface support modules
  • moving fade in/out points makes the fade in/out active
  • font size changes throughout
  • show loop & punch locations properly in Locations dialog
  • use a separate drag rect for cd marker bar, show cd marker details on load in location ui
  • rationalize all region selection for editor operations
  • sessions now have their "nominal sample rate" stored; if you load a session while JACK is running at the wrong rate, there will be a warning dialog
  • changing track heights now applies to all selected tracks

Bug Fixes

  • fix misdisplay of track control headers
  • don't crash if history refers to a location that no longer exists
  • prevent errors when reactivating deactivated tracks
  • prevent excessively long track names from conflicting with JACK port name restrictions
  • fix missing static mutex initialization that causes 100% CPU use on Leopard
  • fix use of template selection from new session dialog
  • fix up JACK discovery on systems (OS X) with an inadequate PATH setting
  • fix invisible cursor in selected track name entry box
  • Fix reversed bounds check in Region::adjust_to_sync (), regions with a sync point snap to the sync point again.
  • Workaround for gui hang when adding gain points (#2048)
  • recognize ambisonic files (.amb) as candidates for import
  • fix loading of VST plugins in older (2.1 and earlier) sessions
  • fix align_selection_relative() to use regions once only, and in the correct order
  • "Set Range Selection" in per-region context (sub)menu now uses all selected regions, not just the first one
  • fix OS X native crashes with gain points, canvas updating and more.
  • fix crash when closing a session that had a selected marker

New Library Required For Source Builders

Linux users building from source should note that this release sees a new library requirement. Ardour now requires your system to have the amazingly excellent FFT library FFTW3 ("Fastest Fourier Transform in the West") library installed. You will need both the double precision and single precision versions (typically called fftw3 and fftw3f). Remember that you will need the development versions of these libraries. Some linux distributions put both fftw3 and fftw3f inside the same package, so get the fftw3 first and don't worry if there doesn't seem to be an fftw3f equivalent.

Congratulations for the

Congratulations for the release! Just compiled on my Ubuntu and noticed that Ardour doesn't fit anymore on my 1280px wide display. Seems like the menu and toolbar are too large. I had to tweak ardour2_ui_dark.rc to make it fit.

You can compile with

You can compile with "scons OLDFONTS=1" to get the old fontsize. Maybe that's your problem. For my system the new fonts were also much too big, the view of Ardour's unclear and menus are larger than my 1280x1024 desktop.

Besides this I'm very excited to try out the new rhythm ferret in practise :)

Benjamin

Thanks for the tip,

Thanks for the tip, Benjamin. Ardour rocks!

Same font problem here, but

Same font problem here, but thanks to the devs for the OLDFONTS option. I'd be interested to see how other people feel about the larger fonts. The program is making such huge strides now; exciting times to be a user...

Sweet. Huge fonts aren’t

Sweet. Huge fonts aren't bad on 1600x1200... in fact, they look the way the old fonts might look at 1152x864 with impossibly good antialiasing. I'll probably turn it back to old anyway because there's a 1280x720 screen I expect to use occasionally.

VST support seems nice and stable so far... and BTW, yes... Tap Stereo Echo + Stop plugins with transport = no crash since Ardour 2.2, it was "fixed". Sweet++. Thanks very much again to all the devs.

I’m running a resolution

I'm running a resolution of 1280x1024 and the fonts look awesome in my opinion. I like it better than the old, smaller fonts. Thanks to all the developers, Ardour inspires me to write music. I am subscribing right now!

Just to clarify what is

Just to clarify what is happening with the fonts for everyone reading this...

Ardour asks for fonts using the typographic units of "points" (1 point is 1/72 of an inch). The intent is that when we ask for a 10 point font, it will be 10/72" high on every display device, regardless of resolution, size etc.

However, for this to happen correctly, Pango (the software library that does font rendering for GTK applications (and others too)) needs to know the physical pixel resolution of the screen accurately. It turns out that at present neither X11 nor OS X provide this information accurately, and the error is variable both in magnitude and direction (actually, OS X always reports 96 DPI - this is supposed to be fixed in the next release of OS X).

As a result, the actual display size of the fonts on your screen will depend on the size and direction of the error between what X11 reports as the DPI and what it actually is.

Ardour 2.4 (end of February) or 2.5 will contain some method for users to control font sizing at run time.

And the new wave outline

And the new wave outline makes matching two takes so much easier.

Also, the Beat Ferret is an interesting feature. It will chop up a region into it's beat components... Life in the FAST lane!

Cheers
Alex Mailer

The rubber-band stuff is a

The rubber-band stuff is a massive improvement over the old mechanism, big thank you to everybody involved with that

Webdesign Germany

I am so impressed i have to

I am so impressed i have to stop now and then and breath very deeply!

THe new fonts look great, and the editing model is already saving me loads of time- more time saved than i spent learning the 'new ways' so that's a plus.

I especially love the little level meters on each track the the editor. Pretty and functional!

thanx loads y'all,

dav=-0