What's new

A sample library wiki?

That'll probably be better as a tag than a general category. So, for example, you have a string lib that falls under Strings / Sections and it has tags like "bartok", "pizz", "chamber", "medieval" etc. Then maybe you can have a tag cloud or a search just for tags. Then you can add what you think is important at your leisure without filling too many fields when submitting. Articulation lists can also be pasted in a text description field. So, you have both tags + text to search without having to list every single articulation from the get go.

Agreed. It could well be that an unstructured tag system of entering metadata is the better way to go, at least for some of the more esoteric information, rather than a strict hierarchical classification system with enforced data entry rules. There are distinct advantages and disadvantages to each. We probably don't need to decide that yet. We should probably just begin by organizing the wish-list, and then figure out what is doable from there.

Unless someone has already started on this or really wants to do it, I volunteer to try to assemble the points expressed so far into a sharable on-line document.
 
Agreed. It could well be that an unstructured tag system of entering metadata is the better way to go, at least for some of the more esoteric information, rather than a strict hierarchical classification system with enforced data entry rules. There are distinct advantages and disadvantages to each. We probably don't need to decide that yet. We should probably just begin by organizing the wish-list, and then figure out what is doable from there.

Unless someone has already started on this or really wants to do it, I volunteer to try to assemble the points expressed so far into a sharable on-line document.

If you want to prepare this, please feel free :)

I updated the V2 and fixed a couple nasty bugs that happend due to bad routing.
Since it has a text search integrated (Search -> Field you search in -> "Contains") a free tagging system can work well for Articulations and such. But yeah - we need an overview to get consenus - or rather - a good compromise. Because I can imagine that everybody has slightly different preferences on what information it all should hold.
 
If you want to prepare this, please feel free :)

I updated the V2 and fixed a couple nasty bugs that happend due to bad routing.
Since it has a text search integrated (Search -> Field you search in -> "Contains") a free tagging system can work well for Articulations and such. But yeah - we need an overview to get consenus - or rather - a good compromise. Because I can imagine that everybody has slightly different preferences on what information it all should hold.
Give me a day or two and I’ll post a link to the document.
 
While I agree that wiki should focus on factual information, there is also a value in subjective measurements.

I propose two things. A secondary section (in addition to primary section with facts) that contains user ratings of parameters that are hard to quantify objectively. Like how dry/wet are the samples, volume consistency of samples, noise, sound quality, playability, support (is developer providing fixes or are there no updates) etc. (The real list of parameters would need to be carefully chosen). It's true that these kind of ratings are not perfect, but they are generally better than having no information at all.

And a comments section for each library. A place where users could voice their individual opinions.

I understand the need to protect developers from unjustified attacks and flame wars about products, but there is also a need to provide as much information to buyers as possible, because there is usually no way to test the product before buying. Some developers even disallow reselling. Otherwise, it will be focused on quantity of features over quality of features.
 
Last edited:
While I agree that wiki should focus on factual information, there is also a value in subjective measurements.

I propose two things. A secondary section (in addition to primary section with facts) that contains user ratings of parameters that are hard to quantify objectively. Like how dry/wet are the samples, volume consistency of samples, noise, sound quality, playability, support (is developer providing fixes or are there no updates) etc. (The real list of parameters would need to be carefully chosen). It's true that these kind of ratings are not perfect, but they are generally better than having no information at all.

And a comments section for each library. A place where users could voice their opinions.

I understand the need to protect developers from unjustified attacks and flame wars about products, but there is also a need to provide as much information to buyers as possible, because there is usually no way to test the product before buying. Some developers even disallow reselling. Otherwise, it will be focused on quantity of features over quality of features.

I think the best way would be like how wikipedia does it. With a "reception" section, quoting the reception of the library. That way it still stays factual.
 
Maybe the reception stuff is a discussion for later. The issue with the subjective stuff is that since anyone can edit, it's possible to be tempted to remove negative feedback or get emotional or prop something up etc. Comments would need moderation in case they get spammed, not necessarily because of flame wars or different opinions.

Still I guess it's better to just have pointers on the database (like links to forum threads) rather than have debates on it. Way I see it, it should be like a detailed shopping list, not an editorial. Having demos falls entirely on the skill of the user (not that easy to tell what the libraries' actual limits are unless you have a measurement that the user did their absolute best or whatever, which is quite impossible, since not even everyone is on the same skill level or approach to begin with; which also stands for official demos btw), so that would be a point of contention too.

Something similar was said about reviews, that it's not the job of the wiki to drive traffic to reviewers. Though it does send traffic to developers, so it seems fair. I think the possibility that reviewers might profit from it is a fine exchange for having a database with as much information as possible (their stuff is searchable anyway, so in essence all you do is save people time). Official walkthroughs seem fine. Although it's technically a dev-approved presentation, it does give an overview of the product (which I guess is another point for reviews, in terms of information and perspective completeness, whether they're sponsored or not). Then again, maybe the best approach is to https://lmgtfy.com/?q=spitfire+chamber+strings+review (have an lmgtfy link) for these. A simple list of links to reviews also seems fine, with the hope it doesn't get vandalised.

Updates will probably be covered by changelogs or "last updated". The end user will have to do their due diligence in the end.
 
Personally
as I said earlier - I think it should be more a detailed description (Like other said - e.g. "What string libraries offer Bartok"). It drives traffic to the developers - which is fair, since they...well..developed it ;)

I personally also would fund the server costs through a Patreon, and not some ad banners. It should be made by and for the community, and not for devs. If there are obvious errors, devs should be encouraged to correct of course.

My current thinking goes into the direction of a less "open" approach. Meaning people who want to add and edit stuff need a login. Without login you can only view. As addition to that, maybe There could simply be a "propose library" thing that's open, which gets it into a kind-of moderation pipeline. Prevents vandalism that way. The community still can crowdsource the information, but it's an additional human step (ideally not much more than a kind-of accept button).

I like the ideas of demos, opinions etc. But - having seen it in this forum multiple times - opinions can get out of hand very fast. Some people are very quick to talk bad about a library. What I can imagine though would maybe be some taglist of proposed use cases like e.g. "Good for exposed passages" or "Good for heroic melodies". But I'd rather strip that away in favor of an ideally objective description.

It should be an unopinionated place, where devs don't need to be afraid to have their product ripped to shreds - and are not able to needlessly glorify it. Is this particular library expensive? Is it worth the money? You can google for those opinions. Only thing there is the current price and the other facts.

As said, it should strike a good balance between maintainability and information. I get the point that the unavailable demos (who else remembers the time of the Floppies or CDs with Shareware fondly?) are not the best - but until that changes we have to roll with it.
So yeah...I'd rather have it dirt-dry and be impartial instead of linking biased reviews or boosting the marketing. One official video (Like Spitfire's walkthroughs, I like them to get an idea of the sound) is enough - and almost every library has that. If not, then we can discuss a different thing to take in instead.
 
For the PianoWorld VI database, we thought about linking relevant forum threads/posts, reviews, videos, etc.

The logistics were a bit overwhelming, as there is so much information. Vetting and highlighting the most useful and unbiased information was a bridge too far. Keeping that info up-to-date was not a realistic goal. We needed to define the goals of the database and how musicians would use it.

We assumed musicians would jump among the piano VI database, forums, reviews, and videos during the research process. Maybe the piano VI database is a good macro review of the landscape but it has too much info for a first pass but is too broad and not deep enough for a final pass. So maybe pianists look at a few reviews-forums to get their feet wet, visit the piano VI database for more info, then target more reviews-forums for a final decision. Maybe not.
 
That's why I suggested a rating system where the worst thing people can do is cast a bad vote. Many sites and digital stores have successfully implemented a rating system. IMO user reviews can be useful, because it's nice to know about the weak points of the library before deciding to spend few hundred bucks on it.

It's true these opinions can be googled. Actually, any info that is going to be in the wiki can be googled... but this takes time.

I agree that this stuff isn't crucial and can be added at a later time after the base wiki is up and running. These features can be added gradually and removed in case they are abused too much. Adding too many features from the start might make the project too ambitious.
 
I think it’s going to be hard enough to accurately capture the quantitative details for a large number of libraries any level of depth. While qualitative opinions would be of great interest and could be very useful, perhaps it’s something we can leave for a ‘phase 2’ of the project? Once a ‘facts only’ home page exists for a library, it should be possible to provide links to other pages containing user quotes, reviews, demos, discussions, polls, etc.
 
I think it’s going to be hard enough to accurately capture the quantitative details for a large number of libraries any level of depth. While qualitative opinions would be of great interest and could be very useful, perhaps it’s something we can leave for a ‘phase 2’ of the project? Once a ‘facts only’ home page exists for a library, it should be possible to provide links to other pages containing user quotes, reviews, demos, discussions, polls, etc.

Yes, exactly. That could then even be separated out to have a divide between "factual wiki" and "opinions".

Btw I updated V2 again a but with some tagging system for instruments and articulations to test out how that feels and if it would yield the proper benefit. The UX is still a bit off, but maybe not even bad - since when an Instrument or Articulation doesn't exist in the DB yet, you have to put it in first, before you put it to a library (although you have the possibility to assign libraries to articulations...you'll see it xD
 
Or (this is not half-serious, maybe 15% serious at most) have ratings and opinions, watch them turn into a total shitshow, delete all of them, then build a new ratings and opinion system based on what you now know you need to be avoided.
 
Or (this is not half-serious, maybe 15% serious at most) have ratings and opinions, watch them turn into a total shitshow, delete all of them, then build a new ratings and opinion system based on what you now know you need to be avoided.
It would certainly have to be handled carefully. Ratings (i.e. 1-5 stars) restricted to VI control members only perhaps, no anonymous reviews, one rating per library per member, etc.. How would you prevent people from rating it who don't even own it? At least Amazon has a verified purchaser requirement.
 
Here is a link to a word document in my dropbox that (hopefully) anyone can view. I'm not sure whether you can make comments or edit it in place. I tried to capture everyone's suggestions for content but undoubtedly I may have missed some. If you are unable to place comments/corrections directly in the document, maybe just post them here.

https://www.dropbox.com/s/tc7k5mag42m4vwn/VI Database Requirements.docx?dl=0
 
I think I prefer the middle-of-the-road approach. Make the most requested/common attributes default categories and leave details up to editors.

  • Dev - ✓ (Grouped category / Bio + Historical data left to editors [text description/dev bio page optional, but dev name should be categorised]) - Initial data input method questionable (easier if dev is auto-populated with previous used terms which ideally would be editable and re-assignable to sub-categories) - Should name be on lib name or assumed based on sub-category/developer sitemap? - Example: Spitfire Audio > Chamber Strings or Spitfire Chamber Strings or Spitfire Audio Chamber Strings (could be typed as Chamber Strings and auto-populated with dev name; redundant but more consistent)
  • Abbreviations - ? (Link to Vi-C Glossary) [SCS, ...] (Simple text)
  • Last entry update - (probably already built-in)
  • Lib name - (linked in the general table next to other filtered attributes)
  • Upgradeable - (Link or description)
  • Official link -
  • Product Family - (Strings, Brass, Woodwinds, Percussion, Drums, Solo, Keys, Synth, Section, Ensemble*, ...) [Category]
  • Part of Bundle/Collection - (Yes - No / Link and/or description)
  • Cover Art - ? (internal or external host)
  • Sample Rate / Bit Depth -
  • Release - (Original date / Update releases / Last date or Original + Last or just Last - Should probably be searchable - Show strings libs from 2011 to 2013)
  • Room - ✓ (Probably simple text description, depends if people wanna look for specific rooms, maybe there could be info on reverb tail times/dimensions, e.g. Air Lyndhurst 5,000 sq. ft., hexagonal, 4s open, 2.1s ceiling or w/e)
  • Articulations/Patches - Paste in description box or tag box (up to editors to populate) > Articulation text box for patches / tags for style (medieval, chamber, world, chinese, hybrid, ...) - Number of RRs/dynamics could be mentioned here
  • Mics - (Just number + Description for type maybe)
  • Capturing gear - ? / (For example, this studio has SSL console, you might want an SSL comp or tape - getting pretty specific over here... Most stuff is already processed but if you wanna get that specific...) (Simple text, sometimes mentioned in manuals)
  • Instruments - (General Sections + Sizes - simple text, divisi marked as x / x / ... > 14 (8 / 6) or (7 / 7) ...)
  • Instrument brand - ? (Simple text or tag, e.g. Steinway)
  • Size on disk - (Simple text?)
  • Resale - (Could be filtered category)
  • Protection - (Should be category)
  • Sampler - (Category)
  • Price - (Searchable, optional historical tracking for initial vs current price)
  • Box/Download - (Yes / No, not necessarily searchable)
  • Part of bundle* - ? (needs clarity on categorisation)
  • OS requirements - (Category - Maybe Main (W, M, L) + specific version subtext (ex: 7, 10, Mojave)
  • Suggested System Specs - ? (Text field)
  • Box for official walkthrough -
  • Separate box for additional walkthroughs/videos - (contextual, DAWcast, ...)
  • Separate box for 3rd party articles/video reviews - ? (could be different for text/video)
  • Box for official demos - ? (can be found on dev site)
  • Box for 3rd party demos, mockups, comparisons - ? (video, forum links - more inconsistent but wider information pool)
  • Sources field/Citations/Extras/Support - (with reference to external or internal linking, e.g. YT/forum link for initial announcement, links to support forum, links to manuals, links to archives...)
^ Sections 2.2, 4.3 + 4.4 could be adapted under these. ^

  • Back-ups - (Number + Frequency)
  • Require sign-in to edit - ? (Leaning to yes)
  • Hosting - ? (Amount of Outsourcing? Depends on hosting cover art, usage, thankfully most of it is simple text, to be determined - exact cost should be visible) / Hosted under Vi-C (undecided) - Donation target per month?
  • Use of cover art - Fair use?
  • Specific styles - ? (Could be specific to instrument family as category Piano > Half-Pedaling Yes / No, but probably best to mention in articulation list) - Falls under 2.4, tricky (How to optimise search?)
  • Sale tracker - Up to editors (maybe link to previous sales or hint at consistent sales/patterns)
  • Opinions - See above (separated or linking to forum threads)
  • Maybe a placeholder generic text field (could contain photos/screenshots)
*Bundle/Collection - Link to official page, price, (cover), protection, then in-linking to individual products (mention savings?)

Free libraries? That could be a separate wiki. Probably way messier. Consideration for later.

Feel free to adapt.
 
Last edited:
Thanks for the Document and the write-up here. For completeness, A short list of that V2 currently does not have yet:
- Current product or discontinued
- Abbreviations
- Bundled with
- Current version number
- Replaces/update earlier version
- Download size
- Standalone or expansion
- OS requirements
- Link to official Videos (one link is given)
- selectable mic placements (free text field currently)
- DRM requirements
- Library overview (e.g. dev's own description)
- Application characterization (is this needed aka - is this factual?)
- Content characterization
- Keyswitched or separate patches
- Assignable CCs
And then a bunch which go (currently) into the further info field as free text. So - overall - a good start already!

on the General Questions:
- Data is enforced due to the relational database approach. Aka - if a developer is not in there, Create it first. That way we have way less rogue typos.
- Backups/Security: Currently, the dev version run with SQLite3 - which should be enough for this purpose. Advantage is that the database is a single file and therefore very easy to back up. Frequency to be determined.
- Bundles: I look into that - but probably similar to devs or Instrument groups.
- Complete edit history: Not implemented currently - that comes from the wiki approach, but the question is if that really is necessary when editing is not open to the public (only after registration)
- Hosting: Currently on Digitalocean, costs can be covered by Patreon, or even by myself
- Developer imagery/logos: Question is images are needed in the first place. Library picture is ok, but I personally don't need a dev picture, especially since not every dev has one. Same goes for the libraries though.
- Affiliation with VI-C: Currently not planned. Can be a way of finance the hosting, but I'd rather keep it separate.
- Sale tracker: There are many other websites who essentially do that. I see the use of this, but I'm not sure if it belongs here
- Qualitative content: Not now.

Ok - so that looks tackable. I personally always favor structured data vs free text. Same goes with Tags - currently instruments and Articulation are implemented via structured Tags - AKA: Only existing Tags can be taken. My experience with free tagging is the old typo ghost lurking, and inconsistency, The way it's currently implemented aims that after a while, "all tags possible" are in the database. If an articulation is not there for example, you put it in and therefore enable all future libraries to have that. Makes it all easily search/filterable.


As far as I've seen from both write-ups, there seem to be 2 general ideas:
1. A detailed overview of libraries
2. All info you can possibly have
While I love 2., I think a lot of the things are very in-depth and imo bloat the database way beyond. The aim shouldn't be to replace all developer websites out there (apart from the actual download link), but to quickly browse and compare on a common ground. So if e.g. a new library comes out, first thing you do is to look at it in the wiki (or put it into the wiki), and many questions like "How many mic positions does it have" are already answered. Fpr anything opinionated - there's VI-Control. Developer push their marketing here, composer compare and make demos here etcetc. This database should not replace that
 
@MatFluor one issue with V2 currently is that articulations are added to a library itself and not to a specific instrument. Often, not all instruments in the library have same articulations.

If possible, it would make more sense for a library to be a collection of patches. A patch itself can contain multiple articulations, multiple instruments (example: section patches, percussion patches), x number of round robins, x number of dynamic/velocity layers etc.

https://www.helpdesk.orchestraltools.com/ag_berlin_orchestra_inspire_articulations.html (For example in Berlin Inspire) not all instruments have a marcato articulation. Some articulations have 3 dynamic layers, while other have 2. There are different number of round robins etc.

Actually, maybe it would be better to have a collection of articulations instead of patches.

| Art. ID | Art.___| Library | Instruments | Mics | D. Layers | RR | Sample offset |
| 1______ | Legato | Inspire | [Violins]__ | 1___ | 2________ | 1_ | ?____________ |
| 2______ | Sus.__ | Inspire | [Violins]__ | 1___ | 2________ | 1_ | ?____________ |
| 3______ | Spicc. | Inspire | [Violins]__ | 1___ | 3________ | 5_ | ?____________ |
...
 
Top Bottom