[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 24 Jan 2004 11:13:30 +0000
On Fri, Jan 23, 2004 at 02:07:04 -0800, Chris Grigg wrote:
> I think a basic semantic error is being made here by glossing over
> that distinction. Basically all existing control surfaces that I
> know of and their existing comm protocols (like MIDI) encode slider
> positions, velocities, etc. as integers. I didn't invent that, it's
> just the way it is. Of course at some point the integers need to be
> scaled & offset (and maybe warped via some curve to an appropriate
> shape) to be converted into the low-level audio DSP parameters that
> the control integers drive, but under all current pro plug-in systems
> this conversion happens at the plug-in stage -- so hosts essentially
> route incoming MIDI streams from external devices directly to
> plug-ins, they don't route exclusively parameter value streams.
> Whereas you guys seem to be proposing that we turn all this on its
> head, so that what the host routes is only the DSP-level values and
> not control-surface-level values.
Just because we dont want to represetn these things as integers doesnt
mean that there is any loss of information, you can store the CC values as
a real and round it out to an int if/when it leaves the graph and becomes
serial MIDI again.
The alternative is that if you want your plugin to use MIDI values
naturally you need to make inputs that shouldn't be ints, ints, wheres
real is capable of encoding on/off and int states (with hnts if neccesary)
perfectly well.
> It seems to me that this has some real problems for practical studios
> and music production. For example:
>
> - Do you propose to toss all existing control surfaces into a lake?
The conversion is lossless, so no.
> - If not, where exactly in the architecture or graph do you propose
> the control-values-to-parameter-values conversions be done? By the
> GMPI host when it accepts the control input from the peripheral,
> before sending into the plug graph? By a driver for the peripheral
> before it goes to the GMPI host?
Yes, or by a plugin. It doesnt really matter, the importnat things is that
it gets converted to a unified GMPI control value representation, and not
7/14bit int coded in 8bit serial.
> - In actual practice, how is the int/real conversion configured for
> scale & offfset etc. by the user?
MIDI cant encode scale and offset, so it doesnt have to be.
> You can see where this path leads. This is a lot like the earlier
> proposal that note pitch be described only in Hz and never by scale
> index (note number), which would turn ordinarily dead-simple stuff
> like scalewise transpose or automatic scalewise harmonization, or
> ordinary note synthesis, into impractically complex
> analyze/resynthesize operations. I can see that the motivation for
> these ideas is pure, but the ideas themselves strike me as both 1)
> impractical and 2) barriers to GMPI acceptance, insofar as they would
> a) tremendously complicate the porting of all the very popular
> existing MIDI synth plug-ins to GMPI, and b) obsolete the end-user's
> investment in MIDI controller gear.
I dont understand the problem, the basic idea is that MIDI is coded up
into some sort of preparsed format for transmission around inside of the
GMPI graph and if/when it has to leave it can be turned back into 'real'
MIDI. There is no compatibility problem.
The portential problems with hadling 'raw' MIDI are:
1) people have to write midi parsers. thats anoying and easy to get wrong.
2) its not sufficiently expressive. I dont want to have to deal with two
different kinds of note on packets (for example), so I need one that is
both MIDI compatible, and adeqately expressive for academic music.
obviously if I use high resolution data values inside of the GMPI graph,
when it get exported to serial MIDI that extra res will be lost, but at
least I had the oportunity to use it in the first place.
I also want the control packet for to be OSC compatible (at least at a
basic level), and I'm definatly not handling 3 packet formats.
...
> Again, if control inputs are typed and named, why does GMPI need to
> dictate what model all GMPI plugs will use? Let some plugs use
> "Pitch-Hz" real inputs and other plugs use "Pitch-MIDINoteNumber" int
> inputs.
Some of us actually want working systems this decade. I think these kinds
of ideas are firmly in the "too much rope" category of software design.
Why not just pick one, simple to handle, fully expressive format and use
that?
> Unless I'm mistaken, that's for the group to decide later, when we
> get to setting requirements for how MIDI will/won't be handled... no?
> Though I have to say, some of the anti-MIDI sentiment here -- not
> naming names -- does strike me as kind of
> religious/ideological/ivory-tower/anti-user.
I dont know if youre referring to me or not, but I'm definatly not
anti-MIDI, it does a great job and I use it extensivly, but being based on
low-bitrate serial comms it has its limitations.
> Possible solution: Maybe we could add a rule that all real-valued
> control input pins could also optionally provide some sort of
> built-in aux input pin that accepts integer-stepped control inputs
> (like MIDI controllers etc.), which comes with a converter function
> for automatically scaling & smoothing & converting & feeding the real
> pin? So you plug a real source into a control input and it goes in
> directly, but if you plug (example only) a MIDI controller source
> into that same control input, the plug is able to easily handle its
> own CC-to-real-param conversion? Then we get both worlds side by
> side.
I think there are two seperate issues here
A) lumps of (parsed) MIDI floating around the graph (notes, maybe CC's
etc).
B) MIDI CC's bound to plugin control ports.
A needs good, lossless representation of the MIDI data, it doesnt need any
particular scaling hints or whatever, as MIDI doesnt have them. B is such a
common case that it can (and probably should) be handled by hosts binding
midi controllers to native GMPI control ports explicitly, possibly GMPI
may need some way for plugins to indicate to hosts that they want some of
thier controls bound to some CC's. I'm not sure about that, in LADSPA its
the hosts job to maintain bindings.
- Steve
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
