Empty loop becomes Master after Record?

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).

jeff

"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."

Yes, I've heard some impressive polyrhythmic and "soundscape" things where you don't want everything locked to the same beatbox-style tempo. Most polyrhythmic things (think Steve Reich or Philip Glass) are actually at "compatible" tempos, they're just of different sizes so they go in and out of phase with each other but over time come back to being in sync momentarily before diverging again. But somewhere there is a lowest common denominator "beat" length that ties everything together. In Mobius-land that comes down to picking what subdivision of the Transport you want to be the "unit" and then build loops that are multiples of that unit. You're still technically syncing with the Transport but the results will sound wildly out of sync because they're all of different sizes.

Truly amorphous ambient stuff might be the only real reason for Track Sync. Some tracks follow the transport and have order. Others form one or more little groups and do their own thing without bothering with the Transport. They're still related to each other, they just don't share the Transport "unit".

jeff

I was going to blow out another long winded post about Input Monitoring today, but it looks like it's turned into Synchronization day!

One last thing about sync, then I need to finish some monitoring things...

This goes back to the notion of parameters being something you have to set up before you do something vs. doing something and asking that it behave a certain way at that moment.

For the things you do, how useful would it be to choose the sync source for a Record in the binding for the Record rather than having to pick a TrackSyncMaster first. That's about what that script is doing, but maybe doing it without scripts. It would depend on how many buttons you can reserve on a controller for variations on Record vs. more tapdancing to setup parameters which also require buttons on a controller. Something like this:

* Record(1 hostSync)
* Record(2 trackSync 1 makeThisTheTSM)
* Record (any trackSyncTSM)

So one button to to a host sync recording in track 1 and another to do a track sync recording in track 2 and having that become the TSM. And then a third for the remaining tracks that would then sync with track 2. . Or variations on that theme. The bindings become less generic and more designed for a particular workflow you have at that moment. They're basically mini scripts but you're not scripting, just saying which parameters you want to have in effect when you Record on this button.

This would argue for bindings being able to live in the Session rather than being shared across sessions. Think of the session as being the "song" you want to perform or workflow you want to use with a certain track configuration, and a certain binding configuration for the controller you're using.

alexs1

jeff For the things you do, how useful would it be to choose the sync source for a Record in the binding for the Record rather than having to pick a TrackSyncMaster first.

I think in general it could be a good idea. In my own setup though, I use a single sustain pedal connected via TS to an MPK MINI to send a CC for Record, which is kinda why I’m hoping the script can work since it allows me to select any track first and then use the pedal to establish the TSM with Host Sync and the rest follow suit.

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

With the track dependency bug out of the way, there is yet one issue preventing the FanC Record script from being fully stable:

sometimes, the initial recording will wait an extra Host Bar after performing the sync source switch. For example, on a track that's default syncSource=Track, when I trigger the script, it occassionally waits an additional bar of syncronization from the host before starting the recording. I couldn't replicate it when trying different button-press timings, the holdup seems to happen on a whim.

jeff

Ugh, I'm getting very close to scrapping the way synchronization works and starting over.

I've been distracted lately, so let me make sure sure I understand what is happening here...

Starting with all tracks in Reset, and the host transport running.

You want the very first track recorded to use host sync since there is nothing else to sync with. This track immediately becomes the TrackSyncMaster. All other tracks then sync with the TSM rather than the host.

If that's the case, then then FancyRecord script I posted before is more complicated than it needs to be. It doesn't need to look for tracks that are using host sync, it just needs to see if there is a TrackSyncMaster or not. If there is a TSM, use it, if not fall back to Host sync.

#name LessFancyRecord
if trackSyncMaster != 0
   syncSource=:track
else
   syncSource=:host
Record

Starting in build 45, there is a better way to do this. You can use parameter overrides in the function call that apply only to one use of Record without changing the parameter globally for other tracks.

if trackSyncMaster != 0
   Record(syncSource=:track)
else
   Record(syncSource=:host)

But this is just a simpler way to get the recording started, it won't solve the problem of the extra host bar wait.

Approximately where are you in time when you press the button to run the script? If it is very close to the edge of the host bar, then even if you're just a millisecond past the bar start, you'll still wait a full bar. If you're running the script at least a beat ahead of the bar, then there shouldn't be a problem.

Maybe it was related to the script jiggling the syncSource before recording. Instead of all tracks defaulting to syncSource=Host, have them all default to syncSource=Track. It shouldn't matter because either of the scripts above should override what was in the session. But it would be good to rule that out.

alexs1

jeff #name LessFancyRecord
if trackSyncMaster != 0
syncSource=:track
else
syncSource=:host
Record

Yeah, that way could work, I'll start using this instead of the one with the LoopFrame variable.

jeff Approximately where are you in time when you press the button to run the script? If it is very close to the edge of the host bar, then even if you're just a millisecond past the bar start, you'll still wait a full bar. If you're running the script at least a beat ahead of the bar, then there shouldn't be a problem.

I am pressing it at least one or two beats ahead of the bar and still experiencing the delay. Still the case with the two examples you posted.

« Previous Page