# A sample library wiki?



## Mason (Jun 5, 2019)

Update, June 13:
A wiki page is under construction at this link: 
http://178.128.198.122/librarywiki

Made by @MatFluor.
Thank you for the great work so far and to everyone for contributing and sharing ideas.
The intention was to have something created by composers for composers. Join by sharing your creativity and ideas in this thread.


Original post:
With a general interest in sample libraries and with the ton of libraries that has been released for quite a few years now I’ve been thinking about some kind of Wikipedia page for sample libraries.

If it doesn’t exist already, wouldn’t it be cool to create one? It’s difficult to have full overview of every library and it could be fun to have more overview of those that are not longer available as well. It could include basic information as developer, year of release, producers, category, size, format, links, some kind of trivia, reception etc.

And everyone who wants can contribute to it.


----------



## gsilbers (Jun 5, 2019)

sounds good. 
i think somehting like Kvraudio.com is kinda like that? more like press release info w date but still has tons of older stuff.


----------



## JEPA (Jun 5, 2019)

there have been individual efforts from members here in VI-control.. but a wiki is a better idea, where everybody can contribute, update and correct.
https://en.wikipedia.org/wiki/Wikipedia:Your_first_article


----------



## MatFluor (Jun 5, 2019)

Interesting Idea. I like what some other members did though.

Would it be good to have a "streamlined" way of entry? I would totally be down in setting something up.

Ah, I'll set something up today and reply again when it's ready to be filled


----------



## Dex (Jun 5, 2019)

I think this would be a useful resource.


----------



## Mason (Jun 5, 2019)

MatFluor said:


> Interesting Idea. I like what some other members did though.
> 
> Would it be good to have a "streamlined" way of entry? I would totally be down in setting something up.
> 
> Ah, I'll set something up today and reply again when it's ready to be filled



Sounds great! I don’t have the technical knowledge to set something like that up but have had the idea for a while and absolutely willing to contribute myself.


----------



## Mason (Jun 5, 2019)

gsilbers said:


> sounds good.
> i think somehting like Kvraudio.com is kinda like that? more like press release info w date but still has tons of older stuff.



Looks like that’s mainly a list of softsynths and plugins or perhaps i didn’t find the correct page?

Anyway I like the idea of something created by users for users, and anyone who have the time and interested can contribute.


----------



## DSmolken (Jun 5, 2019)

Mason said:


> Anyway I like the idea of something created by users for users, and anyone who have the time and interested can contribute.


No one has _that_ much time, heh.

Seriously, though, Spitfire have been putting stuff in the KVR database, but seems like not everything, or at least I don't see it: https://www.kvraudio.com/developer/spitfire-audio

VSL is also kind of there, but probably not current and complete - can't find Synchron stuff for example: https://www.kvraudio.com/developer/vienna-symphonic-library-vsl

Now, KVR is a big source of traffic for me, so it's far from useless, but it does look like it's not as complete for orchestral stuff as we'd like. Seems we can't rely on every developer to want to keep the KVR database up to date and there's a gap to be filled.

I've got some practical experience with the sfzformat page which is also a Wiki, btw. I can offer some practical advice on making stuff maintainable. It's all doable, if people are gonna be OK with it starting incomplete and gradually getting better with time. Cause just entering basic data for every VSL release will add up to many hours.


----------



## MatFluor (Jun 6, 2019)

DSmolken said:


> No one has _that_ much time, heh.
> 
> Seriously, though, Spitfire have been putting stuff in the KVR database, but seems like not everything, or at least I don't see it: https://www.kvraudio.com/developer/spitfire-audio
> 
> ...



I'm currently setting something up with that goal in mind. It's barebones, but usable. Taking this morning to ideally implement most things that would be useful


----------



## DSmolken (Jun 6, 2019)

A great thing to do would be to have either an SQL database in the backend, or the pages generated from something like YAML. That would later allow for the generations of comparison tables - say you want to see all pianos released or updated in the past year, how many GB each one is, and how many mic positions it has. Doing something like that from typical Wiki pages is a giant pain, but if the data are organized like a database from the start, it becomes easy.


----------



## MatFluor (Jun 6, 2019)

DSmolken said:


> A great thing to do would be to have either an SQL database in the backend, or the pages generated from something like YAML. That would later allow for the generations of comparison tables - say you want to see all pianos released or updated in the past year, how many GB each one is, and how many mic positions it has. Doing something like that from typical Wiki pages is a giant pain, but if the data are organized like a database from the start, it becomes easy.


Yes - currently my V1 is based on a simple Dokuwiki, quick and painless to set up (with forms). There are some possibilities with that as well - I rather like a "flat file" versus database. But hey - it's V1!


----------



## DSmolken (Jun 6, 2019)

Yeah, sfzformat started off as flat files and that's definitely the easisest way. Ended up moving stuff to a more DB-friendly format when somebody asked if we can make a big table with everything. Had we thought about it earlier, we'd have saved ourselves migrating all the info to another format, which wasn't terrible, but did take someone a couple of days of work.

And in this particular case, I think the ability to generate a comparison table based on search results and with selectable columns would be very useful to people. We obviously don't need to be able to do that right away, but setting up the data in a way that will make it easier in the future is, not necessarily the right way to do it, but something to consider.


----------



## MarcusD (Jun 6, 2019)

This is a really cool idea!! Could also include stories about the developers, how they founded the business and info about the individuals responsible for putting the products together (if they're ok with it).


----------



## Garry (Jun 6, 2019)

What a great idea! Would love to see something like this.

I have a suggestion to add to it: how about we upload to this wiki, about 5-6 standard short passages of around 16-20 bars (saved in all standard DAW formats) to cover different styles, and then each library on the wiki could have a file in which those passages are played using that library. It would make it easy to directly compare the sound of each library across different playing styles, and allow people to decide which suits them best, and how different each of them are. Reading about a library is one thing, but to really decide for yourself, you need to hear it, and to do that comparatively, it ideally needs to be based on the same material.

Some time ago, I organized a blind shootout for strings, and Saxer contributed a midi file with passages that people used to create a version using different libraries - this could be a good starting point (though more could be added if people want to see additional styles). This could be used for strings, and we could quickly create something similar for brass, woods and percussion (with lines suited to those instruments rather than the strings passages), and others (piano, guitars, etc) could be added as and when people see a need. Also, no need to have just 1 version per library (as different contributors will have different skill levels, and a poor version may reflect more on the individual than the library): there could be several contributions by anyone who wants to upload it. Perhaps these could even allow ratings, so that you could quickly see which are the best representations of a library to listen to. You could then quickly compare the best rated version of library X vs library Y, and make your decision as to which you prefer.

Would this be a useful addition to the wiki?


----------



## d.healey (Jun 6, 2019)

Garry said:


> saved in all standard DAW formats


Good idea but a MIDI file should be the minimum requirement because everyone can use that no-matter what software they're working in.

The wiki should be publicly editable (I don't think KVR's database is). Could VI-Control host it @creativeforge ?


----------



## MatFluor (Jun 6, 2019)

If you're interested - here the absolute barebone, unstyled minimal thing. Quickly hacked together.

With a little Design it could be something xD

Feel free to check it out: http://178.128.198.122/ (http://178.128.198.122)


----------



## Garry (Jun 6, 2019)

d.healey said:


> Good idea but a MIDI file should be the minimum requirement because everyone can use that no-matter what software they're working in.
> 
> The wiki should be publicly editable (I don't think KVR's database is). Could VI-Control host it @creativeforge ?


Yes, you're right, that should also be included, but was thinking of the DAW format additionally, because then all additional programming, is available and visible.


----------



## MatFluor (Jun 6, 2019)

So yeah - I put one Library as example in.

I think it's easier to go with a database backend - especially due to search and changes. Now I hacked an essential "proof of concept" together which can be a nice jumping off point to create the proper thing around it.

On the MIDI files and Developer bios in that sense: I would aim the wiki more at a Knowledge base rather than an additional marketing platform. So to speak - a wiki by composers for composers, rather than developers. They would of course be encouraged to put their stuff in as well - but whole "Marketing speeches" are I think not the good thing to have. Same with reviews in my opinion. I could talk to Don Bodin to link his reviews in - but I think I'd rather keep it "sterile", down to the facts.

With the MIDI files or project files it's a similar situation - it works nicely here in forum context. But it comes down to "does the guy using the MIDI-File just putting it in and be done" or "massages the MIDI a bit to get the proper sound out" - often exactly those question make or break a library - can sound utterly horrible out of the box with minimal CC, or glorious with massaging (and still not FX). That's certainly a point to consider and think about.


----------



## angeruroth (Jun 6, 2019)

I like the idea.
@MatFluor Nice first step! (or second  )
About the audio files, I think good AND bad demos are important to understand how easy/hard is to use a lib, and how much time it requires to get something good out of it.
Anyway, I'm guessing the space required for naked demos would be huge.

Maybe fields like "massaging needed (0-10)" would be helpful, 'tho that would require consensus (like the polls).


----------



## d.healey (Jun 6, 2019)

MatFluor said:


> On the MIDI files and Developer bios in that sense: I would aim the wiki more at a Knowledge base rather than an additional marketing platform. So to speak - a wiki by composers for composers, rather than developers. They would of course be encouraged to put their stuff in as well - but whole "Marketing speeches" are I think not the good thing to have. Same with reviews in my opinion. I could talk to Don Bodin to link his reviews in - but I think I'd rather keep it "sterile", down to the facts.



This makes a lot of sense and there should probably be some editorial guidelines. Wikipedia for example does not permit first hand research to be published and this is probably a good rule for a sample library wiki, otherwise it will be overrun with user opinions and developer marketing. It should stick to the facts, citations from independent videos and articles should be permitted as well as references to official user guides and videos. MIDI and DAW files are probably still relevant since they can be assessed objectively by the person who opens them but audio files shouldn't be used since there is no way to know what processing has been applied and this would be an easy thing for someone to manipulate to their own advantage.


----------



## d.healey (Jun 6, 2019)

angeruroth said:


> About the audio files, I think good AND bad demos are important to understand how easy/hard is to use a lib,).


No-one writes a bad demo  this is far too subjective to be of any use and should be avoided.

I don't think audio should be posted on a public (unbiased) wiki. Our ears are biased and we are full of in-built prejudices. If you love Spitfire then you will most likely think a demo for a Spitfire library is "good" compared to someone who hates Spitfire who will naturally think the demo is "bad". A wiki should be a place for facts not opinions.


----------



## angeruroth (Jun 6, 2019)

d.healey said:


> No-one writes a bad demo  this is far too subjective to be of any use and should be avoided.
> 
> I don't think audio should be posted on a public (unbiased) wiki. Our ears are biased and we are full of in-built prejudices. If you love Spitfire then you will most likely think a demo for a Spitfire library is "good" compared to someone who hates Spitfire who will naturally think the demo is "bad". A wiki should be a place for facts not opinions.


Don't know why anyone would love or hate any developer (a lib yes, we all do) but you are right, it should be about facts. That should mitigate any prejudice and make it plain helpful to everyone.


----------



## MarcusD (Jun 6, 2019)

+1 should be 100% factual language. No promotional material and or bised content that could be manipulated for personal gains. For example, reviews videos.

Which begs the question: If you were to include any video content or content taken from a 3rd party platform, it can be used to that platform (or individuals) advantage to generate meterics, data and potential conversions for their own gains.

Maybe it'd be a good idea to host any audio examples, MIDI, videos etc... directly from the website. Obviously this would require a server and cost some money. But it removes any leaverage for individuals to take advantage of such things. I'm sure if a bunch of people payed £2 or £1 a month contribution towards server costs it would cover things.

Just a thought...

EDIT: could call it Vikapidia haha


----------



## Mason (Jun 6, 2019)

I agree with the facts based approach! I think keeping it as neutral as possible will make it into everyone’s resource page to find libraries and have a great overview of every piano, brass, choir library in the world. Think of it as Wikipedia pages on movies, music albums etc.

A link to the developers website and YouTube channel will make it easy to find demos and walkthroughs, but for resource purposes more than marketing.

When I suggested something about the library’s reception I was also thinking about how Wikipedia pages on movies usually say how the movie has been received on IMDB etc. So perhaps it could say something like “recieved 4 of 5 stars” on “sample library review” with a link to the review, as a fact?


----------



## MarcusD (Jun 6, 2019)

Mason said:


> A link to the developers website and YouTube channel will make it easy to find demos and walkthroughs, but for resource purposes more than marketing.



Yes. Exactly that. Only the factual stuff from the developers. None "outsider" promotional content and certainly no tutorials / overviews from anybody that has nothing to do with the companies. Keep it very much straight-from-the-horses-mouth and to the point.


----------



## WhiteNoiz (Jun 6, 2019)

Maybe make it a bit more streamlined? Seems a bit random as it is. Not sure where to start. It probably needs a By Year category too. Put some training wheels on it in order to figure out the format. It's pretty overwhelming when looking at the blank page, haha.

Issues I immediately notice: Dev names. Someone could, for example, input "Spitfire" and another might input "Spitfire Audio" or "SpitfireAudio". Don't know how easy it would be to crosscheck, rename or re-organise after you get the raw data. Instruments text doesn't show up [in HS I input Violins I (16 / 9-7), Violins II (14 / 8-6), Violas (10 / 6-4), Celli (10 / 6-4), Basses (7 / 4-3)]. Library type seems to have bad reference. Also, some libraries are strings only or ensembles or full sections (EWQLSO technically has the strings separate when installed but I don't think you can buy it separately, though you can figure that out). Maybe ensemble/pack libraries should be somehow separated (like Albion, Symphobia, etc., not sure how). What about numerous entries? Auto-fill would help. Links to manuals maybe. Guidelines on what to input in text fields (wasn't sure what to put in instruments). Maybe add a general text description. Not sure if I can add things myself; don't know how to work it.

And back-ups... In case it gets messed up or vandalised or spammed or whatever. Anyway, let's see where it leads. It can only be as good as what and how much people actually contribute.


----------



## d.healey (Jun 6, 2019)

WhiteNoiz said:


> And back-ups... In case it gets messed up or vandalised or spammed or whatever.


I'd go a bit further and suggest it has a complete edit history like Wikipedia.


----------



## Reid Rosefelt (Jun 6, 2019)

In addition to setting up rules, I think a lot of work should be put into its design and user interface before it's started. Personally, I think it should be a Wordpress site, as that allows the most opportunity for improving the user interface in the future, as people come up with new ideas. 

Also, there is the issue of hosting. Uploading music costs money as this thing grows, particularly if we want to have higher quality than the kind found on other sites. For this reason, we might to host original video, and not just link to YouTube. So a plan for how people could chip in to make this possible should be there from the beginning. 

Or a decision could be made, that no, there won't be anything hosted on the site but words and links. But I think it's worth discussing.


----------



## MarcusD (Jun 6, 2019)

Just thought - When putting any images or logos up of developer brands. It would be worth asking the developer first if it's ok to-do-so. Simply because some artwork is outsourced and the developer may not own the right to an image or work (still remains the artists), unless they paid for ownership.

Just a thought. No one wants to inadvertently be treading on toes, although there's no ill intent behind what's being done. Only takes 1 artist to angrily helicopter boulders of shit over everyone's hard work, like a hippo.


----------



## WhiteNoiz (Jun 6, 2019)

d.healey said:


> I'd go a bit further and suggest it has a complete edit history like Wikipedia.



The basic version posted here before has a revisions/versions button with edits. I added HS and Zimmer Strings to get a feel for it. Trying some edits.



MarcusD said:


> Just a thought. No one wants to inadvertently be treading on toes, although there's no ill intent behind what's being done. Only takes 1 artist to angrily helicopter boulders of shit over everyone's hard work, like a hippo.



Fair use? If you want to copy it, you can copy it from the original anyway.



TigerTheFrog said:


> Or a decision could be made, that no, there won't be anything hosted on the site but words and links. But I think it's worth discussing.



Maybe start with something like Google Drive and decide later based on traffic. Links seem fine though, depends how deep you want to make it. I thought about linking to the old Nick Phoenix tutorials from 2011 or whatever for HS, for example (although technically they've removed them, you can still find them).


----------



## Dex (Jun 6, 2019)

MarcusD said:


> Yes. Exactly that. Only the factual stuff from the developers. None "outsider" promotional content and certainly no tutorials / overviews from anybody that has nothing to do with the companies. Keep it very much straight-from-the-horses-mouth and to the point.



I wouldn’t mind links to tutorials/walkthroughs that focus on the naked sound and the basic workflow.


----------



## JEPA (Jun 6, 2019)

here there is an example for musicologist and musicians searching for sheets or notes of music free of copyright:
https://imslp.org/wiki/Main_Page


----------



## creativeforge (Jun 6, 2019)

d.healey said:


> Good idea but a MIDI file should be the minimum requirement because everyone can use that no-matter what software they're working in.
> 
> The wiki should be publicly editable (I don't think KVR's database is). Could VI-Control host it @creativeforge ?



We'd have to run this through @Mike Greene , as it would entails extra expenses and oversight. Though with the potential pool of professional knowledge involved it could become a beastly resource. But hungry too...  @MatFluor already whipped something up that seems solidly heading in the right direction.


----------



## DSmolken (Jun 6, 2019)

Yeah, definitely heading solidly in the right direction. I think that building the best list of orchestral virtual instruments in the world isn't really all that hard, because there's basically nothing out there right now. So, having something of value out there and improving it later sounds like it really would benefit a lot of people.

Even the current rudimentary form, if it was just populated with stuff from all the big developers (which is many hours of work given the huge numbers of entries, but maybe start with 2019 releases and work backwards), would be a huge step forward.


----------



## dflood (Jun 6, 2019)

MatFluor said:


> If you're interested - here the absolute barebone, unstyled minimal thing. Quickly hacked together.
> 
> With a little Design it could be something xD
> 
> Feel free to check it out: http://178.128.198.122/ (http://178.128.198.122)


Great start, Matt,

I have often wished that something like this existed. The KVR site is good, but not all that complete, and it is littered with plugins and other non sample based products.

Most of the initial work in getting something like this off the ground is in designing the data input fields so that they are complete enough to capture the scope of products out there but perhaps not so detailed that they defy grouping or comparison. Nested categorizations can help, going from the general to highly specific. This is usually accomplished by trial and error with several test iterations and revisions of the data structure being necessary as the number of records grows.

Not sure how to manage this, but it’s probably best to play around with a data schema first for a while until we have one that is not consistently broken by the next library we try to characterize. Some of the oddball libraries and collections might prove the hardest to characterize under a single entry, and it might be useful to try to capture these first. The other thing to think about is the eventual filtering criteria, and to try to ensure this data is captured at the outset. For example, We might want to include DRM requirements, because some people don’t much care for dongles.

Anyway, this is a great idea, and I for one am willing to contribute!


----------



## WhiteNoiz (Jun 6, 2019)

dflood said:


> (..) Anyway, this is a great idea, and I for one am willing to contribute!



I also added Chamber Strings and it hit me that it would be nice to also add the rooms... Added the ilok requirement to HS before. These will probably have to be grouped. Also, Spitfire Sample Player will need to be added, as well as OT (eventually) and UVI (these would fall under 'Other' now). Still messing around (added images too).

General table seems to not be linked with the separate entries: http://178.128.198.122/doku.php?id=overview:families:strings#overview_of_all_string_libraries (Homepage also doesn't show up on its own, although you get a field for it when submitting)

When I initially submit it changes the price to $9 for some reason. Had to manually edit some stuff after the fact.

Some editing stuff needs a bit of familirisation (for example, url tags seem to not work, it just defaults to its own format).


----------



## JEPA (Jun 6, 2019)

some thing like this for each library, like a site tree...?


----------



## dflood (Jun 6, 2019)

MatFluor said:


> Yes - currently my V1 is based on a simple Dokuwiki, quick and painless to set up (with forms). There are some possibilities with that as well - I rather like a "flat file" versus database. But hey - it's V1!


Database vs Wiki is definitely something to sort out from the outset. Many wiki-like applications are actually built with a database back end, as is Wordpress, but they do not necessarily behave like traditional databases in terms of filtering, sorting, summarizing etc. The database part just stores each page, and various binary elements. I think ideally, a VI Library Database would be best built as a real database where all the tables have been normalized. It can take a lot more work in the beginning but the end result would enable much more powerful queries. The UI could look and behave exactly like a wiki or whatever, as the table structure is usually not exposed to the users.

This is not a deal breaker, it would just make the application more powerful. Having said that, I have no idea how to go about it. The last database application I built was with dBase II.  Maybe someone among us has such abilities?


----------



## Mason (Jun 7, 2019)

Even if I launched the idea, one that it seems like a few others have had in mind as well, please know I don’t have the need to be the one to decide how it should work. I don’t have the technical knowledge to do so anyway. But I wonder, is it possible to create something that works exactly like Wikipedia? Assuming we can’t use Wikipedia for sample libraries (?).

I was imagining something like this: https://en.m.wikipedia.org/wiki/The_Lion_King_(soundtrack)

Perhaps that’s what you are discussing and I just don’t know what you’re talking about with all the technical stuff


----------



## d.healey (Jun 7, 2019)

Mason said:


> But I wonder, is it possible to create something that works exactly like Wikipedia?


Yes that's possible.



> Assuming we can’t use Wikipedia for sample libraries (?).
> I was imagining something like this: https://en.m.wikipedia.org/wiki/The_Lion_King_(soundtrack)


Wikipedia is a general purpose encyclopedia, you can go and write about sample libraries there if you like, but it's probably better to have a dedicated encyclopedia just for sample libraries.


----------



## angeruroth (Jun 7, 2019)

I could build the database model, tomorrow if life allows it, but it would be important to choose the engine (MySql maybe?).


----------



## DSmolken (Jun 7, 2019)

I've been thinking about what this could actually do for users, putting it in terms of scenarios where this could be helpful. Not that we need a wiki which can necessarily provide complete answers to all these questions. But I think being able to answer such questions reasonably well is a good long-term aim. And yeah, anybody who's done Agile software development with user stories will probably groan, haha.

"I need a pedal steel for a project with a short deadline." Easy answer there, now that Tod has released his.

"I want a powerful epic choir, doesn't have to have a wordbuilder, and am wondering whether I should wait for a sale."

"I need a big band horn section."

"I want orchestral strings in the traditional orchestral section sizes."

With some of these, the recommendations we'd give as people would be somewhat tricky to get a wiki to return with a simple search - for example, for the horns maybe putting them together from Audio Modeling and Sample Modeling, or using Project Sam Swing/Swing More, which contain a lot more than just horns. And I'm not sure if we want to get into the "do they do sales" questions, as that's potentially a minefield, but OTOH it's something people really do want to know.


----------



## axb312 (Jun 7, 2019)

My 2 cents, you could include technical details - dynamic layers, library size, round robin etc. and perhaps a user rating system.


----------



## d.healey (Jun 7, 2019)

axb312 said:


> and perhaps a user rating system.


No


----------



## axb312 (Jun 7, 2019)

d.healey said:


> No


Yea that could be misinterpreted....


----------



## Dex (Jun 7, 2019)

I’d love to have a database of sample offset times for each patch for grid-based composition. That info is really hard to find most of the time. Performance Samples seems to be the only company that really features that info clearly.


----------



## bigrichpea (Jun 7, 2019)

Dex said:


> I’d love to have a database of sample offset times for each patch for grid-based composition. That info is really hard to find most of the time. Performance Samples seems to be the only company that really features that info clearly.



Yes, that would be useful. And also the mic names, which can sometimes not be obvious from their abbreviations, and key switch info (perhaps with links to user-made DAW articulation sets)


----------



## fretti (Jun 7, 2019)

DSmolken said:


> With some of these, the recommendations we'd give as people would be somewhat tricky to get a wiki to return with a simple search - for example, for the horns maybe putting them together from Audio Modeling and Sample Modeling, or using Project Sam Swing/Swing More, which contain a lot more than just horns.


Might be tackled with something like a tagging system (like Netflix etc. for recommendations)?! Where you can tag e.g. style of music a library is designed for (or capable of playing), section sizes, hall/room, engine, dongle etc....
Then maybe even something like a comparison site where you can select different tags and see what libraries fall under these requirements (for further research afterwards)



DSmolken said:


> And I'm not sure if we want to get into the "do they do sales" questions, as that's potentially a minefield, but OTOH it's something people really do want to know.


Could be bypassed by including something like a "sale tracker" where past sales and events are tracked for all companies. Then sorted by companies and a page with something like a calendar thing for a quick overview (?!).
Recurring sales could be "predicted" (Spitfires Christmas-Wishlist, all companies with Black Fridays sales) and/or even include something like a probability of how the chances stand we'll see a certain sale again (was it a one time thing like NI and OT? is it a yearly thing like Black Friday?). Is at least easier than multiple threads on here asking wether or not OT has sales...

Just some thoughts from me; be happy to see and hear other opinions on those


----------



## MarcusD (Jun 7, 2019)

Tagging system could make it easier to search for stuff. One thing about wiki is it feels some what chaotic despite having endless amounts of information. Be good to make the user experience really streamlined and easy to search for products. Maybe a compare products features? Like patches, size in gb, round robins etc... but that could fall either way


----------



## newman (Jun 7, 2019)

There is a piano VI spreadsheet you have permission to use on your free to access wiki. It is neither complete or accurate but has 183 VIs. Link to spreadsheet is here:

http://forum.pianoworld.com/ubbthreads.php/topics/2752919/digital-piano-master-sticky-thread.html

It was time consuming to compile; maybe took 40 hours+. Good learning experience and a couple of guys helped. Not sure how much people use it. It was designed for classical piano players who use VIs.

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


----------



## DSmolken (Jun 7, 2019)

newman said:


> There is a piano VI spreadsheet you have permission to use on your free to access wiki. It is neither complete or accurate but has 183 VIs. Link to spreadsheet is here:


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.

Also, 40 hours to make a list of 183 piano VIs - that's a great number to know. We can extrapolate that 100 brass VIs would probably take about 20 hours at this level of detail, so populating the whole wiki would probably be a couple hundred hours.


----------



## newman (Jun 7, 2019)

DSmolken said:


> Also, 40 hours to make a list of 183 piano VIs - that's a great number to know. We can extrapolate. . .


Getting the popular VIs is relatively quick. Finding the esoteric VI pianos took a majority of the time and effort.

So I would recommend first pass just getting the database up and running ASAP with the big VIs. Then a second pass later on for the smaller VIs.

To find VIs, the popular forum search bars were most effective. Also check the big US & Euro store internet sites. There are a few magazines that are searchable. And the VI company web sites obviously. Google is pretty useless these days as search results are just vendor placed; smaller search engines like duckduckgo are vastly better.

EDIT - It was fun to make the piano VI database. I learned a lot about the piano VIs available. And it was nice to visit all the music forums.


----------



## MatFluor (Jun 7, 2019)

I am working on V2 with a Database in the background which gives me some leeway in Programming the frontend.

It's more "corporate" in a way, based on a scaffold I made to built a couple of similar database-driven apps with


----------



## WhiteNoiz (Jun 7, 2019)

The spreadsheet definitely seems workable, but it will be harder to add multiple source links, linkbacks, categories, extended descriptions, videos, artworks, links to demos, narrowing down of categories, filtering etc. The site map/folder format seems more usable if you wanna go per developer, just go to the respective folder and see all separate categories without looking at an endless catalog of text. Assuming that's wanted. But as a reference list for general info it's fine. Maybe both? ...

Personally I prefer the wiki format. Linking to V1 again as it'll probably get buried, with the 5 test entries:
http://178.128.198.122/doku.php?id=libraries:start

http://178.128.198.122/doku.php?id=overview:families:strings (This is probably the most useful; full list, with links to individual pages)

Judging by how the individual pages turn out there I feel like a spreadsheet wouldn't be as rich. The wiki seems much more expandable. But it's the database format that needs to be worked out. Categories, necessary fields (Release: Sort By Year, Protection: Sort By Protection, Room: Short By Room, ...), tags etc. Maybe tying hard coded entries to tables etc. (Changing price in product page would also update the price field in grouped table) The categories that are there are a good start. It's probably better to decide what needs to absolutely be collected, then figure out how to sort it. For example, I added rooms, protection, section sizes etc. but those are not grouped under some category in the current version.

*Edit*: Dropping these for reference:
https://vi-control.net/community/threads/string-libraries-complete-list-of-section-sizes.71223/
https://vi-control.net/community/th...te-list-of-orchestral-string-libraries.55990/
https://vi-control.net/community/threads/string-library-list-release-years.43053/
https://vi-control.net/community/threads/glossary-of-vi-c-abbreviations.67167/


----------



## MatFluor (Jun 8, 2019)

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/


----------



## angeruroth (Jun 8, 2019)

No need for me to do any db modeling then 
@MatFluor Would it be possible to change the way instruments and mics are in the "Instrument Details" field ("Violins I (4), Violins II (3)...") to tabular fields?
Maybe like instrument/type/number (Violins/I/4, Violins/II/3, Strings/Hi/38, Violin/Solo/1...). It could appear like it does now in a single output field, but would allow to use the search function to find things like "Violins between 3 and 5" easily, and avoid string mismatches.


----------



## MatFluor (Jun 8, 2019)

angeruroth said:


> No need for me to do any db modeling then
> @MatFluor Would it be possible to change the way instruments and mics are in the "Instrument Details" field ("Violins I (4), Violins II (3)...") to tabular fields?
> Maybe pairs like instrument/type/number (Violins/I/4, Violins/II/3, Strings/Hi/38, Violin/Solo/1...). It could appear like it does now in a single output field, but would allow to use the search function to find things like "Violins between 3 and 5" easily, and avoid string mismatches.



Yes - But that'll be a bit complex I imagine since the number of instruments can change - from e.g. on "Solo Violin" to a pack like Amadeus or similar

Edit:
I mean the big guys like e.g. "Solo Flute, Flutes a2, Fluteas a3, Solo Clarinet....down to "Solo Contrabass"


----------



## angeruroth (Jun 8, 2019)

Maybe combining the lib table with 3 more could make it easier:

INSTRUMENT: ID, NAME (Violin, Viola, Cello, Bass, Strings...)
SECTION: ID, NAME (I, II, High, Low...)
LIBRARY_INSTRUMENT: ID, ID_LIB, ID_INSTRUMENT, COUNT, ID_SECTION

This tables would isolate instruments and sections from the general lib info, as the following example:

INSTRUMENT
0 Violin
1 Viola
2 Cello
3 Bass
4 Oboe
...

INSTRUMENT_TYPE
0 -
1 I
2 II
3 High
4 Low
5 Solo
6 A2
7 A3
...

LIB (the current table)
0 Tundra ...Other field values...
1 Symphonic Orchestra ...
...

INSTRUMENT_SECTION
0 0 0 38 3 (Tundra, 38 Violins in section High)
1 0 2 12 4 (Tundra,12 Cellos in section Low)
2 0 3 6 4 (Tundra, 6 Basses in section Low)
3 1 4 5 0 (SO, Solo Oboe)
...


----------



## JEPA (Jun 8, 2019)

is there a "feed function" for the changing prices in the database? or must they be changed manually?


----------



## Mason (Jun 8, 2019)

Fantastic to see how this is developing!


----------



## berto (Jun 8, 2019)

would it be just for orchestral stuff... or all sample libraries?


----------



## MatFluor (Jun 8, 2019)

berto said:


> would it be just for orchestral stuff... or all sample libraries?



Ideally all. Orchestral has just a ton of Variety, but the current philosophy is to be able to have a full thing - for Synths like Omnisphere libraries, Zebra, ORchestral, Guitars....


----------



## DSmolken (Jun 8, 2019)

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 (Jun 8, 2019)

angeruroth said:


> table with 3





MatFluor said:


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



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?


----------



## dflood (Jun 8, 2019)

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?


----------



## Dive (Jun 8, 2019)

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


----------



## dflood (Jun 8, 2019)

newman said:


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



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.


----------



## MatFluor (Jun 8, 2019)

dflood said:


> 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 (Jun 9, 2019)

DSmolken said:


> 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 (Jun 9, 2019)

fretti said:


> 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 (Jun 9, 2019)

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.


----------



## Mason (Jun 9, 2019)

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 (Jun 9, 2019)

Mason said:


> 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 (Jun 9, 2019)

angeruroth said:


> 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 (Jun 9, 2019)

angeruroth said:


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



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.


----------



## newman (Jun 9, 2019)

DSmolken said:


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


----------



## angeruroth (Jun 9, 2019)

MatFluor said:


> The list as "wiki" part is already updateable


Sorry, yes, typing too quickly there. I meant need to fill the list.


----------



## dflood (Jun 9, 2019)

MatFluor said:


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

Organize the ideas into some sort of order (document).
Come to some sort of consensus regarding which ideas/details to move forward with.
Identify the volunteer development team and assign duties.
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.
Create the database
Create the user interface
Test against a small but diverse set of data samples (libraries)
Revise/retest iterations until stable.
Find an on-line home for the application and data. Cost?
Decide on user access restrictions: Who can use, who can edit.
Roll out V1.0 for initial data input.


----------



## dflood (Jun 9, 2019)

newman said:


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


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 (Jun 9, 2019)

dflood said:


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


----------



## dflood (Jun 9, 2019)

WhiteNoiz said:


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


----------



## MatFluor (Jun 9, 2019)

dflood said:


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


----------



## dflood (Jun 10, 2019)

MatFluor said:


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


----------



## zigzag (Jun 10, 2019)

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.


----------



## ThomasNL (Jun 10, 2019)

zigzag said:


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



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.


----------



## WhiteNoiz (Jun 10, 2019)

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


----------



## MatFluor (Jun 10, 2019)

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.


----------



## newman (Jun 10, 2019)

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.


----------



## zigzag (Jun 10, 2019)

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.


----------



## dflood (Jun 10, 2019)

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.


----------



## MatFluor (Jun 10, 2019)

dflood said:


> 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


----------



## DSmolken (Jun 10, 2019)

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.


----------



## dflood (Jun 10, 2019)

DSmolken said:


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


----------



## dflood (Jun 10, 2019)

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


----------



## zigzag (Jun 10, 2019)

I did a quick search what open source project might fit the requirements of this wiki. More specifically, what wikis or wiki extensions have support for _structured data_. Here are some I found:

Semantic MediaWiki (MediaWiki)

Foswiki

Cargo (MediaWiki)

WikiDB (MediaWiki)

Wikibase (MediaWiki)
Structured Data Plugin (DokuWiki)

Strata Plugin (DokuWiki)

struct Plugin (DokuWiki)
EDIT: Added some more


----------



## angeruroth (Jun 10, 2019)

Nice! I'll read the full doc tomorrow, but from what I've seen it is very thorough.


----------



## WhiteNoiz (Jun 10, 2019)

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_*)*

*Changelogs/maintenance updates - ? (Simple description box, *_maybe subtext to Release, this could be relevant for dev consistency/maintenance/expansions/bugs/support_*) - Release version could fall under this (*_Text with all iterations, latest entry marked as current_*)*

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


----------



## MatFluor (Jun 10, 2019)

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


----------



## bigcat1969 (Jun 10, 2019)

Ah come on and include free stuff. A couple 'real' companies are giving away some pretty good instruments. But you knew I would post that didn't you?


----------



## zigzag (Jun 11, 2019)

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

http://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_ | ?____________ |
...


----------



## MatFluor (Jun 11, 2019)

zigzag said:


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



Yes, I see the point. But I think that this would grow into a unmaintainable beast. For entry *and* for viewing as well.

In that mindset - a library is a collection of instruments, where one instrument alone can have tons of variations (different round robins for articulations, different available notes in some as well, CC1 vs Velocity and whatnot). I feel that this kind of extreme details could be added later on, as kind of separate "detail view". If you would add it right there, some libraries would be a solid minutes of scrolling (think Hollywood strings articulation lists).

So I would say - the shotgun approach of "Yeah, there's Bartok in this library" is good for the overview, and details "Contrabasses don't have Bartok, but The others have, but only 2 mic positions and one octave less...." can be retrofitted later as part of an "expansion" of the wiki


----------



## Lindon (Jun 11, 2019)

axb312 said:


> Yea that could be misinterpreted....


and gamed...


----------



## Lindon (Jun 11, 2019)

MatFluor said:


> I am working on V2 with a Database in the background which gives me some leeway in Programming the frontend.
> 
> It's more "corporate" in a way, based on a scaffold I made to built a couple of similar database-driven apps with


hmm, I'm starting to like this a lot less than I did. The title of this thread is "A Sample Library wiki" not "An Orchestral Sample Library wiki" - the current implementation seems very very focused on orchestral libraries...I appreciate my people will want to know all the good stuff about orchestral libraries, but speaking as an independent library developer I'm already beginning to see this as squeezing me out.


----------



## zigzag (Jun 11, 2019)

MatFluor said:


> Yes, I see the point. But I think that this would grow into a unmaintainable beast. For entry *and* for viewing as well.
> 
> In that mindset - a library is a collection of instruments, where one instrument alone can have tons of variations (different round robins for articulations, different available notes in some as well, CC1 vs Velocity and whatnot). I feel that this kind of extreme details could be added later on, as kind of separate "detail view". If you would add it right there, some libraries would be a solid minutes of scrolling (think Hollywood strings articulation lists).
> 
> So I would say - the shotgun approach of "Yeah, there's Bartok in this library" is good for the overview, and details "Contrabasses don't have Bartok, but The others have, but only 2 mic positions and one octave less...." can be retrofitted later as part of an "expansion" of the wiki


I agree, listing all articulations by default certainly isn't a good idea. Maybe it could be done in a similar fashion to how Wikipedia handles TV series. One page is a description of the series and another page lists all episodes for that series.

Structured details can be pushed to a later phase of the wiki. Goal of the first phase could be just to add all available sample libraries with a basic description and links to an official website and to a manual.


----------



## MatFluor (Jun 11, 2019)

Lindon said:


> hmm, I'm starting to like this a lot less than I did. The title of this thread is "A Sample Library wiki" not "An Orchestral Sample Library wiki" - the current implementation seems very very focused on orchestral libraries...I appreciate my people will want to know all the good stuff about orchestral libraries, but speaking as an independent library developer I'm already beginning to see this as squeezing me out.



It shouldn't be "Orchestral only" - it should concern all samples. Orchestral just boosts the most variety, and the people here work mostly with those - so the talk is about that currently. So, for other (non-orchestral) sample libraries, the input is very welcome - because that also weighs in in the "proper middle of the road for everybody".

Apart from that - the backend (and current frontend) is not biased towards orchestral. It happens to have two Orchestral sample libraries in there - But I could very well throw an Orange Tree guitar in - it shoudl essentially work the same.

Do you have other concern that I'm not seeing/addressing here?


----------



## fretti (Jun 11, 2019)

Lindon said:


> hmm, I'm starting to like this a lot less than I did. The title of this thread is "A Sample Library wiki" not "An Orchestral Sample Library wiki" - the current implementation seems very very focused on orchestral libraries...I appreciate my people will want to know all the good stuff about orchestral libraries, but speaking as an independent library developer I'm already beginning to see this as squeezing me out.


It seems to me that many (most?) users on VI are using orchestrals libs and writing mainly with them. So I think it's not that we want it to be focused only on those libraries, it's just they're well known by many and therefor the first coming to mind when searching for examples
(At least that's what I think, can't say to what extend that's actually true)


----------



## Mason (Jun 11, 2019)

Lindon said:


> hmm, I'm starting to like this a lot less than I did. The title of this thread is "A Sample Library wiki" not "An Orchestral Sample Library wiki" - the current implementation seems very very focused on orchestral libraries...I appreciate my people will want to know all the good stuff about orchestral libraries, but speaking as an independent library developer I'm already beginning to see this as squeezing me out.



It should and will be for all sample libraries. Perhaps it’s a good idea for the developing process to add libraries from different categories to make sure the wiki page has been build for for any style?


----------



## dflood (Jun 11, 2019)

Lindon said:


> hmm, I'm starting to like this a lot less than I did. The title of this thread is "A Sample Library wiki" not "An Orchestral Sample Library wiki" - the current implementation seems very very focused on orchestral libraries...I appreciate my people will want to know all the good stuff about orchestral libraries, but speaking as an independent library developer I'm already beginning to see this as squeezing me out.


I for one am not particularly interested in orchestral libraries at all. But I think we’ve been focusing on the big orchestral libraries because the assumption, right or wrong, is that they are the most difficult to characterize, particularly in any level of detail, since they are multi-instrument, multi-articulation products.

We should probably now attempt to characterize a few real libraries of various genres according the the criteria that has been suggested to see what a full record might look like. This could potentially be done in a spreadsheet for starters, or perhaps @MatFluor is already expanding his V2 prototype?


----------



## dflood (Jun 11, 2019)

zigzag said:


> I agree, listing all articulations by default certainly isn't a good idea. Maybe it could be done in a similar fashion to how Wikipedia handles TV series. One page is a description of the series and another page lists all episodes for that series.
> 
> Structured details can be pushed to a later phase of the wiki. Goal of the first phase could be just to add all available sample libraries with a basic description and links to an official website and to a manual.


Naming every instrument or section, and then all the articulations applicable to them may be a bridge to far. Even the orchestral developers tend to group their instruments into ‘Strings”, ‘Horns’, etc, and then list the articulations by group. I’d be satisfied with a list of the instruments/sections, and a separate list of articulations. Most of us could figure out that a ‘rip’ would not apply to the strings and ‘pizzicato’ would not apply to horns. At some point, if we are doing a deep dive with our research, we have to transition to the developer’s published info and manuals anyway.


----------



## JEPA (Jun 11, 2019)

bigcat1969 said:


> Ah come on and include free stuff. A couple 'real' companies are giving away some pretty good instruments. But you knew I would post that didn't you?



I volunteer for "free stuff" Team. When the spreadsheet is ready to use everybody can work independently and add information like in Github... oh! Maybe we could make this project a Github project?

EDIT: anyway I'm all in for the "free stuff" team


----------



## dflood (Jun 11, 2019)

MatFluor said:


> It shouldn't be "Orchestral only" - it should concern all samples. Orchestral just boosts the most variety, and the people here work mostly with those - so the talk is about that currently. So, for other (non-orchestral) sample libraries, the input is very welcome - because that also weighs in in the "proper middle of the road for everybody".
> 
> Apart from that - the backend (and current frontend) is not biased towards orchestral. It happens to have two Orchestral sample libraries in there - But I could very well throw an Orange Tree guitar in - it shoudl essentially work the same.



I entered some new instruments (guitars) into the instrument list in your current V2 prototype and it worked fine. I also expanded the Families/Groups list with Solo Instrument, Choir, etc. I should try entering a complete non-orchestral library but I’m sure it will work just fine. I guess the intent is to try to select terms from a list wherever possible, and if there isn’t an existing term that describes the library type, instrument, or articulation, then we can add a new term to the appropriate list, after which it will always be selectable. Seems pretty workable to me. Even when there are a lot of articulations it seems to be a simple matter of selecting them from the list. I like that approach because it preserves data integrity rather than everyone typing or pasting words into a general text field. It’s looking good!


----------



## newman (Jun 11, 2019)

I entered 4 piano libraries in the v2 prototype. Couldn't leave sample rate or bit rate blank. Thumbnails look a bit wonky.


----------



## MatFluor (Jun 12, 2019)

newman said:


> I entered 4 piano libraries in the v2 prototype. Couldn't leave sample rate or bit rate blank. Thumbnails look a bit wonky.



Yes, currently Sample rate and Bit Depth are enforced - I'll add a "unknown" option. I hardcoded those 

yes, Thumbnails need some work, it's just a quick and dirty cut-to-size.

Thanks for entering other stuff to see how the worklow fits (both prior posters!). It can show what a proper middleground could be.


I would like to remind everyone that this V2 is not a "deployed and ready to fill" thing, but a prototype that can be made into the actual thing (unless there is something deeply wrong with the approach). Meaning that a lot of the Data some people entered is likely to be deleted if changes in the Database are needed (like I prepared on my local version that an additional "last changed" field gets automatically filled on edits/additions). Still feel free to give it a testdrive, but make sure you know that the data won't likely be taken over. I'm working on that though. I am also working on some idea of conditionals - meaning that e.g. if a Piano is entered, that an additional "pedaling" field might pop up, or when a guitar comes in, a different field "fingerstlye/picked" for example gets visible. Trying to keep the whole UI a bit cleaner. That said - the whole visuals are from the scaffold and absolutely adjustable. Although - wich such large forms, I might need some frontend designer to make it pleasing for entry. I'm a dev/researcher/composer in the end - so it will look like that until I spend some time on making it "beautiful"


----------



## dflood (Jun 12, 2019)

@MatFluor

I just entered a library from Indiginus. It went pretty smoothly for the most part with a couple of exceptions:

For Bit Depth, Release Date and Resale, if we can't find that information, should we have a blank or 'unknown' option?
I tried to enter a link to the official video but got an error message on save that the field can't be more than 50 characters. I deleted the entry and resaved, then tried a shorter URL but the field now seems to be corrupted
Link to product page should probably be a hyperlink (if possible) that opens up a new page/tab.


----------



## MatFluor (Jun 12, 2019)

dflood said:


> @MatFluor
> 
> I just entered a library from Indiginus. It went pretty smoothly for the most part with a couple of exceptions:
> 
> ...



Thanks!

1. Yes, I prepared some reasonable default ("No information given"). Will update soon.
2. Yeah - normally YouTube links shouldn't be longer. Little mishap there - due to the rendering in the background, it's currently made for YouTube URLs only. - EDIT: I see - I corrected the link. The thing is that I have not thought about the YT-shorturl scheme xD I corrected the video - update do cover that coming shoonish
3. Yes, coming up.

I'm currently looking at Database migration or change so I don't loose all the info already in. I know how, but I want to make my life a bit easier


----------



## MatFluor (Jun 12, 2019)

Alright - corrected that. Still Youtube only - but at least know youtu.be link will be recognized correctly.

The other points as well (Hyperlinks, some defaults except for dates). Also added some Pseudo-Buttons for Articulations and Instruments to just be able to click on it to see an overview of that (like - you look at one library and say "Show me all Libraries with a Mandolin" - you can do that now right from the first library on).


----------



## newman (Jun 12, 2019)

Have issues searching the Piano VI database with special European characters (eg. the ö of Bösendorfer).


----------



## MatFluor (Jun 12, 2019)

newman said:


> Have issues searching the Piano VI database with special European characters (eg. the ö of Bösendorfer).



It works (Renamed one of the pianos by changing o to ö in the "Synchron Cöncert D-274 (Standard)"). Maybe you didn't choose the right filters?


----------



## newman (Jun 12, 2019)

MatFluor said:


> It works (Renamed one of the pianos by changing o to ö in the "Synchron Cöncert D-274 (Standard)"). Maybe you didn't choose the right filters?


Sorry I meant we had those types of issues in our excel spreadsheets. I didn't think of checking the v2 database here (because I didn't sleep last night lol).


----------



## JEPA (Jun 12, 2019)

a question: it has started? where to insert information? could the OP edit OM with instructions? thanks


----------



## Lindon (Jun 12, 2019)

MatFluor said:


> It shouldn't be "Orchestral only" - it should concern all samples. Orchestral just boosts the most variety, and the people here work mostly with those - so the talk is about that currently. So, for other (non-orchestral) sample libraries, the input is very welcome - because that also weighs in in the "proper middle of the road for everybody".
> 
> Apart from that - the backend (and current frontend) is not biased towards orchestral. It happens to have two Orchestral sample libraries in there - But I could very well throw an Orange Tree guitar in - it shoudl essentially work the same.
> 
> Do you have other concern that I'm not seeing/addressing here?


well my concerns are we are seeing suggestions for a set of attributes focused around orchestral libraries - and I dont see your comments addressing that.

To be specific:

Instrument Details (Section sizes, Brands...)

-- what would this be if its not an orchestral Library?

Articulations

-- a select-able list - that makes no sense for (say) a synth library

Mic Positions

-- again if (say) I'm sampling some hand-crafted set of presets from my Moog and I'm DI-ing this into my Audio interface - then this makes no sense at all...

So to stop me being Jonny-negative any further perhaps we can re-name these:


Mic Positions - should really be "Capture System" (so you can say if you used 27 different mics in Air Studio -or if you just DI-ed it into your Lynx audio interface.

Articulations, might be Audio Variants - so if you have articulations you can list them or if say you've recorded every one of your Synth patches dry and thru some esoteric foot-pedal you can name these too.


----------



## newman (Jun 12, 2019)

Lindon said:


> Mic Positions - should really be "Capture System" (so you can say if you used 27 different mics in Air Studio -or if you just DI-ed it into your Lynx audio interface.


I think with Piano VIs, the left and right mics are typically counted as one mic position. A mono mic would also be counted as one mic position. So a piano VI claiming 6 mic positions available might actually have 6x2=12 as they may be in stereo pairs.

Rare cases where marketing speak is underselling.


----------



## MatFluor (Jun 12, 2019)

Lindon said:


> Instrument Details (Section sizes, Brands...)
> 
> -- what would this be if its not an orchestral Library?



For example for Synth that could be the oscillators (Sine, Triangle, Saw) together with stuff like "Adjustable LFO" and whatever.



Lindon said:


> Articulations
> 
> -- a select-able list - that makes no sense for (say) a synth library



Articulations are essentially playing style - yes, that wording is Orchestral (or acoustical instrument) specific. For a synth that could be the basic preset (Bass, Brass Pad or whatever)



Lindon said:


> Mic Positions
> 
> -- again if (say) I'm sampling some hand-crafted set of presets from my Moog and I'm DI-ing this into my Audio interface - then this makes no sense at all...



Yes, this is also Orchestral specific, since many orchestral people care about how many mic positions are available, and maybe which ones.


Look, I totally see your points, but it absolutely not like "this is it, roll with it". This is intended as an ideal middle ground for everything. Synths are definitely a special breed with their own deep complexity that they have inherently. And since I'm not an expert on Synth (apart from using some semi-modular and modulars - very amateur of course), I greatly appreciate your input. And it's important - because I don't want to scare non-orchestral people off. Easiest to implement are other acoustical instruments - and that currently works well enough. But for Synths maybe a separate category would make sense - like dividing the whole thing into "Acoustical incl Modeling" and "Synth" (please say if I ignorantly left something very important out).

So that could very well be a separate thing - and instead of "list Library", you might see two entries "List Acoustical instrument based" and "List Synth-based". Don't hit me on the appropriate terms, I'm not a native speaker 

What do you (and the others here) think of that approach? Right now in my overheated (due to the temperature of the air) head sees this as a nice compromise. The "Developers" wouldn't change, but maybe the "Articulations" and "Instrument" Metadata parts. Create the same current "idea" that is implemented for acoustical instruments adapted for synths.


----------



## Mason (Jun 12, 2019)

JEPA said:


> a question: it has started? where to insert information? could the OP edit OM with instructions? thanks



Yes, if @MatFluor can give me the instructions I’ll make the edit.


----------



## MatFluor (Jun 12, 2019)

It hasn't started yet, it's still in development and doing some feedback stuff


----------



## dflood (Jun 12, 2019)

@MatFluor @Lindon
I think these are the general types of sound libraries we are most interested in (have I missed any?) and we should experiment by entering some libraries from all types. It's the best way to find out what fits and what doesn't.

Orchestral - solo and ensemble instruments and choirs
Chromatically sampled / physically modelled libraries of musical instruments of all types
Percussion instruments
Vocal libraries
Soft synths
Hybrid libraries
Loop and phrase-based libraries
Synthesizers may be a bit of an outlier when it comes to shared attribute classes with primarily sample based libraries, but here’s some ideas on how we might be able to handle some of those details.

*Product Family (Type)*: Synthesizer

*Subtype(s): *Subtractive; FM; Phase Distortion; Physical Modelling; Sample Based; Hybrid; Hardware Emulation, etc (could all of these potentially apply to a single product? If that's the case the field would need to allow multiple selections.

*Articulations*: I wouldn’t change this field. If it doesn’t apply to a library or library type, just leave it blank.

*Synth Details*: If there are a number of synth-specific attributes (arpeggiators, granular synthesis, etc.) that are common points of distinction or comparison with other synths then maybe we should create a separate field similar to the articulations field? Not sure what to call it. If not, then I guess the only thing is for the editors to to try to provide these sorts of details in the *Instrument* *Details* text field.

*Keywords:* We have identified a number of important, recurring, but often genre-specifc keywords such as: Divisi, Half-pedalling, Chord Mode, Strumming, Arpeggiators, etc,. We could maybe use a catchall field for selecting any and all terms that apply and for creating new ones? This would help with searching and filtering.

Perhaps we should change the name of the *Sampler* field to: *Required* *Sampler/Synth/Plug-in*? Some products also require a minimum version of the host plug-in i.e. Kontakt 6. Should we also add a *Minimum* *Version* sub-field?

Some products like Audio Modelling, include their own host plug-in (SWAM engine) with each product. Should we add an ‘*Included with Library*’ selection to the ‘*Required Sampler/Synth Plug-in*’ field?
Edit: Ignore this. I didn’t think to scroll down. The ‘Other or Custom’ selection is fine.


----------



## dflood (Jun 12, 2019)

@MatFluor Another wrinkle: perhaps the ‘Required Sampler/Synth’ field needs to be multiple choice since some libraries are offered in multiple formats (Kontakt, EXS, etc.) ?


----------



## WhiteNoiz (Jun 12, 2019)

MatFluor said:


> What do you (and the others here) think of that approach? Right now in my overheated (due to the temperature of the air) head sees this as a nice compromise. The "Developers" wouldn't change, but maybe the "Articulations" and "Instrument" Metadata parts. Create the same current "idea" that is implemented for acoustical instruments adapted for synths.



It could be set separately for synths, have a mirror field for synths. For example, the Articulations field could be renamed to Presets in a separate database or just use the same field and rename to "Arts/Presets". Maybe a totally separate "Patches/Presets" field that works for both. And then maybe articulations for orchestra only or for specifics. In synths it could be the same, orchestral could have patches in patches list and then in articulations the same with details. So, it'd be like:

Patches
Violins > 01. 1st Violins Pizz (...)
Bass > 01. Moog Destroyer (...)

Articulations
Violins > 01. 1st Violins [Pizz] (4x layers, 5x RR, 3 mics, ...)
Bass > ? (Empty or say responds to velocity or mod filter or whatever, leave up to editor)

And here it becomes simpler and better for me to have patches and arts as text fields, instead of preset, pickable boxes/options. You can still search for text (a search for bartok could return bartok text is arts field). Tags could be used as filtered arts or just keep them for style or brands (rock, steinway, dunno...). Tags are a bit of a wildcard. They could still be auto-filled when typing.



dflood said:


> *Minimum* *Version* sub-field



That looks like an easy yes to me.

-

*Instrument details* could be for section sizes only or general categories with number of patches in synths (Bass [20], Lead [30], etc.). Or it could be in patches/presets or arts, like:
- Violins 1 [16 / 8/8]:
01. Violins 1 Pizz (...) {} 01. Violins 1 Pizz (3x dyn, 4x rr, ...)

- 

Another idea: Maybe let user define for how long to lock editing for specific page (say up to 2 hours or something). Maybe someone can stay for 1 hour and edit or 3 minutes, and time remaining could be visible. Then the page could be released as soon as user is done or locked again. Don't know how viable that is. Could be better at least in the beginning. Maybe it's better to just auto-lock to last IP or account for a set time. Curious to see the actual traffic...


----------



## Lindon (Jun 13, 2019)

dflood said:


> @MatFluor @Lindon
> I think these are the general types of sound libraries we are most interested in (have I missed any?) and we should experiment by entering some libraries from all types. It's the best way to find out what fits and what doesn't.
> 
> Orchestral - solo and ensemble instruments and choirs
> ...



This and @MatFluor 's suggestions keep narrowing the criteria to stuff you know about. If I took the same approach I'd narrow it to the criteria I know about, what I'm saying here is this is the wrong way to do this I think. Just picking "synth" as a "thing to fix" is worrying - but anyway whilst we are here:

Lets just look at Sub-type - there are as many synthesis approaches as there are developers - waveguide wavetable Dynamic Oscillator Sequencing the list goes on...

and this in Synth Details

" If not, then I guess the only thing is for the editors to to try to provide these sorts of details in the *Instrument* *Details* text field."

- yeah compromise - and I assume a less searchable area.


Look let me be plain:

Please STOP drawing up list of attribute values, it wont work because you wont cover everything.
So a guideline - if you can think of the data entry field as a drop-down menu then you've failed.

Define attributes sure, but then allow each of these to be a free entry key-word. I understand that then its a free for all - and some developer can add some silly keyword - but really why would any of us do that? If we have a subtractive/Hybrid synth we'd just say "Subtractive" and "Hybrid"

I suggest we take a lead from KVR Audio - where instruments are added all the time and allow each field to be a keyword and also provide some sort of existing-keyword-search so I can see if the key-word I'm looking for is already present and/or pick from a list of existing keywords.


----------



## dflood (Jun 13, 2019)

Lindon said:


> Please STOP drawing up list of attribute values, it wont work because you wont cover everything.
> So a guideline - if you can think of the data entry field as a drop-down menu then you've failed.
> 
> Define attributes sure, but then allow each of these to be a free entry key-word. I understand that then its a free for all - and some developer can add some silly keyword - but really why would any of us do that? If we have a subtractive/Hybrid synth we'd just say "Subtractive" and "Hybrid"
> ...



I think that is more or less the intention and the route that is being taken, albeit the current V2 prototype is lagging a bit behind in this capability. If I understand correctly, @MatFluor is using a database back end so he has to specifically provide the data entry capabilities for users to add any terms or phrases that don't already exist. There are significant advantages to doing it this way rather than free text entry as in a wiki. However, nothing precludes a search filter from looking within all fields in all records in the database. There is, or will be one or more catchall text fields where I presume anything can be entered. No reason why these can't be searchable as well.

Currently the ability to add your own terms is only available in a few fields and the entry method is bit awkward, but give @MatFluor a chance! It's not as straightforward as a wiki, but there are big advantages later on for searching and filtering.

Frankly, in my own experience, the KVR site doesn't work all that well for my searches. Either that, or the data is very incomplete.


----------



## newman (Jun 13, 2019)

Dropdowns can speed data entry and reduce errors for common fields. Not everything needs to be a dropdown but they can be helpful IME.


----------



## dflood (Jun 13, 2019)

newman said:


> Dropdowns can speed data entry and reduce errors for common fields. Not everything needs to be a dropdown but they can be helpful IME.


Even better when they filter the list as you are typing and allow you to enter a new word in place if one doesn't exist (provided that's the intent).


----------



## Mason (Jun 13, 2019)

Great work so far!

I think it’s a good idea to not make this too complicated. In the “Summary” box, I suggest having only fields that would apply to any library, synth etcetera. So “Instruments” should be removed in my opinion as it would not work that well with a synth or libraries like Albion One or Ethno World with a few hundred instruments.

In the “Detail” section, may I suggest changing from “instrument details” to “library details” or “content”? This would work better with synths or a library with just a flute.

Then I suggest not having a required field for “articulations” for the same reason. It doesn’t work well with a lot of percussion libraries either. So it could be included in the “library details/content” field for the libraries this applies to and for those who have the time to enter all that info. “Mic postitions” could perhaps also be a non-required part under “details/content”.

So, make it a bit less complicated and more universal and with that also invite to a bit more creativity for those who want to add libraries.


----------



## Mason (Jun 13, 2019)

Original post updated.


----------



## chillbot (Jun 13, 2019)

There needs to be an entry for the size of the lali drum being sampled. And also for the size of the stick being used on the lali. And a field to sketch in any carvings that might be carved into the lali. And also for the inebriation level of the lali performer. Thanks.


----------



## dflood (Jun 13, 2019)

chillbot said:


> There needs to be an entry for the size of the lali drum being sampled. And also for the size of the stick being used on the lali. And a field to sketch in any carvings that might be carved into the lali. And also for the inebriation level of the lali performer. Thanks.


To say nothing of Frog Guiro dimensions. I fully expect a drop down under Guiros/Frogs/Sizes


----------



## WhiteNoiz (Jun 14, 2019)

May I suggest an appetizer before that articulation list? 

Still, should probably have filters for what is deemed more universal or necessary, the ultra detail should be left to editors I feel. Not sure how to work it out or limit it other than starting to input some data and see what feels off.

(Will need all those extra text fields to make a proper estimation. Fully edit a handful of libs and see what works. Then can figure out what to consolidate/skip/remove/...)


----------



## MatFluor (Jun 14, 2019)

Well
The original V1 Wiki (based on a wiki engine) is still there. You can free ignore the input field and just put stuff in there to test out. V2 seems not to hit the right marks and sparks a lot of discussion that often go against a structured approach.


----------



## zigzag (Jun 14, 2019)

What about separate input forms (and database structure) for sample libraries and synths? They are quite different beasts, and trying to fit both types into the same universal structure will only hurt both. 

Synths focuses more on on type of sound generators, filters, modulations, step sequencers etc. While sample libraries focus on the number and quality of recorded sounds (articulations). 

Structured approach will enable much better searching and filtering capability compared to more flexible text only wiki. Each has its own pros and cons.


----------



## MatFluor (Jun 14, 2019)

zigzag said:


> What about separate input forms (and database structure) for sample libraries and synths? They are quite different beasts, and trying to fit both types into the same universal structure will only hurt both.



I asked on peoples opinions on that - but if I read it somewhat right, it wasn't hitting the right mark.


----------



## zigzag (Jun 14, 2019)

MatFluor said:


> I asked on peoples opinions on that - but if I read it somewhat right, it wasn't hitting the right mark.


In all cases there will be some compromises. What are the downsides supposed to be of this separation? I don't really see them, except that it means more work to develop.


----------



## dflood (Jun 14, 2019)

Well, how about a semi-structured approach? I still don’t think a plain wiki is going to be all that useful due to the haphazard way people will enter information, but it could certainly be done that way. A lowest common denominator approach will likely yield the least useful results. May as well just use Google search. The problems with a structured approach tend to diminish if people can easily enter their own terms as needed, ignore any fields that are non-applicable, and have the ability to enter or copy/paste any additional information as required. Many developers are trying to include unique or novel features that will defy standard categorization.


----------



## WhiteNoiz (Jun 14, 2019)

dflood said:


> Well, how about a semi-structured approach? I still don’t think a plain wiki is going to be all that useful due to the haphazard way people will enter information, but it could certainly be done that way.



That's what I'm trying to get at and figure out. It seems it's hard to decide on what should be hard-coded and what should be freely input (albeit, maybe with some guidelines or a format that will naturally be adopted along the course). Should "http://178.128.198.122/librarywiki/articulationview/show/1 (pizz)" be a field? Admittedly, this is cleaner to navigate and you'd need to guess what to search for if there wasn't a list, but it's harder to decide what to catalog and/or it could get bloated. A "patches/arts" simple text seems usable. Different devs might use different names and we're conflating patches names with playing styles. In that sense, maybe at least having both plain text and tag/filter/category would prove useful in helping separate them. Is an automated table of all pizz arts needed or would it suffice to do a text search and just see what libraries come up? Middle-of-road seems to me to be that. Categorize some general info or similar groups, then leave details more loose. Number of RRs could be seen in manual or text info. Problem is, do people actually want to compare patches based on RRs in an automated table? It's probably wise to stick with database structure and add text fields at least. Ugh... 

Here, in V1, not all attributes are shared, for example (Kontakt list can't link to string category directly, and you may also want to sort by both price and type):
http://178.128.198.122/doku.php?id=overview:families:strings
http://178.128.198.122/doku.php?id=overview:samplers:kontakt_player

While in V2 it's easier to get to the nitty gritty by filtering:
http://178.128.198.122/librarywiki/libraries/list/

(You can also see that, for example, Sampler is not filtered/grouped in V2, while in V1 you can list all "Kontakt Player" libraries)

It probably just needs more fields added, so I can try doing a closer copy of the V1 extra info (assuming it's wanted). See, for example:
http://178.128.198.122/librarywiki/libraries/show/1
vs
http://178.128.198.122/doku.php?id=libraries:spitfire_audio:strings:chamber_strings (Like abbreviations, extra videos, links, sources, etc.)

Small note: Seeing numbers in link instead of words is also kinda strange (although maybe mostly aesthetic if anything).

If you look more closely, one category is already "Violincelli" in V2 which is not really typical. Is there a hard and fast way to replace it with "Cellos", "Celli", "Violoncellos", whatever... Should all these exist and be separately filterable? Would probably be better to make a list and start striking from it, figure out groupings and stuff (what should be text or tag; I think I integrated most stuff from the dropbox text in that).


----------



## DSmolken (Jun 14, 2019)

Having dealt with a wiki where all the information was migrated to a different format twice this year already, I can say it's a pain but not a disaster, when there are only a few hundred entries.

Having a vague structure, seeing what kind of information people enter for the first few weeks, and then building a more set structure to around the data that people actually entered, would be my recommendation. That would mean cleaning up things like "cellos" and "celli" at some point - will take work, but that's probably easier than trying to imagine all such possibilities in advance.

Also being able to live with inconsistent levels of detail should be fine. I mean, if for a library with hundreds of instruments somebody just enters "hundreds of Persian instruments" in the instrument field once, that's still information useful to readers, though having the instruments listed individually would be better. Having full detail about every instrument probably isn't as important to somebody making a purchasing decision about a violin, where detail would matter.


----------



## MatFluor (Jun 14, 2019)

Yes, a Wiki need a ton of curation. All the crossreferencing and lists wass essentially put in by me through the entry form.

The Number in the links are just because this hasn't a domain, it's the pure address of the server it runs on currently.


----------



## MatFluor (Jun 14, 2019)

DSmolken said:


> That would mean cleaning up things like "cellos" and "celli" at some point



In a database it's just a simple renaming mainly, unless people start to make tons of alternate spellings - then it gets tedious, but not unmanageable.

But The opinion have started to divert extremely, and I propose that those who know different libraries sit together and create something that would be "the right thing". You can freely use my prototype as a jumping off point - I prepared it with the best of intentions, even if it maybe didn't come off as that.


----------



## WhiteNoiz (Jun 14, 2019)

https://docs.google.com/document/d/1ARPXuAdN4q2LppqZwF6bcp35k6YSpyQd3jlNHWzFBqQ/edit

Cleaner list from before, based on V2. (Editable)

Will try to make image for what I'm thinking based on that (based on V2).

*Edit*, pic:
https://i.postimg.cc/1m1QGGVw/Libwikiadd.jpg


----------



## dflood (Jun 14, 2019)

MatFluor said:


> In a database it's just a simple renaming mainly, unless people start to make tons of alternate spellings - then it gets tedious, but not unmanageable.
> 
> But The opinion have started to divert extremely, and I propose that those who know different libraries sit together and create something that would be "the right thing". You can freely use my prototype as a jumping off point - I prepared it with the best of intentions, even if it maybe didn't come off as that.


I think you did a really great job on the prototypes and you got them up and running very fast! I’d encourage you to keep working on the V2 if there is still interest out there. But I don’t blame you if you want to take a break, particularly as some of the comments have been a bit hypercritical. These are early prototypes meant to test assumptions. It’s important to figure out what works and what doesn’t. They have been very helpful!


----------



## newman (Jun 15, 2019)

Frankly, I didn't receive much help with the Piano VI database. So I find with these free crowd projects, either you just do it or it doesn't get done.


----------



## zigzag (Jun 16, 2019)

dflood said:


> I think you did a really great job on the prototypes and you got them up and running very fast! I’d encourage you to keep working on the V2 if there is still interest out there. But I don’t blame you if you want to take a break, particularly as some of the comments have been a bit hypercritical. These are early prototypes meant to test assumptions. It’s important to figure out what works and what doesn’t. They have been very helpful!


Most people critiquing are probably interested in the product, they just have different ideas/vision what wiki should look like. And depending on the kind of work they do, what they need/are looking for is different. 

I think everyone appreciates MatFlour's hard work and prototypes, as they are really helpful in figuring what works and what doesn't work. Critique at the this stage is meant to give feedback and guide the development in the right direction. The worst thing is committing to a project and figuring out it's not really what people need _after _it's done. Critique is an essential part of prototyping phase. Design is hard. 

Maybe we just don't say it enough, but thank you MatFlour and everyone else contributing!


----------



## zigzag (Jun 16, 2019)

WhiteNoiz said:


> That's what I'm trying to get at and figure out. It seems it's hard to decide on what should be hard-coded and what should be freely input (albeit, maybe with some guidelines or a format that will naturally be adopted along the course). Should "http://178.128.198.122/librarywiki/articulationview/show/1 (pizz)" be a field?


 
Hard-coding things like that would result in too rigid system that would require a lot of maintenance.

For different spelling a search system that would find similar words might help. Or system of related/connected tags. Both "cellos" and "celli" would be marked as related tags. Filtering/searching would then also return related tags. I don't know if any plugins exist for such functionality, as developing something like that sounds like way too much work.

EDIT: Another thing that could be done, are free text fields + wiki guidelines for posting, where preferred terms are listed. So if someone inputs "celli" its up to a community to correct it to "cellos" (if that is a preferred term).


----------



## Zedcars (Jun 16, 2019)

Thanks for this - really useful. Just one small crit: I noticed it says “violincelli” for many of the libraries. I think it should be “violoncelli”, although that word is kind of old fashioned now with “celli”, or “cellos” being the more usual word.

I appreciate the work that has gone into this.


----------



## WhiteNoiz (Jun 16, 2019)

zigzag said:


> Hard-coding things like that would result in too rigid system that would require a lot of maintenance.


If you check the Chamber Strings in V2 for example, the articulations are already categorised like that. That's why I suggested an articulation field that uses the arts as tags or filters (existing) and a simple text one to list them as patches/playing styles along with Dyn layers and RRs. Relevant details that don't necessarily need to be filtered that extensively. But still unsure about the scope. Do people actually want to filter all pizz patches and then even filter more with dynamics layers and RRS between libs and compare them or just see that this and that lib have pizz? That means more work that has to be put in or a particular path to be taken.

Tbh, I tried to setup my own version on local server to check things out but I had issues with the database setup... Also, kinda hard to find out what system to use. The fact that there's been this brainstorming, that Mat setup 2 versions on his own server to test it out even as a WIP and that there's at least something in there is still an important step. If I can figure out how to set it up like I envisioned and properly share it I'm up to doing it myself at my own pace locally and then just hosting or sharing it. If we want it done (faster), we all need to contribute, it's a simple fact. Saying this so it doesn't all look as mere requests or criticism (it's just a fact that a certain feature/field needs to exist in order to actually test it).


----------



## zigzag (Jun 16, 2019)

WhiteNoiz said:


> If you check the Chamber Strings in V2 for example, the articulations are already categorised like that. That's why I suggested an articulation field that uses the arts as tags or filters (existing) and a simple text one to list them as patches/playing styles along with Dyn layers and RRs. Relevant details that don't necessarily need to be filtered that extensively. But still unsure about the scope. Do people actually want to filter all pizz patches and then even filter more with dynamics layers and RRS between libs and compare them or just see that this and that lib have pizz? That means more work that has to be put in or a particular path to be taken.
> 
> Tbh, I tried to setup my own version on local server to check things out but I had issues with the database setup... Also, kinda hard to find out what system to use. The fact that there's been this brainstorming, that Mat setup 2 versions on his own server to test it out even as a WIP and that there's at least something in there is still an important step. If I can figure out how to set it up like I envisioned and properly share it I'm up to doing it myself at my own pace locally and then just hosting or sharing it. If we want it done (faster), we all need to contribute, it's a simple fact. Saying this so it doesn't all look as mere requests or criticism (it's just a fact that a certain feature/field needs to exist in order to actually test it).


I thought you meant "Pizz" value would be hard-coded. My bad. An issue with the current version is that new articulation type can't be added directly in the "new instrument" form, but only in articulations list.

I agree that it might not be necessary to perform search/filtering by articulation details (RR, dyn layers etc). So text field for articulation details might be good enough. (This can be added in a later phase.)

Some example use cases of articulations:
- search for string libraries that contain articulation that is not common (eg: bartok)
- search for string libraries that include specific list of articulations (eg: legato, pizz, staccato, portato, tremolo, trill...)
- search for string libraries that have at least x number of string articulations

Maybe we could try sketching a database schema design, if it would be useful?


----------



## JEPA (Jun 16, 2019)

"*A sample library wiki?*" as the thread's title says does include algorithmic synths? I mean I love synths, but it should only include sample based then...


----------



## JEPA (Jun 16, 2019)

by metadata > family/groups, 






I would make these changes of classification (not after Sachs&Hornbostel, but after product design):

*- Full Orchestra Ensemble
- Orchestral/or Symphonic Strings
- Orchestral/or Symphonic Woodwinds
- Orchestral/or Symphonic Brass
- Orchestral/or Symphonic Percussion*

then

*- Strings *(not orchestral) > world, solo instrument (e.g. arabic strings, celtic harp, Kamançe)
*- Woodwinds *(not orchestral) > world, solo instrument (e.g. Duduk, Zurna)
*- Brass *(not orchestral) > world, solo instrument (e.g. erke of Bolivia, the alphorn of Switzerland, the amankondere of Uganda, the shofar of Israel, the sringa of India, the dung‐chen of Tibet, the nabal of Korea, the didjeridu of Australia, and the conch of Oceania)
*- Percussion *(not orchestral) > world, cinematic, hybrid (e.g. Djembé, War drums, sequencer engines)
*- Synthesizer *(sampled based)


----------



## JosepBernad (Nov 8, 2019)

Is the server up? I can't reach it.
Great idea btw, as soon I can access the site I will contribute!


----------



## creativeforge (Nov 8, 2019)

JosepBernad said:


> Is the server up? I can't reach it.
> Great idea btw, as soon I can access the site I will contribute!



Sorry, that is outside of the forum, so I actually have no idea what happened...


----------



## JosepBernad (Nov 8, 2019)

Can't load the webpage. Am I using the wrong ip/link?


----------



## creativeforge (Nov 8, 2019)

JosepBernad said:


> Can't load the webpage. Am I using the wrong ip/link?



It looks like you are using the right link. Not sure what's going on, I just wrote Mat to find out if it's still a live project. I gave him the link to your post. 

Hope it helps!

Andre


----------



## JosepBernad (Nov 8, 2019)

creativeforge said:


> It looks like you are using the right link. Not sure what's going on, I just wrote Mat to find out if it's still a live project. I gave him the link to your post.
> 
> Hope it helps!
> 
> Andre



Appreciate that, thanks!


----------



## MatFluor (Nov 8, 2019)

Yes, the server is not online.
After some more discussion and the various - at times extremely detailed - requirements, I decided to put it on the shelf for later when I have more time to refine it.

The key issues were mainly the depth of the information paired with ease-of-use. The overall idea was a more "shallow" but comprehensively crowdsourced overview, but it got very deep very quickly.

So - it's inactive until I got some private stuff sorted (read: dayjob + music work takes up a lot time currently). But I will get back to it in the not too distant future - I'll inform here once I work more on the prototype and maybe approach a final thing that has a healthy balance between depth and birds-eye.


----------

