An acceptable way to introduce and describe parameters that acccept multiple classes of input? #3397
Unanswered
CUBICinfinity
asked this question in
Q & A for Developers
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
On the forums, Amiika created a patch for custom scales.
https://in-thread.sonic-pi.net/t/support-for-custom-scales/5334
It can also be applied to chords.
https://in-thread.sonic-pi.net/t/chord-progression-tool/4947/31?u=cubicinfinity
Usage example for custom scale:
scale(:C4, [1,2,1,2,1,2,1,2])
Usage example for custom chord:
chord(:C4, [0, 2.11765, 4.94118, 7.05882])
I started working on a pull request for this, but when beginning to edit the documentation, I realized the complexity of introducing a parameter that can be one of multiple object classes, i.e., a symbol or an array. It makes the most sense to me for this one parameter (currently called
name
) to be used for both types of input, but I don't know what convention to follow for renaming this parameter and how to present it in the documentation. Would we just replace "symbol" with "symbol or array"?Beta Was this translation helpful? Give feedback.
All reactions