dig65
Yeah, I'm gathering my thoughts on this. A couple of quick points.
I think the biggest problem with perceived density of what is happening in 46 is the way it is being presented in the UI. There are a lot of knobs and switches, but they're kind of all saying the same thing, it's just that different groups of them apply in different situations. The fundamental ideas: quantization waits for a point, sync recording records in pre-defined units, are the same as they've always been. What's different are the exception cases. Do I have a leader or not? Is there a track already generating MIDI clocks or not? And the and the answers to those two questions changes the way you want things to behave.
We used to solve these exception cases by writing scripts. What I'd like to do is avoid having to dump people into scripting, because these kind of exception cases happen all the time.
It's sort of like using what used to be called Presets. There is a preset named "All Tracks Are Empty And I'm Recording The First Loop".
There is another Preset named "One of the tracks is Leading and I'm Going To Follow That".
And a Preset named "This is How a Track Behaves When it gets to be the one generating MIDI clocks"
And a Preset named "This track wanted to generate MIDII clocks but someone else is already doing that".
What those four preset contain are exactly the same things: what am I quantizing to, and what am I synchronizing with.
What is new in 46 that I think makes it look harder than it is, is the notion that quantization doesn't have to come from inside the loop. If all you want is off/subcycle/cycle/loop then a big chunk of things no longer applies. This may seem strange to people coming from the EDP, but for people that haven't and are coming from another multi-track tool of some sort, it's one of the first things they ask. Why can't I wait for my "master clock" instead?
It's similar with the Transport. Literally the first thing I'm asked by anyone that has no history with the EDP or Mobius is "where the hell is the transport". Because everything has one. In part this is because they think they need to be looping on a grid, but even things that allow "first loop" still have a transport. The two biggest examples of that right now are the RC-505 and Loopy Pro. That is what the vast majority of people think looping is. And slamming the EDP in their faces, results in an instant swipe-left.
So we're kind of in a transitional period right now. I want to support all of the same things the dozen older people (there are dozens of us!) know and love, but at the same time provide a user experience that the new people think they want. I'm failing miserably in the UI department, but I need to juggle some of the underlying pieces before I can address that. But you will see more of an emphasis on looking like a DAW or something "popular" and if you want more than that having to dig for it, rather than what we have now which is just the opposite.
But even for the olds, I think the Transport is really a simple concept, it's just that we're not used to thinking about it this way. What did people used to do? They set aside one track with SyncMode=Out and then recorded a one bar loop into that, and let it just run silently forever generating clocks. That's really all the transport is, it's a track, it just doesn't take up space at the bottom. The problem with the tracks-generate-clocks approach is that if you ever want to change the tempo, you have to Reset the track and re-record it which results in a clocking gap. So there needs to be a thing that operates independently as the clock generator. So the Transport kind of behaves as a "tempo holding area" and a track can imprint what it thinks the transport track should look like. Then the audio track can go on it's merry way and the transport just sits there generating clocks and quantization points and record units, until some other track comes along with a different imprint.