hey just wanted to check you saw the edit in above post, I tried a few different things but it’s always starting one beat (4 16th notes, or 4 “trigs” on my rytm) late. Thinking this can’t be how it’s intended to work…
I’ll take a look… what is sending the MIDI, a sequencer? and is it over USB or the 1/8" MIDI jacks?
the transport is coming from elektron Analog 4, via the thru port on the Rytm, I suppose I should have tried directly connecting - I can try starting it directly transport from Rytm.
I’m on organelle-1 so it’s via usb using the M-Audio Uno, which is known to be working. I could also try the usb from Rytm rather than Midi. I’ll check all this out.
Ok just tried all of the above - transport via Midi Out from Rytm directly (using Maudio Uno) yields same result: bpm sequencer starts one beat later than transport is sent.
Via USB of Rytm didn’t work at all - most likely Rytm doesn’t send transport this way though I have to check, but I think we’ve ruled out external factors that would cause the problem.
Hi there @oweno - thanks for making this new clock, I’m excited about having more than 24 pulses per quarter note. 64th note arpeggios, here I come!
But I’m also having issues with syncing external gear, using the organelle for tempo. There is an offset between when the click module makes sound and when the external gear receives a click. One thing I noticed that might help track it down - if I toggle midi out to off and then on again, the offset changes. If I toggle it a couple times, I can get them to sync correctly. I’m digging around the clock module myself, but you might have a better idea where this comes from!
Another thing is that I see the same behavior with the built-in orac clock module (@thetechnobear). Not sure if anyone else has seen this, or if it’s a peculiarity with my gear. I’m sending MIDI (USB-to-MIDI cable) to a volca keys, and then sending sync out (regular audio cable) to a pocket operator.
This was my first idea (for the built in clock), but it has the same problem as before:
If midiout is enabled, wait for the downbeat and then start sending pulses. (If you can’t tell by this sentence, I’m used to C-style programming and could totally have done it wrong in Pd!)
I fixed it! I saw that the new clock uses the aux button to send the MIDI start message, and that syncs it to the downbeat. So I had the clock wait a few beats then send a start followed immediately by a stop:
Happy to submit a PR for the built-in orac clock, @thetechnobear, if you point me to it. So other folks don’t have my problem :]
@aus10 this is really interesting! thanks for looking into it in such detail and working on it. Will it also work now receiving transport from external gear, or does this just fix an issue with sending it?
I’ll take a look
My assumption is that what needs to happen is:
- on recv midi clock start , reset counter.
- for midi clock send, start should be at bar start.
But I see a number of issue here ( which I’ve commented on before)
A lot of patches / orac modules maintain separate counters from the clock module - so changing the clock will not fix everything.
Delay compensation , has to be generic , as it will be different for different setups. We cannot assume it’s a specific time.
Clock module probably needs to have a tighter concept of master/slave.
I do want to review all these, and internally follow a model that is closer to the Ableton Link model, this works much better for things like joining an active ‘session’ and also drift/jitter.
It’s not possible to get this 100% with midi clock, but we can get better
but as mentioned before this needs almost an almost rewrite for many of the sequencers - not just a small clock fix 
@TheDeadFarmer my fix is only for sending from the organelle, I don’t think it would work for receiving…but I would guess it’s a similar issue - the orac clock is receiving 24 ticks, and it doesn’t know where the downbeat is among those 24 ticks. If it responded to a MIDI start message to set the tick count to 0, that might fix it (I believe that’s what @thetechnobear describes above).
so my post was rather what should be happening… as I wasn’t looking at the code
so now brought up the clock module in orac…
so for receiving midi, I can see…
clock start is being dealt with correctly… it resets the tick to zero.
but clock continue is questionable - it is resetting the clock… but many sequencers would not normally do this however I suspect it doesn’t matter what you do with clock continue, it’ll likely not sync properly.
so your always better to do a full transport stop/start if you want things to sync.(*)
(*) this is not unusual, I find this is true if I try to sync my Octatrack and Pyramid. a full transport stop/start seems to be need to pull them in sync.
(I think the stop behaviour for receiving is largely irrelevant… yes it delays by 1 second, but why care?)
BUT as i highlighted before… there are sequencers that don’t use the master tick it a way that would be compatible with the start/stop behaviour - this is where I expect there are issues.
midi clock sending.
ok, orac currently only sends clock, no start/stop.
and the reason for that is that the internal clock is running constantly… there is no start/stop of the clock.
so there is no appropriate ‘hook’ to put midi start/stop behaviour to…
this is a bigger issue than just midi start/stop for orac,
since this is part of the cause for not being able to sync properly sequencers in different chain.
they cannot start/stop on the bar boundaries, because they do not really share this.
you can’t assume they are going to reset on the zero of 24ppqn… as thats not what the sequencers start/stop are quantised too.
all of this is why I didn’t mess with the clock in orac 2.0, as when Iooked at it.
I realised its not just a quick hack to the clock thats need, rather a rework of how time is handled, and change the sequencers so they then follow this new model.
e.g. it raises questions … is there one time signature, or different ones per chain.
anyone that has messed with polyrhythms and polymeters on the pyramid will understand this gets complex. even on the octatrack, where its simple - we get into the idea of patterns having different lengths but then having the ‘master track length’ to determine when a reset… stuff which confuses many users 
without this… you cannot really handle quantisation (for start/stop) above beyond ‘beat’ , and most expect start/stop quantisation at bars.
(beyond orac, I think its much easier… as they aren’t running multiple sequencers … patches can pretty much just send midi start when the aux button is pressed )
Ok, cool. Thanks for being so detailed with why it’s a complex issue. I think I was just confused bc I thought the bpm modules were supposed to work with sync and transport and that maybe it was a problem with my setup, or perhaps something easy that could be fixed. In the case of polybeats where the organelle was synced up (receiving transport from elektron rytm), but delayed by exactly one beat, I thought, “ok good! it’s just off by one beat, there must be a fairly straightforward workaround or fix for this” but perhaps not the case depending how the module is set up.
hi everyone,
i’ve modified the basic euclid module in orac to work seemlessly with the transport module by ben blash.
used some of his code to do so ( thanks man
no more drifts.
works great with external gear ( octatrack, etc… ).
bests
gaminerie
4 Likes
hi everyone,
also did this
grids module tempo divised by 4 and 2 to main the clock.
transport module compatible.
small modification of the grids module made by ben blash.
bests
gaminerie
2 Likes
Thank you for this update! I just started with ORAC today, but already this is making some of the things I’d envisioned possible.
A couple of questions:
-
I’m going through the demo sequencer patches, and I don’t exactly understand how Punchy in ORAC works vs. the regular Punchy. From what I can tell, in the demos, it acts not as a note generator, but modifies the sequence from the sequencer. Can anyone explain a bit more about how this works?
-
I was trying to play modules using my Keystep into the midi port, but while it works in the regular non-ORAC patches, it doesn’t work when I’m using ORAC modules. Is there a step I’m missing?
And while I’m asking questions…
- What is the “pb range” parameter on ORAC patches? Is there any documentation anywhere explaining the included patches that come with ORAC?
Thank you, any help is appreciated!
I can answer no 2:
There are per-chain midi settings which can be found by pushing the encoder and C# (key 61) then scrolling using the encoder past the slots for modules.
There you will find in and out settings for midi that allow you to have different channels control different chains.
1 Like
Thank you!
The " pb range" is the next most dire question for me. I guess I’ll go watch Youtube videos again and see if it’s addressed.
1 Like
I assume pb range stands for ‘pitch bend’ range
Thank you!! I was like “playback range? peanut butter range?”