table with 3
Looks great!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.
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.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:
# sampling layers
# mic perspectives
Exactly. The V2 is barebones, but since it's based on a Database I can easily design different "views" for various kinds of user queries (e.g. side-by-side comparisons are possible, I just have to code that).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.
Exactly, I think the question of which libraries to include (and what defines a library for the wiki) is almost as important as the criteria of what we want to see for the library sites.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.
The way I went about that in V1 for SCS was to include the release date of the original volume and then the one for the re-release (along with a link to threads and the transition announcement). For Symphonic Brass, I used the release of BML Horns Vol. 1, then skipped to the consolidated SSB. You could include every single release up to SSB. Again, it depends how detailed you want it to get and the amount of work people are willing to put in. At some point you'll also probably need devs to double check the info or provide extra material (insights, bios... if they care to). You can go from simple shopping list to full-on historical tracking. It could be kept simpler by just linking to the latest iteration and leaving everything else out (same for historical price vs current price or sale vs regular, though, judging by the forum, people are interested in tracking at least consistent sales, like EW or getting a possibility of a sale appearing; where's AI when you need it? :D ).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.
The list as "wiki" part is already updateable - currently barebones, just name, Website and Country. But as soon as a developer is in the Database, it is chooseable to enter libraries for it.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
If we only address standard orchestral libraries, then the list of shared attributes between them will be easier to define at a high level of detail. And of course, shared attributes enable filtering and comparison. But the wheels will quickly fall off as we try to define hybrid libraries like Thrill, or thematic libraries like Era Medieval Legends when using an attribute set heavily tailored to only orchestral libraries. So I don’t think that common characteristics should necessarily be the test for whether an attribute type is included in the database. Preferably, an expandable list of instruments, would be possible so that carnyxs and dilrubas could be included with ease.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.
Agreed.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.
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.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.