1. A short summary of changes
Ecasound's emacs mode, ecasound.el, has been updated to
version 0.8.3. Due to severe bugs found in the native Python
ECI implementation, the C implementation has been again set as
the default. Minor interoperability problems with older JACK
releases and Ecasound have been fixed. A bug that caused builds
against an external libreadline to fail, has been fixed.
Also recording problems with the WinTv 401Dbx and other
bt878-based devices have been fixed. This release is compatible
with the upcoming alsa-lib-1.0 releases.
---
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
Full list of changes is available at
<http://www.wakkanet.fi/~kaiv/ecasound/history.html>.
---
4. Interface and configuration file changes
None.
---
5. Contributors
Patches - Accepted code, documentation and build system changes
Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes)
Junichi Uekawa (ecasound makefile bug, doc generation
using Hevea)
Kai Vehmanen (various)
Bug Hunting - Reports that led to bugfixes (items closed)
Hirendra Hindocha (2) -- recording problems with WinTv 401dbx,
ecacontrol.py bugs
Stefan Bundt (1) -- ecacontrol.py breaks under heavy load
Dave Phillips (1) -- errors in EIAM help
Junichi Uekawa (1) -- compability bug with older JACK versions
---
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.1.tar.gz
Distributions with maintained Ecasound support:
Agnula - http://www.agnula.org
Debian - http://www.debian.org
FreeBSD - http://www.freebsd.org/ports/audio.html
Gentoo Linux - http://www.gentoo.org
PLD Linux - http://www.pld.org.pl
SuSE Linux - http://www.suse.de/en
Contrib Packages and Add-On Distributions:
AudioSlack for Slackware - http://www.audioslack.com
PlanetCCRMA for RedHat/Fedora
- http://www-ccrma.stanford.edu/planetccrma/software
Thac's RPMs for Mandrake - http://rpm.nyvalls.seApps.kde.com packages for Mandrake/Redhat/SuSE
- 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!
Hi,
I've written preliminary OSS driver for JACK. Patch for jack 0.80
attached.
This is by no means final, this is something pre-alpha, but seems to
work at least with alsaplayer. It's likely to contains errors in jack
driver implementation. All comments/patches/anything is welcome..
If you are compiling with OSS Lite, please comment out the non-S16
formats.
RedHat RPMs and patch available at http://www.sonarnerd.net/linux/ ,
SuSE 9 packages coming.
--
Jussi Laako <jussi.laako(a)pp.inet.fi>
what would all this mean for LADSPA?
1) there would need to be a way to associate plugins+GUIs since we
probably don't want them in the same object.
- could be done using LRDF or a dir search path combined with the
plugin ID.
2) the GUI would have to declare which toolkit it was using so that
the host could ensure support for it (i.e. fire up a thread that
will run the equivalent of gtk_main or QApplication::exec()) and
ask the relevant toolkit thread to call the primary entry point to
the GUI. how does it declare this? a well known symbol? is it a
char* or a function call? is it in the LRDF entry, or the filename,
or what?
3) adopt a standard for how the entry point is to be
called. presumably it should get a pointer to the plugin instance,
but what (if anything) else? oh yes, a return value that provides
a way to terminate the GUI.
4) the names of toolkits would have to be standardized and possibly
include version information. "GTK+:2.2" or "Qt:3.1" might work, for
example.
5) a small library (which i have more or less started already) to
provide simple C functions to offer per-toolkit support. a host
would look at the pluginGUI toolkit, call the support function
with the .so name, and the right things would happen. the library
needs an ancillary function to kill the GUI when the time is
right.
6) [ only if we really wanted hosts to have a "real" handle on the
plugin GUI window ] the library would need to contain a way to
pass in an X "Window", and wrap it up as a native drawing area
for each toolkit. i would prefer not to do this for now, if ever.
--p
>BUT, I think a userspace daemon that starts at boot time and protects
>against lockups (rt_monitor) would be a very good thing to have.
>
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to jack even rt_monitor did not helped,
the machine keeped totally locked. Ping is still answered but thats it.
- Stefan
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
These updates makes it possible to use windows vst plugins in
linux applications getting very descent realtime performance.
I have successfully ran vst plugins in ardour with 2.66 ms latency.
Sources:
http://www.notam02.no/arkiv/src/
Linux Vst Compatibility Page
http://80.61.20.184/vst/
Tutorial:
http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/
Mandrake binaries: (not the latest versions (yet))
http://rpm.nyvalls.se/sound9.1.html
Vstserver 0.2.7 -> 0.2.8:
-------------------------
-Added SCHED_FIFO priority and locking all mem (mlockall) to the
processing thread. Can be used without being root by for example
using the givertcap program by Tommi Ilmonen
http://www.tml.hut.fi/~tilmonen/givertcap/
To turn off realtime priority, start the vstserver with either
the "-NRT" or "--nonrealtime" flag.
vst ladspa plugin v0.1.5 - stable
----------------------------------
-Fixed the worst nonrealtimeness for the default mode.
When using realtime priority on the vstserver, it
should not be necesarry to set LADSPAVST_RT to "1".
--
Can this get applied? We discussed it in September, and I thought it
was going to be applied, but it never was.
It includes defines for:
LADSPA_HINT_MOMENTARY
LADSPA_HINT_RANDOMISIBLE
Taybin
Hello LAD,
I'd like to propose an extension of the LADSPA specs, or more correctly, a
particular interpretation of the current specs, in order to support the use of
plugins in a 'polyphonic' context.
The problem to be solved is this:
In a host such as AMS, a plugin can be loaded as part of a polyphonic patch. This
means that there will be as many instances of the plugin as there are voices, but
all of them share the same parameters and user interface. To the user they look as
a single module.
Now a plugin could have resources that can be shared between voices of a polyphonic
instance, but not in general between al instances. For example there could be
precomputed (w.r.t. the sample rate code) tables that depend on a control parameter.
At the moment there is no mechanism to tell instances of a plugin that they are part
of a such a polyphonic group.
I propose the following solution, which does not require the definition of new
data or functions in the interface. It has been tested with AMS, and works well.
It is also backwards compatible. Plugins or hosts that do not care about polyphony
can just ignore these requirements.
1. Plugins that contain code that is specific for polyphonic use must implement
all four 'lifecycle' functions, i.e. instantiate(), activate(), deactivate()
and cleanup().
2. If a host wants to create a polyphonic instance, it first calls instantiate()
for all voices, then activate() for all voices. To remove a polyphonic instance
it first calls deactivate() for all voices, and then cleanup() for all voices.
To create or remove multiple instances that do not form a polyphonic group, a
host always calls both instantiate() and activate() c.q. deactivate() and
cleanup(), for each instance before dealing with the next.
3. If a plugin detects that its instantiate() function has been called N > 1 times
before the first call to activate(), it knows that some of the recources created
by the first activate() can be shared with the other voices. The symmetrical
treatment of deactivate() and cleanup() helps to keep the 'destructor' code
simple.
Comments invited !
--
FA
Hi,
I've recently been learning to use JACK, and I had a look around for
some kind of introductory article. I couldn't find one, so I wrote
the tutorial I would have wanted, as I learnt.
The tutorial is here:
http://dis-dot-dat.net/jacktuts/starting/index.html
Please have a look, make suggestions. Flames are fine, too. Let me
know if I've made some huge error. Or maybe I'm not doing things
the best way? Whatever, let me know.
If this is well received, I'll write about more advanced topics as I
get to them - mixing, the transport, threading without blocking the
process callback, etc.
I'll probably be asking a lot of questions later on, especially
about best practise.
Thanks peeps,
James
hi!! this is my fist post on LAD, something may know me from my
presence on #lad @ freenode :P
btw i've a question for you all..
is someone using a powermac for linuxaudio apps? if yes what audio
interface do you use?
i've got an imic but i've a loooooot of troubles!!
--
wil - BeHappy_