What's new

A sample library wiki?

DSmolken

Senior Member
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.
 

dflood

Active Member
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.

http://178.128.198.122/librarywiki/

:)
Looks great!

Since you have moved to a database engine, which I think is by far the best way to go, we should try to think about what degree of data granularity and filtering will be useful and try to offer defined attribute fields accordingly, even if many of them have to be left blank. I’m thinking of things like:
  • Recording Location: (i.e. Air Studios, Lyndhurst Hall)
  • Content Creator/Producer: (i.e. Eduardo Tarilonte)
  • Recorded Artist(s)/Orchestra: (i.e. Joshua Bell, Clara Sorace, members of London Symphony Orchestra, etc.)
  • Selectable Microphone Positions: close, Decca tree, hall, etc) (select all in list that apply?)
  • Microphones types used:
  • Instrument Categorization: (ensemble, solo, both)
  • Sample Characterization: (single note, phrases/loops, both)
  • Divisi: (N/A, none, manual, auto, manual and auto)
  • Other Special Features: (strumming engine, auto chords, etc.)
  • Legato: (Y/N)
  • ?
  • ?
  • ?
I don't pretend to have thought any of this through, but where you have the: “Instrument Details (Section sizes, Brands…)” field, I would characterize that as a kind of summary note field. Under the Detailed Info section I would try to create an a-z instrument selection table something like:

  • Instrument; Sub-Type; Performance Class; Instrument Count;
  • Accordion; Piano; -; 1;
  • Accordion; Button;-;1;
  • ---
  • ---
  • Violins; - ; solo; 1;
  • Violins; II; 4;
  • Violas; -; -; 3;
  • ---
  • ---
  • Zither; -; -; 1;
Maybe the “class” and “count” sub fields would only appear for instruments where that seems appropriate?

I’m thinking of how we might classify something like UVI World Suite, or Eduardo Talirontes collections. For maximum benefit of data retrieval and comparison, it’s probably going to be necessary to enter or preferably select each instrument (or instrument patch?) in a separate field. The ability to create new instruments as part of the selectable list would also be useful, as well as editing/combining any obvious duplicates.

Edit: Sorry, I was in a rush and couldn't figure out how to make a table for the above. Anyone know if this is possible here?
 
Last edited:

dflood

Active Member
Would we want to capture the list of articulations, keyswitched or other, Learn CC, etc? Would this be captured at the library instance or the instrument instance? Or is this getting way too far into the weeds for each library?
 
Last edited:

Dive

New Member
As a suggestion possibly include library download size (GB) I've been adding a number of spitfire libraries to the wiki.
 

dflood

Active Member
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.
 
Last edited:

MatFluor

Senior Member
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. 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).

I personally think that wiki should give a comprehensive overview without getting too much into details - in the end, contributors will have to work their way through an endless form to put in all the details. The "User stories" (what does a user want to be able to do, what does he want to get info on) are key. There are many good ideas, but I think we need a consensus on which we can then go off of. Keeping it comparable without getting too detailed. On that - is the recording space already too detailed, or is that an important information? Stuff like that.
 

fretti

Senior Member
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.
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.

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?

What should we do with certain bundles or products like Komplete? Should it be treated like an own product or just link to all products included (maybe including a comparison or actually linking to the comparison site from Native Instruments)?

What is the definition of a Sample Library for the Wiki? Are Loop packs and collections of Midi Drum Loops seen as Libraries? Are Synths (Zebra, Omnisphere...) included to have the most complete list of available stuff? Or are they also seen as Libraries for which Soundpacks should be included?
 

WhiteNoiz

';...;'
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?
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 ).

Komplete could fall under "Bundle". (A category like Section, Ensembles, Solo) It will be grouped under the "Bundle" table but each single product should have its own page (Komplete master page with linking to individual products), I guess. Same for things like Hollywood Orchestra or SF collections and things like that. Again here you can skip bundles and mention only individual releases (or mention them in description without details or also part of "xxx" for % off). Things like Albion or Symphobia should probably be different since you can't separate, say, strings or brass only (Ensembles or other). It starts to get more complicated but in the long run it will be better for grouping and filtering.

To be considered a library it should probably contain audio samples. (You could separate loops and phrases or have them as tags) Or be chromatically sampled? (No loops, no MIDI patterns or including at least a chromatically sampled/playable instrument) The initial focus should be on one page or a handful of them for each category which will be edited and iterated to death so a default format can be extracted. You could start with a list like the piano one above and extrapolate from that.

Synths could fall under synths and preset packs could fall under Add-ons or Expansions with some in-linking to the host synth. Maybe you want to mention just the main synth. Or have only orchestral packs, dunno. Or leave them out entirely. Depends on the scope. That's how I think about it at least, I'm sure in practice or if trying to actually draw the site map other things will pop up (much like protection, disk size, mics, rooms which popped up later while editing).
 

angeruroth

Active Member
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.
 
OP
Mason

Mason

Active Member
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.
 

angeruroth

Active Member
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 ;)
 

MatFluor

Senior Member
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 ;)
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.
The "Groups" or "families" thing is meant for the broad categorization, like Brass or Full Orchestra.

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.

Even though V2 looks a bit coporate, the backend is stable and it has user login etc implemented - meaning if it grows large with volunteers and a Patreon, there could also be a proper curation.
 

dflood

Active Member
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.
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.

If the information is available, I’d like the ability to list any included articulations, and whether they are keyswitched or separate sound sets. 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. Obviously, for the database to return anything, the term ‘Bartok’ would need to have been captured where applicable, preferably in a field defining articulation types, or if not, in some generic descriptive field.
 
Last edited:

newman

Member
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.
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.
 

dflood

Active Member
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.
Agreed.

Here's a suggested roadmap for advancing the project. Please feel free to improve on this.
  1. Organize the ideas into some sort of order (document).
  2. Come to some sort of consensus regarding which ideas/details to move forward with.
  3. Identify the volunteer development team and assign duties.
  4. Translate those ideas into an Entitiy Relationship (ER) map for modelling the database. This would likely be done by one or maybe a few volunteers with suitable abilities.
  5. Create the database
  6. Create the user interface
  7. Test against a small but diverse set of data samples (libraries)
  8. Revise/retest iterations until stable.
  9. Find an on-line home for the application and data. Cost?
  10. Decide on user access restrictions: Who can use, who can edit.
  11. Roll out V1.0 for initial data input.
 

dflood

Active Member
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.
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!
 

WhiteNoiz

';...;'
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.
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.

As for volunteers, maybe that's more suited for creating the framework. Once it's set, anyone can edit (I noticed the V1 would lock the topic to your IP for 15 minutes so you could probably do your thing and then leave without too much interference). Maybe devs could have special/verified accounts so you can tell what they edit officially (still can be done anonymously, but easier to verify accuracy; release dates for example, if made by specific account). Or if posting changelogs etc. Stuff they have direct access to. This could be irrelevant though if there is proper source linking for the data (like an official announcement, forum thread or news bit).
 
Top Bottom