#musicbrainz

If they are too long they could always be put at Style/Language/Whatever/Classical I guess

Or if you feel it's useful to have them all together in one page so people can easily compare languages, that could be done too

I'm afraid it will be too big

Maybe

I'd suggest to first write an example (for English)

yeah

And then we can look at it and think what to do

+1

BTW i think this should be done before a CSG Track Title RFC

Sounds sensible

"follow these non-existing language guidelines" sounds problematic

we can't put any language specific things in there

we could add new Style/Language/<lang>/Whatever pages if we need detailed instructions on something per-language, I suppose...

right. I'll see if I can find that "opus" thread from a while ago & get started

symphonick: IMO it might be best as a part of CSG work style…

What would be the appropriate place to mark Kissin as the pianist for http://musicbrainz.org/release/f56b7b06-e041-45... ?

hawke_: but it's not only for works, it's for tracks & recordings to

too

symphonick: Isn’t the idea that tracks and recordings will follow the work name (or at least that recordings will)

ryanakca: first of all, you can relate him to all recordings as piano performer

hawke_: & it's different for all languages

ryanakca: Relate to... on the right, Kissin (name will be in Cyrillic I guess), "relate to recordings" in the dropdown

Oh, I see you added it to the release

To all recordings is better :)

http://musicbrainz.org/doc/Style/Classical/ too - in theory, the release artist should be "Robert Schumann; Evgeny Kissin"

But it's a bit of a pain to set right now without userscripts, I can do that change for you

regarding CAA types: is “spine” any edge part, or just the back/outer edge?

But what do I know :)

reosarevok: I have a release which is a folded cardboard sleeve with a slipcover

ryanakca: I've added him to the release artist now. also, this was Official, English, Latin - did the changes

reosarevok: Thanks :)

I think I’ll hold off in favor of a “slipcover” type which we might get in future.

hawke_: tracks will follow what's printed, recordings will maybe follow works

symphonick: That sounds good to me.

+ my idea is that you can enter a pseudo-release to get work names on tracks if you really want

found the English CSG thread: http://musicbrainz.1054305.n4.nabble.com/pre-RF...

symphonick: I’d think tagger support would be the better way to do that, but regardless 'as on cover' is preferable to me.

I just think that they will be so inconsistently names that recordings will be better of just being named like the work

*named

hi all. has the return data formats for release groups changed recently?

hmm, gatefold stuff really complicates the CAA stuff.

Relequestual: the 'release types' have.

hawke_: noticed the return data now contains primary and secondary

Yep.

hawke_: the downside is that you lose identification on the works/recordings list

yeah, there's now primary/secondary, the old type field in the WS is done in terms of a mapping

symphonick: recording AC should do that, no?

which I think is "first secondary type unless there's no secondary type, in which case the primary type"

my api call wanted to get only albums and eps, but now it gets it based on the primary type, which seems to be mostly album

so is there a new param to only return the secondary types?

Hmmm

Relequestual: albums and EPs are still the primary type.

You'd probably want to get only primary types which have no secondary type

hawke_: yeah, I don't have particularly strong objections

but say i want to get only the studio albums

Relequestual: then you want take only albums which do not have any secondary types set.

do i now have to do that on my side rather than with than in my api request?

so with the release type, according to the api, should that type not be for the secondary release type (if there is one)

hmm. good question - I can't find a reference as to what (if any) new webservice attributes were added for this feature :/

imo, a description of the webservice changes should have been included in the announcement :)

you would assume that if the options include album, ep and live, that if i set type as album, i don't want ep or live, but if album is primary and live is secondary, i get the live album

where are said anncouncements found btw?

Relequestual: official announcements are on the blog (also shown on the front page of musicbrainz.org now)

Announcements are in the blog, usually http://blog.musicbrainz.org/

ok cheers

I know it can't be helped, but this has now broken my dissertation project which I'm due to demo on friday, and I'm not allowed to change the source

haha

=/

it looks like there is a way, I'm not doing well with my perl-fu

to specify if you want primary vs. secondary

bah

:/

That seems like something we should have

as a param in the api call?

indeed

yeah, it does

looks like st:<something> says "secondary type of <something>"

but there's nothing for "no secondary type"

Hmm

No st:unknown nor st:none?

no, it has an "if there's a secondary type specified, then add 'st.secondary_type = any(<list of types>)' to the WHERE clause"

which you can't put NULL into, I don't imagine

well, someone should file a ticket for this issue, I guess.

I can do it at some point tomorrow

no problem

it would be from the api usage point of view as opposed to how the server deals with that aginst the database, is that acceptable as a ticket?

Yeah. Is that a search server ticket?

add it to MBS for now

though I didn't think about the search-server side of it, I was under the impression you were getting albums/eps by artist

and it should be fine to just mention the API, the backend stuff is an implementation question, the devs can figure that out :P

i am using the api... album is ambigious though. assumed meaning was "studio" when using in conjunction with live, ep, compliation etc, but now it just looks at the primary type, so returning all "album" type release types

yeah; we possibly need more types -- for now album or ep with no secondary type is what you want

"studio" would be a good secondary type, but that would need to go through style

Relequestual: It kind of was, because any other type overrode the base album type

ok cheers for the info. I'll file it as a ticket tomorrow. give me an interesting talking points in my dissertation defence presentation / qna on friday hahaha

hah

it's not drastic, just means my indexing takes... up to 10 times as long...

there are older data dumps, you could possibly set up a server mirror with a pre-schema-change dataset

or do that, I guess :P

haha I don't have the space online for that, running it live

Enjoy y'all

Go#love22

Go#love22

هاي وأحد

#love22

ModBot needs an avatar!

http://musicbrainz.org/doc/ModBot should removing recordings be added to its tasks?

pankkake: How would that work?

I mean, aren't recordings removed automatically already?

from my experience they are

No

weird

There’s no way for modbot to know whether something is a standalone recording (non-album track) or not

I was watching a recording to remove it after it a medium was removed (because it was completely wrong), and when I refreshed the page, it was gone

Strange

http://musicbrainz.org/edit/17568383 see, first track has no recording now

but nothing about removing it in the edit history

and adding *standalone* recordings is different than adding recordings, it's not an auto-edit

(unless I'm mistaken?)

I could well be mistaken too.

If I understand correctly, I need to wait for three people to vote in favour of my changes for them to take effect, or hope at least one person votes in favour of them within the next 14 days, lest they be dropped?

ryanakca: most edits will automatically approve if there are no votes when it expires, but if the wait is 21 days then those fail it there are no votes

3 unanimous votes cause the edit to approve or reject immediately

if there's a mix of votes, then it's decided when the edit expires

equal yes and no fails, more yes than no passes