Introduces two function families for introducing chromaticism in melodies

[aherrou]

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]

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]

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

[cleary]

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

[aherrou]

I have modified the name of chromatiseBy -- my French brain was influenced by our chromatisme, but you're right, chromaticiseBy is more coherent in an English-speaking context.

Regarding the other function, what do you think about scaleAlteration(s)? It's a bit long, but it's a rather precise description of what's happening. We could make a scaleAlt(s) alias for shortness.

[telephon]

Btw. for naming conventions and avalability of easy to reach features in SuperDirt, you could check this help:

https://doc.sccode.org/Classes/Event.html#Useful%20keys%20for%20notes

The SuperCollider event model allows for scales, tunings, stretched octaves, steps per octave, scale degree, modal transposition, gamut transposition, accidentals, chromatic transposition, detuning and harmonic.

[yaxu]

It would be good to get this merged soon due to #1112

I prefer scaleWith, as it fits with other tidal function names (I think this is what I meant earlier rather than withScale). Read as "scale, but with this function". For plural we could then have scaleWithList - quite long but in the future we can maybe solve this use case with patterns of functions.

Rather than chromatici[sz]eBy, howabout just chromatici[zc]e? Perhaps even with chroma as another shorter alias if that makes any sense?

[aherrou]

I agree with the scaleWith and scaleWithList renamings, they sound clear and descriptive.

I had the project to rewrite scaleMods/scaleWithList, which doesn't behave in the most intuitive way (it currently copies each cycle of the pattern as many times as there are modifying functions, when one would probably rather the list of function and the pattern advance jointly). But I could correct that in a future pull request (it would be better that I do it before ICLC anyway).

I used chromaticiseBy instead of chromaticise because I would like to keep this name for a possible variant of the function where all the intermediate values are inserted (although I'm not sure it is possible with Tidal's current time model).

[yaxu]

@aherrou Ah if you have a chromaticise in mind then that makes sense to me. So if you can rename to scaleWith / scaleWithList then I think we can merge

[yaxu]

Sorry I noticed one more problem - you're using slowcat but that needs importing from Sound.Tidal.Core.

Then hopefully (the working) tests will pass and we can merge!

[yaxu]

Excellent thanks!