[ardour-dev] build from last evening's tarball fails

Mark Knecht markknecht at gmail.com
Mon Nov 8 17:22:32 PST 2004

On Mon, 08 Nov 2004 19:46:41 -0500, Paul Davis
<paul at linuxaudiosystems.com> wrote:
> >> and btw, Battery is doing exactly what the GMPI working group was
> >> discussing a few weeks ago as an evil thing - a host needs to get
> >> "metadata" on the plugin, but the plugin requires a license even to do
> >> that. this is not good design, and GMPI will specifically say that
> >> hosts must be able to avoid this.
> >
> >GMPI?
> General Music Plugin Interface. Its a cross-interface industry plugin
> API that has been in working-group reqs. discussion for about 2yrs
> (Steve Harris, Tim Hockin and myself represent the open source
> community there). The workin group has people from every company
> except Digidesign and MS on it.

Cool. Thanks. Although I'm sure that the group realizes that what ever
is out there in the marketplace will have it's own quirks. No one can
be expected to comply with a spec that isn't written as of yet.
> >Well, since the host is jack_fst it's back to us, I think...
> i thought the host was ardour. 

Nope. It runs ouside of Ardour in every session I can remember, unless
Ardour has decided to suddenly call up a very old session.

Humm....looks like a bad idea on Ardour's part:
ardour: [INFO]: detecting VST plugins along /home/mark/vst_dir

It does this line and then attempts to start a VST that it has no
reason to start.

Anyway, you wouldn't allow me to instantiate Battery since you don't
handle MIDI in on any VST, thus making pretty much all synth VSTs a
non-play inside of Ardour today. (And being that synths are, I think,
far and away the most universally used type of VST that leaves a
pretty big hole.)

> the best we could would be to enable a
> plugin backlist so that it would never try again.

Nah...come on, I'm sure we can do better than that. Waves manages to
recognize that I don't have a plugin available at a given time and
then just gray it out. The plugin stays positioned for further use but
is just skipped in the current session.

Permanant blacklisting sounds like a major overkill to me, based on
how other programs work. However, if Ardour has no way to handle a
MIDI-based VST existing in a directory structure that has all sorts of
VSTs then I suppose it could be blacklisted in terms of Ardour trying
to run it.

I suspect that the segfault is caused because you might be using a
version of jack_fst inside of Ardour that doesn't have my
wine-20041019 memory hack? If so then that would cause this since I
now use new versions of Wine that the opfficially released version of
jack_fst won't work with. If you point me toward the jack_fst code
within Ardour I could throw in my hack and see if that eliminates the

> >'that'? Meaning the keyboard comment? I'd be happy to fix it. Any info
> >around on how to do so?
> xmodmap(1) is the tool of choice. however, figuring out exactly how to
> rebind it (i.e. what keys to use for what) is often a per-user thing.
> Personally, i have numlock bound to the Num_Lock symbol, and it is not
> a modifier at all. Then my "windows" key is bound to be Mod2. The
> examples in the xmodmap man page are quite good, i think. But as I
> said, precisely how you want to set things up might vary drastically
> compared to myself.

This laptop won't be my normal Ardour machine so I think I'll skip
this for now. I have to run Ardour using a standard desktop machine
since Alsa cannot handle 1394 audio devices yet. Remote recording gigs
remain Pro Tools for now.


More information about the Ardour-Dev mailing list