-
Notifications
You must be signed in to change notification settings - Fork 667
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
Update and move convention section to CONTRIBUTING.md #1635
Conversation
89de503
to
e3a6636
Compare
CONTRIBUTING.md
Outdated
* `win_length`: the length of the STFT window | ||
* `window_fn`: for functions that creates windows e.g. `torch.hann_window` | ||
|
||
Transforms expect and return the following dimensions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove the transforms. This is not a convention. The same thing is explained in the doc, and there should be only one source of truth. Also this is not necessarily relevant to new contributors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this. If I need to know the input or output, I would just go to the documentation website instead of here. I've removed them in the latest commit.
* `f_min`: the lowest frequency of the lowest band in a spectrogram | ||
* `f_max`: the highest frequency of the highest band in a spectrogram | ||
* `win_length`: the length of the STFT window | ||
* `window_fn`: for functions that creates windows e.g. `torch.hann_window` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at the code, the explanation, and your comment I think only waveform
, and sample_rate
is standard and relevant across the code base. If there are only one or two usage, then it's not really convention or standard. And when a new contributor add a new feature, and when we review it, as a good software development practice, we naturally try to stick to existing variable names. So I doubt we need this.
Rather, this list of convention is rather confusing and limiting because IIRC there are cases where waveform
have batch dimension in addition to channel and time, which seems like not following the convention.
How about removing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think we should keep it. I think this short table can help for a quick reference. I've updated the batch dimension problem and rewrite this paragraph a bit.
Please let me know how you think about this new version.
Thanks.
e3a6636
to
e236dd7
Compare
cf98c56
to
15fffe3
Compare
15fffe3
to
2796d2b
Compare
n_mel
ton_mels
since all related variables in functional and (transforms)[https://github.com/pytorch/audio/blob/master/torchaudio/transforms.py] are calledn_mels
.n_freq
, there are two exceptions (1 and 2) calling itn_freqs
.min_freq
andmax_freq
are changed tof_min
andf_max
are used here and no other function usesmin_freq
ormax_freq
.