A sample library wiki?

Lindon

VST/AU Developer
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.
 
Last edited:

newman

Member
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

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

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)

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.
 

dflood

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

WhiteNoiz

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

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

Lindon

VST/AU Developer
@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.
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

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

dflood

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

Mason

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

chillbot

Sock Muppet
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

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

';...;'
May I suggest an appetizer before that articulation list? :cautious:

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

MatFluor

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

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

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