What's new

A sample library wiki?

DSmolken

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

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

Dex

Member
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

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

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

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:)
 
Last edited:

MarcusD

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

Member
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

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

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

MatFluor

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

';...;'
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/threads/is-this-a-complete-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/
 
Last edited:

MatFluor

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

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

Senior Member
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"
 
Last edited:

angeruroth

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

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