Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Associating a song with multiple parent (original) versions #55

Closed
riipah opened this issue May 6, 2015 · 8 comments
Closed

Associating a song with multiple parent (original) versions #55

riipah opened this issue May 6, 2015 · 8 comments

Comments

@riipah
Copy link
Member

riipah commented May 6, 2015

Mostly useful for mashups. Has been requested a few times, for TouhouDB as well.

Would obviously require changing the current association from one-to-many to many-to-many. Could possibly make the performance worse. To mitigate performance penalty we could still use the old original song property to minimize the number of times the collection needs to be accessed.

Still need to evaluate whether it's feasible to implement due to increased complexity and lower performance.

Also need to consider how to implement "filter by parent version" feature. Probably the many-to-many list would need to include the whole parent hierarchy, and maintaining that could be very complicated.

Open issues: if multiple parents are specified, from which should the lyrics and characters be inherited? Could we always use the first parent song (most derived songs only have one parent anyway)?

@ycanardeau
Copy link
Contributor

This could be done by VocaDB/vocadb#558.

@dset0x
Copy link

dset0x commented Jan 23, 2021

@ycanardeau Perhaps linked to the wrong issue? How is BPM related to multiple song inheritance?

@ycanardeau
Copy link
Contributor

ycanardeau commented Jan 23, 2021

@dset0x No, it's not wrong. Originally I was thinking having multiple offset-length pairs (which is overly complicated) to support variable BPM.

Offset in seconds Length in seconds BPM Song (nullable)
0 10 100 Parent song 1
10 10 200 Parent song 2
20 30 50 Parent song 3
50 5 20 Parent song 4
55 5 400 Parent song 5

@dset0x
Copy link

dset0x commented Jan 24, 2021

Oh, I think this is too much. I might also not be applicable to many songs.

Do you have a use-case for trying to maintain so much information?

@riipah
Copy link
Member Author

riipah commented Jan 24, 2021

I also don't recommend this suggestion. It sounds too complicated for the main website (feature bloat). If necessary, such information could be on a related website.

Do you have a use-case for trying to maintain so much information?

I can imagine mashups at least?

@ycanardeau
Copy link
Contributor

Do you have a use-case for trying to maintain so much information?

Yes. For example, this song could be associated with 26 parent songs.

@dset0x
Copy link

dset0x commented Jan 25, 2021

Do you have a use-case for trying to maintain so much information?

Yes. For example, this song could be associated with 26 parent songs.

Oh, I understand having multiple parent songs, but I wonder if making a table like the example you gave is generally useful (where you maintain not only the relationship, but also the timing)

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the Stale label May 23, 2021
@ycanardeau ycanardeau added Stale and removed Stale labels May 25, 2021
@github-actions github-actions bot closed this as completed Jun 2, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 8, 2022
@VocaDB VocaDB unlocked this conversation Aug 12, 2022
@ycanardeau ycanardeau transferred this issue from VocaDB/vocadb Aug 12, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants