What's new

A sample library wiki?

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

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

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 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.
 
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.
 
Last edited:
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?
 
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)
 
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?
 
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?
 
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.
 
Last edited:
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
 
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!
 
I entered 4 piano libraries in the v2 prototype. Couldn't leave sample rate or bit rate blank. Thumbnails look a bit wonky.
 
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" :dancedance:
 
@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

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.

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 ;)
 
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).
 
Have issues searching the Piano VI database with special European characters (eg. the ö of Bösendorfer).
 
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?
 

Attachments

  • umlaut-scr.png
    umlaut-scr.png
    12.2 KB · Views: 6
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).
 
a question: it has started? where to insert information? could the OP edit OM with instructions? thanks
 
Top Bottom