Set_rlimits 1.3.0 has been released. This release integrates a Makefile
patch by Lucas C. Villa Real and adds an option to specify non-standard
library locations (which must be secured directories) via LD_LIBRARY_PATH to
the called executable.
It is available from
http://www.physics.adelaide.edu.au/~jwoithe/set_rlimits-1.3.0.tgz
Regards
jonathan
Hello,
DRC 2.7.0 is out and is available at:
http://drc-fir.sourceforge.net/
Here are the release notes:
A new method for the computation of the excess phase component inverse, based
on a simple time reversal, has been introduced. The sample configuration files
have been rewritten to take advantage of the new inversion procedure. Sample
configuration files for 48 KHz, 88.2 KHz, 96 KHz sample rates have been added.
The homomorphic deconvolution procedure has been improved to avoid any
numerical instability. A new Piecewiswe Cubic Hemite Interpolating Polynomial
(PCHIP) interpolation method, providing monotonic behaviour, has been
introduced in the target response computation. All the interpolation and
approximation procedures have been rewritten from scratch to provide better
performances and accuracy.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
Hello,
I try to squeeze as much performance as possible out of my upcomming
Linux synthesizer and try manual vectorization with following construct
in c, mainly to vectorize away multiplications :
typedef float v4sf __attribute__ ((vector_size(16)));
union f4vector
{
v4sf v __attribute__((aligned (16)));
float f[4] __attribute__((aligned (16)));
};
On AMD 64bit Turion (single core) on 64 Studio in 64bit mode this doesnt
improve performance at all, actually it even get worse. Is GCC that good
at optimizing on its own? I have no access to Intel processors at the
moment but would love to know how to benefit from SIMD optimizations of
float operations.
Sources on the web are rather thin...
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
New version of Simple Sine Generator is available.
Simple Sine Generator is very simple instrument/generator plugin with
midi in and audio out. It expected to be useful for testing LV2 hosts
and as base for writing your own plugins.
It is written in plain C.
= What is new =
Main change is switch to event port LV2 extension. LV2 URI is changed
and installation directory is changed too. So you can have both older
midi port variant and newer even port ssg installed simultaneously.
Also, bug in Makefile is fixed. If with earlier version you got error on
compilation because of missing fftw or dynparam libraries, now it should
be fine.
Also, there is fix of a pitch bug (wrong octave).
I'd like to thank Andreas Kusterer for switching ssg to even port
extension.
Simple Sine Generator has trac homepage now:
http://nedko.arnaudov.name/soft/ssg/trac
= Download =
http://nedko.arnaudov.name/soft/ssg/ssg-1.13.tar.bz2http://nedko.arnaudov.name/soft/ssg/ssg-1.13.tar.bz2.sig
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
ll-plugins is a small collection of LV2 plugins and a host that runs
them. This is the first release.
In order to build ll-plugins you need to have the following packages
installed:
cairomm >= 1.2.4
gtkmm >= 2.8.8
libjack >= 0.109.0
liblash >= 0.5.1
lv2-c++-tools >= 1.0.0
libsndfile >= 1.0.16
libsamplerate >= 0.1.2
You can download the latest released version of ll-plugins from
http://ll-plugins.nongnu.org
You can also get the latest development code from the Git repository
using this command:
git clone git://git.sv.gnu.org/ll-plugins.git
Beware that the development code may not work or even compile.
THE PLUGINS
===========
All plugins are installed in separate LV2 bundles (except the ones that
are closely related, like the math-constant plugins or the mono and
stereo versions of the peak meter). The GUIs, for the plugins that have
GUIs, are installed in bundles of their own to make it easier for
packagers to put them in separate binary packages to avoid Gtk
dependencies for the plugins themselves.
The plugins are reasonably simple and could be used as examples or
starting points for hackers who want to write LV2 plugins based on the
frameworks in the lv2-c++-tools package. There are synths, event
processors, simple audio and control manipulators and GUI-based plugins.
BASIC ARPEGGIATOR
=================
This plugin is just what it says. It takes MIDI event input and writes
MIDI event output in the form of an arpeggio over the held keys in the
input. You can control the speed of the arpeggio and the direction (up
or down).
CONTROL2MIDI
============
A plugin that converts a LV2 control port value to MIDI CC events. You
can set the CC number and the expected range of the input value.
KLAVIATUR
=========
A MIDI keyboard. You can use it to send pitchbend events, CC events and
of course notes, using mouse or keyboard. Handy when you want to test a
synth patch but don't have a real keyboard nearby. Klaviatur has a Gtk
GUI that you use to control it.
MATH-CONSTANTS
==============
A set of plugins that output constant control parameters for
mathematical constants defined in the C header <math.h>.
MATH-FUNCTIONS
==============
A set of plugins wrapping most of the functions in the C header <math.h>
(sin(), cos(), exp(), modf() etc). All are available as both audio rate
and control rate functions.
PEAK METER
==========
A decaying peak meter that shows the peak level of the input signal.
There is a mono and a stereo version. Both have Gtk GUIs.
RUDOLF 556
==========
A simple drum machine with six separate drum voices - two bass drums,
two snares and two hihats. The different voices are mapped to C, D, E,
F, G and A in all octaves, and every voice has three control parameters
(length, hardness and volume). This plugin has a Gtk GUI that you can
use to control the parameters.
SINESHAPER
==========
An LV2 version of the Sineshaper synth - two sine oscillators fed
through two sine waveshapers in series, with a bunch of parameters to
control them. This plugin has a Gtk GUI too.
THE HOST
========
The host that comes with this package is called Elven (Experimental LV2
Execution ENvironment). It is pretty slow and I don't really recommend
it. If you can use another host, do that.
--ll
Hi!
I have recently done some window-shopping to get a grip on what is out
there these days (should the temptation to spend even more money on tech
become irresistable ...)
Anyways, this chip:
http://www.analog.com/UploadedFiles/Data_Sheets/AD1988A_1988B.pdf#xml=http:…
.. appears to be quite popular, has 10 (ten!) channels out at 24/196
plus a healthy 6 channels in.
I wonder, do any vendors really connect all of this to any real physical
ports?
--
http://karma.darktech.org/~male/lash_requirements.html
_____________________________
______ __ _ _
-+--- Overview - - -
The Non-DAW comprises a modular system. It would be convenient for
the author and the users alike if the state of Non-DAW's components
and other, entirely separate, programs could be managed together as a
coherent whole. The LASH system appears, at first glance, to support this
kind of arrangement. However, the current LASH API is overly complex and
lacking in what this author considers to be a basic level of functional
maturity. It is this confusion, I believe, which has resulted in the
poor adoption of LASH and its subsequent stagnation.
______ __ _ _
-+--- Basic Concerns - - -
Non-DAW, and other complex programs with large state which cannot
be held in RAM all at once, require a few things that LASH doesn't
currently provide. These needs include the following:
1. The need to know the LASH project path the moment it first joins the
LASH session at startup. If this were so it could start a new Non-DAW
project under the LASH project path and new captures would go in their
right place without any intervention by the user. To clarify: there
must be no time when Non-DAW is connected to LASH without knowledge
of the path to the current LASH project directory.
2. The need to be informed of, or else be able to query at any time,
the LASH project name. If the LASH project path and the LASH project
name weren't different, we could get away with scanning the path for
the name, but this is unfortunately not the case.
Additionally, the following would be required in order to fully integrate
with LASH (transparently to the user).
1. Ability to initiate new projects, choosing among a list of previously
recorded templates.
2. Ability to save the current project as a template.
3. Ability to initiate a save of the entire LASH project.
4. Ability to choose from a list of LASH projects to load.
Some of the above are already possible to some extent with the current
API, but complicated greatly by the artificial division of the API into
client and control portions.
Non-DAW and Non-Sequencer have the ability to change to a new project/song
without restarting, but LASH makes no use of this--always restarting
instances of these programs instead of reusing them. Of course,
Non-DAW and Non-Sequencer have extremely short startup times compared
to other programs in their class, but still, I would like to avoid the
distraction of many windows opening and closing at LASH project change
time--it reflects poorly on my and any other programs which can change
songs without crashing.
I would also like to see the preferred behavior of new/save/load
operations in all clients specified by LASH so as to avoid confusion
and potential data loss. Should any LASH client be permitted to save
or load to/from disk /it's own state/ without informing LASH? This may
seem harmless when the program state consists of a single file--as it
is assumed that a copy of that file will be saved by the program in the
LASH project directory whenever a LASH save is next performed. But now
the user has two (differing) copies of his file--and he isn't sure which
one he really edited--or where it is on disk. The problem becomes even
more serious when the program state includes a directory filled with
gigabytes of audio sources...
Is it really advisable for LASH clients to operate on their state,
which is supposedly under the control of LASH, as if it was theirs
alone--without informing LASH of their activities? I don't necessarily
know the answer to this question, but I do know that LASH needs to make
a recommendation of some kind regarding the expected behavior--whatever
it may be.
______ __ _ _
-+--- Additional Thoughts - - -
There are also many things which LASH /could/ do to enhance the
integration experience, but doesn't.
These include, but are by no means limited to, the following:
* Templating and layering functionality.
* Project grouping (eg. all songs for an album) for easy management
of hundreds of projects. Please use subdirectories and/or symlinks
for this and not some XML junk.
* Global Undo/Redo functionality (simply sends a message to all clients
asking them to undo/redo and possibly providing feedback), additionally,
we can envision storing state diffs on disk for clients with no native
undo capability--something akin having the state in a git repo could
be used, reloading a reconstruction of prior state upon an 'undo'
request)--this is only viable if LASH can reuse program instances.
* Looser integration with/no direct dependance on JACK.
Some of these have been mentioned before and I've omitted many potential
improvements and design changes which I consider less important.
--
May 15 2008,
John Moore Liles
Hi,
is there a way to compute an absolute timetag from the jack position in order to
send timestamped OSC messages, from the jack process callback?
Regards,
--
Olivier
Is there any good reason why the B-format port groups refer
to the 2nd order horizontal components as R and S ?
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
