Syncltch + MIDI SPP (Song Position Pointer)

Hi pichenettes,

I’ve been using the MIDIpal for a couple weeks now and love it. As a DSI Tempest user, the MIDIpal helps me overcome some of the drum machine’s current firmware limitations. The Dispatch app, along with a Roland MSQ-100 is an excellent combo for sequencing chords into the Tempest.

The Syncltch is absolutely brilliant! Well done! It is great that you can set the Numerator = 32 and Demoninator = 4, so that you can get external sequencer to only Start/Stop at 8 bar block boundaries.

I have a few questions / suggestions regarding some apps.

(1) Regarding LCD. When using external power, sometimes the LCD has no contrast at all. Turning the power off and back on again fixes it for a while. (Connection issue?) Using 9V battery, the problem does not manifest. Strange.

(2) Regarding Monitor app: does not show any SPP (Song Position Pointer) messages.

(3) I STRONGLY encourage you to process SPP (per MIDI specifications) for both Syncltch and Arpeggio apps also. (And this gets into a larger discussion about the industry as a whole, as I’ve pleaded with Waldorf and DSI engineers to correct SPP / Clock / Arp timing bugs in their products.)

I’ve noticed that many instruments these days do not respond correctly (or at all) to MIDI SPP. What’s going on in the engineering departments???

Many musicians, composers, producers and engineers still heavily rely on correct MIDI Song Position Pointer for linear composition/performance - or in general - the concepts of START, STOP, SPP [CUE] and CONTINUE.

RECOMMENDED PRACTICE for devices with external MIDI-synchable arpeggiators, LFOs and pattern sequencers in response to MIDI SPP and REAL TIME messages:

Use Modulo arithmetic:
seq_clock_ticks = ((SPP % (([# bars in pattern] * 16 * time-sig numerator)/time-sig denominator)) * 6 + [# of MIDI CLKs following CONT message]) * (PPQN / 24)

Otherwise the arpeggiator has no way of knowing which MIDI CLOCK ticks relate to the note triggering. For example if an arp is set to 16th note resolution - and if ignoring START, STOP, SPP, CONT messages - then it probabilistically has only a one-in-six (16%) chance of syncing correctly. At 8th note resolution, the odds are worse; only one-in-tweleve (8%) chance of guessing right. The Waldorf Blofeld is notorious for exhibiting this kind of inconsistent arp timing. Users are rightfully infuriated by it!

On a side note, I’ve found that some gear, while as clock Master, will continuously transmit MIDI CLK, even when it’s in STOP mode. Doesn’t seem to be a bad thing, so long as the slave devices know to ignore any CLKs seen between SPP and CONT messages. Only CLKs AFTER the CONT message should advance the slave’s sequencer position beyond the SPP.
Example of devices which always transmit MIDI clock (0xF8), even while STOPed:
Roland MSQ-700
Roland MSQ-100
DSI Tempest
Elektron MachineDrum

Example of devices which ONLY transmit MIDI CLK (0xF8) following a START or CONT message and ceasing after STOP message:
Roland MC-50
Ensoniq EPS

Also, remember that a MIDI START message is equivalent to SSP=0 followed by CONT messages.

Anyway, getting back to the Syncltch app:
It should respond to SPP+Cont as described above. I noticed that the Synltch app already correctly responds to MIDI CONTINUE message. So you only need to add code to read the SPP and adjust the loop clock position according to the Modulo arithmetic in the recommend practice.

Why is this so important you ask? Because there are many times then you need to restart a master sequencer at some arbitrary point in a song - and have all subsequent slave machines re-cue and sync appropriately. It is a huge issue these days. Back in 1985, every master/slave sequencer could properly cue to any random bars and beat without fail. We lost some essential functionality in modern gear.

Thanks for your time and help!

Regarding (1) I am afraid it might be a problem with your board. If you want to send it back to me, I’ll have a look for a quick fix - or ship you a replacement.

Regarding (2) / (3). Song position pointer is not supported - by lack of equipment in my setup sending it. I’ll see what I can do. In any case thanks for the details!

Thanks for the quick response! Ok, I’ll send the unit back for board inspection.

Seriously, thanks for looking into SPP! It really is important for many musicians.

Roland MC-50s are cheap on ebay - all-around good test tool for many applications, including SPP.

Hi pichenettes, following up.
The hardware issue likely was due to a flaky AC power adapter. I tried a different one, and the unit seems to be behaving now. If I still have trouble, I’ll send back. MIDIpal is so cool, I’ll probably get a second/backup unit soon.

Regarding Syncltch again - It might also be cool to have a CC switch (say #64, #69 or #80) activate/deactivate the Sync Latch, in addition to the encoder button.

So any progress with SPP? I wish they called if “MIDI CUE” instead. This little three byte message only gets sent during a STOP’d state. Sometimes people mistakenly assume it is a continuously occurring message like MTC and complicated, but actually it is very simple. Most DAW-based tracking/sequencing programs can be set up to transmit SPP.

I did read up a bit on the MIDIpal development environment + WinAVR. Having written other MIDI related software in the past - ( MSQconvert ) , I could likely implement these changes. However, you (being intimately familiar with the code base) could make the mods faster. Maybe faster than the time for you to reply in this forum. :slight_smile:

What are your thoughts?

Random note : I just read the Korg Volca Keys (and Beats, Bass) MIDI implementation chart and, sure enough, it processes incoming MIDI SPP for sync. That looks to be a cool little box too!

Thanks again for making MIDIpal!

It’s on my TODO list, but there are much urgent priorities.

Excellent! …and understood, about priorities. Thanks!

Okay, I implemented these features in my customized MIDIpal firmware:


Bravissimo !

Many thanks for your guidance, pichenettes!