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

Introduces two function families for introducing chromaticism in melodies #1097

Open
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

aherrou
Copy link

@aherrou aherrou commented Sep 29, 2024

Context

The contributions of this pull request are described in detail in an article submitted to ICLC 2025. The primary goal of this pull request is to make the related code available to reviewers in context, so that they can manipulate it and test it.

Content

This introduces two families of functions that aim at facilitating the use of chromaticism in melodies.

  • The first family of functions is made up of the chromatiseBy function, that introduces chromatic notes in between the anchor notes given in a pattern. The number of chromatic notes inserted (potentially 0, for no chromaticism, or a negative number, for a descending movement) is a patternable parameter.
  • The second family of functions revolves around the scaleMod and scaleMods functions.
    scaleMod is a variant of the scale function that takes a supplementary functional [a] -> [a] parameter. This parameter is used to transform scales (represented as numbers lists), and allows to functionally transform the current scale. scaleMods has a similar role but takes a list of functions rather than a single function.
    Other functions in this family include getScaleMod (used to build scaleMod the same way getScale is used to build scale), and raiseDegree(s) and lowerDegree(s) (meant to be passed as parameters to scaleMod(s), in order to raise/lower one or a range of degrees in a scale by a semitone).

Merging

Besides the usual code reviews and implementation considerations, I am not entirely convinced by my naming choices and I think they should be discussed before merging.

  • scaleMod is short for "scale modification", but the mod suffix sounds a little bit too much like "modulo" to my ears (especially given that the whenmod function exists). Any suggestions for a more Haskell-idiomatic suffix are very welcome.
  • chromatiseBy is fine enough in my opinion, but there might be some debate between a British vs an American-style spelling.

@yaxu
Copy link
Member

yaxu commented Sep 30, 2024

I'm not sure of the Haskell idioms but maybe for scaleMod, withScale would fit a bit better with other tidal functions? The downside being that this then is harder to pluralise..

This could be a good time to explore possibilities for working with patterns of functions in Tidal, then scaleMods (or whatever it becomes) could accept a pattern rather than a list of functions.

@yaxu
Copy link
Member

yaxu commented Sep 30, 2024

We have quantise rather than US quantize spelling as well btw.. But there'd be no harm in making aliases to support both

@cleary
Copy link
Contributor

cleary commented Sep 30, 2024

This looks really interesting to me, and an area I've struggled to work out how I'd imagine a fix - I'm very interested to explore.

My thoughts on spelling are regarding chromatiseBy vs chromaticiseBy though?
Ie chromaticism is the correct term as far as I understand, not chromatism

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.

3 participants