Feature Request: ""Song Play Position" and/or MIDI_CONTINUE Implementation

[WarMacre]

At present, I cannot see a way to queue uClock with the Song Play Position, or SPP, of an external synth acting as master clock. For example, using Ableton Live, if you play a 1.0.2 bar (one bar & one 16th note) loop, uClock quickly loses sync and continues to play at the starting tempo but not in time with the beat of the master clock of Live. In short, uClock is not able to receive the position of the playback head in Live.

Methods of implementing this could involve parsing the common system message SPP, and/or utilising the system real-time message 'CONTINUE' .

Song Position Pointer.
This is an internal 14 bit register that holds the number of MIDI beats (1 beat= six MIDI clocks) since the start of the song.

Continue.
Continue at the point the sequence was Stopped. Data byte = decimal 251; hex 0xFB.

[tuulikauri]

I'm not associated with the library, but as a user of it, I believe the library can already handle that. You would just trigger void uClockClass::start() when you receive the 0xFA START messages from Ableton. That will reset all the counters in uClock, and keep your loops in-sync. You're right there's no SPP support in uClock though.

I think the issue may be more on the Ableton side though. Ableton says it puts out START each time the play position changes. Or, SPP in Song mode, but again it's each time the play position changes. I just tested with MIDI-OX and Ableton seems to only do this when manually changing the position, otherwise it only outputs 0xF8 timing ticks, even at the start of loops and bars. In Pattern mode, I'm actually not seeing the 0xFA START messages its supposed to send, only in Song mode... Here's a MIDI-OX screenshot, I've filtered out the 0xF8 messages after a point so we can see the STOP, SPP, CONTINUE messages sent when beat-jumping.

So I would think uClock could handle it fine if Ableton sent information when the loop is restarting, but it natively doesnt, it just sends the timing ticks for tempo, no sync information. Do you have Suite? Maybe M4L could make a MIDI-Start output tool, that can send 0xFA every loop. If not, you could hack it by having Ableton play a specific note (say, 0x907F7F, G9 or G10 noteOn...) at the start of each loop.. and then your sequencer with uClock can detect that incoming MIDI note and call uClockClass::start() when it sees it.

I'm curious what you decide to do and what your use case is, best of luck!

[WarMacre]

I think the issue may be more on the Ableton side though. Ableton says it puts out START each time the play position changes. Or, SPP in Song mode, but again it's each time the play position changes. I just tested with MIDI-OX and Ableton seems to only do this when manually changing the position, otherwise it only outputs 0xF8 timing ticks, even at the start of loops and bars.

Strange. I just tried testing MIDI-OX, but got some strange errors and I could only receive MIDI messages once.

However, when I used the example program "InputFunctionsComplete.ino" under _teensy/USB_MIDI/, Ableton is sending SPP in Song Mode every time I press play and every time I beat jump, so the limitation does seem to be uClock.

[tuulikauri]

Ableton is sending SPP in Song Mode every time I press play and every time I beat jump, so the limitation does seem to be uClock.

If by that you mean uClock doesnt have SPP, you are correct.

But if you trigger uClock's start() function, which it DOES have, at the start of every loop, your loops will be sync'd. There's nothing sent by Ableton at the start of every loop that would tell it it's a new loop; and there's nothing telling uClock how long the loops are supposed to be either. When Ableton runs normally, uClock only receives the 24 PPQN pulses from Ableton.

Theres nothing uClock library can do (even if it did support the SPP pointer, since that would only be a one-time sync...) unless more information is sent from Ableton. Ableton only sends 0xF8 so it's equivalent of a navigator saying "keep going" only, instead of telling the driver to make any turns to drive in a loop... Hope that makes sense, it's kind of a silly analogy!

I just tried testing MIDI-OX, but got some strange errors and I could only receive MIDI messages once.

Hmm. Sometimes I've noticed Ableton being really glitchy with it's MIDI and stopping sending sync messages. FYI, Ableton was originally audio-only, and it's MIDI is it's weakest point as a DAW.
If you print the realTime sync messages with your Teensy you'll see the same thing I have in MIDI-Ox though, and can poke around from there. I believe you are using this library, so you would implement these callbacks to view the realtime messages
https://www.pjrc.com/teensy/td_midi.html

  void myClock()
  void myStart()
  void myContinue()
  void myStop()

Or maybe this one, but it would be easy for you to check void myRealTimeSystem(byte realtimebyte)
Best of luck!

[WarMacre]

If by that you mean uClock doesnt have SPP, you are correctIf by that you mean uClock doesnt have SPP, you are correct

I know. Which is why I requested it to be implemented.

...if you trigger uClock's start() function, which it DOES have, at the start of every loop, your loops will be sync'd

Only if the loop starts at the beat 0 of a bar. If it starts anywhere else, say at beat 3 and the loop ends and beat 10 (7 beats), it will become unsynced.

There's nothing sent by Ableton at the start of every loop that would tell it it's a new loop; and there's nothing telling uClock how long the loops are supposed to be either. When Ableton runs normally, uClock only receives the 24 PPQN pulses from Ableton.There's nothing sent by Ableton at the start of every loop that would tell it it's a new loop; and there's nothing telling uClock how long the loops are supposed to be either. When Ableton runs normally, uClock only receives the 24 PPQN pulses from Ableton.

But, I have already shown that Ableton does send more than 0xF8. It sends clock, start, stop, continue, and song position, as well as a plethora of other messages. When you play Ableton, it sends the beat number position to the slave. This alone is enough to sync a slave device. And at the rollover of the loop, Ableton sends the beat number again of the loop starting position. So, Ableton does send more than the PPQN ticks, because as already stated, it sends start, stop, continue, clock, and song position. uClock, however, can only handle start, stop, and clock (it may be able to handle continue, but with only limited function, as far as I can tell).

Regarding Abletons midi capabilities, I have used it for many years (over 10) with external midi hardware without any major issues. It has certainly never been weak in my opinion In this area.

Anyway, I really appreciate your help. I think I will look deeper into the teensy MIDI USB library and try to get it to do what I need. I started using uClock for its BPM algorithm. But, I can probably work out how to do this with the native teensy MIDI library with a little hacking.

Peace, brother!

[tuulikauri]

And at the rollover of the loop, Ableton sends the beat number again of the loop starting position.

Oh interesting, that's really great. Maybe you have Suite then, and it sends more MIDI out than Standard, or there's a setting to turn that on. In my Standard v. 12.3.5 it only sends 0xF8 when the loop is running. On mine, if you manually jump, it then sends the SPP, but only once; not automatically at the start of the loops. I am thrilled to hear your Ableton is sending SPP every loop. I wonder if mine could do that too, I'll look into it, it would be very handy. Thanks for the tip!

Since you have the SPP data every loop, you could hack uClock too to beatjump around it's sequence; my gut instinct is it's just a matter of editing the tick counter to where you want it (of course, these things are never as simple as hoped...). I've found it a pretty nice organized library to hack though; just an idea.

Best of luck!

[WarMacre]

OK, so I need to eat my words here, or at least some of them. I'm sure that Ableton Live! was sending SPP at the start of the loop when I first tested it. Having tested again, it isn't doing it anymore (and I'm questioning whether it was doing it before, now).

However, on testing with Reason 12, it does send SPP at the beginning of a loop, so this is something I probably need to raise with Ableton. It looks like I will now be testing with Reason going forward.

At this stage, I will go back to basics and work out how to use SPP with the usbMIDI library, and then go from there.

FYI, the way SPP works is like this:-
if you press play (or a loop wraps around) the midi master:

1. sends a STOP message (0xFC);
2. then it sends the SPP (0xF2) which tells the slave how many beats from start the play head should be;
3. then it sends a CONTINUE message (0xFB). CONTTINUE obviously differs from START as START will play from beat 0.

[tuulikauri]

Sounds like a plan! Thanks for the update, I did go on a hunt but quickly gave up since I didnt find any way to enable SPP on loops for myself.

I looked briefly into SPP for uClock as I thought it would be a simple thing to implement, but turns out I misremembered where the uClock library ends. It excels at sending on-time pulses, but the coarsest pulses are 1PPQN. So a pulse every quarter note; it's not a sequencer library so doesnt track anything coarser such as bars, or emit any bar-based events. Since SPP sends position in 16ths, I'm not sure there is any way to implement any SPP tool in uClock, or indeed that it would have a distinct outcome that is different from start() except for the 1PPQN and 2PPQN (quarter notes and 8th notes) pulses which are easily implementable in the host program that uses the uClock library.

Presumably you will have uClock or just the external ticks driving a sequencer program, and it's the sequencer that is receiving the ticks and turning those into a position in a bar / song. This is where SPP should be implemented. You should ignore the 1 PPQN and 2 PPQN ticks from uClock (simply dont implement any callbacks for them) and count the 1/16th (4 PPQN) callbacks at the coarsest (you could also instead count and handle finer ticks; 96 PPQN is not unusual as it lets you implement swing in your sequencer). Then adjust your counter when you receive an SPP message.

Good luck!

[WarMacre]

OK, so I have managed to sync the teensy with SPP from Reason while looping. I have also created a way of calculating the BPM from the clock messages, all by using Teensyduino's USB midi, so I am moving away from uClock as it is redundant for my use case.

Thanks anyway, @tuulikauri . I appreciate the help.