[gmpi] Re: 3.15 MIDI
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 16 Jun 2004 01:18:25 -0700
Tim said:
On Tue, Jun 15, 2004 at 07:52:27PM -0700, Chris Grigg wrote:
existing plug, have already been incurred so there is no opportunity
for savings at this point.
Saving complexity is at least as valuable as saving time to write code.
Since you are not answering the point I made, I will assume you agree
with it. Your further point is fine as far as it goes, but saving
complexity by omitting necessary functionality isn't efficiency, it's
cheating on the requirements. ;-)
> Well, if you're going to support sysex delivery to the plug, which is
not undoable and can change plug state including parameters, then
Yeah, SysEx is pretty fugly. I'd really like to see us expose SysEx as a
blob. It *is* undoable, because you can save the old blob before writing
it.
Then I don't understand why you say other kinds of MIDI messages sent
to the plug would -not- be undoable, which seemed to be one of your
main arguments against it. Can you please explain what in this
regard is special about SysEx msgs vs. other MIDI messages? Or have
you changed your mind about that? There have been a lot of messages
today, it's hard to tell.
At the risk of over-repeating: I would be perfectly willing to accept
compelling arguments that MIDI messages should not be allowed in the
GMPI graph, but so far the arguments have not been compelling, and
frankly have tended to be correlated with complaints about unrelated
perceived problems with MIDI per se, some of them based on
misunderstandings, and some of them irrelevant to the GMPI situation.
As I have worked hard today to demonstrate. I am .not. proposing to
replace the other GMPI host-plug communication messages with MIDI, so
there is no loss of the functionality that the anti-MIDI people like
on the table, I am just unconvinced by the unsupported statements
that transcoding will automatically be perfect, and that the two
kinds of messages cannot exist side by side. It will take more
detailed discussion to demonstrate or refute those claims.
Although, to sort of cut to the chase, ultimately I fail to see how
truly outlawing MIDI message bytes in the graph is even remotely
possible, since the blob parameter datatype exists. If we fail to
specify MIDI message transport, don't you think the .first. thing
host and plug developers will do is to find some bastardized way to
send MIDI message bytes to plugs via blobs? I sure do, especially
since it's trivially easy: All they have to do is expose an input
blob parameter named myPlug/MidiIn. So really, who are we trying to
kid about outlawing MIDI in the graph, anyway?
> I think that depends completely on how it's presented in UI and
documentation (I can move a Finder selection with a keyboard -or- a
mouse, I can set an onscreen fader by dragging -or- using my control
surface fader, etc. etc. etc.), and in any event not more confusing
As long as a MIDI fader is exactly equal to a mouse move. You'd sure find
it bizarre if this happened:
* delete a file in Finder with the "Delete" key on the keyboard
* undo it
* delete a file by dragging it to the trash
* can't undo it!
That's hypothetical. You'd sure find that awkward, wouldn't you? Mouse
an keyboard are two different input (event) sources operating on the the
OS (host) managed file (parameter).
Sure, I'd find it awkward, but if that's how the computer worked, and
I couldn't change it, and it was the only way I could use both my
mouse and the keyboard to get my work done, then I'd curse the thing
but learn to get on with my work with it that way. But the analogy
is, as you acknowledge, strained, and I'm confident a much less
conflicted model than that can be found for GMPI. And I'm much less
concerned with total absolute host efficiency than I am with giving
the largest number of users and developers the functionality they
want -- especially if GMPI is also able to enable the small number of
the most discerning and visionary ones to go farther so they can
create the small-number fringe things that they want to.
Tim said:
> than having their familiar MIDI gear start breaking and behaving
unpredictably.
Come on now, you're attacking something that we've already agreed will not
happen. That's no more fair than me saying that we can't use MIDI between
plugins because the DIN cable is too slow. Non sequitur.
Sorry, no, I have not agreed to accept what amounts to mere
handwaving that transcoding will automatically be perfect. The
burden of proof is on those who want to go that way, the questions
have not been answered.
I should mention that I am getting quite a bit of off-list
communication -- phone calls, even -- that is very much in agreement
with Vincent's assessment of the situation. These people do not want
to get drawn into this discussion mainly because they do not want to
be disrespected and shouted down for their opinions. Which I fully
appreciate.
-- Chris G.
----------------------------------------------------------------------
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:
