Sorting sub-works and more generally ARs

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Sorting sub-works and more generally ARs

Frederic Da Vitoria
Hello,

http://tickets.musicbrainz.org/browse/MBS-3375 is more than 2 years old. It seems it is stuck because nobody is sure how it should be implemented. I feel many important things are clumsily patched (or not addressed at all) because we lack ordering. I'd like to revive the discussion about this and hopefully not have yet another schema change without it.

Here is my suggestion: add a simple number to ARs which could be used by the AR types which we find relevant. This number would of course be used for ordering.

Why not a string allowing for things like "2.1.5"? Because I am not currently convinced that smart sorting on strings such as this would be the correct way to handle sub-hierarchies.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Lemire, Sebastien-2
Earlier we have news of attributes to works and now this. Looks like Christmas must have come early :)

As for how to implement this, the simple way would be a numerical attribute in attribute for the Work is a part of work relationship. It might not gracefully handle one making a mistake and entering the same number to two the sub-works though... Also editing mistakes or adding a work in the middle would be a pain in the a**.

The best solution would that as soon as a work has 2 or more parts related to it, that an option appears on the right hand-side to re-order the parts. Clicking on it would bring a small GUI and we could move them similarly to how he we currently move tracks on a tracklist. The actual ordering value could be kept internal to MB and not be editable by hand.

As for sub-hierarchies, I'd be happy with having to treat each sub-hearchy separately. Although it would be nice obvously if you go to the top of the tree, click on the re-order and see the whole tree...

Makes sense?

Sebastien



On Tue, Oct 22, 2013 at 8:37 AM, Frederic Da Vitoria <[hidden email]> wrote:
Hello,

http://tickets.musicbrainz.org/browse/MBS-3375 is more than 2 years old. It seems it is stuck because nobody is sure how it should be implemented. I feel many important things are clumsily patched (or not addressed at all) because we lack ordering. I'd like to revive the discussion about this and hopefully not have yet another schema change without it.

Here is my suggestion: add a simple number to ARs which could be used by the AR types which we find relevant. This number would of course be used for ordering.

Why not a string allowing for things like "2.1.5"? Because I am not currently convinced that smart sorting on strings such as this would be the correct way to handle sub-hierarchies.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
2013/10/22 Lemire, Sebastien <[hidden email]>
Earlier we have news of attributes to works and now this. Looks like Christmas must have come early :)

As for how to implement this, the simple way would be a numerical attribute in attribute for the Work is a part of work relationship. It might not gracefully handle one making a mistake and entering the same number to two the sub-works though... Also editing mistakes or adding a work in the middle would be a pain in the a**.

Yes, but all these issues would remain if we use a character zone.

 
The best solution would that as soon as a work has 2 or more parts related to it, that an option appears on the right hand-side to re-order the parts. Clicking on it would bring a small GUI and we could move them similarly to how he we currently move tracks on a tracklist. The actual ordering value could be kept internal to MB and not be editable by hand.

Yes, but these are purely UI issues. Unless I have missed something, none of these would impact a schema change. I am more concerned about some wish which would require something more complex than a simple number field.

 
As for sub-hierarchies, I'd be happy with having to treat each sub-hearchy separately. Although it would be nice obviously if you go to the top of the tree, click on the re-order and see the whole tree...

We seem to agree about sub-hierarchies: if we need a numbering like "2.5", then this means that we should enter 2 part levels, a higher and a lower, and each level should be numbered relatively to it's parent. So that "2.5" would be split into 2 lines: a "2" at the higher level and a "5" at the lower level. It would be the UI's job to coalesce all the parts correctly if the user wishes to see them all at the same time.

Again, I believe numbering could be used for other things than sob-works. Nikki and monxton found other (but similar) uses for this field: medleys and compilations. Both of these would IMO be addressed with a simple number. But can someone think of another use?

 
On Tue, Oct 22, 2013 at 8:37 AM, Frederic Da Vitoria <[hidden email]> wrote:

Hello,

http://tickets.musicbrainz.org/browse/MBS-3375 is more than 2 years old. It seems it is stuck because nobody is sure how it should be implemented. I feel many important things are clumsily patched (or not addressed at all) because we lack ordering. I'd like to revive the discussion about this and hopefully not have yet another schema change without it.

Here is my suggestion: add a simple number to ARs which could be used by the AR types which we find relevant. This number would of course be used for ordering.

Why not a string allowing for things like "2.1.5"? Because I am not currently convinced that smart sorting on strings such as this would be the correct way to handle sub-hierarchies.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock
In reply to this post by Frederic Da Vitoria
Frederic Da Vitoria wrote
Here is my suggestion: add a simple number to ARs which could be used by
the AR types which we find relevant. This number would of course be used
for ordering.
Unfortunately there's various places that wouldn't achieve what I want. It won't work where the links aren't all to one entity or where there's multiple sets of ordered links to one work. For example, with medleys, if the performance is split over several recordings the numbering wouldn't work. Alternatively, if there are two medleys on one recording again it wouldn't work.
I'd like to see an ordered list of relationships. However, if something like that wouldn't be implemented for several years and the simple numbering could be quickly then it'd be worth doing that as it would cover many cases.
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
2013/10/23 tommycrock <[hidden email]>
Frederic Da Vitoria wrote
> Here is my suggestion: add a simple number to ARs which could be used by
> the AR types which we find relevant. This number would of course be used
> for ordering.

Unfortunately there's various places that wouldn't achieve what I want. It
won't work where the links aren't all to one entity or where there's
multiple sets of ordered links to one work. For example, with medleys, if
the performance is split over several recordings the numbering wouldn't
work. Alternatively, if there are two medleys on one recording again it
wouldn't work.

Could you explain why it wouldn't work?

 
I'd like to see an ordered list of relationships. However, if something like
that wouldn't be implemented for several years and the simple numbering
could be quickly then it'd be worth doing that as it would cover many cases.

What could you be waiting for? What is it which could possibly only be done in a long time?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock
On 23 October 2013 08:53, Frederic Da Vitoria <[hidden email]> wrote:
2013/10/23 tommycrock <[hidden email]>
Frederic Da Vitoria wrote
> Here is my suggestion: add a simple number to ARs which could be used by
> the AR types which we find relevant. This number would of course be used
> for ordering.

Unfortunately there's various places that wouldn't achieve what I want. It
won't work where the links aren't all to one entity or where there's
multiple sets of ordered links to one work. For example, with medleys, if
the performance is split over several recordings the numbering wouldn't
work. Alternatively, if there are two medleys on one recording again it
wouldn't work.

Could you explain why it wouldn't work?

With the work sub-parts example you have work a linked to parts x, y and z. That works fine with numbered ARs.

a) medley with recordings split into component works:
The ARs are between
recording - work
a - x
b - y
c - z
So there's nothing apart from perhaps some versions of a tracklist to tie them together.

b) two medleys on one recording:
the recording is linked to works p, q and r (medley 1) and x, y and z (medley 2). I guess with some kind of 1.1 numbering system this might be able to be handled, but probably not gracefully and not sure how it would interact with other works linked to the same recording that aren't part of a medley...


 
 
I'd like to see an ordered list of relationships. However, if something like
that wouldn't be implemented for several years and the simple numbering
could be quickly then it'd be worth doing that as it would cover many cases.

What could you be waiting for? What is it which could possibly only be done in a long time?

It wouldn't necessarily take a long time, I'm just aware that the developers have a very long list of requests and only so much time, so changing the structure of the database is necessarily a long way down the list.
The mechanics I'm thinking of would be a defined relationship between ARs. Something like a table of ordered types (medley, sub-parts, ...), a table that defines that grouping (medley 1, medley 2 in my examples above), and a table that links the grouping to the AR and defines the order. There's probably a more elegant / robust solution but anyway, something that would achieve that kind of thing.
A simple number could more easily be added, but the UI for that would still be tricky to get right.

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
2013/10/23 Tom Crocker <[hidden email]>
On 23 October 2013 08:53, Frederic Da Vitoria <[hidden email]> wrote:
2013/10/23 tommycrock <[hidden email]>
Frederic Da Vitoria wrote
> Here is my suggestion: add a simple number to ARs which could be used by
> the AR types which we find relevant. This number would of course be used
> for ordering.

Unfortunately there's various places that wouldn't achieve what I want. It
won't work where the links aren't all to one entity or where there's
multiple sets of ordered links to one work. For example, with medleys, if
the performance is split over several recordings the numbering wouldn't
work. Alternatively, if there are two medleys on one recording again it
wouldn't work.

Could you explain why it wouldn't work?

With the work sub-parts example you have work a linked to parts x, y and z. That works fine with numbered ARs.

a) medley with recordings split into component works:
The ARs are between
recording - work
a - x
b - y
c - z
So there's nothing apart from perhaps some versions of a tracklist to tie them together.

Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

b) two medleys on one recording:
the recording is linked to works p, q and r (medley 1) and x, y and z (medley 2). I guess with some kind of 1.1 numbering system this might be able to be handled, but probably not gracefully and not sure how it would interact with other works linked to the same recording that aren't part of a medley...

Ah, now I see. But in this case, I believe the recording should be split in p, q, r, x, y and z using the Compilation Relationship, and then the r and z recordings should themselves be ARed using the medley AR. Thus the structure of the data would reflect the structure of the recording.


I'd like to see an ordered list of relationships. However, if something like
that wouldn't be implemented for several years and the simple numbering
could be quickly then it'd be worth doing that as it would cover many cases.

What could you be waiting for? What is it which could possibly only be done in a long time?

It wouldn't necessarily take a long time, I'm just aware that the developers have a very long list of requests and only so much time, so changing the structure of the database is necessarily a long way down the list.
The mechanics I'm thinking of would be a defined relationship between ARs. Something like a table of ordered types (medley, sub-parts, ...), a table that defines that grouping (medley 1, medley 2 in my examples above), and a table that links the grouping to the AR and defines the order. There's probably a more elegant / robust solution but anyway, something that would achieve that kind of thing.
A simple number could more easily be added, but the UI for that would still be tricky to get right.

I hope that we don't need the complexity you are describing, because if this true, then AR ordering is probably still for the far future.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock



On 23 October 2013 09:50, Frederic Da Vitoria <[hidden email]> wrote:
2013/10/23 Tom Crocker <[hidden email]>
[...]

a) medley with recordings split into component works:
The ARs are between
recording - work
a - x
b - y
c - z
So there's nothing apart from perhaps some versions of a tracklist to tie them together.

Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

But simple numbering will not tell us that a-x is part of a medley with b-y and c-z and there is no robust way of knowing that based on the data we have. We could probably figure it out in most cases based on the ordering of tracks but that's complex, implicit and can't be guaranteed. We know x has been recorded as part of a medley, but not which the other works were.

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

symphonick
Maybe we could do work-work parts now & save medleys for later?


2013/10/23 Tom Crocker <[hidden email]>



On 23 October 2013 09:50, Frederic Da Vitoria <[hidden email]> wrote:
2013/10/23 Tom Crocker <[hidden email]>
[...]


a) medley with recordings split into component works:
The ARs are between
recording - work
a - x
b - y
c - z
So there's nothing apart from perhaps some versions of a tracklist to tie them together.

Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

But simple numbering will not tell us that a-x is part of a medley with b-y and c-z and there is no robust way of knowing that based on the data we have. We could probably figure it out in most cases based on the ordering of tracks but that's complex, implicit and can't be guaranteed. We know x has been recorded as part of a medley, but not which the other works were.

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users



--

/symphonick

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
In reply to this post by tommycrock
2013/10/23 Tom Crocker <[hidden email]>

On 23 October 2013 09:50, Frederic Da Vitoria <[hidden email]> wrote:
2013/10/23 Tom Crocker <[hidden email]>
[...]

a) medley with recordings split into component works:
The ARs are between
recording - work
a - x
b - y
c - z
So there's nothing apart from perhaps some versions of a tracklist to tie them together.

Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

But simple numbering will not tell us that a-x is part of a medley with b-y and c-z and there is no robust way of knowing that based on the data we have. We could probably figure it out in most cases based on the ordering of tracks but that's complex, implicit and can't be guaranteed. We know x has been recorded as part of a medley, but not which the other works were.

Oh, you mean a b and c are distinct recordings? I thought they were parts of the same recording. That's a completely different issue. We'd need a way to virtually "merge" those recordings and then create medley ARs from the virtual recording to x, y and z. But that would be a 3 entity AR (virtual recording / physical recording / work), something we can't do currently. I can't imagine any numbering scheme which would tell that those recordings are tied together. There is a similar missing virtual recording in classical music, when sometimes a movement is artificially split in several tracks.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock

Oh, you mean a b and c are distinct recordings?

That's right. The medley has been split into several tracks.
 
That's why I suggest using a set of ARs (with ordering within that set) as the approach. Simply numbering the ARs only works when the set is already defined by association with one entity.

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock
In reply to this post by symphonick



On 23 October 2013 10:18, symphonick <[hidden email]> wrote:
Maybe we could do work-work parts now & save medleys for later?

 
Yes. That would make sense to me as it's probably much easier to achieve and would cover most cases (even for medleys, etc.) and could be transferred to a new system fairly straightforwardly (I think!)

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

David Gasaway
In reply to this post by Frederic Da Vitoria
On Wed, Oct 23, 2013 at 1:50 AM, Frederic Da Vitoria <[hidden email]> wrote:
Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

I'd like to point out that it works only in one direction.  When looking at the work, the numbers would be meaningless, and sorting by these numbers wouldn't make sense.  I also assume that you mean that the number would apply only within that specific AR.  Surely, we wouldn't be ordering all Recording-Artist ARs globally, mixing performance and production credits, and so on.  Let's take a specific example:

Recording A
- Produced by X, Y
- Assistant produced by Z

These are all the very same AR type, but the last has an additional attribute applied.  We might want to sort X and Y.  But would we also need to sort Z with them?  After all, the UI keeps them separate.  So, do we say that the ordering only applies when there is more than one AR where the type and attributes (except number) match exactly?  What happens when edits change those attributes?

Point is, I'm not sure we can extrapolate from here and say this solution that could work medley could work for ARs in general.

--
-:-:- David K. Gasaway
-:-:- Email: [hidden email]

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock


On Oct 24, 2013 4:48 AM, "David Gasaway" <[hidden email]> wrote:
>
> On Wed, Oct 23, 2013 at 1:50 AM, Frederic Da Vitoria <[hidden email]> wrote:
>>
>> Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.
>
>
> I'd like to point out that it works only in one direction.  When looking at the work, the numbers would be meaningless, and sorting by these numbers wouldn't make sense.

That's right,  but that's okay.

> I also assume that you mean that the number would apply only within that specific AR. 

That's my assumption too,  but I would assume we wouldn't allow ordering in most cases. In those we would allow it, the ordering would be regardless of attributes I would think.

>  Let's take a specific example:
>
> Recording A
> - Produced by X, Y
> - Assistant produced by Z
>
> These are all the very same AR type, but the last has an additional attribute applied.  We might want to sort X and Y.  But would we also need to sort Z with them?  After all, the UI keeps them separate. 

What the UI currently does isn't very important. The release UI shows credits inline (sorted by track) or per join string.

PS meant to say to davitof 1.1.1 doesn't need to be (shouldn't be ) a string, just not an integer.


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

David Gasaway

On Wed, Oct 23, 2013 at 11:51 PM, Tom Crocker <[hidden email]> wrote:

What the UI currently does isn't very important.

If I read between the lines, you're saying that the UI would change?  If it stays as-is, applying a sort number to all three from my example as a group has no useful outcome.  So I'm still in the dark as to what you would consider a group of ARs that needs to be sorted.  And know I don't even know what kind of UI you are imagining. :)
 

The release UI shows credits inline (sorted by track) or per join string.


I had recording view in mind, but release inline view works, too.  Sorting wouldn't work in the "credits at bottom" view, as far as I can figure.

--
-:-:- David K. Gasaway
-:-:- Email: [hidden email]

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
In reply to this post by David Gasaway
2013/10/24 David Gasaway <[hidden email]>
On Wed, Oct 23, 2013 at 1:50 AM, Frederic Da Vitoria <[hidden email]> wrote:
Interesting, I hadn't thought of that: in a Recording-Work AR, the "parent" is the Recording. But that doesn't change anything IMO, simple numbering would still work.

I'd like to point out that it works only in one direction.  When looking at the work, the numbers would be meaningless, and sorting by these numbers wouldn't make sense.  I also assume that you mean that the number would apply only within that specific AR.  Surely, we wouldn't be ordering all Recording-Artist ARs globally, mixing performance and production credits, and so on.  Let's take a specific example:

Recording A
- Produced by X, Y
- Assistant produced by Z

These are all the very same AR type, but the last has an additional attribute applied.  We might want to sort X and Y.  But would we also need to sort Z with them?  After all, the UI keeps them separate.  So, do we say that the ordering only applies when there is more than one AR where the type and attributes (except number) match exactly?  What happens when edits change those attributes?

Point is, I'm not sure we can extrapolate from here and say this solution that could work medley could work for ARs in general.

I was expecting a very "local" effect. I hadn't thought of attributes but I agree that ordering should only apply to completely identical ARs.

I believe than when an edit changes the attribute of a previously "ordered" AR, the old order value should be cleared. I suggest that when a set of ARs is "ordered", if one of the AR's position has not been set, this AR should be displayed in a special way. This could happen: for example we could know that a work has sub-parts, we know which is the first or which is the last, but we are not sure of the order of some sub-parts.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock
In reply to this post by David Gasaway


On Oct 24, 2013 8:37 AM, "David Gasaway" <[hidden email]> wrote:
>
>
> On Wed, Oct 23, 2013 at 11:51 PM, Tom Crocker <[hidden email]> wrote:
>>
>> What the UI currently does isn't very important.
>
> If I read between the lines, you're saying that the UI would change?  If it stays as-is, applying a sort number to all three from my example as a group has no useful outcome.  So I'm still in the dark as to what you would consider a group of ARs that needs to be sorted.  And know I don't even know what kind of UI you are imagining. :)
>  
>>
>> The release UI shows credits inline (sorted by track) or per join string.
>
>
> I had recording view in mind, but release inline view works, too.  Sorting wouldn't work in the "credits at bottom" view, as far as I can figure.

Given we don't have sorting currently I can't imagine how we would implement it without some sort of UI change. What I was meaning about track credits on releases is we can display the same ARs sorted in different ways - sorry I'm not being very clear! Sorting would have to be subsidiary to any dates. But not other attributes IMO (the sort number would be an attribute I guess).

Groups of ARs that really need sorting (and could be with the kind of structure proposed here):
Work -Work :
Medley
Parts

Recording -Work :
Performance of (medleys are soon to be attributes here) but for example, one performance could be instrumental, another partial, but they only appear in one order on a recording.

Recording -Recording :
Compilation, DJ mix.
Possibly also samples?

There might be some others where it would be useful but I don't think all should be able to be sorted.


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

tommycrock

Oh, I also meant to say, given the structure that was put in place to deal with instrument free-text credits I don't think this would be a case of just adding an integer to the link table, because they'll want to have a postgresql way of restricting when it can be used.


_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
2013/10/25 Tom Crocker <[hidden email]>

Oh, I also meant to say, given the structure that was put in place to deal with instrument free-text credits I don't think this would be a case of just adding an integer to the link table, because they'll want to have a postgresql way of restricting when it can be used.


Could you explain more?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
Reply | Threaded
Open this post in threaded view
|

Re: Sorting sub-works and more generally ARs

Frederic Da Vitoria
In reply to this post by tommycrock
2013/10/25 Tom Crocker <[hidden email]>

On Oct 24, 2013 8:37 AM, "David Gasaway" <[hidden email]> wrote:
>
> On Wed, Oct 23, 2013 at 11:51 PM, Tom Crocker <[hidden email]> wrote:
>
>> What the UI currently does isn't very important.
>
> If I read between the lines, you're saying that the UI would change?  If it stays as-is, applying a sort number to all three from my example as a group has no useful outcome.  So I'm still in the dark as to what you would consider a group of ARs that needs to be sorted.  And know I don't even know what kind of UI you are imagining. :)
>  
>>
>> The release UI shows credits inline (sorted by track) or per join string.
>
>
> I had recording view in mind, but release inline view works, too.  Sorting wouldn't work in the "credits at bottom" view, as far as I can figure.

Given we don't have sorting currently I can't imagine how we would implement it without some sort of UI change. What I was meaning about track credits on releases is we can display the same ARs sorted in different ways - sorry I'm not being very clear!


Sorting would have to be subsidiary to any dates. But not other attributes IMO (the sort number would be an attribute I guess).


I don't understand what you are saying. Could you explain in other words? Or maybe with examples?


Groups of ARs that really need sorting (and could be with the kind of structure proposed here):
Work -Work :
Medley
Parts

Recording -Work :
Performance of (medleys are soon to be attributes here) but for example, one performance could be instrumental, another partial, but they only appear in one order on a recording.

Ah, yes: most often sorting should apply for ARs with all attributes identical, but sometimes it would be better if sorting did not take some attributes into account. Should we consider this as a corner case which happens rarely enough that we can just stick to the simple rule "sorting should apply for ARs with all attributes identical" and use comments for the few situations where this rule does not allow to match reality? Or can we assume that solving this complexity will only affect the AR parameters, so that the AR editing UI can remain simple?

 

Recording -Recording :
Compilation, DJ mix.
Possibly also samples?

There might be some others where it would be useful but I don't think all should be able to be sorted


I agree, most ARs probably don't need to be sortable.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-users mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users
12