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

Quantisation of events and notes #327

Merged
merged 4 commits into from
Sep 19, 2017
Merged

Quantisation of events and notes #327

merged 4 commits into from
Sep 19, 2017

Conversation

superbock
Copy link
Collaborator

@superbock superbock commented Aug 22, 2017

Changes proposed in this pull request

  • Quantisation of events does not alter them
  • Check for correct dimensionality (i.e. 1D) of input data
  • Add functionality to be able to quantise notes, i.e. return a 2D representation of the notes.

This pull request fixes #325.

@superbock superbock force-pushed the fix_325 branch 3 times, most recently from 5f42a17 to 7ebc0ff Compare August 22, 2017 13:55
@superbock superbock changed the title Quantisation of events does not alter them Quantisation of events and notes Sep 17, 2017
@superbock superbock requested a review from fdlm September 17, 2017 11:34
Copy link
Contributor

@fdlm fdlm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the code is fine, but I suggest some changes to documentation and the function signature.

def quantize_notes(notes, fps, length=None, num_notes=None, shift=None,
offset=None, velocity=None):
"""
Quantize the notes with the given resolution.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the description needs to be elaborated. I would expect that "quantizing the notes" would "snap" their start and end points to a grid. This function, however, does something else. I'm not sure how to describe this concisely...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a more descriptive docstring.

length : int, optional
Length of the returned array. If 'None', the length will be set
according to the latest sounding note.
num_notes : int, optional
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name of this parameter is easily confused with the "number of notes in the notes array". Maybe changing the description to something like "Number of possible pitches"? Not sure...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to num_pitches.

will be based on the highest note number in the `notes` array. All note
numbers equal or greater this value will not be included in the
returned quantized array.
shift : float, optional
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think shift or offset should be part of this function.

  1. It is very easy to implement both outside of the function
  2. It makes the function signature unnecessarily complex

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, at least for offset. On the other hand, since shift can be a float and rounding is used inside the function, moving this outside the function may introduces more errors.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO the following is not more error-prone:

notes[:, 0] += 2.3
qnotes = quantize_notes(notes)

than this:

qnotes = quantize_notes(notes, shift=2.3)

If there is a common use case for the shift, then the second option is fine, but if it is a special case, I vote for the first one, because I think a function should do only one thing, if possible. That said, I don't have a strong opinion on this specific case.

Copy link
Collaborator Author

@superbock superbock Sep 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, I somehow only considered applying the shift after calling the function... I will remove it (and deprecate shift in quantize_events).

If no `length` and `num_pitches` are given the values are inferred from the
notes. Then each note is put into the column corresponding to its pitch
and all frames between the note's onset and offset (i.e. onset + duration)
are set to the velocity of the note.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already much better! I would try to describe what the function does, and not how it does it, maybe like this:

"Create a sparse 2D array whose rows correspond to points in time (according to fps and length), and columns to note pitches (according to num_pitches). The values of the array correspond to the velocity of a pitch at a given point in time (based on the note pitch, onset, duration, and velocity). If no values for length and num_pitches are given, they are inferred from notes."

Number of pitches of the returned array. If 'None', the number of
pitches will be based on the highest pitch in the `notes` array.
shift : float, optional
Shift the events by `shift` seconds before quantization.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we keep the shift parameter, I think it should say "Shift the notes...

@fdlm
Copy link
Contributor

fdlm commented Sep 18, 2017

I think there was a comment of yours about renaming of the function to expand_notes, or something like that. I can't find it right now. Anyways, I think with a useful description in the docstring, both names should be fine. I would go with whatever is more consistent with the rest of the codebase.

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

Successfully merging this pull request may close these issues.

Quantize Events - Wrong dimensions returned.
2 participants