Winter (and build 42) is coming

jeff

It's been awhile since I had anything significant to say, so I wanted to reassure the few of you that remain that Mobius hasn't been put on a shelf again. Besides documentation, I've been finishing up a large new feature that I'm rather excited about but is taking longer than I expected. The feature is called Snapshots and it replaces what Mobius 2.x called Projects.

A Snapshot is like an old Project in that it saves the contents of all tracks, both audio and MIDI to the file system. It is unlike a Project in that snapshots are saved automatically inside the session so you don't have to fiddle with a file browser to pick a location where you want to save or load them. As you perform, you can just press the New Snapshot button several times, and everything that was happening at that point will be saved. Later you can go back and browse through the list of snapshots you created and resurrect them to get back to that moment in time. One of the snapshots may be designated as the Startup Snapshot which will be loaded automatically whenever you launch Mobius, this is useful if you want to use pre-recorded MIDI drum sequences, or audio backing tracks. It is closer to what DAWs call a project (or what Ableton calls a Live Set). Sessions have not only a bunch of configuration parameters, but also have track and loop content you can use as the starting point for a performance.

During performance, you can also use snapshots as a sort of "multi track undo". Say you've spent a few minutes building up 8 tracks that are all doing something different. Press New Snapshot. Now start hacking on those tracks, do some overdubs, do some re-records, change speeds, whatever. After awhile you don't like what you hear and want
to get back to the last thing that was nice. Press Prev Snapshot. Everything you did after the last New Snapshot is reverted and you're back to where you started.

Hopefully that gets people thinking, I've been having fun with it, but let me know how you might use something like this, and how you think it should behave.

alexs1

jeff

Snapshots sound awesome and useful. An immediate question that came to mind is whether this "Revert" on the fly concept can be Quantized? Will it take significantly more CPU/RAM to store Snapshot states while performing?

alexs1

What is the meaning of life, the universe, and everything else?

-Build 42 0_o

jeff

alexs1 Loading a snapshot cannot currently be quantized but that will be possible eventually. You can get close to that with a script by doing

wait loop PrevSnapshot

What makes this complicated is related to your other question. Yes, it is significantly more CPU intensive to save and load a snapshot than it is to make or undo a loop layer. Since we're dealing with the file system and potentially large files, this can take a long time, so even if the operation was quantized, there will be a lag between when you want it to happen and when it actually finishes and is installed back in the audio processing engine. It's sort of like audio interface latency but much larger. If you're syncing with the host for example, after loading a snapshot, it would need to be fast forwarded a little to bring all the track playback heads back into alignment with where the host is, as if it had all happened in an instant. Possible, but complicated.

So for the near future, restoring snapshots will be mostly useful if you're not trying to sync with something. If you're performing without sync, I'll try to make it so the transitions happen without clicks and pops, but you may notice slight timing irregularities depending on how much content has to be moved around.

A nice side effect of all this was I was able to do that "drag from Mobius into the DAW" thing you asked for awhile ago. As we talked about before, drag-and-drop between different applications can only use files, I can't give the host a big block of audio data in memory. When you click-drag on a loop in the Mobius Loop stack, it starts creating a mini-snapshot containing just that loop in the background. Then you drag a file name from Mobius into the host. If this loop save finishes before you release the mouse button over the host, the host will read the file and it transfers. If you get there before it finishes, the host will give you some kind of "file not found" error, and you have to try it again more slowly. It isn't perfect, but it works pretty well for smaller loops and is near instant for MIDI.

Oh, and yes, saving MIDI tracks to .mid files finally works. Audio tracks now save as 24-bit .wav, and can loaded from any format of .wav, .aiff, .ogg, .flac, or .mp3 files. So you can finally import all those Taylor Swift .mp3's you have in your iTunes library as Mobius loops 😃

alexs1

jeff A nice side effect of all this was I was able to do that "drag from Mobius into the DAW" thing you asked for awhile ago.

Very exciting! This will make for a huge workflow improvement, thank you for thinking of it.

Not to bother you, but is there any chance of an intermediary hotfix for some of the bugs before b42 (if not, no pressure)? Besides some other minor behavior, the main bug causing obstacles for me currently is the Loop Switch Glitch. I have some creative ideas on how I'd like to start using loop switching, I just need the function to be able to quantize with host sync.

Leftyloopy

Glad to hear about things moving along. Ironically, I still havent made the move, even though I do have Mobius 3 on another PC. I had a big pause, because of not figuring out how to make some scripts that I use in 2.5 work in 3 with outputs assignments, group scopes and such.
I'll be asking about those things again in the future once I restart the experimenting. I did also have some issues I mentioned about loosing sync, but can't recall now well.
Anyhow, I haven't abandoned it, just keeping 2.5 actively in the meantime.
Thanks for the journey, Jeff 👍

Howldin

Very exciting, Jeff! I’m particularly interested in the “drop into DAW” feature. I also echo the requests from alexs1 that the LoopSwitch Glitch, and Leftyboy’s holding off on a deeper dive into 3 because of “not figuring out how to make some scripts that I use in 2.5 work in 3 with outputs assignments, group scopes and such.” I’ve been coming back to 3 frequently, but in several respects it is in a way that is less sophisticated and less useful than what I was doing with 2.5 - but to be clear, that is largely due to my failure to spend the concentrated time required to grasp the new scripting language, or even get my thoughts about things I can’t do sufficiently clear to post about.

Lastly, it is great to know you are working on such useful feature additions.

jeff

Thanks for the comments...I've started on the "Loop Switch Glitch", I see several things wrong there.

Regarding 2.x scripts that don't work in 3, if you can post one of those I'd like to see it.
There are a few cases where 2.x scripts would have to be rewritten to use the new script language, but I'm trying to avoid that when possible. Group scopes and output assignments should work though.

For output assignments, are you using the script to set the track output ports?

   set outputPort 2

For group scopes, were you using it like this?

   for groupName
        ...do something...
   next

Leftyloopy

So, for example, one of the scripts that we use is to change outputs to tracks that have been grouped. Besides that I am yet struggling being able to change the output at all (but that's a different problem), here's the example in .mob:

`
!name Toggle output 3

if outputport = 0

set outputport 2

message Output to Mixer

else

set outputport 0

message Output to Mobius Master

endif
`

Also trying in .msl doing just scripting this (without trying to scope it to a group, which i also had failed)

set outputPort 2
doesn't do anything and even before saving it, when compiling it shows Warning: unresolved symbol set.

Am I doing something wrong?
Thank you!
G

jeff

Ugh, ports. The problem is that in scripts, ports are numbered from 0. So if you have 4 ports
configured, you refer to them with the numbers 0, 1, 2, and 3.

In the UI though, we display them starting from 1, the thinking here is that non-programming users aren't used to seeing 0 as a port number, they expect to see 1 to mean "first".

So we have a numbering inconsistency depending on where you are looking. I don't remember how old MOS scripts numbered ports, I thought they were also zero based but maybe not. So with that in mind, I was able to do "set outputPort 2" in a MOS script, and it went to the right place, it's just that 2 means "the third port" not "the second port".

If you wanted to do this in MSL the syntax would be

  outputPort = 2

The biggest difference between 2.x and 3 related to ports is the way in which you configure them. In 2.x you would select an audio interface and it would automatically add numbers for every port that interface supported. So if you had an 8x8 interface, there would be 4 stereo ports in each direction numbered 0-3.

In Mobius 3, the UI I use to configure audio devices is provided by Juce (a tool that I use) and there it is a two step process. You first pick the output device you want to use. Then UI then displays a list of all of the available channels and you have to check the boxes next to the ones you want to use. It won't automatically include all of them. So again if you had an 8x8 interface and you wanted Mobius 3 to use the same port numbers as 2.x, you would have to check the boxes for "Output 1 + 2", "Output 3 + 4", "Output 5 + 6" and "Output 7 + 8". Each channel is grouped into a stereo pair and each pair is a Mobius port. Only the channel pairs that are checked will be assigned port numbers.

So, If you had only the boxes checked for "Output 1 + 2" and "Output 7 + 8" "Output 1 + 2" would be Mobius port 0 and "Output 7 + 8" would be Mobius port 1.

If you are using Mobus as a plugin the process is different. There you configure the number of ports the plugin will advertise to the host in the Configuration->System Configuration popup window. There are two fields labeled "Plugin inputs" and "Plugin Outputs". If you want 4 ports in each direction you have to type the number 4 in both fields.

If your scripts does "set outputPort 2" that means "use the 3rd output port" and the value of Plugin Outputs must be at least 3.

Leftyloopy

Yes. I am aware of those to details because in 2.5 the ports also started from 0. And I checked by looking at the.xml file. In there, they also show from 0. Regarding the pairs activated, yes i was also aware. When I changed from the session settings I can change the output to out 3 and it works, but not from the scripts to port 2. I won't be back to keep trying until the evening pacific time, but I'll keep trying.
Thank you.

jeff

Its possible I may have fixed something in my work builds that isn't in build 41 from the website.
If you want to try that script in MSL it would be:

#name Toggle output 3

if outputPort == 0 {
  outputPort = 2 
  Message("Output to mixer")
}
else {
  outputPort = 0
  Message ("Output to Mobius Master")
}

Leftyloopy

So I was able to compile the .msl you wrote for me. But nothing happens when I execute it, not even the messaging on the screen. I am triggering it from a button to focused scope to avoid any other issues. The tracelog doesn't show anything when execute it, either.
Now, I also tried again the .mos version and the weird thing is that the messaging does toggle between the two outputs, so that would indicate that indeed is working, and in the tracelog I get the "starting script thread 1" and then the "thread 2" but the actual output assignments aren't changing. Mind boggling, at least for me!

I also notice that whenever these failed attempts are produced, the trace logs start showing a lot of "Transport: Drift 320" and others like 448, 384. But I dont think it hsppens when I just lay some loops and mute, or insert or non failed scripts. Mentioning this in case that hints at something.
EDIT: it does drift no matter what. Looks like the clock it's sending out that makes devices slave to mobius transport starts falling behind, the number become bigger as time elapses.

Thank you, at some we'll win !

jeff

Hmm, this probably means that I fixed something in 42 that is still broken in 41. I'll have 42 out in about a week so hopefully that resolves the issue.

The drift messages in the trace log are normal, I'll hide them eventually but I like to see them now. They typically bounce around small-ish positive and negative numbers, but if varies between the different sync sources. 0 is the ideal goal, but with MIDI especially that is never achievable. Clocks will always jitter a bit, but over time it should average out. Due to floating point roundoff and other factors, drift can accumulate if you let a loop play for a long time, minutes or more. When drift finally exceeds a threshold, drift correction is supposed to kick in and make a slight adjustment to bring the loop back into alignment with the source. I say "supposed to" because that is disabled at the moment. It is usually not noticeable unless you are using MIDI sync (in or out) and you leave a sync'd loop running for 20 minutes. I'll fix that eventually. When you use the transport the drift messages are related to MIDI clock generation, not the internal sync that happens when you have tracks syncing with the transport. So if you're not trying to be the master MIDI clock for an external sequencer, transport drift messages don't matter.

If you see drift accumulate rapidly and steadily in one direction, it is a math error on my part and I'd like to hear about that.

Leftyloopy

jeff I say "supposed to" because that is disabled at the moment. It is usually not noticeable unless you are using MIDI sync (in or out) and you leave a sync'd loop running for 20 minutes.

Ok, this makes sense as in 2.5, which we've been using for more than 10 years doing 1+ hours sessions that include several loops that can stay for 1/2 hour easily, we haven't noticed an "accumulated" drift. Mobius has always been our master clock to sequencers and drums, etc. Sometimes, I might trigger a drum sequencer, recorded and mute the live one, to then after a while, bring it again and it hasn't drifted noticeable compared to the looped one. And I would say that those drift messages now in mobius 3 have only positive numbers, and as they go they get higher values. Maybe after 20 min the numbers would be between 1000 and 2000.
Telling you all this so that you have more info. Thanks, as always, for doing this.

gustebeast

Very excited for this. Will it be possible to load snapshots using MIDI bindings? Maybe I could have a script that loads snapshots using the CC value and just name my snapshots 0,1,2,etc