When using the Play as my setup’s “brain”/master clock and sequencer, the MIDI timing that it sends to my external devices sounds unsteady. Like if it was a drummer, I’d think they were a little drunk and wouldn’t keep the gig because they can’t put down a solid groove.
If I sequenced an external drum machine and the internal sampler to hit a note at the same time, they will often flam.
The correct behavior is to send out a steady tempo.
Reproduction Steps
Open the provided Play song file
Route the tracks to MIDI channels that work for your setup
Press play and listen for a few minutes.
-or-
Hook up the Play’s MIDI out to some external gear. A drum machine and a synth, a groovebox…it doesn’t matter. Just some way that you can send out sequences on 4-5+ MIDI channels simultaneously.
Sequence a typical drumbeat, but give it 16th note hi-hats throughout the pattern.
Sequence a few melodies to different midi channels (for simultaneous playback). We could say “a bass line and 1-2 leads”, but the instrument names are really arbitrary.
Press Play on the Play and listen to the timing for a few minutes. It’s very wonky.
I’m including some audio samples of the drift in action. I added click tracks (in post-production) to some of the samples to highlight the drifting timing.
Occurrence
Every time I use the MIDI sequencing features of the Play.
Hello @adam.pugliese Thank you for reporting this bug. We are sorry you’re experiencing issues while using our product. Unfortunately, we are unable to reproduce the issue ourselves.
Made a new project following your instructions and ran 7 separate sequences into my Eurorack and the MicroFreak, using the Play as the main clock source. There was only a slight difference when the external gear was not all set to 24PPQN.
from Play manual page 164
Could you give us a bit more info about the external gear you’re using with your Play?
In the most civil tone possible, my setup is currently a Play connected to a Roland SH4D. I typically run a more elaborate setup, but I’ve had to pare back my system on an attempt to troubleshoot the Play’s timing issues.
I put time and effort into creating a bug report that includes a project file and multiple audio samples of the issue. Did to happen to check those out? I’m genuinely sorry that you were unable to replicate my issue, but you should consider reviewing the files i included with my bug report. I believe that these may hold insights for you, as indicated in my original post. @Mitch expressed an awareness of this issue on another thread, and suggested that a formal bug report be filed for it. But if you’re saying “cannot replicate” and you haven’t tried my project files or listened to my audio samples, then I’d politely ask you to do a more thorough job.
Hello everyone,
I have encountered the same problem. I want to use the Play as a midi master. My looper (Singular Sound Aeros) is connected as midi slave/ receiver. Unfortunately I noticed that the looper goes out of sync after a few beats/ bars because the midiclock signal of the Play seams to bee unstable/ not even. The looper recognizes all midi signals (Start/Stop/BPM,…). I tried the looper with an Elektron Digitakt (to rule out that the problem is with the looper) and it worked without any problems. After some research in various forums I realized that the problem has already occurred with several people.
Therefore I would like to know if this problem is being worked on. Unfortunately I can’t use the Play as it is. The Play is without question a great device and the people who work on it do a great job. But I can’t use it with an unstable midi clock. I would therefore like to know what is happening with regard to this. I don’t want to put time into my production if I can’t realize it live with the Play. Thank you very much.
I had contact to the Developers of the Aeros Looper and asked on wich PPQN the Looper is operating. Aeros runs at 24 pulses per quarter note (PPQN). So this matches with the Play.
I recently bought a Polyend Play and encountering the issue of a wonky clock as well. My current setup consists of two midi instruments. Sequencing them from the Play doesn’t give issues, as they are only midi notes and no clock data.
The problem occurs when hooking up anything clock-related. I first noticed it when connecting an Arturia Keystep Pro from the Play (so the play sends transport and clock data to the Keystep Pro). There is a bpm indicator on the Keystep and it constantly jumps around. Let’s say I set the Play to 125 BPM, it will juggle between 123 to 128 BPM.
This issue is even more present when hooking up euorack gear. I have used the Keystep Pro as a midi to CV converter (set to 24 PPQN clock rate output) and tried the ALM Busy Circuits mmMidi (midi to clock & CV eurorack module which has 24 PPQN clock output) as well.
I tried to clock of these midi to cv devices to clock Pamela’s New Workout as well as the Abstract Data ADE32 Octocontroller, which are both clock divider/multiply modules. When I set them to produce a trigger on the start of every bar, both of these modules produce a very unstable trigger, resulting in off-beat triggers or skips.
I tried to re-organize my setup in a way that the Play is not the master clock, to see if this fixes the problem. For example, I have used both a Keystep Pro and the Empress ZOIA as main clock, and setting the Play to use the clock coming from the midi input jack. This makes the clock coming out of the Play a little bit more stable, but still results in wonky clock output. This leads me to believe that it isn’t only the clock coming out of the Play that is wonky, but a clock coming through from another device as well.
Maybe good to know that I have a midi keyboard hooked up to the play as well for midi input notes. The keyboard doesn’t send clock data
Did some more trials, it seems that there are two things that influence how sturdy the clock output is.
The overall tempo seems to influence how much the clock output jumps around. At least in full bpm numbers. Up until 100BPM seems fine most of the time, around 115 it starts to change one BPM lower and higher than the original, above 150 BPM it jumps around two to four BPM.
I say “at least in full bpm numbers” because I assume that the jumping is a percentage of the tempo, so while the clock on the receiving end displays 100 BPM, my assumption is that is actually jumps between let’s say 99.5 BPM and 100.4 BPM. If we take this example of a 1% inaccuracy of the BPM, when you change the BPM to 160 it will jump between 158.4 and 161.6. Again this is just an assumption and have no clue if this is actually the case.
Then the more midi is send to the output, the less stable the clock seems to be. Note that I only tested it with my Play > midi/cv > eurorack setup described above, so it’s purely based on hearing but I believe it is clearly noticable (I can make a video if that helps).
To reproduce, fill all the midi lanes with a note on each grid step, with each lane having a separate midi jack channel output (I tested with lane 1 have midi channel 1 as output, lane 2 having midi channel 2 etc.). Mute all the midi tracks and add a simple sample sequence to keep track of the rythm, like a kick on each bar. Start the sequence and unmute the midi lanes one by one. At around five playing lanes the clock gets more jumpy, unmuting them all has a audible effect with the clock being all over the place.
As for the flamming**
This will always be an issue with every machine that can play samples and also sequence other midi gear. It needs to have latency compensation parameters. Polyend added it to the tracker+ but it doesn’t work. It needs to be on both machines and it needs to work. Its an innate issue with how midi works in general. All machines being sequenced have different internal latencies(very small differences) and they need to be compensated for. There is also ALWAYS going to be latency when the machine sends midi out its port compared to when the sample plays internally unless polyend is compensating for this internally. Kinda not easy to do and is best handled by offering compensation params for user to dial it in. This is how your daw works for a reason.
“Then the more midi is send to the output, the less stable the clock seems to be.”
Unfortunately this is an issue with any MIDI sequencer that is also sending MIDI CLOCK over classic DIN cables. MIDI over DIN connectors runs at a glacial 31250 baud - that’s basically 3125 characters per second. Each MIDI message is multiple characters long. When you enter a big chord in your sequencer manually, technically all of the notes should sound at the exact same moment in time. Because of MIDI’s slow serial connection though, all those notes will instead sound in a sequence from first to last as decided by the sequencer.
When a sequencer is trying to pump out a dense stream of note messages, especially with CC data like pitch bend messages, over such a slow serial connection, there will always be jitter. Add to that the challenge of trying to insert a perfectly spaced MIDI CLOCK message into that stream and it’s inevitable that some messages are going to get nudged in time, reducing their timing accuracy.
MIDI 2.0 has features to reduce jitter and can run over very high speed links making these audible jitter issues largely disappear. With classic MIDI connections though, we are stuck with it, like it or not.
