Heya!
The Linux Plumbers Conference 2009 CFP ends soon! If you are working on
Linux audio infrastructure then make sure to submit a paper for the
audio track! Do it now, it'll soon be too late, you have time until
June 15th!
Why attend or submit a paper? Because this is *the* conference where
you can make yourself heard and influence the lower levels of our
audio stacks. If you have some beef with or something to contribute to
the lower level sound (and other) infrastructure of modern Linuxes,
then *this* is where to go.
http://linuxplumbersconf.org/2009/
Papers go here please:
http://linuxplumbersconf.org/2009/submit/
LWN has some coverage of what happened last year, in case you want to
have a peek:
http://lwn.net/Articles/299211/
See you in Portland! And spread the word!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Four-band parametric equaliser LV2 plugin. DSP code by Fons Adriaensen.
Homepage: http://nedko.arnaudov.name/soft/lv2fil/
Screenshot: http://nedko.arnaudov.name/soft/lv2fil/lv2fil.png
Tarball download:
http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2http://nedko.arnaudov.name/soft/lv2fil/lv2fil-2.0.tar.bz2.sig
= Overview =
Stereo and mono LV2 plugins, four-band parametric equalisers.
Each section has an active/bypass switch, frequency, bandwidth and
gain controls. There is also a global bypass switch and gain control.
= DSP =
The 2nd order resonant filters are implemented using a Mitra-Regalia
style lattice filter, which has the nice property of being stable
even while parameters are being changed.
All switches and controls are internally smoothed, so they can be
used 'live' whithout any clicks or zipper noises. This should make
this plugin a good candidate for use in systems that allow automation
of plugin control ports, such as Ardour, or for stage use.
= GUI =
The GUI provides knobs and toggle buttons for tweaking filter
parameters. It also provides frequency response widget with
differently coloured curve for each section and separate curve for
total equalization effect.
The GUI uses the External UI extension. lv2rack (part of zynjacku)
supports this extension. Ardour-2.8 needs patch to support the
external UI extension.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
> does anyone have any idea on the uptake of VST 3 ?
Seems only VST3 works well on 64-bit systems. (VST 2 is supported, but runs
in a high-latency 32-bit emulation environment).
My hunch is VST3 uptake will track 64-bit Windows uptake.
Jeff
> Is this becoming the standard and 2.* being quickly
> deprecated?
> Comparing the two, there is a lot of stuff in VST3, it
> seems quite heavy, which seems to be a change
> from the relative simplicity of 2.*. Also 3 does not look
> backwards compatible (so older plugins would not
> work with it).
> On the FOSS front then, with 3 we are stuck again
> with Steinberg's terms. So my question is: are
> developers in general sticking with 2.* or has everyone
> moved to 3. Again, my question has an educational
> slant, should we be teaching 3 or 2 (or both, if we
> are teaching VST at all, that is) ?
>
> Thanks
>
> Victor
Hi everyone,
does anyone have any idea on the uptake of VST 3 ?
Is this becoming the standard and 2.* being quickly
deprecated?
Comparing the two, there is a lot of stuff in VST3, it
seems quite heavy, which seems to be a change
from the relative simplicity of 2.*. Also 3 does not look
backwards compatible (so older plugins would not
work with it).
On the FOSS front then, with 3 we are stuck again
with Steinberg's terms. So my question is: are
developers in general sticking with 2.* or has everyone
moved to 3. Again, my question has an educational
slant, should we be teaching 3 or 2 (or both, if we
are teaching VST at all, that is) ?
Thanks
Victor
In this release:
* slv2 is no longer required
* cache list of suitable plugins
* speedup plugin list window
* new tool, zynspect, that can be used to list and inspect available
lv2 plguins.
* Fix assert when restoring rack presets
* By default, sort plugins by name
* Experimental support for dynmanifest extension. Combined with
NASPRO allows loading ladspa plugins in lv2rack.
* Set plugin GUI window's role to "plugin_ui" (for WM kludges etc)
* single plugin mode for lv2rack
* Hide external UIs when zynjacku/lv2rack quits
zynjacku is JACK based, GTK (2.x) host for LV2 synths. It has one JACK
MIDI input port (routed to all hosted synths) and one (two for stereo
synths) JACK audio output port per plugin. Such design provides
multi-timbral sound by running several synth plugins.
zynjacku is a nunchaku weapon for JACK audio synthesis. You have solid
parts for synthesis itself and you have flexible part that allows
synthesis to suit your needs.
lv2rack is a host for LV2 effect plugins.
Project homepage with screenshots:
http://home.gna.org/zynjacku/
Get tarball from here:
https://gna.org/files/?group=zynjacku
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
a2jmidid is a project that aims to ease usage of legacy ALSA sequencer
applications, in a JACK MIDI enabled system.
a2jmidid implementation is based on jack-alsamidi-0.5 that is [almost]
same as jackd ALSA "seq" MIDI backend, both created by Dmitry Baikov.
Static bridges are based on code by Sean Bolton and Lars Luthman.
Homepage with screenshots: http://home.gna.org/a2jmidid/
Tarball download: http://download.gna.org/a2jmidid/
Changes since version 4:
* Fix thight loop on D-Bus disconnect
* D-Bus signals for bridge start and stop
* Fixed alsamidi "disappearing output" bug. (backport from jack1)
* MIDI note-off normalization fix from Dave Robillard (Backport from jack1)
* Removed wrong assert from alsa_seqmidi.c reported by Ken Ellinwood (Backport from jack1)
* Mark anything that looks like a hardware port as physical&terminal (Backport from jack1/jack2)
* Fix potential crash when D-Bus is not used
* Support for multiple ALSA clients with same name
* Merge midibridge changeset by Paul Davis that is expected to fix
midi event timing problems that some people have reported.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Hi everyone,
does anyone know where I can get the VesTige headers
easily without having to svn a whole package down?
Is it available anywhere?
Thanks
Victor
Hello all,
The 4-band paramatric filter plugin has been updated:
FIL-plugins-0.3.0.tar.bz2, available as usual on
<http://www.kokkinizita.net/linuxaudio/downloads>.
Changes:
It's still the same filter, but may 'feel' different.
The mapping from param values to actual responses has
been modified, in particular the interaction of gain
and bandwidth at extreme gain settings.
People have asked for 'shelf' filters in addition to
the parametrics. You can use the parametric filters to
obtain shelf responses, for LF use the first section
with F = 20 Hz, for HF the fourth section with F = 20
kHz. In both cases use the bandwidth control to shift
the actual shelf frequency. Useful values for bandwidth
in this case are those >= 1.
Nedko Arnaudov is preparing an LV2 version that will
also show the actual frequency response.
Enjoy !
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Robert Keller wrote:
>
> On Jun 11, 2009, at 5:19 AM, Grammostola Rosea wrote:
>
>> lasconic wrote:
>>> I took some time yesterday night to take a look to improvisor code and
>>> estimate the cost of adding musicXML export. Import is indeed more
>>> complicated.
>>> I downloaded the code of improvisor 3.39. It's the last and only code
>>> available. Improvisor inner model is a little bit different than
>>> musicXML
>>> one. Common practice in musicXML is to don't "time" the chords and
>>> put them
>>> in the middle of notes. At least, this is my experience with finale
>>> musicXML
>>> export features. I managed to make a quick and dirty prototype to
>>> export a simple melody (no
>>> tuplet) and chord root and bass (no extension yet). Chords are in
>>> between
>>> notes but lily+musicML2ly shoud be able to deal with it.
>>> Unfortunately, 3.39
>>> is an old version, and according to Bob Keller the code base changed
>>> a lot
>>> but it's not public yet. With some more voices, perhaps we can
>>> convince Bob Keller and his team to
>>> open up the repository to the public. After all, improvisor is a
>>> fine piece
>>> of software which can benefit from open development, moreover if
>>> time and
>>> resources are an issue.
>>>
>>> Lasconic
>>>
>>>
>> Thanks man. I'll forward this to Bob Keller too.
>> I think he mentioned in a message that he is willing to give
>> developers svn access to the recent code.
>>
>> Bob, could you comment on this?
>>
>> Kind regards,
>>
>> \r
>>
>
> I'll be looking toward moving Impro-Visor to a public repository, as
> soon as I stabilize the current version, which I hope will be before
> the end of June.
Ah that's good news. Thanks.
> Is SourceForge the best bet?
>
>
I think SourceForge is good, but others might think different (I have
little experience with it myself, others?)
Let us know when it's up there.
Kind regards
\r
lasconic wrote:
> I took some time yesterday night to take a look to improvisor code and
> estimate the cost of adding musicXML export. Import is indeed more
> complicated.
> I downloaded the code of improvisor 3.39. It's the last and only code
> available. Improvisor inner model is a little bit different than musicXML
> one. Common practice in musicXML is to don't "time" the chords and put them
> in the middle of notes. At least, this is my experience with finale musicXML
> export features.
> I managed to make a quick and dirty prototype to export a simple melody (no
> tuplet) and chord root and bass (no extension yet). Chords are in between
> notes but lily+musicML2ly shoud be able to deal with it. Unfortunately, 3.39
> is an old version, and according to Bob Keller the code base changed a lot
> but it's not public yet.
> With some more voices, perhaps we can convince Bob Keller and his team to
> open up the repository to the public. After all, improvisor is a fine piece
> of software which can benefit from open development, moreover if time and
> resources are an issue.
>
> Lasconic
>
>
Thanks man. I'll forward this to Bob Keller too.
I think he mentioned in a message that he is willing to give developers
svn access to the recent code.
Bob, could you comment on this?
Kind regards,
\r
