Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Nov 22 2000 - 17:28:43 EET


>> FYI: tonight, I stole the (simple) code from Quasimodo that provides both
>> "themed" graphics for LADSPA control port GUI's and full MIDI control
>> over control values. As in Quasimodo, Ctrl-Button2 puts any plugin
>> control element into "learn" mode, and the next MIDI (relevant)
>> message received will bind to that control element.
>
>This is great, is there any facility to customise the display per plugin?

Not at this time ...

>I'm currenty working on one complicated enough that the usual "dialog of
>all the parameters in the order thier declared" isn't going to be very
>usable.

Well, this is why we need the XML-or-other spec for the plugin GUI's.

>If I understand correctly, doesn't Quasimodo make its elements from an
>XML description? Or did you not reuse that bit?

Yes, it creates and lays them out from an XML description. But The
part I reused was the code that generates one specific kind of visual
control element, a MotionController, which would be better named
MIDI-and-Motion-Controller (it responds to mouse motion and MIDI
events in an integrated way).

If we get some closure on the XML-for-plugin-GUI-descriptions, I will
probably take a stab at using the Quasimodo code for this and creating
a Gtk-- -based library/object that takes the XML and returns a window
with the plugin editor (as steinberg would call it) all set up (but
not displayed on the screen yet).

>PS Is there any way to get Ardour running without ALSA?

Nope. Absolutely no way. Nothing the OSS API is capable of dealing
with what Ardour wants from the audio interface abstraction. 4Front
have asked me about this, and I've had to explain (I try to be nice)
that their API simply isn't adequate. Basic problems include:

     * no way at all to handle non-interleaved streams without using
         their mmap interface, *and*
     * no device-independent way to determine the memory layout
         of the DMA buffer for the mmap interface (*)
     * no device-independent way to control sample clock source and
         h/w monitoring (**)
     * no way to ensure that "channel N" corresponds to any particular
         physical connector on the interface itself.

not to mention the lack of support for the Hammerfall, and, as I
understand it, no really functional support for any multichannel cards
but the Sonorus Studi/o card (and I hear stories that even there, the
functionality is not that great).

--p

(*) and anyone who thinks I'm going to hard-code the memory layout
    for the Hammerfall, the ice1712 set, various consumer cards,
    etc. had better think again :)

(**) to be fair, neither did ALSA till very recently.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Nov 22 2000 - 18:15:59 EET