Allow for multiple tempo

[tmhglnd]

A feature that allows for setting tempo in multiple places would be interesting to give more freedom in sequencing.

For example if one would want to make a piece inspired by Piano Phase from Steve Reich one would have to make two instruments playing the same phrase but one is slightly faster then the other. This could look something like:

list phrase random(16)

set tempo 120 
new synth sine note(phrase 1) time(1/16) // uses tempo 120 bpm

set tempo 121
new synth sine note(phrase 1) time(1/16) // uses tempo 121 bpm

This however requires a rework of mercury where instruments use separate clock sources instead of a global transport. Another option could be to allow for some tempo/time multiplication factor within the time() method, for example as a third argument.

list phrase random(16)

set tempo 120
new synth sine note(phrase 1) time(1/16) // uses tempo 120 bpm

new synth sine note(phrase 1) time(1/16 0 1.00833333) //uses tempo 120 but multiplied by 1.008 to reach 121, the 0 is the offset argument that we don't use

[totalgee]

How does the clock/tempo work in Mercury when you re-evaluate code, does it restart at zero each time, or just keep running from where it was?

Also, if you're scaling/offsetting a single global clock, you need to decide what should happen on re-evaluation. Do you mind if it jumps in time, or do you want it to continue from the beat where it was, but now with the new tempo (or scale factor)?

[tmhglnd]

Thanks for joining the discussion! These are some good points to think about.

Currently the global transport of Mercury doesn't reset when you re-evaluate, it just continues where it was. In the browser only when you hit alt+. it resets to 0, and in Max only when the audio/dsp is turned-off and back on. (This is also something I could align better, maybe both resetting to 0 when alt+. is used).

How I think of it now is that when rescaling the time() it would "jump" to the moment where it would be if that scaling was already effective since the beginning of the transport. This way I can make sure that when removing the scaling factor (or setting it back to 1) the time() is back in sync with all the other instruments.

An additional feature could be that clocks can be desynchronised, allowing for rescaling from the moment of evaluation, but with the risk that things stay out of sync when the scaling goes back to 1.