Empty loop becomes Master after Record?

alexs1

I know this is possible with Mobius' internal transport without any external sync, but is there a way (via configuration or script) to have this work in Host sync? For example, any empty track that I press record to will be 1) synced to Host bar and 2) become the Master for all other tracks set to sync to "Track."

jeff

The way it's supposed to work is that any track that is recorded, or becomes non-empty in some other way (loading from a file, switching from an empty to non-empty loop) is eligible to become the Track Sync Master and should be selected automatically if there is not already a Track Sync Master. It shouldn't matter if that track synchronizes with something else like the host. I'll check to see if that is working properly.

What isn't there without scripting is for a track to automatically "steal" Track Sync Master from another track if the other track currently has it. TSM normally sticks with one track until that track is Reset, or it is moved manually.

alexs1

Ok, I'm willing to try that out. Would I need to set the sync source to host for each track individually and then record to designate the Track Sync Master? (But then how would the rest of the tracks become the "follower"?)

jeff

A track can't have both SyncSource=Host and SyncSource=Track. So you would need to configure some for Host and some for Track. Then record one of the Host tracks, the first one should become the TSM. Now the tracks with SyncSource=Track can sync with that one. Is that what you wanted?

alexs1

jeff

Sort of. My idea might be more complex; I want to have all empty tracks listening to host tempo so that when I press record on any one of them, it will sync to host, and the rest which were set to host would automatically be set to track, so when I press record on another empty track, it will then follow whichever track was recorded first as the master. It feels like a job for a script, but I don’t really know how that’d look. Could be a proper use for overlays?

jeff

Interesting concept. Parameters that start with one value but can change to another in response to something that happens in another track. Sort of like the follower options. Or maybe "conditional parameters" like

   if trackSyncMaster == 0
      syncSource = host
  else
     syncSource = track

It could also be another use for Event Scripts. A script that runs whenever trackSyncMaster changes its value.

Overlays would provide a way to set syncSource=track in a bunch of tracks, the trick is automating that. If you're willing to push another button after recording that first syncSource=Host track, then an overlay could work.

Without something new, the only way I see to do that now is with a SpecialRecord script you use instead of binding to Record. All tracks default to syncSource=Host in the session. Then what SpecialRecord does is something like this:

      if track is empty
          // the first press, start Record
     else {
        // the second press, end Record
       // iterate over all tracks that are not this one and set syncSource=Track
      }

Let me experiment with that and see what happens.

alexs1

I would be interested to hear the result!

Another alternative solution that might work is to have all tracks' sync source set to Track, then bind a unique Record script that starts off by setting the currently focused track sync source to Host before hitting Record in the following line. Then, since all other tracks are already set to Track sync, I would use a different binding set to Record normally to get them to follow the host-recorded track. That method takes two different buttons though and isn't as optimal if it could be done under one script.

jeff

alexs1 Yes, that's better. The default should be Track and a HostRecord script would be easy

#name HostRecord
syncSource = host
Record

I think it could be made smarter about seeing if there are any other tracks using Host sync first

alexs1

jeff

Yeah, maybe it could check whether there’s a track already in host sync to keep it all in the same binding? In other words, don’t set the sync to Host if the first one has already been recorded.

This isn’t the right syntax, but roughly,

if track = empty
if anyTrackIsInHostMode
Record
Else
if track = empty
set trackSyncSource = Host
Record
End

jeff

I'm seeing room for improvement, but this one is close:

#name FancyRecord
variable anyhost = 0
in all if loopFrames > 0 and syncSource == :host anyhost = 1
if anyhost == 1 {syncSource  = :track Record} else {syncSource = :host Record}

That's working for me as far as picking the right syncSource, but sync recording in general for the track sync seems to always be using Cycle rather than Loop as the sync unit. I'm looking into that, but if you get a chance try that script and see if it's close. With this one, it doesn't matter what syncSource is set to in the Session, it will force it to either track or host depending on what it finds in the other tracks.

Script syntax digression since this isn't documented...

When I use a word that starts with a colon like :host that is a "keyword symbol". That is what you need to use when setting or testing parameters whose value is not a number. Those are called "enumerated parameters" or just "enumerations" and they have to be set to one of a small set of names. You can also test and set them with quoted strings like this:

    if syncSource == "host"

But I usually use keyword symbols since it saves a character for that ending "

If you've used old MOS scripts, you didn't have to do that, you could just write

    set syncSource host

In MSL however, any unquoted word is treated as a reference to a variable or parameter with that name. And since host is not the name of a variable or parameter it will cause a compilation error.

Another difference between MOS and MSL is the difference between = and ==. This is another one of those things that programmers understand but non-programmers often miss. I hate this, but haven't found a good way around it yet. What = is is the "assignment operator" which is used to set the value of a variable. What == is is a "comparison operator" that is used to test the value of a variable. To help avoid the confusion, you can also use equals instead of == like this:

    if syncSource equals :host

Which reads a little nicer and makes it more obvious what it's doing.

alexs1

jeff

Thanks for the script and updated syntax explanation!

I tried the FancyRecord script verbatim and took some notes. I think close is accurate. The script does set the initial empty track sync source to host and retains track sync for the rest, but there is some odd behavior with what happens during record. For one, it is placing a "Record End 2" marker, effectively acting like Auto-Record in both the initial track and the rest of them. Another is that when I trigger the script in a Track-Sync track after the Host one is done recording, it records double the length of the Host track. The last thing that caught my eye was that on the initial Host-Sync record track, it will set the Unit to Loop so that it's Host Sync Loop, and I usually have it set to Bar by default.

alexs1

jeff

Have you had a chance to look into the delayed-recording behavior from the "Fancy Record" script? I noticed it sets the track to Sync Host = Loop instead of Bar (which is the default Host Sync unit), and I wasn't sure if that could throw things for a...yeah. My other guess is that there is maybe a little buffer in Mobius when it switches sync sources, where it has to "catch on" to the fact first, getting used to counting pulses from the host before entering Record?

alexs1

jeff #name FancyRecord
variable anyhost = 0
in all if loopFrames > 0 and syncSource == :host anyhost = 1
if anyhost == 1 {syncSource = :track Record} else {syncSource = :host Record}

I came back to trying this script again. It has gotten closer with b42 improvements. A track initially set to syncSource == :track successfully turns into a Host Sync track and becomes the TSM. However, when I run the script after the TSM is set, on a different default-Host-Sync track, it will set syncSource = Track effectively, but then it gets stalled on Syncronization while waiting to record based on the TSM loop.

alexs1

@jeff

Well, I feel silly...

Both of these problems were caused by having the MIDI device opened in Mobius and in the Host, so the messages were double and triple-sending, hence the additional loops. You can ignore the last reply.

I re-tested the script, and it is actually working very near-perfectly for this idea. The only problem I haven't been able to resolve is that sometimes the recording will miss the cue to begin and wait an arbitrary number of bars before starting. Incidentally, I've noticed this behavior using Record in a general sense when in Host Sync. That might be worth a separate bug report, unless you know what else it could be?

jeff

alexs1 There was a bug with trackSyncUnit=Loop, I fixed it, but I've been traveling on family business for the last two weeks and haven't had a chance to get another build out. I'll get that out soon.

jeff

alexs1 "I came back to trying this script again. It has gotten closer with b42 improvements. A track initially set to syncSource == :track successfully turns into a Host Sync track and becomes the TSM. However, when I run the script after the TSM is set, on a different default-Host-Sync track, it will set syncSource = Track effectively, but then it gets stalled on Syncronization while waiting to record based on the TSM loop."

I found the bug. It's a track dependency ordering problem, where the TSM needs to be processed first so we know where it's internal sync points will be before we process the tracks that are waiting on it. You won't usually see it if the TSM has a lower number than the track you're trying to record, but you almost always see it if the syncing track has a lower number. It's also because the script is changing the syncSource out from under the part that is making decisions about sync dependencies. It looks in the Session and sees "Host" and thinks the order is fine, but then we change it to Track at the last minute and it doesn't recalculate the dependency order.

I'll have this, the #focused fix, and a few other things out tomorrow.

alexs1

@jeff

screenrecord demonstration.

alexs1

@jeff Have you had a chance to inspect this? It would be great to have this for my workflow.

jeff

I'll look at this again today, but as food for thought, in the next few weeks I'll be doing something related to this.

What it currently means to set syncSource for a track to Host or Midi or Transport is kind of weird. It isn't how any of the DAWs I'm familar with work. Let's start with MIDI sync. In Ableton, and I assume FL Studio, you don't go to a track and say "I want this track to sync to MIDI clocks". Instead you configure the Ableton transport to follow or slave to midi clocks. Tracks do all their syncing to the Ableton transport as usual, it's just that the Ableton transport is getting its tempo and start/stop/song position from MIDI.

Mobius has the same issue, instead of asking a Mobius track to sync with MIDI, it would be easier in many ways to just have the Mobius Transport sync with MIDI and tracks just sync with the transport. The effect is the same but tracks don't have to know they're syncing with MIDI, You don't need to have MIDI sync related parameters (midiBeatsPerBar, midiBarsPerLoop) and you don't need a different UI component to show you where the MIDI "loop" is playing. You just configure and see the Transport starting and stopping. If the transport is connected to MIDI, it starts and stops automatically with the MIDI hardware, and if it isn't connected it freewheels at it's own tempo and you have manual control over it.

What you lose is the ability to have Mobius track 1 syncing with the transport going at 120bpm and track 2 syncing with MIDI going at 93.432 BPM at the same time. I'm not seeing any reasons why you would want to do that, and it adds a lot of complexity to allow it.

Now we can take that concept for MIDI and apply it to HOST sync. If you're using Host sync at all, you're either going to have some tracks configured for Host sync, and some for Track sync, but you're never going to use the Transport and never going to use MIDI sync. Instead, just configure the Transport to follow the Host. When tracks have syncSource=Transport it is just like having syncSource=Host, except that the Transport is acting as the middle man between the tracks and the external sync source.

This reduces all things related to synchronization to three choices: No sync at all, Sync with the transport, and Sync with another track. Tracks don't need to care if the Transport is getting it's tempo from somewhere outside Mobius. AbletonLink is yet another sync source on the horizon, and this would add another axis of confusing sync settings. Letting the Transport be the hub for synchronization simplifies so many things and I think would be fine for the vast majority if not all Mobius users. Does anyone really have a use case for one track syncing to itself, another syncing to the host, another syncing to MIDI, another syncing to CV beat pulses, another syncing to AbletonLink all at the same time at different tempos?

alexs1

Tying all sync sources into Transport makes a lot of sense to me for simplification. As for what the script accomplishes, wouldn't it still require MSL to make any empty default Track Sync tracks sync to Transport (in place of Host) initially and for the rest to be followers?

jeff Does anyone really have a use case for one track syncing to itself, another syncing to the host, another syncing to MIDI, another syncing to CV beat pulses, another syncing to AbletonLink all at the same time at different tempos?

It might make sense for some asynchronous ambient workflows? But if using disparate sync sources boils down to asyncronicity, I feel like that could be done moreso from the technique department rather than technical configuration.

jeff

Going back to your use case that started all this. The notion that a track can have "fuzzy" or "adaptive" sync is so much easier because there are really only these choices:

no sync
sync with transport always
sync with TSM always
sync with TSM first then transport
sync with Transport first, then TSM

For the last two, it depends on which of the TSM or the Transport gets started first.

The need for TrackSyncMaster as a concept also diminishes. TSM exists because in the days before the Transport that's all we had. The Transport is really just a TSM, it's just usually short and it makes no sound. So for many if not most cases if you're just trying to record loops that have the same tempo and "bar" size, you don't need to use TSM at all. Just get the transport started and sync to that. A track can still want to be the TransportMaster to get things rolling by setting the transport tempo after freely recording a loop. But once you do that and the transport starts, you don't necessarily care about any particular track being the "master".

Where you might care is when what you're trying to accomplish is recording tracks that are the size as each other, and that size is a multiple of what the transport thinks the "loop" is. But you could also do that by letting the TransportMaster track control BarsPerLoop in the Transport. In a lot of cases TrackSyncMaster just goes away. You let one track be the TransportMaster and say, "I want the transport to look like me". Then other tracks continue syncing with the Transport.

I'm not sure we can ever get away from the concept of syncing with the Transport and syncing with another Track as being different things, but I think for many use cases they don't need to be.

Finally, there is another way of thinking about what syncSource=Track does. That is a way to do a Record over time and end up with a loop that is the same size as another track. But you can also do that with TrackCopy which is instant. So rather than this:

press Record
wait in Synchronize mode for the TSM to get to the start
record something
press Record again to round off the recording
continue playing till the end or wait in silence

You can just do this

TrackCopyTimingAndOverdub

You instantly land in new loop that is the size of what another track is playing, and can begin Overdub recording over that. You don't need to wait for a sync point, the Overdub starts at the same location the source track is playing. There are of course lots of details to work out on how to control this: what is the source track, do you want all of the source track or some of it? a multiple of the source track? This is more-or-less how loopers like the RC-505 work, or at least give the appearance of working. You're not really thinking about the timing of the start and stop of the recording, you just want to start a new one that is the same size, or a multiple of a source pattern that is already playing.
You can pick up recording at any time relative to that source pattern, it all just magically lines up with a compatible number of bars.

alexs1

jeff sync with Transport first, then TSM

I think this is what the script does in essence currently, right?

jeff TrackCopyTimingAndOverdub

I could see that being helpful in some workflows. I personally like to determine the length by manually starting/ending the recording on non-TSM tracks. I've thought about just setting all tracks to Host Sync, but I prefer having one that sets the stage for the rest (being multiples).