would it be just for orchestral stuff... or all sample libraries?
table with 3
Here is the barebone V2 (or rather V0.2).
Based mainly on the dokuwiki V1, but based on a database backend - which leaves far more freedom to create frontends and specific things that could be useful.
Keep in mind, since it's in-development, if the underlying databse scheme has to be changed, the data will be lost (or rather, I'm way too lazy to do a proper migration everytime something new comes up).
Have a look around, it might be rough around the edges in some places (pretty much so due to the somewhat special deployment now), but you get the general idea.
https://178.128.198.122/librarywiki/
Getting comparable VI technical data into a database is tough as the marketing specs are a chore to sift through. And they change. For the segregation of different versions (e.g. platinium, gold, silver, bronze, steel, lead), we used a different row.
We settled with the following fields:
Software Company
VI title
Piano sampled
Player/security scheme
Price list
Box/download
Release year
Website
Sample rate
Bit depth
HDD usage
Half pedaling
# sampling layers
# mic perspectives
comments
Exactly. The time to sort this out is before we start populating anything, expecting that there will need to be several changes/additions to fit the real world data as we go along. In the quest to assemble a common set of data attributes for every VI, the wheels will fall off pretty fast after Company Name, Library Name, Price, etc. Incompleteness and non applicability of many data fields are going to be features. What we need to settle on is a set of attributes, whether common to all libraries or not, that we want to see captured and resolvable in a user query.
You don't want to have every EDM loop library or hip-hop drum pack in there, though, just because of their sheer numbers.
Edit: for synths I think having a totally incomplete and biased selection of "things VI-C people like" would be OK, and probably actually better than having every synth VST in the world listed. KVR does a good job of covering the latter.
E.g. what do we do with legacy/discontinued products / the ones that got replaced by new versions? Should we put Albion 1 in as a page on it's own? Or should it be only a foot note on the Albion One page just stating this is the successor of Albion 1?
Maybe creating a list of devs and libs and allowing people to volunteer, pick 5 (or 10, or...) at a time and then add the content, could sort this out.Even if this will be a project going on "forever" as new libraries come, and as with Wikipedia libraries can be added as people have the time to add them, but perhaps we should still make some kind of list of who of us that's gonna add libraries from different developers? With large companies like Spitfire and it could perhaps be Spitfire A-F, G-M, etc. I'm sure we all have different favorite companies we would like to add first.
Maybe creating a list of devs and libs and allowing people to volunteer, pick 5 (or 10, or...) at a time and then add the content, could sort this out.
Of course, we would need to create an updatable list first, but that could also be a collaborative effort.
Just throwing ideas to the wind
Libs could have "replaces old_lib" and "replaced by new_lib" fields.
I'd say Albion 1 and Albion One are different libs, so yeah, different pages for different versions, but we could start with just the current libs and, like Wikipedia, just add a link to a still-not-created page for later input if someone decides to add it.
K12, SSO, EWHO, etc. could be in a bundle table (just a simple group) if you can get different parts. I mean, if I can buy HBrass and HStrings like two different libs, I'd say HOrchestra is a bundle, not a lib.
I'd start with just orchestral libs, but that's me, and anyone could add synths and other kind of libs at any time, even at the beginning, so the question here could be what characteristics have synths/etc. in common and different from orchestral libs, to prepare the database beforehand. I wouldn't know how to answer this question.
Thanks @DSmolken .I really like the format. Sure, having separate lists of piano-specific fields like half-pedaling and string-specific fields like divisi will make things harder to set up and maintain, but in the right format it's not too bad, and it would potentially make the wiki really, really good at giving the users what they're looking for.
Sorry, yes, typing too quickly there. I meant need to fill the list.The list as "wiki" part is already updateable
We should create some collaborative document to gather the ideas and wishes, and then digest down what the best and most usable thing will be in the end.
Very good thoughts on instrument-specific attributes. It's not particularly difficult to define entity-specific sub-attributes in a database or in a form based user interface, but it is quite difficult to identify and define all of these relationships in the design phase!Thanks @DSmolken .
Excellent insight on the pedaling topic. For classical piano players, proper pedal function is essential, so there was a lot of demand for pedaling database fields, perhaps the most demanded field.
Marketing speak around piano VI pedaling is opaque or downright false, so the only way to classify pedaling is for expert pianists to test drive and report.
But. . . since the piano VI universe is relatively small, it is easy to search the PianoWorld forums and find less than a dozen modern piano VIs that are popular for advanced practice of classical music (e.g. responsive, balanced, realistic sounding, reasonably PC resource intensive, etc). Of those another quick search reveals just a few modern VIs with good pedaling support (e.g. PianoTeq). Dozens of senior forum members can recite the popular piano VIs and the ones with good pedaling support for new users.
So, we decided to keep the piano database more "factual" as a good starting point for piano VIs. And rely on forum posts to provide more "real-world colour". We dropped the highly demanded "pedaling database fields".
You can see that the piano VI database is probably more useful for music production than classical music practice.
Given the massive size of the VI-Control wiki, our approach would be too simplistic. Hopefully you find our thought process somewhat helpful.
For example, I might want to ask the database which of the hundreds (or is it thousands?) of orchestral sample libraries out there feature a ‘Bartok’ articulation.