Difference between revisions of "User:CatCat/INSTwave"

From MusicBrainz Wiki
Jump to navigationJump to search
m
Line 247: Line 247:
 
* [https://staticbrainz.org/irombook/xylophone/icon.png xylophone/icon.png] (icon)
 
* [https://staticbrainz.org/irombook/xylophone/icon.png xylophone/icon.png] (icon)
 
* [https://staticbrainz.org/irombook/ngoni/ngoni_donso.png ngoni/ngoni_donso.png] (a sub type)
 
* [https://staticbrainz.org/irombook/ngoni/ngoni_donso.png ngoni/ngoni_donso.png] (a sub type)
* [https://staticbrainz.org/irombook/cabasa/caba%C3%A7a.png cabasa/caba%C3%A7a.png] (an alternative, but related instrument)
+
* [https://staticbrainz.org/irombook/cabasa/caba%C3%A7a.png cabasa/cabaça.png] (an alternative, but related instrument)
   
 
as seen above, sometimes a related instrument should just be in the same folder as that one, use discernation
 
as seen above, sometimes a related instrument should just be in the same folder as that one, use discernation

Revision as of 17:25, 20 January 2022

instead of vaporwave

FISHWAVE! no. Instrument addition stuff!

The list of extant instruments on mb are https://musicbrainz.org/instruments The Instrument project on jira is situated https://tickets.metabrainz.org/projects/INST/summary/statistics it shows an overview of stats and the like (I also have some dashboard named "blup" and stats images for my own uses)

https://tickets.metabrainz.org/issues/ is the view for all the issues.

I have some filters i use to delimit tickets and find things. (such as https://tickets.metabrainz.org/browse/INST-776?filter=11020 for "ensemble this!" fix version)

Fix versions are used for an overarching large compound.

First the ticket must be selected. usually I square related things of in "mini-version" type ticket, where related tickets are subtickets of that.

  • for new instruments we have new feature/sub-newfeature
  • for tickets that require updating or changing, description or adding aliases we have improvement/sub-newimprovement
  • for actual errors we have bug
  • task is seldom used but occasionally for large unspecific things like "research the difference between these concepts or "translate this wikipage"

When closing the ticket thus status is used

  • for fixed finished tickets, just "fixed" and a comment with a link to the finished instrument if adding a new one/description of what has been done (eg "added all aliases and fixed description")
  • for tickets that are duplicates, just "duplicate" and close them while pointing to the one we have in a comment and linking it "as a duplicate" of that one. recently I've also been upping the priority of tickets which receive duplicates.
  • for tickets which are deemed to not be added (usually these are novelties (link to see how to add $ novelties)) just "won't fix" with a comment explaining why and a link to the appropriate guideline.
  • if the ticket does not have enough information and a search on the internet has yielded no usable information, i close it with "incomplete" these can always be reopened if someone has more information and adds it!
  • for situations where something is totally not actionable by me, not an instrument ticket etc, it would be closed as "invalid" (this doesn't happen very often and usually the ticket should be *moved* to the appropriate project)


Ticket should have at fixing closing have a comment with a link to the instrument and the instrument add on musicbrainz should have a link to the associated ticket.


on the actionable tickets thus:

usually the ticket will have a wikipedia link, we follow hat and read the article, possibly also i will read swedish/danish/norwegian wikipedia as well I will then do a duckduckgo search as well as following any other links in the ticket.

I have a set of resources I almost always look up in:

for string instruments especially(of which as of current (2022) still is the largest group of instruments on INST tickets)

Next there is of course wikipedia. but also:

there is also countless blogs, sites etcetera that have specialist info, such as https://chandrakantha.com/articles/indian_music/instruments.html for indian instruments

finally there is irom for images (but someone japanese could possibly get info from pages)

(more on image abstraction later)


Then I have some offline sources I loom in:

  • The excellent The New Grove Encyclopedia of Musical Instruments I-III 1984 edition
  • The History of Musical Instruments by Curt Sachs (only borrowed from library)
  • Percussion Instruments and their History by James Blades (for percussion instruments, only borrowed from library, it is an excellent book I wish I owned)
  • Taonga pūoro: Singing Treasures (The musical instruments of the Māori) by Brian Flintoff (for the Māori instruments I extensively borrowed from the library this book several times (its music CD has already been added to mb ;)) another book I wish I owned)

else I borrow from the library any topic books if they have them, I also go through https://www-jstor-org.wikipedialibrary.idm.oclc.org/action/doBasicSearch?Query=SEARCH ([off] and https://libgen.is/) searching for any article or book of the topic for what I'm adding

(example: while trying to piece together how ancient Indian string instruments connect together I searched extensively for these "Veena" instruments in all these sources.)


How to determine if a ticket is not actionable?

it can be not actionable because:

  • it has insufficient information, calls for more information has not yielded any result in a fair amount of time and search in prior explained ways have left nothing -> close as incomplete
  • duplicate or erroneous type - > as already explained.
  • finally may be a valid instrument or issue, but can not be done because something blocks it, such as implementation detail (eg https://tickets.metabrainz.org/browse/MBS-9642 or https://tickets.metabrainz.org/browse/INST-658) in this case it's status should be set as "blocked" with an explanatory comment.

Which leave the difficult "when is an instrument not useful for musicbrainz"

In general the logic for deciding this has been outlined in https://wiki.musicbrainz.org/How_to_Add_Instruments#Not_to_be_added_as_instruments (which was the secondary reason we worked it out - have a document that describes the rationale for inclusion/non-inclusion)

So after reading it what is the summary?

Basically it comes down to judgement! all examples have counter arguments, it's never actually that clear, because artists, sigh.

So what I do is I ask for other people's point of view, chiefly reosarevok (Nicolas Tamargo), sometimes Freso (Frederik Olesen) or yvanzo (I don't actually know your name :O) for things that they might know specific about, Bodhráns/Koras etc. I will also reach out to the community with specific opinions and calls for help from anyone who could know/languag ot translate etc. (example sothotalker or shepard for translating german, d4rkie for translating japanese, zas, yvanzo, loujine etc for french, etcetra.) some years ago we had gci'ers coming in from countries that spoke languages we did not have many of in our community, they where a great help and I hope we can attract more people with more languages to help with translations.


However be advised: the community can be fickle, ask them for suggestions on alias translations and they'll just get occupied with with the usage of transliteration in sortnames :|

You can *not* direct peoples attention or incentives anywhere, you can only suggestively nudge, if they do not want to help, but instead want to argue about something else, it is little use to try to redirect them.

Remember that anything can always be edited.

In general all instruments that are "signature moves" to borrow a Pokémon-term of a specific artist are susspect of novelty


What to do when two (or more) sources contradict eachother

if there is one source contradicting the others:

  • unless very reputable, ignore it.
  • if reputable and the others may infact be sourced to one or a few not so reputable source(s), go with the contracting source (but be discerning)

if two (or several where it is conceivable that the others source either of the two) reputable sources contradict eachother especially:

  • try to find a synthesis of the two (if one says 4 strings an the other says 6 write "4-6 strings")
  • try finding a third reputable independent source and see what it says. it might clarify why the two seem to disagree (sometimes things in these are a bit like the telephone game, in different places bits are given different weight and then when the whole story gets repeated with omissions and finally in a few iterations results seemingly contradict eachother)
  • if it is an open known that there are several leading ideas that contradict eachother, try to include both.
  • if ALL sources disagree with a point, omit it entirely, in this case it is speculation on the part of the writers because it is actually not known.
  • if a western and native source disagree, go with the native source.
  • check (get machine or help with translation) what other language wikipedia say, and see their sources. it might be a translation error.

In the end if it is still unclear, simply write "it is include if" since this is literally true.


What makes a source reputable?

  • in general academic, sourced, researched stuff is good for (western) musical instruments
  • hobbyist blogs that are written by people with a passion for whatever - often this will be your best bet with native and non-western instruments (if only reading in english, in the native languages, there are sure academic, sourced, researched stuff as well.)
  • reputable data can come from surprising places, like a reddit thread or blog, never assume that hobbyists don't know what they're talking bout, if possible engage with them and ask more. Naturally be discerning in any case

unreputable!

  • sites that *sell* instruments - (unless data also collaborates other better sources)
  • things like wikiwand or fandom or random crap, disregard these as main sources and only look if they collaborate a better reputable source.
  • be on the lookout for badly written text, it *might* just be badly translated/nonenglish person writing, but usually it also means the data is less reputable.


.


How To (actually) Add An Instrument

The link to add Instruments is in the "Admin" dropdown at the rightmost of the user menues, after $name and data options (for simplicity the url is https://musicbrainz.org/instrument/create anyway)

add instrument.png (the add instrument screen)

After all is researched and data is found one makes the instrument. a Disambiguation and a Description.

  • The Name should always be lovercase, unless an actual proper noun is in it, (eg "Saraswati veena"). Do not include anything but the name (e.g. like "Swedish lute", unless that is the name)
  • The Disambiguation should be as short and sweet as possible, it should have the main idea up. so you include where or whence it is from, what it is made of and the summary of what makes it distinct. So if the neck is short write "short-necked" if it is goblet shaped write "goblet-drum" etc. combine like "Namibian short-necked lute" or "Ancient cedarwood goblet-drum" or "Double-barrelled brass used in western orchestra" etc.
  • Type is one of "Percussion" (membranophones, in here also idiophones), "Wind" (aerophones), "String" (chordophones), "Electronic" (electrophones), as well as "Family" "Ensemble" and "Other"
    • piano is a string-instrument, shut up.
  • Description! here the essence of your research should go. try to use as few helper conjugations as possible, don't include the name of the instrument, be concise and get to the point as fast as possible; ex: "Used in traditional dance and religious ceremony, it's 40 cm long heavily decorated bamboo soundbox has 3-4 metal strings plucked by bone plectrum."

In Relationships you connect other entities in MusicBrainz

  • Area: linking the instrument where it is from. you can also use rel-credits for historical placenames and instruments
  • Artist[1] & Label: if it was invented by a person or company, add this, try to find at-least a circa year - it is permissible to add a new artist for the inventor of instruments (but unsure about adding new labelcompanies just for instruments?)
  • Instrument:

a bit about Families and Ensembles

    • consists of (opposite of "part of")

I have put this here as it is a relationship used for Families and Ensembles especially Like above, a violin is a member of the viola (not viol) family, and a member of several ensembles

Families are new type of alround more "fuzzy" instrument, like "lute family" which encompasses most necked string instruments. A family can itself contain a family (lute family containing guitar family) there might be some problematic overlap with "type of".

Ensembles are a lot more defined. These are stings like "string ensemble" or combination of instruments like "pipe & tabor", "guban" or "samba drums", even large things like Western Orchestra or Gamelan are ensembles.


else see https://beta.musicbrainz.org/relationship/5ee4568f-d8bd-321d-9426-0ff6819ae6b5


Consists of can have attributes: optional and amount. These are both used for Ensemble, for example and ensemble of 2 violins a viola and an optional cello.

More attributes are possible.

  • finally, the External Links section! here you will paste the Wikidata link, the image link form IROM/staticbrainz (see below) and any very interesting sites that look stable.
  • it is permissible (and encouraged!) to create wikidata items for instruments that do not have them (but their creation is out-of-scope of this guide, maybe some other time :|)

For the Edit note: we write the jira ticket and any intresting things if there is something unusual (this will be rare, usually)

"Enter edit! and we're done!

actually no, we still have:

a bit about aliases

(technically parts of this part goes against established guidelines of how things are *supposed* to be, but I do it this way anyway because it's easier and can be retrofitted should the mb schema be updated (hopefully) in the future )

Generally I will go by the Wikidata list of aliases (ie other lang wiki's) names for an instrument is. I will also add other actual aliases written on that wikidata page, additionally some wikipedia pages will sometimes have more names in their article text (usually the first or second sentence includes them in bold/italiceds) I will include these (provided they don't duplicate any actual language names) as "search hint"

Then I will add any extra names/spellings from Grove or Oxford dictionary (or any other source) as an alias too.

for aliases in a script other than latin i follow the common done thing for artist names -> that is, for the alias name use the full script but for the sortname of thus, use a latin transliteration

this has some issue in that example, japanese names should probably use hiragana instead

I do this because it is easier to see what an alias is, it's interesting ot see language families, and not to unoften are alternate names transliterations of other scripts as well.

a better way of handling this would be to create a transliteration/script way for aliases

for actually adding the aliases i use https://github.com/loujine/musicbrainz-scripts/blob/master/mb-edit-add_aliases.user.js which was actually initially request by myself, this creates the ability to submit several aliases at the same time, as some of the more well documented instruments can have over 20 aliases + alternate names it is indispensable a tool.



a bit about image (IROM) extraction

irom has many sites

often in addition he has blogs like

Usually saisaibatanka will have the best images, but occasionally digitalstampa will surprise you. sometimes graphicnobody will have pages that will *link* to a page (on saisai) that is different than the usual one. on https://digitalstamp.suppa.jp/musical_instruments-chordophone/bowed_strings.html is a rare list of images without people playing them, and on https://animal.tyabo.com/musical_instruments/2string_instruments.html is a great list of various stringed instruments but these are older.


I strongly recommend installing https://github.com/Arnie97/katakana-terminator for being able to quicklier see what things are on IROM's sites (unless you read kana natively of course)


In general go with the largest, clearest and cleanest image, the saisaibatanke page for an instrument will sometimes have more images, and clicking on the main image will usually get you to a /$instrument2 page that may have other images. Sometimes there is even a third page obtainable by clicking the image on the second page, and in the event of several images always check every one, usually an image will have an url to a different page, always.

Collect also the icon infront of the instrument name as seen in the sidebar and here https://saisaibatake.ame-zaiku.com/gakki/r-musical_instruments.html it will be uploaded as a small image in the folder as well. finally it can be beneficial to also have an image of a person playing the instrument, especially if any other image if the instrument is older or not as descriptive (or if the playing of the instrument itself is interesting, e.g. keytar)


Instrument image will be uploaded to https://staticbrainz.org/irombook/ on github https://github.com/metabrainz/irombook-instrument-images in the format of https://staticbrainz.org/irombook/$instrumentname/$instrumentname_(possible_variation).png

example

as seen above, sometimes a related instrument should just be in the same folder as that one, use discernation family (like ngoni, kacapi, etc) are usually in the same folder. Names will have spaces as underscores but hyphen if the name itself conceivably can has hyphen.


reosarevok knows the drill.


how to deal with community friction

How to deal with community friction when correct decisions lead to argument and complaints about "making it impossible to add instruments unless you're a scholar" etc?

  • first thing, Don't panic!
  • Don't just "give in" and give the people what they (think) they want and compromise data
  • learn to walk away and ignore toxious people and arguments
    • don't engage with toxic people, ignore them.
  • always second guess yourself, but get a 2 persons opinion about if your initial logic was all that faulty to begin with


in closing

I haven't written this part yet, oops!

  1. due to MB schema limitations, it is possible for regular users to add this rel via the *artist* screen, happily there are users patrolling and reverting these edits so fast that you almost always won't have to do it yourself.
  2. I predict that "related" might be made obsolete some time in the future, it is of course better to specify *how* it is related. new types can be added instead of the vague "related"