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

Cycles and pulses - maturing stepwise UI #1207

Open
yaxu opened this issue Oct 29, 2024 · 6 comments
Open

Cycles and pulses - maturing stepwise UI #1207

yaxu opened this issue Oct 29, 2024 · 6 comments

Comments

@yaxu
Copy link
Member

yaxu commented Oct 29, 2024

The stepwise functions are useful but need some rationalisation.

I propose:

  • Rename all references of 'tactus' to 'pulse'. They're synonymous but the latter is less obscure.
    • setTactus could become pulse or maybe pulseAt.
    • s_expand could become pulseBy, as it does the same as pulse but with a factor change rather than absolute value
  • Renaming steps to cycle. Then it should be slightly less ambiguous, as a function for changing hap density and therefore the number of pulses per cycle. Other potential options are cycleAt, or recycle.
    • The difference between above pulse and cycle is that pulse just sets the pulse, whereas cycle both sets the pulse and changes the pattern density (i.e. via fast) to match.
  • Rename s_extend to cycleBy, as it does the same as steps but with a factor change rather than absolute value for the tactus/pulse.
old new hap density pulse absolute/factor use case
fast fast x factor Used when you want the pattern to be faster relative to the pulse. This is usually the case, otherwise in e.g. sound(s_cat("bd sd".fast(2), "cp")), the bd sd would repeat twice but each hap would have the same duration as cp
steps cycle x x absolute Used when you want to change the speed of a pattern to match a given 'pulse'. Useful e.g. where you have two patterns with different pulses and want to align them 'stepwise' so they have matching meters.
s_extend cycleBy x x factor Used when you want the pattern and pulse to be increased along with the pattern speed. This is basically ! in mininotation.
setTactus pulse x absolute
s_expand pulseBy x factor Increases (or decreases) the pulse density, thereby reducing (or increasing) the hap density per pulse. Equivalent to @ in mininotation.
@yaxu
Copy link
Member Author

yaxu commented Oct 30, 2024

Or maybe..

old new hap density pulse absolute/factor
fast fast x factor
steps pulse x x absolute
s_extend pulseBy x x factor
setTactus pulsate x absolute
s_expand pulsateBy x factor

fast = maintain the pulse, while speeding up/down the pattern
pulse = speed up/down the pulse and pattern
pulsate = set a new pulse without changing the pattern

@yaxu
Copy link
Member Author

yaxu commented Oct 30, 2024

Or given the use cases above..

old new hap density pulse absolute/factor mininotation equivalent
fast fast x factor *
steps pulses x x absolute {}%
s_extend repeat x x factor !
setTactus x absolute
s_expand expand x factor @

@yaxu
Copy link
Member Author

yaxu commented Oct 30, 2024

What if as an alternative to setting the cps, you could set the pps, i.e. pulses per second. Then when you did that, you'd be in 'pulse mode' and all patterns would automatically align pulsewise.. polymetric heaven.

@felixroos
Copy link
Collaborator

I generally like the renaming scheme, better than s_* . fwiw i mildly prefer typing steps over pulses , maybe they could be aliased?

@yaxu
Copy link
Member Author

yaxu commented Oct 31, 2024

I think best to just pick one name as it's all quite confusing and seeing multiple names for the same thing could make it worse.
It could just be pulse rather than pulses.
I'm not not keen on steps as the concept is quite different from the use in step sequencers.

@matthewkaney
Copy link
Contributor

As a minor point, I prefer pulse to pulses just because it reads elegantly as infix Haskell notation:

8 `pulse` s "bd ~ ~"

Also perhaps s_polymeter could become something like polyStack so the relationship to stack is explicit? In this context, "poly" would properly mean something like "poly-cycle" because of how multiple cycles would be shifted and combined in order to be pulse-aligned. I do also like polyrhythm/polymeter as an alternate pairing. These would still make a lot of sense as synonyms or as the proper function names if we were willing to demote stack to more historical status.

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

No branches or pull requests

3 participants