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

LN key-up sound #9

Open
DolphinDTM opened this issue Apr 25, 2017 · 2 comments
Open

LN key-up sound #9

DolphinDTM opened this issue Apr 25, 2017 · 2 comments

Comments

@DolphinDTM
Copy link

DolphinDTM commented Apr 25, 2017

zardoru, wosderge, flicknote, suitougreentea, exclusion and I discussed the addition of this in a DM conversation on Twitter.

The idea is simple: The ending point of a LN plays a sound when the player releases the key.
This lets us emulate back-spin scratch from IIDX where a new sound is played at the note release, and it also offers more variety and interesting possibilities for chart creation.

image
Pictured above:
note1 with l: 240 is a regular long note.
note2 with up: true overlaps note1
Due to up: true, the player will know that note2 is a key-up sound and not a regular note.
note2 may also be in a different sound channel than note1. Like so:

image

Some key points from the discussion:

  • Most people agreed that this is a natural extension of "layered notes", which is already a feature in bmson.
  • flicknote said the "up" event is redundant, however suitougreentea explained that we can not trust that all implementations will consider note1.y + note1.l == note2.y as an overlap. We should make it explicitly clear that there is an overlap to ensure that all implementations are similar.
@DolphinDTM
Copy link
Author

One thing worth discussing: What should the expected behaviour be when a note with up: true does not overlap a longnote (or any note)?

Should it be ignored (play as BGM), or should it be played as a regular note?

@excln
Copy link

excln commented Apr 26, 2017

Because up: true is clearly meant to be a key-up sound, we should consider a note with up: true not overlapping a long note to be an error. So I think the expected behaviour does not need to be defined in specification.

For relief implementation, playing as a regular note (ignoring up: true) may be slightly better because that note is intended to be more a playable note than a BGM note.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants