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
Robert Keller wrote:
>
> On Jun 10, 2009, at 2:09 PM, Grammostola Rosea wrote:
>
>> but Impro-visor doesn't have musicXML support right? Is it possible
>> to add that?
>
> Correct, it doesn't. It is possible to add musicXML output. Anything
> is possible. However, I have too much else to do at this point in time
> to give that a high priority.
>
> Input would be harder, because Impro-Visor has only a single melody
> line, but musicXML, I'm pretty sure, can specify polyphony, so there
> would be the issue of how to interpret that. Also, I'm not sure how
> musicXML deals with chord symbols, but that could be a second issue.
>
> Regards,
>
> Bob
>
> Robert Keller
> Csilla & Walt Foley Professor
> Computer Science
> Harvey Mudd College
>
>
Thanks again.
I understand, time is scares these days...
Maybe other Lilypond devs or people who can work on adding Musicxml
support could help you a bit. I will Cc this mail to the Lilypond users
mailinglist (you have to check that app!) and the Linux dev list.
We will see. If you have questions, requests or announcements, just let
us know. We (Lilypond and Linux users) like to stay in tune with
Impro-Visor.
Kind regards,
\r
Ps. If people have problems to get sound working on GNU/Linux you can
point them to:
http://linuxmusicians.com/viewtopic.php?f=4&t=860
This is an very interesting application, and it is released as GPL software.
The only drawback on GNU/Linux is that sound is not working very well,
at least in my experience:
http://linuxmusicians.com/viewtopic.php?f=4&t=860
I dunno if there is a way to get better sound out of java applications.
Maybe some devs can help this application with ALSA and/or Jack support?
Kind regards,
\r
I removed some bugs that came up till now and released version 0.3 of
JackMixDesk formerly known as jackminimix.
Get it from http://sourceforge.net/projects/jackmixdesk/
Jackmixdesk is a client/server mixer application with a user defined
number of channels, pre and post fader sends. It has LASH support an OSC
control interface and a XML config file. There is also a gui made with
GTK+. It uses less resources than it's ancestor jackminimix.
I'll soon start further development.
Regards and please report me something
Uli
PS Could someone from the proaudio list please make an ebuild? Thanks!
