What's new

A sample library wiki?

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.
 
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.
 
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 "https://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... :confused:

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):
https://178.128.198.122/doku.php?id=overview:families:strings
https://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:
https://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:
https://178.128.198.122/librarywiki/libraries/show/1
vs
https://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).
 
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.
 
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.
 
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.
 
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!
 
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! :)
 
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 "https://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).
 
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.
 
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).
 
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?
 
Last edited:
"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...
 
by metadata > family/groups,

Metadata family-groups.png

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)
 
Top Bottom