Re: [LAD] LV2 Achievement of GMPI Requirements

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jeff McClintock <jef@...>
Cc: <linux-audio-dev@...>
Date: Thursday, August 2, 2012 - 3:38 pm

--=-+TyV5DdBNLu72mSbZE6a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-08-02 at 10:59 +1200, Jeff McClintock wrote:

We
ed

Interesting. I didn't think anyone had done any actual work here in
ages, if ever. I stand corrected.

I don't suppose the code for those modular synthesis plugins is
available? :)

> .SEM Comparison with GMPI...

tio
ent

Well, the requirements I made this comment for say the plugin must
provide a method. Taken literally, this is not met, and I do not think
it *should* be met, hence I disagree (they clearly derive from mistakes
in VST). I guess I can interpret "method" more abstractly and consider
them met.

> The SEM DSP Plugin API has a total of four functions { open(), setBuffer=
(),

d

Did you consciously decide to use a setBuffer method for some reason? I
consider that (connect_port in LADSPA/LV2) a mistake and efficiency
problem. Passing an array to process is better.

> >61 ...It is unclear what "patches" means here.

I see. "With patches" should have been omitted. Thanks.

> >73 "GMPI must define a simple in-process custom UI mechanism. " Disagree=
-

g a
ore
rom
hat
e'
.

Redundant with 71. I'll consider it met, then, thanks.

A requirement specifically about a strong and sensible plugin/UI
separation would have been a good one. By far the worst thing about
porting VSTs with GUIs. A free for all for UIs to screw with DSP code
is insane.

> >101 "GMPI should allow for copy-protected plugins" Disagree - LV2 is not

uld
le

Fair enough, I guess I will just list this as met. I felt compelled to
at least hint that LV2 is not the sort of project that would ever
consider including evil software crippling garbage as a requirement ;)

> All in all very good to see GMPI requirements used as a benchmark. A lot=
of

nd

Yes, I thought it would be a useful comparison. If there is any more
useful information in an easily digestible requirements-based format,
let me know.

> My suggestion that it didn't need MIDI at all (MIDI being too

ts

Anything but events with an arbitrary type tag and a POD body of
*whatever* is a mistake, period.

"Including" MIDI is not a burden, it is a trivial consequence of having
a sane event mechanism. You just need a type tag, and fill your payload
with some MIDI bytes. Not allowing for MIDI is completely unrealistic,
and would mean plugins can't work with by far the most common format of
musical control data, and porting existing code to work as a plugin
become dramatically more difficult. Clearly a loss. All you get trying
to do things that way is endless mailing list fights about whether to
mandate MIDI, or OSC, or the new Ultimate Control Structure, or whatever
- a waste of everyone's time.

I am ranting a bit here about specification philosophy, but: plugins can
use whatever events they want. The organic reality of software
development is... well, reality, and good. The silly idea that The Holy
Specification having written something down means every host magically
supports it is not reality, it is a fantasy.

("Profiles" sound to me symptomatic of this same wrong thinking.
Fine-grained features that precisely describe specific functionality is
the proper way to deal with varying platform and host support, trying to
classify the entire world up front is delusional)

MIDI sucks. But MIDI is what plugins are using, and MIDI is what hosts
are using, MIDI is what tons of existing code uses, MIDI is everywhere.
It is not LV2's place, and it is not my place, to make some fascist
mandate that you may not use MIDI, which would do nothing but cripple
LV2 and reduce support and power. That said, something better is indeed
needed, but=20

(Sidenote: Similarly, Jack royally screwed up by mandating MIDI only,
despite being presented with a patch by myself to trivially make the
event system generic, and that is why you can't sequence precise
per-note pitch bends and parameters in Ardour and control a Jack Synth
via OSC or whatever else today, a common source complaint on IRC these
days. That is what you get when you don't let developers freely
develop)

That said, sure, MIDI sucks. Something better is needed, but certainly
not some One Ultimate Control Structure to the exclusion of everything
else. Extensibility is the way. Anyway, the actual details are the
same. With LV2 I have been thinking a lot about this, but there are 3
main options for controllers:

1) Use atom "objects". These are essentially POD dictionaries, and thus
extensible. By far the most flexible, automatically serialisable, but
with a bit of conceptual and syntactic overhead to actually using them

2) Use OSC. Frankly atoms are better, but OSC is 'standard'.

3) Use a special struct. This is the knee-jerk C programmer thing to
do, and simple and fast, but it worries me because if something is
omitted from that struct - oops, now everyone has to switch to an
entirely new one. I guess an extensible struct with a size field would
be a good compromise, we should have made *all* the structs like that
anyway.

I have been generally going by the philosophy that custom structs are
bad, since there is an existing serialisation mechanism in place that
works with standard atom types that is used e.g. for cross-process
communication between UI and plugin as well as state saving and so on.
It saves to/from the same format as LV2 data files, meaning describing
things there for whatever reason is also natural. This might be an
exception for performance reasons, however. It might be best for me to
just forcefully drag people into using atoms for everything, though,
since that is also what you need to use to get higher level control like
"load this sample", and it means progress is not held up by explicit
host support for every little thing... perhaps I need to spend some more
effort making working with dictionaries really clear and obvious, it is
the best solution on paper, it's just confusing to people who don't get
the big picture. I very much like the idea of completely open ended
communication between plugins and UI, as well as between plugins (and/or
plugins and hosts), where everything is fast, numeric, and POD, yet
serialisable to the standard LV2 data syntax. It seems worth it.
Liberating, but you have to 'get it' first.

Anyway, I've gone on a digression. Thanks for the input, document
updated as suggested.

-dr

--=-+TyV5DdBNLu72mSbZE6a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAABCAAGBQJQGp73AAoJEDZyeCqb82jzuvIQAKJ+RTvidi2BQGrb13QK3v2b
Erk1cN8JpJiynAmDQWG6Yantet1jIa5VTtn9tZdBXc1ZlnRYA3fRSYnfJw5XLdbE
bozeTPnXWpQYGm7DaVSZe5f/BgcceXL9dN295r6yFvF0F6wg0Wme9rPT2cvhEEF0
7VMHp4RqFLYMctujvKUVCkjZWQQnpveGewCaZR6YWaHaB874Vt8P9BOY09Lo9VMa
suWJX/+KwsWsQRssoHXOo6RPi5zZwtgEneTrzuOISr9egevbXEqdr/Iyy1tzYJnF
CYF1ET8XjIWx3MpXsXJp5a1zFB0fAdYAbc7syFg836P/mmtvqaGKtFoZ2VLgfRrH
sbJBOcM2PZt/eeu7nwGLsQMp30t81oTjS9qOwYKDj0DHXgr+vQ22bIPy3BPLeCZi
nZJixCWy6u9Zb+4cheCoTjsAGIAtxhnLFaVjp2Z7BUUSU+oI+51vWHeVJAOeWHJ9
o4NBFxK2xclpPRxI+Hbn6EGdqjPpcfx/7i6+C1t6B/5D7jY/FtcHMjFlsqwiIfsB
mE58MbViUalancqq6NaaV4XA/NM/ZPLfE6VUAis9UEXGvcgGlx2Erf5kp4Cn9VK1
83J98WQW/LB4gR8XoXvb6oDwzPreFEKpPf5Q5UOrNtvR54s652C3zS+fHDvUoTKx
zMMIhgA9/p6ouK3U+mAO
=SAZQ
-----END PGP SIGNATURE-----

--=-+TyV5DdBNLu72mSbZE6a--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] LV2 Achievement of GMPI Requirements, Jeff McClintock, (Wed Aug 1, 10:59 pm)
Re: [LAD] LV2 Achievement of GMPI Requirements, David Robillard, (Thu Aug 2, 3:38 pm)