Content-Type: text/plain; charset="UTF-8"
On Sat, 2012-08-04 at 10:10 +1200, Jeff McClintock wrote:
Sure. Sorry, I was basically ranting against the concept of not
supporting MIDI whatsoever, which comes up, not what you've actually
> > LV2 UIs are also like this, though there is an extension to provide a
Yes, even for this using a proper mechanism is better, though when the
possibility of cross-process or cross-machine comes up, you have to
start worrying about how much data is being tossed around here. My
serialization stuff does not currently deal with actual audio. This is
largely untreaded territory for LV2, though somebody is tinkering with
it right now. That said, in most hosts (that do not have a process
barrier there) doing this will simply work because they don't care what
those blobs of bytes are whatsoever. So in this respect it is the same
as your API.
To be honest I care *dramatically* more about more important things than
whiz-bang GUIs. Notably that big red section of the table that stems
from inheriting LADSPA's control ports mistake and not having parameter
events is way up there.
> > Your argument sounds very obviously right because it's about numeric
There is no voice control in the sense that I mean. When I think
post-MIDI note control, I am thinking things like being able to
independently draw note vectors in a sequencer and bend each note
independently around, and likewise for parameters other than frequency.
This also maps well to controllers like the Continuum or Soundplane.
> By supporting these two MIDI commands you get the familiarity of MIDI wit=
Fair enough, I suppose that is more or less true (if you count sysex,
anyway), but not *quite*.
> By binding MIDI to the plugin parameters as 32-bit 'float' via meta-data,
I agree entirely that using MIDI directly in plugins for parameters is a
> GMPI parameter events include an optional 'voice-number', this extends th=
I will look in to your events to make sure I don't miss anything...
though I am strongly drawn to making the events themselves dictionaries
so it doesn't matter if I miss anything... but that will be less popular
than a rigid static struct...
One could argue that you, and I, could and perhaps should just use OSC
for this, though. It is a bit hand-wavey to say you can support both,
or new protocols entirely, by virtue of having added yet another event
type. Really you're just making the host translate from X to Y, and
added a new Y to the pot to deal with. No judgment really, because I
have done the same, and will likely do more of the same, but that sales
pitch is questionable :)
OSC unfortunately sucks entirely for high level control (and is annoying
to build in real-time since you must know how many arguments a message
is going to have to be able to construct it at all, making realtime
append-only APIs impossible). My stuff is a lot more of a JSON style
thing, which works much better (by "high level control" I mean stuff
like loading waveforms, expressing complex state, arbirarily complex
messages, and so on). However the case for using it for at least note
stuff, and perhaps even parameters, is a pretty good one. At least it's
kinda sorta an existing standard.
Difficult decisions here, which is why LV2 doesn't have such events yet.
I really loathe to create something that isn't already serialisable by
the existing mechanism (the main important consequence of which means
UIs and plugins can talk however they want), but one can at least
hypothetically expect other programs to send OSC. Perhaps your "let the
host deal with mapping to what the plugin spec wants" solution is best
after all, but I have to play extremely carefully with saying "oh well
the host can do all this fancy stuff" because in reality that means host
authors get pissed off at me and LV2 and complain about it. Selling to
yourself is much easier :)
(Support libraries are the solution to this, naturally, but I have
learned that people have a powerful aversion to using *anything*, no
matter how completely unoffensive a dependency it is. To address this,
LV2 will probably reluctantly grow an "SDK" that includes essentially
all my libraries soon, but I remain completely convinced that this is
awful, and the spec should be more timeless and have no ABI issues
contained in it whatsoever, and hate this idea with a passion. Nobody
gives a shit about specifications, or implementation independence. The
better part of a decade later there's still precisely one left alive:
mine. Time to give up those ideals I suppose)
> > This is precisely the kind of reason why monolithic non-
Kinda sorta. Better than most, I'll give you that :)
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----