EXT switching off in Live, make BPM coming back to the previous value
steps to reproduce :
-choose a X bpm tempo with EXT off
-switch EXT on
-tempo goes from X bpm to Y bpm
-switch EXT off
-> Live doesn't stay at this tempo but comes back to previous X tempo.
I am quite sure it's a design choice. OK. why not ? I am looking for a workaround
What I want to achieve is that when I play with others musicians I want to be in sync with them but I still want to be able with my device to half or double (or any division/multiplication) my own tempo.
With regular division/multiplication of the external clock everyone is still "in sync".
For that, my goal is to be able when I want to be clocked to my friend but still able to divide/Multiply my tempo, to :
-just press EXT to have the external BPM
-a device grabs this tempo
-I press EXT off
-the device sets instantanly Live to the tempo received while EXT was on
-and now I can set another tempo accordingly to this one. (it's impossible to change tempo while EXT is on)
So I need when EXT is switched off to instantanly make the global tempo to come back to the value that was received while EXT was on..
But it's impossible to observe with API the state of the EXT button (why??!)
So, I have to use another way to know when the BPM is from EXT or not.
As Source Audio proposed in another topic, [plugsync~] reports the tempo when EXT is on (API cannot)
We can notice that
when EXT is on :
the BPM reported by plugsync is fluctuating very quickly after 2 or 3 decimals. I know it's a normal behaviour.
when EXT is off :
the BPM reported by plugsync is not fluctuating at all and is perfectly stable.
The question is : (sorry for the long post...)
How can I use this to deducte if the EXT button is pressed or not ?
If the tempo outputted by plugsync is moving very very quickly after the 3rd decimal :
-> detect EXT is ON and grab the current tempo ( a mean because it is fluctated a lot)
If the tempo is not fluctuating very very quickly after the 3rd decimal :
-->detect that EXT if OFF and instantanly set Live's tempo to the tempo received when Ext was on.
Maybe this "detection" should be done during a choosen duration (if there is several fluctuations within 1 second for example) to avoid the detection to be triggered if I manually change my tempo..in this case the BPM will change but will not "fluctuate" quickly during this second...
(a side problem will be to make a difference when the tempo is fluctuating quickly beacause of the EXT sync or because a tempo automation, but it's not the main problem here...)
I hope I am clear enough... :/
thank you !
If you want to perform multytempo get rid of
all nn metro things.
you can use absolute tick count linked
to any clock source and switch between clocks
But input of MIDI clock ticks is not available in M4L devices...
I almost manage to make a workaround, it's not very elegant but it seems to work...
ticks count is nothing else than counter set to progress using tick interval.
If I understand correctly, getting it from plugsync~ which is linked to
live's transport, no matter if clock is internal or external is so called
synced clock, and on the other hand "my own tempo" would be some other tick progress , generated by whatever.
Why is that not available in m4live devices ?
Regarding ticks from plugsync~ there is no limitation.
You just can't use the ticks from MIDI clock directly, in contrast to Max.
If I remember correctly imp.midi does route realtime messages
were there not also some other 3rd party midi objects available
to overcome Live midi limits ?
Unfortunately non-standard routing like imp.midi (or OSC) induce some unpredictable latency relative to Live's audio buffer size. So it's not useful for time-critical messages.