[gmpi] Re: URIs vs GUIDs - rewind

  • From: "Angus F. Hewlett" <angus@xxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 10 Feb 2005 10:48:37 +0000

This debate seems to be getting quite heated... let's just look back to the problem-space.

Even if GMPI is an outstanding success, it's unlikely that there's going to be more than 50,000 plug-ins.

Currently there are something like 3000-4000 VSTs... the KvR database lists ~800 instruments and ~600 effects, but is not exhaustive.

We can assume that there are maybe 2-3x more VSTs which have been developed but never got past alpha/beta stages.

VST has been in existence for, what, 6-7 years, and is showing its age. MIDI has been with us for just over 20, and is declining (as a hardware protocol, thanks to wide adoption of computers and USB... it's still king at the software level) but will be with us for a few years yet.

Based on that, IMHO a safe design lifespan for GMPI is 40 years. Even assuming 1,000 plug-ins released per year, that's still "only" 40k total.

Remember, GMPI is supposed to solve a moderately narrow problem-space well. We're only addressing plug-ins that are bigger than unit-generators, and smaller than FL Studio.

Plug-ins need to be uniquely identifiable, yes, but that alone does not immediately solve version-compatibility and patch-compatibility issues. HOWEVER we identify plug-ins, a plug-in also needs to be able to identify itself as able to load settings from plug-ins with other unique identifiers. For example, whatever scheme we use, there must be a mechanism whereby NewSoft FooPlug Pro v3 can identify itself as able to load patches for OldSoft FooPlug 2.0SE.

Given the above, using fields like Manufacturer, Product, Version would be perfectly adequate. The GMPI target area is narrow enough that manufacturer namespace collision is absolutely not an issue.

If manufacturer names change, not a problem... the plug-in simply needs to be able to identify that it can load patches from the older item. Nobody in this business is secretive enough that users musn't find out that things get passed from owner to owner.

Finally, I can think of advantages to having the ID mechanism human-readable and somewhat parseable. Humans need to be able to distinguish between similar plug-ins as well, as does the file system.

I'm not against using UUIDs or other numeric identifiers for code-interface identification and enumeration, as that's something that can be centrally defined and is never exposed to the user - not to mention, comparing fixed-size binary IDs is faster than comparing long strings, and so allows for heavier use of interface-query techniques. However, for class instantiation... seeing as GMPI will have to supply its own instatiation mechanism anyway (we can't use the DllRegisterServer/CoCreateInstance mechanism anyway as it uses the Windows registry) - GUID is simply not necessary and just makes extra work for everyone.

Not to mention - it's NOT just C++ geeks who are going to be making GMPI plug-ins. We can expect Reaktor/Synthedit/MaxMSP style kits to be popular. Do we really want to bamboozle users of those with the whole GUID generation thing ("um, so when exactly do I need to give the plug a new GUIthingummy?"), when having them enter their "manufacturer" name -once- (in their devkit's master preferences page) will be enough to ensure that their plug-ins won't collide with anybody else's.

Regards,
      Angus.









Steve Harris wrote:

Please,

I don't want to read any more of these rants from people who haven't read
about what a URI is or does.

If you dont think you can maintain a URI space, and it doesn't matter,
then use a non deferencable one, UUID URN, whatever.

If you dont think you can maintain a URI space, and it does matter, use
a purl.org namespace, (guaranteed in perpetuity, by the library of
congress amongst others), OID, DDDS URN, etc.

The http: in the namespace doesn not /neccesarily/ indicate the method of
retreival.

On Wed, Feb 09, 2005 at 05:15:12 -0800, Frederick Umminger wrote:


In terms of database theory, the URI solution commits two unfogiveable sins by conflating the identity of data not only with a location (www.supercoolplugins.com/pitchwobbler) but also with a method of access (http:).



I'm sorry, but thats just not true. I am reasonably conversant in database theory, URI representation issues, and particularly the combination of the two.

As evidence I'd like to offer that Oracle 11 uses URIs for identifcation
liberally, one might almost say excessivly.

- 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







--
=========================================================
Angus F. Hewlett, Managing Director (CEO)
FXpansion Audio UK Ltd - http://www.fxpansion.com
Registered in the UK - #4455834 - VAT: GB 798 7782 33
=========================================================



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