[gmpi] Re: 3.15 MIDI (What does it mean to be a plugin)
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 21 Jun 2004 20:56:59 -0700
On Mon, Jun 21, 2004 at 07:59:44PM -0700, Chris Grigg wrote:
> >malloc and free are part of the standard C API. They are not part of the
> >language, and I don't see much degree difference between wanting to bypass
> >the memory allocator and wanting to bypass the event system.
>
> Faulty parallelism, I think, you can use alternative memory managers
> and still write in C.
OK, well there's a parallel somewhere, and you know it! :)
> > > >Sequencing (my host doesn't sequence MIDI, just GMPI)
> >>
> >> Then I have good news, your host is relieved of the need to handle
> >> MIDI. Now, if you would kindly consider getting out of the way of
> >> the long line of other folks stretching down the block...
> >
> >So all hosts have to support sequencing MIDI to run these plugins.
>
> ?? - Non sequitir. "Your host doesn't need MIDI" is not the same as
> "all hosts that use MIDI must also sequence MIDI".
My host does not sequence MIDI. These hypothetical plugins would only
work with MIDI. So therefore either these plugins are not usable under my
host (which goes against the fundamental goals of GMPI) or my host has to
sequence MIDI.
I suggest we all re-read section 1. of the reqs :)
> >And I don't find a vague notion of "studio routing" nor lazy hardware
> >companies wanting a free GMPI port to be reasons to include a facet into
> >the API that makes things less manageable.
>
> Honest difference, but: - Who proposes a facet? - Some of that
> manageability is an illusion. - Some hosts don't care as much as you
> do. Etc .etc.
The potential to be managed is not an illusion. It's the removal of that
potential to which I am objecting.
> >I believe that with good docs and a good API, they won't want to
> >circumvent GMPI. If I am wrong, then GMPI can grow, but we can't ever
> >remove something.
>
> Honest difference but some things are not easily shoehorned into an
> architecture at a later date. This smells like one of those, don't
> you think?
I think we can design with an eye toward leaving a place for it, if it is
needed. I operate on the primary tenet that we CAN do anything.
> >Subversive in the sense that I fear some people on this list would lead
> >the charge.
>
> Since I know you know I like you, I feel safe in smiling and saying
> "Tin foil hat time!" You really don't think people will do this
> spontaneously?
My tinfoil hat has been firmly affixed for some time now. No, I really do
not think that people would do this spontaneously. It would have to start
with a host.
> >There are two levels of semantic. The higher semantic is that a midi
> >message is a ratio. The MIDI value 64 is really 64/127 or ~ 0.5039. We
> >can retain that semantic. The other semantic is that 0.5039 means -6.3 dB
> >(made up). That semantic we don't pretend to touch, nor does MIDI (except
> >as suggested curves in some cases).
> >
> >So we retain the exact higher-level semantics, while preserving opacity
> >for lower-level semantics. Is that worded better?
>
> Y, thx.
OK, so for future reference, we have agreed that we can keep this
semantic. When anyone speaks of lossless MIDI->GMPI semantic transcoding,
THIS is what we mean. :)
> >> Uh... really? This is opposite to everything you guys have been
> >> saying. Why more possible in the future than now?
> >
> >Because we've not had real reasons now. Again, show me something that you
> >can't reasonably do in GMPI? With details about why it can't be done,
> >please.
> You misunderstand, I'm asking to justify your statement that MIDI can
> be added in the future.
It's not more possible in the future, it's more appropriate.
----------------------------------------------------------------------
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:
