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:
Example of devices which ONLY transmit MIDI CLK (0xF8) following a START or CONT message and ceasing after STOP message:
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!