First and foremost, kudos to the Organelle team for Ypolimenti – this may be my favorite Polybeats implementation yet!
I do have one inquiry for frequent Polybeat users, however.
Does anyone else find the sync timing of Polybeats (in all its implementations) somewhat laggy? The Organelle gets a single midi pulse from my TR-8 drum machine, and I find it exceedingly difficult to get Polybeats samples to play in time with say, even something as simple as a quarter note pulse. No matter how many times I tap in sample playback (admittedly, my rhythm isn’t great, but give me enough times and I usually get it right!), Polybeats playback feels like it comes just a hair after the quarter-note pulse I’m trying to lock to…
Anybody else have this experience, or is something else at play?
All I can tell you at the moment is the polybeats module in orac syncs up perfectly with some other sequencer modules but that makes sense bc everything is sharing the same clock. Also I’ve had the organelle synced up to other devices and seemed to play in time, but now I’m not sure if I maybe had issues at one point. The new seq3 patches are supposed to sync up perfectly tho.
On polybeats I’m wondering if it’s bc there’s no transport send/receive - I was thinking, could that mean that, even if the clocks are synced to the same tempo, that they are somehow slightly off in terms of where the beats fall? But really idk but I love polybeats! I had this issue with my arpeggiator patch at one point, actually - not sure if I ever solved it but now there’s the seq3 version so maybe similarly, a polybeats that works w transport might solve that, if it is the issue.
So I had a short peak at the c&g metronome (edit 2: metronome 360) sub-patch and what may (theoretically) pose a slight problem is the following: The midirealtime-in signal (248) is not taken as a direct impulse, but used as the basis to calculate the clock speed. Meaning: Sub-patch counts the impulse over time and then calculates what the clock speed should be. Now, C&G are using a pretty sophisticated way to do this, but as midi is prone to clock drift, it does seem at least possible to me that you may get some (minor) timing issues. (yet you report major timing issues…so…?)
Because C&G uses their metronome sub-patch in all of their newer “clocked” patches, you could check if you get the same timing issues in all of their patches. (edit 2: i’m mistaken here, ypolimenti uses a different metronome sub patch) If not, your issue could also result from samples not being sliced neatly and therefore not triggering in time… Or maybe, you have some latency-issues in your setup.
To be honest these two options seem more likely to me, as I assume other people would have addressed an existing syncing problem.
EDIT: I just checked POW WOW Polybeats on my setup and it was nearly spot-on regarding timing. Therefore I think the issues does not lie with the patch itself… After re-reading your comment, may I ask how to do sync your organelle with the rest of your setup?
I just checked the arp-synth as well and yes, timing was a bit off for me as well (not horribly, but distinct enough to notice). Will explore further to see where the problem may lie… (and if I am to blame )
If it’s any help, the offset seems to change when the patch is reloaded (while still receiving clock from an external source) - that’s why I thought the issue might just be the problem of the tempo sync being on, but the beats themselves not falling together. That’s why I initially thought the issue was clocks being synced afa tempo, but beats not falling together. Thanks for looking into it, really curious to hear what you discover!
DeadFarmer’s comment about offset hit home for me, actually.
The sync timing itself, once started, seems solid and consistent. Though I can see the bpm clock wobble by 1 bpm or so every now and again – likely due to the abovementioned midi jitter – once Polybeats gets going its playback timing is consistent.
Getting that first sample to play “on beat” however, is where I struggle. No matter how sure I am of my timing, Polybeat’s first sample playback always seems to, I dunno, slide forward by 5 or 10 ms, giving me a consistent, if somewhat off-beat, performance.
Yes, I do experience the timing issue with Ypolimenti.
I did another quick test trying to remove my horrific timing from the equation.
TR8 -> Keystep -> Organelle
TR8 starts Keystep’s sequencer, sending midi notes to the Organelle.
Using something like Basic Poly, if I program the Keystep to send note data on, say, the 2 and the 4, Organelle playback lines up with the TR8’s quarter-note hihats perfectly.
If, however, I use the same Keystep sequence to turn on one of Ypolimenti’s samples (one with a fast attack), playback is almost always behind the TR8 beat.
Not trying to bring back a dying thread – Ok, maybe a little.
Just an update:
First – those new AcmeSequencer and 16-Step Sequencer patches (lovely, btw) sync perfectly with my Organelle. I thought, perhaps, the fact that I was running TR8-> IConnectMidi 4+ -> Organelle might be introducing latency, but that doesn’t seem to be the case.
Second – the updated Ypolimenti patch, which obeys midi start-stop, lays bare my problem. If I set a sample to play quarter notes, then start the whole shebang by sending a midi-start from my TR8, the Ypolimenti/Polybeats sequence SEEMS to start in sync, but actual sample playback fails to start on the first beat… it slips to become something closer to a backbeat
I stumbled upon a few things, while testing the different patches (setup Organelle synced to Ableton via mio4 midi-hub and a mio connect)
Yplomenti uses a different metronome-patch (metronome 360) than the other polybeat patches (master-metronome). Therefore issues with this patch may differ from issues with other polybeat patches…
(Sidenote: What i said in my post before regarding counting, then calculating the bpm and triggering samples based on that number applies only to this subpatch (and even here I’m not quite sure, as Yplomenti is a really complex patch))
Regarding your issue, I found these two “limitations” regarding the polybeat patches:
If you have Polybeat Pow-Wow (or DRV) playing a pattern while using the internal clock and then throw a external clock at it, the pattern will only sync if you start the external clock exactly on beat with the interal clock (I got it maybe 3 out of 5 times)
If you trigger an external clock and hit a key at the same time, the sample will only be in sync if you time it to the already running internal clock (which starts automatically as soon there’s no external clock).
Regarding the Yplomenti-patch : It was syncing up nicely for me, so not sure what the problem could be. Only thing which was a bit weird was that the external BPM was only displayed correctly after a bar. Yet as sample-playback was in time, I assume the patch triggers samples not based on that number…
Just a quick thanks for taking a look into this! Was starting to question my sanity… It is nice to know that latency from the midi hub doesn’t appear to be at play.
Will play about with some of your observations and add to the conversation if I discover anything.
but I love polybeats! I had this issue with my arpeggiator patch at one point, actually - not sure if I ever solved it but now there’s the seq3 version so maybe similarly, a polybeats that works w transport might solve that, if it is the issue.
)