Sync and the DAW (Reaper in this case)

manymanyhaha

Hey Jeff, hope all is well. Haven't been around much lately because I've been spending all of my spare time trying to get my Live Rig to a certain point and I'm getting really close to where I was hoping to go.

I'm curious: When Sync Source is Master and the first loop closes, is it possible to expose the calculated tempo as a VST parameter that Reaper can read?

I'm asking because I'm trying to find a way to eliminate the playhead jitter I get sometimes. You might recall that I use Standalone Mobius and I send Midi Clock to Ableton which then transmits Link to Reaper (via Reablink). It works well mostly except sometimes the playhead skips a step, or goes back a step. Like the last loop I did this morning, Ableton was reading the loop back and forth between 79.50 and 79.51 and that caused the playhead to skip around here and there. Turn off External Sync in Ableton and no playhead jitter. I've been working with Claude to create some custom jsfx that do various things, some of which require smooth playhead movement forward to function as intended. If the tempo were exposed as a VST parameter while using plugin Mobius, I could get Claude to write a jsfx that would take that tempo and make Reaper use it as the BPM. Thus I'd be able to use Plugin Mobius like I do Standalone Mobius, which is using the first loop to set BPM.

Is this something that would be difficult to expose? Of course, if you did do this, I'd need to finally upgrade Mobius to the current build, ha. I'm still on, which is it, Build 28? Anyway, I'm looking at several options on how to eliminate this problem but this is one path that might be easiest to implement. That is if it is something you can do, and can do easily. I don't want to take up too much of your time, especially since I'm going to need some help upgrading my Scripts to MSL soon! Ha.

manymanyhaha

Actually, think I fixed the jitter problem I was having, seem to be running quite nice at the moment. In the future, might be a useful thing if it is possible to expose tempo but no worries if it is difficult to implement or not possible. Still going to be trying to upgrade Mobius past Build28 at some point very soon, would love dive into all the new features!

jeff

Sorry for the delay...

MIDI clock jitter is pretty much unavoidable when generated within a plugin. I try to keep it to a minimum and it might be improved a bit, but there's not much more I can do. The clock receivers for the most part expect this and do their own tempo smoothing so it doesn't often matter unless the jitter is way out of hand. It's fairly common to see the receiver bounce between two tempos that are .1 away, usually it settles on one of them, sometimes it continues to bounce every few seconds. This isn't necessarily a problem but it all depends on what the receiver is trying to do with the tempo. Drum machines generally don't care, they'll make little micro-adjustments as they play their pattern. Hosts might try to be smarter about things depending on what they're doing, but I haven't noticed anything weird in the hosts I test with.

The way the clocks are generated is however done by a high resolution timer thread, that is sensitive to other things going on in the system. It's as close to "real time" as I can get, but may still have periods of instability if the system is under stress.

Having said all that, I did make the current tempo visible as a parameter that can be shown in the Mobius UI, and in your case exported as a host parameter. I don't remember when exactly that went in, but it was after 28. So when you are able to make the jump off 28 it should be there.

manymanyhaha

No worries Jeff, thank you for the thoughtful reply. I was out of town for a quick vacation also.

So I ended up getting a solution together, will describe in case it helps anyone out there. Same setup: Standalone Mobius is set to Out (Build 28/pre-transport Mobius), sends Midi Clock to Ableton, Ableton receives, sends out tempo via Link. Reaper has Reablink loaded at its startup. Here is what I did different. Reablink is now set to Master (instead of Puppet). One can change this by moving the two dashes before the Master line in the code to the Puppet line. Now, when Reablink is set to Master, Reaper will not respond to transport (Start/stop) messages. I need for the transport to be running so in my Reaper Startup Action, I run the Play Transport action before the Reablink action. And then if I need to stop the transport, I have toolbar buttons set up for a custom action that turns off Reablink, stops the transport, and then another to Play Transport and startup Reablink. The result from my last session was awesome. Reaper stayed in tempo without moving Playrate back and forth (which was causing unwanted sounds when it moved). So pretty stoked about this.

The only problem I see in the future is where the playhead sets the '1'. If the transport is continually moving, I can set that possibly becoming a problem when I wipe Mobius clean and start a new loop with a new tempo. If so, I may experiment with this Tempo parameter you exposed, see if grabbing that with LUA might help getting start/stop transport sync going again. That's awesome that you do that.

I'm getting really close to start working on modernizing my scripts to go past Build 28. I'm looking forward to this. Have you done anything extra or different with Slicing? The Slice command in Mobius up to Build 28 has become a very important part of music creation for me, I love it.

And another question, ha: Did you ever get to a place you liked with muting and soloing tracks? Remember you were looking at one of my scripts? No worries if you haven't, just curious what we are looking at for my scripts moving forward. Thanks again, exciting things afoot!

jeff

manymanyhaha

I'm just getting back from another trip and catching up. Need to study your Reaper setup more, but a few answers...

There is no function named Slice so maybe we had something scripted in the past? When talking about slice, this usually means what the EDP calls "unrounded multiply" which is cutting a section out of the middle of the loop or using TrimStart or TrimEnd to lop off sections from the start or end. Those haven't changed.

I did a lot of work on GlobalMute and Solo, so those should work better now.

manymanyhaha

Sorry, not Slice, Shuffle. I have a script that copies a track to other tracks and then uses Shuffle. I use this ALL the time, I love it.

When I was writing this script, it became apparent there were different versions of Shuffle. You could put a /u or a /r after Shuffle and it would Shuffle differently. I think one would Shuffle randomly but use each of the existing "slices" and then the other would Shuffle randomly but randomly use any of the "slices" such that if you did it enough, it would just become the same "slice" over and over.

Anyway, that is what I was curious about. If that all is still the same after Build 28 or if that has been changed or updated? It is now a must-have feature for me, this script I wrote that uses Shuffle.

Anyway, welcome back! Hope all is well. And looking forward to playing with Mute and Solo. When it was working in 2.5, I would hit a button and it would mute all tracks except for the current one and then everything would kick back at the loop start (was using Wait Loop). Fun way to get some dynamics while improving.