This is intended to be the last beta release before Ardour 0.9 is
released. No new features will be added before we release 0.9.
FYI, 0.9 is intended to differ from 1.0 only with respect to bug
fixes, install and first-time user experience. We do still have a few
significant crashing and other major bug fixes to be resolved before
0.9 can be released, but optimism is in the air.
http://ardour.org/releases/ardour-0.9beta20.tar.bz2
NEW FEATURES
-------------
* Added support for midi parameter feedback. When enabled,
controls that are bound to incoming midi events will send out
that event when modified. This lets you control generic midi
control surface with motor faders and/or led encoders (like the
incredibly affordable Behringer BCF2000, which was used for
testing), to match the internal state. Note the extra/changed
options in the option editor's midi tab.
Reminder: to bind a fader or bar-control to midi, do a
Control-Middle-Click on it, then send some midi control.
* automation playback will send MIDI parameter feedback, thus
making external motorized faders etc. move with automation.
Note: this feature will probably be reimplemented in the
future because of interlocking problems with the realtime
audio thread.
* Added generic midi bindability for mute, solo, and rec-enable
controls. to do it, you can do Control-RIGHT-click on the mute
and solo buttons (the normal binding click is taken on these
buttons for other functions). For the Record-enable button, it
is the normal ctrl-middle-click. You can also pick it from the
context menu of the mute button. A menu will be added to other
buttons later.
* add -V/--novst flag to avoid using VST even if it
was compiled in
* multiple selected regions can be dragged across tracks (nick mainsbridge)
* normalization can be undone (patch from jkyro)
* export dialog redesigned
- master outs appear in their own selector, preselected
- button to control visibility of specific other tracks
* new playlist selector (uses a tree structure in a scrolled
window, instead of menus)
* add "nudge by capture offset" operation for regions
* remove zoom changes from the undo/redo history
* sessions still load when audio files are missing or corrupt
* Ardour is believed to build on OS X (CVS and/or this release)
FIXES
-----
* templates now get installed/uninstalled/rolled-into-tarball/etc. Let me
know if some corner of "make" doesn't work with the templates.
* Removed libglib dependency from libardour. Instead of guint32, we use
stdint.h's uint32_t, etc.
* fixed some midi prompter dialog issues
* fixed some midi binding state saving issues
* change entire buffer management scheme to be (more) RT-safe
* a major CVS commit that includes the first pass of changes to fix
some serious errors in the way ardour handles threads when
exiting. it also includes a significant fix to make export work
when sync'ed with JACK
* new functions to do "internal seeks" within the existing playback
buffer of a DiskStream, avoiding a new disk read for
small adjustments of playhead position
* lots of work on MTC slaving
* changed prototype of pthread_exit_pbd()
* don't send a message via error/info/warning/fatal if thread
is not registered with GUI
* remove "eox" signal from MIDI parser
* cleanup a few details of MIDI parsing
- importantly, all sysex messages get eox on the end
when passed to specific functions
* add "timecode-source-is-synced" option to ardour.rc(.in)
* remove Session::request_roll()
* fix bug with MMC rec-enable handling (only odd-numbered tracks
could be enabled)
* make region export progress bar move in the right direction
* more MTC slaving fixes and improvements (not done yet)
* remove wrong-thread-calling of Session::clear_event_type(),
which should help a number of loop-related crashes
* remove erroneous use of "abort" in function call
* Automake-1.7 or higher is required for libmidi++ now
* add "nudge by capture offset" operation for regions
* enlarge playhead/edit cursor arrows a bit
* avoid duplicate keyboard target registration
* pay attention to "virtual" window enter/leave events,
but continue to ignore "inferior" ones (may help
with keyboard focus issues)
* cancelling tempo/meter create dialog doesn't insert
a default tempo/meter marker
* tempo/meter create dialogs have minimal WM decor, and
use standard ArdourDialog API
* 2d panner fixed in many ways (still not to my taste and
not really correct)
* context-click on 2d panner shows context menu (Bypass is the only
entry so far)
* bypass added to stereo panner context menu
* general panner state load/restore fixes
* master outs added to connections menu
* added optimizations for peak metering (use of fabsf, flag
constants as floats, avoid implicit double/float casting)
* Updated the Italian and Brazilian translations.
* handle disk over- and under-run errors in the GUI, and be more
comprehensible to regular users.
* fix panning bypass for 2d panner
* fix stereo panner "mute" menu item so that it doesn't
toggle panner mute state every time it pops up
* fix more subtle elements of panner state restoration
* remove window crossing debug messages
* add "OK" button and remove window decoration from "can't
connect to JACK" dialog
Due to some untracked issues, 0.9beta20 was released in a form that
prevents it from offering any MIDI I/O or MIDI configuration.
In the time it took to discover that, other work had already happened
that is fairly important, so we bring you an unintended extra release.
http://ardour.org/releases/ardour-0.9beta21.tar.bz2
Changes
-------
* MIDI support now configured and built
* use Steve Harris' new libgdither code for dithering
* new patch from Nick Mainsbridge for multi-region
cross-track dragging
* increase size of Session event pool (to aid with
loading large sessions)
* use "in 1" or "out 1" if a named connection cannot
be found (e.g. when switching from a multichannel
to a stereo audio interface)
* patch for RPM building from Thac
* libardour: 0.838.0
ardour/gtk: 0.536.1
Thanks a lot for the help Paul!
One more quick question though, has the issue with jackd + alsa + hdsp ever been fixed where jackd only allows 2 periods and no other number?
Best wishes,
Ico
>Hence, I've been wondering what do I need to do to automate hdsploader as soon
> as the cardbus has been connected?
using the new modprobe.conf syntax ....
install snd-hdsp /sbin/modprobe --first-time --ignore-install snd-hdsp && { /usr/bin/hdsploader; }
Hi all,
As some of you may already know, I am going to present a paper/demo at the
upcoming ICMC 2004 conference in Miami on Linux titled:
Linux as a Mature Digital Audio Workstation in Academic Electroacoustic
Studios – Is Linux Ready for Prime Time?
As promised I will be posting an expanded version of the paper online right
after the presentation that is slated for the Wednesday next week.
I would like to use this opportunity to thank all the members of this
wonderful community for their insight and help in making my final paper as
accurate and objective as possible. Furthermore, I would like to thank
everyone involved in the development of audio software for the GNU/Linux
platform because without you none of this would've been possible.
Finally, just a couple days ago I was invited to serve as one of the panel
members on Matthew Wright's discussion titled "Standards From the Computer
Music Community" that will take place on Saturday November, 6. He wants me
to present the Linux audio community's angle on standards and considering
that this conference encompasses faculty as well as researchers and
programmers from all across the World, I feel that this is a perfect
opportunity to voice out our angle on the given topic and perhaps that way
further expose the strengths that Linux can offer.
I would like to share with you a short overview of my thoughts on this issue
and would like to encourage those of you who may have additional thoughts to
please send me your suggestions and/or corrections. Your help in this matter
is most appreciated! However, please bear in mind due to fact that I am
leaving for the conference on Sunday afternoon and am not sure how regularly
(if at all) will I be able to check my e-mail while away from home, I would
really appreciate it if you would please send me your responses before
Sunday 2pm or so. I would of course appreciate also belated comments just in
the case I do get to check my e-mail, I just cannot guarantee I'll get to
read them prior to the presentation. My sincere apologies for the unusually
short window of opportunity.
At any rate, here's my blurb:
----------------------------------------
My initial presentation will be limited to 5-7 minutes since panel will
consist of a number of members. Following everyone's initial presentation,
there will be a discussion driven in part by the questions from the
audience.
LINUX AS A STANDARD
I feel that considering linux as a standard is on one hand a kind of a
paradox as it is built on the premise that individual truly can tweak it to
heart's content and therefore it is relatively unlikely that any two Linux
boxes would look and/or perform the same. Yet, on the flip-side of the coin
Linux stands as a most successful offspring of the GNU movement and as such
it is the most revolutionary and therefore the standard-setting OS in a
category where it has no competition. Furthermore, this diversity it offers
perhaps stands in its own light as a kind of a standard offering the
end-user to shape their computer as a personalized instrument.
PLANET CCRMA/DeMuDi/THAC'S RPMS/AUDIOSLACK
The diversity seemingly suggests lack of standards, yet the software
packages in most cases seamlessly compile on various distributions. This
diversity is simply a byproduct of the diversity of the commercial Linux
distributions. This is where lies perhaps the biggest problem with Linux,
and that is the issue of different file tree across the different
distributions which introduces hurdles for the "compile-from-the-source"
crowd and in part feeds the demand for the prebuilt distros and subsequent
fragmentation (a vicious circle if you like).
KERNELS
There is no "standard" audio kernel even though some of the kernel releases
in conjunction with patches yield better performance. This diversity is
however irrelevant as most of the applications work just fine on different
sub-versions of the same kernel without a recompile. Therefore such
disparity is more of a nuisance for the end-user than a potential
standard-breaking anomaly. Furthermore the fix for such disparity is
provided via aforementioned distributions.
APPLICATIONS
The powerful thing about Linux is that while everyone is welcome to
contribute their own ideas or even design their own applications from
ground-up, the strongest concepts rather than most developed applications
are the ones who set the standard (i.e. JACK, ALSA, etc.) which is not
always the case with the commercial proprietary World where often PR plays a
critical role (i.e. VHS vs. BETAMAX -- although this is not the best example
as this is not software-related but you get my point). Eventually, the
strongest concepts do become also the most developed ones, but due to the
fact that the source is readily available and that other developers choose
to implement and therefore support those interfaces which look most
promising, should there ever a new standard arise it will always have the
chance to rise and overcome the leading standard, no matter how well the
leading standard is established, and will likely do so in a least painful
fashion for the end-user (i.e. ALSA vs. OSS as opposed to OS9 vs. OSX
transition). Finally, open-source nature of the software minimizes the
potential for misrepresentation of the format's features (a.k.a. false
advertising in the commercial world). This is where Linux truly shines.
That being said, Linux has its own share of disparate formats which impede
the development of a standard (i.e. every sequencing software has a
different format for saving the sessions). However, it is my feeling that
this is simply a transitional phase and in due time the strongest will
prevail.
As far as the standard or core applications of the Linux community are
concerned, I really do not wish to go there as that may spawn heated
discussion which may completely detract from my goals. Besides, it is
exactly this individualized preference that drives the diversity in Linux's
software offering.
AUDIO-RELATED STANDARDS THAT CAME FROM LINUX COMMUNITY (in no particular
order -- it's 3am, give me a break ;-)
Jack, LADSPA, LASH, ALSA, Ogg/Vorbis, others?
(Lash is especially interesting as it is designed to unite seemingly
different standards under one umbrella session controlling mechanism which
is something unique for the Linux platform -- other proprietary formats are
imho harder to unite under such a meta-standard, if you like, because they
are often conceived to work just by themselves and do not necessarily
encourage efforts from various competitive companies to conform to them;
they rather come up with their own standard unless the existing standard is
too strong to compete with which in either case results in a less adequate
solution for the end-user)
What is both interesting and in part detrimental (at least in short-term) to
the Linux audio community is that many formats due to their openness are not
readily supported by the proprietary world as they have no profit-making
value (i.e. Apple's DRM-ed AAC is safeguarded by Apple so that they can
profit from licensing it to other companies and/or locking in their
iTunes/iPod market).
One final remark on Linux standards as a whole is that Linux holds an upper
hand when it comes to longevity of their standards as they are not
encumbered by the IP limitations imposed by a particular company and
therefore directly dependant on the company's longevity.
----------------------------------------
Sorry for the messy spill of thoughts, hopefully you'll get the main points
of my ideas. I am just too tired at this point to try to clean-up my prose.
I would really appreciate your thoughts as well as any potential additions
you may have. Many thanks!
Best wishes,
Ivica Ico Bukvic, composer & multimedia sculptor
http://meowing.ccm.uc.edu/~ico/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004
Hi all,
I am working on a project that makes very heavy use of the gtkmeter code
(borrowed from JAMIN), and seem to have a hard to track down problem....
I am using jack so there are a few threads involved and the meters are updated
from a g_timeout_add timer callback, the update_meters function is protected
by gdk_threads_enter/leave. The problem is that in spite of this I still
sometimes get the GUI locking up. There are no locks shared between the GUI
and the DSP code and when this happens the DSP continues to run just fine.
I remember a CVS version of JAMIN used to do something similar?
Does anyone here remember what the cure was, it might give me some hints....
Regards, Dan.
On Sat, Oct 30, 2004 at 03:23:04AM -0400, Ivica Ico Bukvic wrote:
> AUDIO-RELATED STANDARDS THAT CAME FROM LINUX COMMUNITY (in no
> particular
> order -- it's 3am, give me a break ;-)
> Jack, LADSPA, LASH, ALSA, Ogg/Vorbis, others?
RTP MIDI was prototyped on Linux (sfront). And
while I'm pretty sure Eric Scheirer prototyped
saolc (MPEG 4 Structured Audio) on SGI IRIS, a lot of the
late-stage debugging and Corrigenda changes
were done as part of sfront.
Although, in the interest of full disclosure,
I switched my desktop to OS X a few years
ago, so at this point its fair to say the reference
platform going forward for sfront-related standards
work is OS X ... although if I had enough energy to
maintain two desktops I'd make the second one Linux :-).
---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---
Hi all,
In the light of my upcoming presentation at ICMC, I am wondering whether it is possible to somehow automatically start hdsploader as soon as the snd-hdsp cardbus has been connected?
I tried adding the snd-hdsp executable shellscript to the /etc/hotplug/pci folder but that apparently did absolutely nothing and since there is no suggested syntax for the pci.usermap file (at least not under the mandrake), I have no idea how to make hotplug aware of it.
Furthermore, it seems that hotplug has very little or nothing to do with the cardbus as nowehere in the hotplug script do I find the syntax for this dmesg output:
PCI: Enabling device 0000:02:00.0 (0080 -> 0082)
ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
Hammerfall-DSP: no Digiface or Multiface connected!
card initialization pending : waiting for firmware
Hence, I've been wondering what do I need to do to automate hdsploader as soon as the cardbus has been connected?
I would greatly appreciate any help I can get!
Best wishes,
Ico
The realtime Linux Security Module is an installable kernel module
that enables realtime capabilities for any 2.6 kernel without needing
to directly patch the kernel. It was originally 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.
We are preparing a new version of this LSM for inclusion in an
upcoming 2.6.x kernel version. Special thanks to Jody McIntyre and
Chris Wright for many improvements to the LSM, and to Lee Revell for
patiently shepherding it through the kernel patch acceptance process.
No one *needs* to use this new version, the older ones work fine. But
it would help for some of you to download a beta version and try it
out. Two test files are available, use either one. The first is a
tarball[1] for building stand-alone, like previous LSM releases. This
version no longer supports kernels earlier than 2.6.4. The second is
a patch[2] for the current (2.6.10-rc1-mm2) development kernel. This
patch should apply cleanly against any recent kernel since 2.6.9-mm1,
and should work with some earlier ones with a little fiddling.
[1] http://www.joq.us/realtime/realtime-lsm-0.8.3.tar.gz
[2] http://www.joq.us/realtime/linux-2.6.10-rc1-mm2-rt2.patch.gz
There are some small changes to the user interface.
(*) The `allcaps' option is no longer supported. It was an
unnecessary security exposure to include in standard kernel sources.
Consequently, you will not be able to use the `jackstart' command
with this version, unless you are running a recent CVS version of
JACK (>=0.99.2). There is really no need for `jackstart' with
realtime-lsm, invoking `jackd' directly works fine.
(*) Recent kernels (>=2.6.9-mm1) externalize module parameters in
sysfs. With this feature, realtime-lsm options can be queried and
set via files in /sys/module/realtime/parameters, each named after
the corresponding parameter (any, gid, mlock).
Please report directly to me (i.e. mostly off-list) any problems or
successes you have with this version.
Thanks,
--
joq
Dear music enthusiasts,
LilyPond version 2.4 was released today!
LilyPond is a program for making beautiful music notation. It is
open source/free software, and is available for all popular operating
systems. It runs on most Unix flavors --including Linux and MacOS X--
and MS Windows. Use it for your music as well!
With this release, LilyPond does not rely anymore on TeX to do titling
and page layout, but distributes page breaks optimally by itself to
produce evenly spaced pages, while respecting user specified turning
points.
The slur formatting code has been completely rewritten, and now yields
classical engraving quality results for most cases.
In addition, version 2.4 adds fret diagrams, a safe execution mode for
webserver use, a further simplified input format, better typography
for ledger lines, many bugfixes and a fully revised and updated
manual.
Grab it at
http://lilypond.org
A big thank-you goes out to our contributors:
Carl Sorensen
David Svoboda
Guy Gascoigne-Piggford
Heikki Junes
Hendrik Maryns
Kristof Bastiaensen
Mats Bengtsson
Michael Welsh Duggan
Peter Lutek
Werner Lemberg
Also thanks to our bug-hunters:
Antti Kaihola, Bertalan Fodor, Brian Clements, Christian Hitz,
Christoph Ludwig, Christophe Papazian, Daniel Berjón DÃez, Dave
Phillips, David Bobroff, David Brandon, Doug Asherman, Ed Jackson,
Heinz Stolba, Jefferson dos Santos Felix, Karl Hammar, Marco Gusy,
Martin Norbäck, Matthias Neeracher, Maurizio Tomasi, Michael
Kiermaier, Pascal Legris, Peter Rosenbeck, Russ Ross, Stephen Pollei,
Thomas Scharlowski, Will Oram, Yuval Harel,
Happy music printing,
The LilyPond development team,
Han-Wen Nienhuys & Jan Nieuwenhuizen
Core development
Graham Percival
Documentation Editor
Erik Sandberg
Bugmeister
Pedro Kroeger
Build meister
--
Han-Wen Nienhuys | hanwen(a)xs4all.nl | http://www.xs4all.nl/~hanwen