Hi.
I released ZynAddSubFX 1.4.3 at
http://zynaddsubfx.sourceforge.net
ZynAddSubFX is a free software synthsizer with many
features.
Paul.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
I have done some testing on different audio codecs with different
settings.
Results are available at http://www.sonarnerd.net/projects/wavcomp/
More tests to come... Any comments on testing procedure are welcome.
Is someone able to put test .wav through ATRAC (back-and-forth)? I'd
like to include it in test results.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
1. A short summary of changes
A set of severe bugs in audio mixing code have been fixed.
Pyecasound build process has been improved. Reporting chainsetup
parsing errors has been improved significantly. Support for
the JACK 0.80 transport interface has been added. Support for
reading and writing aiff, snd and au files has been fixed.
Changes have been made to ensure correct operation with
the NPTL package recently added to Linux kernel and glibc.
A serious bug in metronome timing was fixed. Minor bugs
in dynamic sample rate changes, MIDI-server initialization
and the ewf file format have been fixed.
---
2. What is Ecasound?
Ecasound is a software package designed for multitrack audio
processing. It can be used for simple tasks like audio playback,
recording and format conversions, as well as for multitrack effect
processing, mixing, recording and signal recycling. Ecasound supports
a wide range of audio inputs, outputs and effect algorithms.
Effects and audio objects can be combined in various ways, and their
parameters can be controlled by operator objects like oscillators
and MIDI-CCs. A versatile console mode user-interface is included
in the package.
Ecasound is licensed under the GPL. The Ecasound Control Interface
(ECI) is licensed under the LGPL.
---
3. Changes since last release
* Support for JACK 0.80 transport interface. The recently
released JACK 0.80.0 marks another milestone for Linux audio
development. The new transport interface allows concurrent use
of multiple independent audio applications with full
sample-accurate transport synchronization. This release of
Ecasound provides full support for the new transport API.
See the following links to ecasound-list postings that
give examples of how to use Ecasound with the new transport API:
http://eca.cx/ecasound-list/2003/08/0005.htmlhttp://eca.cx/ecasound-list/2003/08/0070.html
* Metronome timing bug. There was a subtle bug in the
pulse gate operator that is used to generate the
metronome signal. This bug caused a small (<0.5%) timing
error in metronome speed. The bug has been fixed, but the
change in speed might cause problems for working with
sessions recorded with previous versions of Ecasound.
Thanks to Carsten Bauer for finding the bug.
Full list of changes is available at
<http://www.wakkanet.fi/~kaiv/ecasound/history.html>.
---
4. Interface and configuration file changes
Libecasound interface version number was incremented to 11.
This release is backwards compatible with interface
versions 9 and 10. See 'ecasound/libecasound/ChangeLog'
for a detailed list of changes.
Libkvutils interface version number was incremented to 6.
This release is backwards compatible with versions 5 and 4.
See 'ecasound/kvutils/ChangeLog' for a detailed list of changes.
Note! Using libecasound and libkvutils outside Ecasound has
been discouraged since the release of 2.2.0 in Jan 2003. The
interface changes introduced in this 2.3.0 release should
only affect a small group of distributors and developers.
Apps such as Ecamegapedal need to be recompiled only if
you want to take advantage of the new features introduced
in the latest Ecasound release.
---
5. Contributors
Patches - Accepted code, documentation and build system changes
Kai Vehmanen (various)
Bug Hunting - Reports that led to bugfixes (items closed)
Jeremy Hall (3) -- non-default chainsetup srates, mixdown
signal leak bug, pyecasound install
Junichi Uekawa (3) -- non-default chainsetup srates,
pyecasound install, gcc-3.3 verification
Janne Halttunen (2) -- locale-settings broke map-* commands,
MIDI-server startup bug
Vegard Lima (2) -- feedback bug, ewf srate bug
Carsten Bauer (1) -- timing bug in metronome and pulse gate
Ismail Donmez (1) -- build errors with sys-readline option
Lars Henrik Mai (1) -- aiff/au/snd bug
Stephan Niemz (1) -- non-default chainsetup srates
Al Oemens (1) -- reporting chainsetup parsing errors
Oliver Thuns (1) -- -ei big shift-x values
Tommi Uimonen (1) -- problems with ecasignalview channel meter
layout
---
6. Links and files
Web sites:
http://www.eca.cxhttp://www.eca.cx/ecasound
Source packages:
http://ecasound.seul.org/downloadhttp://ecasound.seul.org/download/ecasound-2.3.0.tar.gz
Distributions with maintained Ecasound support:
Agnula - http://www.agnula.org
Debian - http://packages.debian.org/unstable/sound/ecasound2.2.html
DeMuDi - http://www.demudi.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software
SuSE Linux - http://www.suse.de/en
Contrib Packages for Distributions:
Mandrake - http://rpm.nyvalls.se/
Slackware - http://www.audioslack.com
Various distros - http://apps.kde.com/rf/2/info/id/2146
Note! Distributors do not necessarily provide packages for
the very latest Ecasound version.
--
http://www.eca.cx
Audio software for Linux!
Firmware loaders for Midiman and Tascam USB MIDI devices
These packages allow you to use Midiman's MidiSport USB MIDI interfaces and
Tascam's USB Audio interfaces with Linux. These devices require a firmware
download before an operating system driver (e.g. ALSA's snd-usb-audio) can
access them.
These loaders use the same firmware used by the Windows drivers, so you need
a file of the respective Windows driver to install them. (See README files
for details.)
-*-
The MidiSport firmware loader is required to use USB MIDI devices from
M-Audio/Midiman under Linux. Release 0.1 contains some slight enhancements
to the installation process, and is the first release hosted on
SourceForge.net.
Supported devices:
MidiSport 1x1, 2x2, 4x4, 8x8, KeyStation, Oxygen, Radium, Uno, and maybe
MidiSport 2x4.
-*-
The Tascam firmware loader is required to use USB MIDI/Audio devices
from Tascam under Linux. There is also a loader for the FPGA
configuration data included. The firmware and the FPGA configuration
data will be extracted from your Windows driver files during
installation. This is an initial release.
Supported devices:
US-122, US-224 and US-428
-*-
To download the loaders, go to the project home page:
http://usb-midi-fw.sf.net/
martin
Hi,
Back in March it was suggested that some additional hints should be
added to LADSPA - there was some discussion, but nothing since. Here's
what I gathered from the archives:
/* Hint MOMENTARY indicates that that a control should behave like a
momentary switch, such as a reset or sync control.
LADSPA_HINT_MOMENTARY
may only be used in combination with LADSPA_HINT_TOGGLED.
*/
#define LADSPA_HINT_MOMENTARY 0x40
/* Hint RANDOMISABLE indicates that it's meaningful to randomise the
port
if the user hits a button. This is useful for the steps of control
sequencers, reverbs, and just about anything that's complex.
Randomising
a control should not result in anything too suprising happening to
the user (eg. sudden +100dB gain would be unpleasant). */
#define LADSPA_HINT_RANDOMISABLE 0x80
/* Hint OUTPUT_METER indicates that the value of output
control port is likely to be most meaningful to the user if
displayed as a meter. Can be combined with LADSPA_HINT_LOGARITHMIC
if the meter should use a log scale. (e.g. dB)
*/
#define LADSPA_HINT_OUTPUT_METER 0x??
/* Plugin Ports:
Plugins have `ports' that are inputs or outputs for audio or
data. Ports can communicate arrays of LADSPA_Data (for audio
or continuous control inputs/outputs) or single LADSPA_Data values
(for control input/outputs). This information is encapsulated in the
LADSPA_PortDescriptor type which is assembled by ORing individual
properties together.
Note that a port must be an input or an output port but not both
and that a port must be one of either control, audio or continuous.
*/
[...]
/* Property LADSPA_PORT_CONTINUOUS_CONTROL indicates that the port is
a control port with data supplied at audio rate. */
#define LADSPA_PORT_CONTINUOUS_CONTROL 0x10
-
Myk
The MidiSport firmware loader allows to use the MidiSport USB MIDI
interfaces from M-Audio/Midiman with Linux.
Version 0.2 fixes a bug in the loader script which tried to load the
firmware files from the wrong directory.
Supported devices:
MidiSport 1x1, 2x2, 4x4, 8x8, KeyStation, Oxygen, Radium, Uno.
To download the loader, go to the project home page:
http://usb-midi-fw.sf.net/
--
Clemens
JACK RELEASE 0.80.0
JACK is a low-latency audio server, written primarily for the GNU/Linux
operating system. It can connect a number of different applications to
an audio device, as well as allowing them to share audio between
themselves. Its clients can run in their own processes (ie. as normal
applications), or can they can run within the JACK server (ie. as a
"plugin").
JACK is different from other audio server efforts in that it has been
designed from the ground up to be suitable for professional audio work.
This means that it focuses on two key areas: synchronous execution of
all clients, and low latency operation.
CHANGES:
New transport API (details (of a sort) below).
new example client for control the transport.
ignoring of first xrun on jackd startup.
Much more portable across processors (details below).
jackd -v (--verbose) now prints useful transport state change
information for debugging JACK and clients. Also reports timeout info
in seconds, not microseconds now.
new dummy driver (along side the existing alsa and portaudio drivers).
Removed incomplete Solaris driver.
support for asymmetric soundcards (for example, es1968 chip has
interleaved stereo for playback but non-interleaved stereo for capture).
Now enforces power of two sized buffer lengths.
Many minor bug fixes.
DETAILS:
The new transport API:
It has greatly changed; if you're a developer, please see the
documentation. But as a highlight: jack_set_transport_info() and
jack_engine_takeover_timebase(), (the old timebase master interfaces)
now do nothing. Instead, use jack_set_timebase_callback().
Portability:
<jack/types.h> typedefs are now defined using the C99 standard
fixed-size integer typedefs. These new typedefs are binary compatible
with 32-bit platforms, but not 64-bit machines.
Programs using printf on these values will get GCC compiler
warnings. To suppress the warnings, use the corresponding C99
printf specifications defined in <inttypes.h>. That header is already
implicitly included by <jack/types.h>, but can also be
included explicitly to maintain compatibility with older versions
of JACK without messy #ifdef's. Adding explicit casts will also
work, but may suppress future warnings you might want to see.
jack_get_sample_rate() now returns jack_nframes_t rather than
unsigned long. These are the same on 32-bit machines, but not on
64-bit platforms.
These changes were made to accommodate the increasingly popular 64-bit
platforms; specifically, the new Opteron with it's 32-bit compatibility
mode. 32-bit mode probably won't work, but if all programs are compiled
as 64-bit (which Jack supports), it should work fine.
Taybin Rutkin
Greetings:
I've added some new & updated listings to the pages since posting the
last announcement. Some of the interesting items include Drums++ (a
programming language for percussion), GuitarCodex Plus (excellent
chord/scale utility for guitarists), Pymprovisator (accompaniment
software), and updates for Mixxx and the Music Kit. Just FYI...
Best regards,
== dp
For those who are interested in JACK's transport functionality, the
following message provides a step-by-step example of distributed (as in
multiple independent apps participating in the same session) multitrack
recording, plus some discussion about current limits and usability issues.
Links to the latest snapshot tarballs are available at the very end
of this message. For info about JACK transport, see:
http://www.joq.us/jack/refman/transport-design.htmlhttp://eca.cx/lad/2003/08/0109.html
The Feb'03 mail I refer below can be found at:
http://boudicca.tux.org/hypermail/jackit-devel/2003-Feb/0052.html
It's good to note that I could have used any transport-aware application
in place of the Ecasound instance 'ecafoo' to provide audio tracks to
record against [*]. The application could have been (assuming proper
support is added to them at some point) Alsaplayer, Ardour, SoundTracker,
CheeseTracker, Hydrogen, Gmorgan, etc, etc... you get the picture.
Similarly the recording client 'ecabar' (an Ecasound instance in our
example session) could be replaced by Ardour, Rosegarden, Muse, Audacity
or any other multitrack capable audio recorder.
Sounds good, doesn't it? :) So let's continue with the example:
[*] As we are still developing the transport system and there
are only few apps that follow bleeding edge development,
I had to settle on using Ecasound. :)
---------- Forwarded message ----------
Subject: Re: [Jackit-devel] distributed multitracking
It's more than six months now since I last tried this, time for another
look at this use case:
On Wed, 5 Feb 2003, Kai Vehmanen wrote:
> --------------
> The good news:
[...]
> I just managed to record a piece with three guitar tracks using three
> separate instances of ecasound, each instance handling one guitar take. I
I did the same again with the new transport interface.
Environment:
linux-2.4.19-lowlatency-capabilities-tracepatches
Midiman Delta44 as the soundcard
latest 0.9.6 ALSA drivers
latest JACK and Ecasound from CVS (2003-Aug-25)
I set jackd to use the _maximum_ latency settings for Delta44 (-n 3 -p
1024) to create the worst possible environment for syncing clients.
The test went through unbelievably smoothly. Not a single crash in any app
during the whole testing. Unlike in the test in February, this time I
didn't have to restart all the clients after each and every take and/or
mixdown run. Also, I was now able to seek from any of the Ecasound
sessions or from jack_transport and all the other clients would
correctly follow the changes. Yay! Nice work Jack (J.O'Quin) and JACK! :D
> -------------
> The bad news:
[...]
> Synchronization is a big problem. Let's say you have the following setup:
... and still is.
> alsa_pcm -> ardour
> soundtracker -> alsa_pcm
[...]
> Jackd is run with -p 1024 -n 2, ST is the sync master, hw-monitoring is
> used for the alsa_pcm input. The big problem is that there's no easy way
> for ardour to learn how much non-valid data will come out of alsa_pcm in
> the start. In this distributed recording case ardour should ignore the
> first 2*1024 samples (maximum of ST output and alsa capture latency).
There doesn't seem to be any easy way around this problem. Somehow we need
to provide meta-information concerning how these independent connections
between JACK ports are related (from user POV) to each other.
To solve this for my test case, I added a new option to Ecasound for
specifying explicit multitrack recording offset. The syntax is
"-z:multitrack,XXX", where 'XXX=n*p', 'n' jackd/alsa_pcm period count
and 'p' jackd/alsa_pcm period size in samples. With this meta-info, the
multitrack sync works comparably with a session without JACK.
And finally, a test script for a minimal distributed multitracking
session:
--cut--
# 1. launch jackd and jack_showtime (_very_ useful if something goes wrong)
# 2. test input levels (play something and verify that the meters
# are moving); ctrl-c to exit
ecasignalview jack_alsa
# 3. create the monitor track to play against (15 secs)
sh1> ecasound -i null -o monitor.wav -x -pn:metronome,120 -t:15
# 4. launch the slave client
sh1> ecasound -i monitor.wav -o jack -G:jack,ecafoo,sendrecv -c
ecasound1> engine-launch
# 5. launch the master client (replace 3072 with value corresponding
# to the -n/-p params you run jackd/alsa_pcm with)
sh2> ecasound -a:rec -i jack_alsa -o recorded.wav -a:mon -i jack -o jack_alsa -G:jack,ecabar,sendrecv -z:multitrack,3072 -c
ecasound2> engine-launch
# 6. connect the slave client to the master client
sh3> jack_connect ecafoo:out_1 ecabar:in_3
sh3> jack_connect ecafoo:out_2 ecabar:in_4
# 6. launch jack_transport and control the two multitrack-recorder
# instances
sh3> jack_transport
jack_transport> locate 0
jack_transport> play
# 7. record something against 'monitor.wav' (check jack_showtime output
# if you have problems)
# 8. listen to the result (note! we can let the slave client to run
# all the time)
jack_transport> stop
ecasound2> stop
ecasound2> quit
sh2> ecasound -a:rec -i recorded.wav -a:mon -i jack -a:rec,mon -o jack_alsa -G:jack,ecabar,sendrecv -c
ecasound2> engine-launch
sh4> jack_connect ecafoo:out_1 ecabar:in_1
sh4> jack_connect ecafoo:out_2 ecabar:in_2
jack_transport> locate 0
jack_transport> play
--cut--
... and that's it, the sync should be correct.
If you want to try this, remember to update to latest JACK and ecasound
CVS, or use the following snapshots (note that these are __NOT__ official
releases, so the APIs can still change before the next actual stable
release):
http://ecasound.seul.org/download/other/jack-audio-connection-kit-0.79.2-jo…http://ecasound.seul.org/download/ecasound-2.2.4-snapshot20030826.tar.gz
--
http://www.eca.cx
Audio software for Linux!