[gmpi] Re: Reqs draft

  • From: eric <dilvie@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 10 Nov 2003 18:27:20 -0700


community has had ample time to comment on this topic? Do you really think we have time to put off the standards while I go passing around a petition?



We won't put it off, but we can amend it. Get me a dozen or two REAL users who think this is a must-have feature.

I don't understand why you think people should consider it a must-have feature. It's easy to implement.. if enough people think the feature is even desirable, GMPI should not ignore it (because doing so would make the feature difficult to implement, at best).

I've got two signatures in the last five minutes.. I asked two musicians that happened to be online on my im list. Neither of them are pro musicians with major studios, but both seem to think the feature might be handy:

dilvish: do you have a lot of vst plugins?
Jesper / Setec: i have a few. i actually rarely use more than a handfull though.
Jesper / Setec: few=quite a lot actually.
dilvish: do you use more than one vst host?
Jesper / Setec: nope
dilvish: okay, I'm going to ask you question #3 anyway:
dilvish: have you ever wished there was a single interface that would let you configure which hosts loaded which plugins?
Jesper / Setec: i suppose if i used multiple vst hosts, that would be highly desirable.


dilvish: do you have a lot of vst plugins?
jmr2: heh
jmr2: a few ;)
dilvish: do you use more than one vst host?
jmr2: no
dilvish: okay, I'm going to ask you question #3 anyway:
dilvish: have you ever wished there was a single interface that would let you configure which hosts loaded which plugins?
jmr2: what?
dilvish: well, for instance, say you have cubase vst, and you also have psycle...
jmr2: ok
dilvish: would you want a single interface that would let you say: psycle should not try to load this plugin, cause it crashes, but cubase should, 'cause it works great in cubase..
dilvish: ?
jmr2: quite a nice idea


They're the only ones I've asked so far, but I'll continue collecting if you insist. I can probably come up with 15 similar responses in a matter of days.

Fact: many studios own hundreds or (in some cases) thousands of plugins.
fact: many studios own at least two or three different hosts that they use regularly
fact: there are sometimes compatibility issues between hosts and plugins



GMPI won't have incompatibilities. That is goal #1.


Oh, forgive me for assuming that bugs might exist in implementations. Perhaps I should ignore my decade of programming experience that disagrees with you.

that crashes when loading a plugin. We've already more or less agreed that
there is some metadata such that a host won't have to load plugins at
startup. So that is a non-issue. Once the host is up, DON'T LOAD THE
PLUGIN THAT CRASHES.


You make it sound like it's easy NOT TO LOAD THE PLUGIN THAT CRASHES.


It *IS* easy. The only time the host loads a plugin is when you ask it to. Don't ask it to. Full stop. Probing does not involve loading the plugin. USING the plugin will cause the host to crash. Don't use that plugin.

Forgive me again. I had no idea that you could predict the future of host implementation details. What if a user doesn't want the crash-prone plugin to even appear in a list inside the host for unsuspecting studio workers to try to load while a client is sitting in the chair next to them being charged by the hour. Ever work in a professional studio? Ever had to deal with customers when something like this happens?

prevent loading specific plugins, in order to use hostx, you have to remove pluginx from the plugin path, and then replace it to use it in


No, you just don't use that plugin. What is not clear? Really, I'm curious how you magically load all these plugins in every host.

What is not clear is how you think this side-stepping constitutes an addressing of the issues at hand. You're talking about a social solution to a technical problem.

2,000 plugins. Many host developers never even imagined that many plugins being installed, and quite a few would give up and crash if he attempted to simply let them all load every session. He uses a


Bugs. See above. Don't autoload all the plugins. That's inane. GMPI was not started to provide workarounds for broken hosts. It was designed to provide a simple and consistent way fo getting it right.

Doesn't prior experience with a plugin standard that has already been implemented widely count for anything? Should we just ignore the problem and see if it magically disapears in GMPI, even if it hasn't been addressed head-on?

Can you name me one other thing that this requirement does, besides force
all hosts to find this global config file and load it?


Can you name one good reason NOT to consider it a requirement, other than some implementation you have in your head seems like a bad idea to you right now?



Yes. It is counter intuitive for any host specific configuration to be outside the host's control. You don't have an app to configure your web-browsers outside the browser.

In real studios with multiple hosts and hordes of plugins, it is the system that matters. The way the hosts and plugins work together. In this context, it is perfectly intuitive to create a system-wide mechanism for configuration. Preferable to other alternatives, from where I'm sitting. This doesn't preclude the idea of adjusting that configuration from within a host. It compliments it.

Who says the config file has to be global? It could be a host-specific file.. my only global-sounding suggestion was to keep the files in a well-known location.



Great. Write it for your host. Publish it. Heck, we can even consider putting the GMPI-Recommended seal of approval on your spec. It's not a requirement for the GMPI core, though. You have to admit this.

Happily, but it's far more likely to be adopted if it has the letters GMPI attached to it. If it doesn't, it's practically worthless unless by some miracle it gains some momentum and a few big developers decide that supporting it is a good thing to do. It could mean the difference between an industry-wide solution that works for all the major hosts, vs some little open-source developer's good idea that works in about 3 fringe hosts. If the latter comes to be, it's not the solution it should have been, is it?

- Eric

--
~
<http://www.dilvie.com/>



----------------------------------------------------------------------
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: