Thanks for commenting, Steve.
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.
> It seems to me that this has some real problems for practical studiosand 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 theGMPI 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 earlierproposal 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 todictate 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 weget 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-valuedcontrol 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.
---------------------------------------------------------------------- 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
