Scroll though separate snap values and jog by selected snap step

[iakovkoshkin]

Hi.
I came across the following scenario would be interesting to implement using the advanced functions of AZ Controller.
Is it possible to assign to an infinite knob the selection snap values from Whole to 1/128? And setup the jog based on that selected value?
E.g. I could turn the knob to select 1/8 and then turn another knob or tap pads to move the Now Time pointer by 1/8 back and forth.
The former looks feasible because there are already the commands to set the snap values. Just need to figure out how to map them to the knob, via SW states or other features which I don't have good understanding about.
The latter though have no idea where to look. The implemented jog takes only Measure, Beat, Times, Ticks etc.
Appreciate it if someone already have a solution for that or similar scenario.

[azslow3]

First of all, update AZ Controller. I have uploaded b430, it includes small change for the purpose (selecting the number of Ticks for 1/8...1/32 as jog parameter was not possible).

An example preset is attached, but I am not sure it will work (the explanation below).

You will need to re-assign MIDI (I have used my controller to test).

One control is changing Software State and tries to change Snap setting. The second was not really working in my tests, i use X2... Up to you to test with current Sonar.
There is no was to get current snap settings, so I just try to execute a "Command". It is the same as in Shortcut preferences, if you can create a shortcut to change snap (in "General" bindings), you can do this from surface as well. If that doesn't work, it is on Sonar side.

Another control is using current Software State to issue jogging operation with corresponding settings.

Note the example assumes the project has 960 TPQ (Ticks Per Quarter), I don't know how to get that option from Sonar. I always use 960 (maximum and standard, till you use old MIDI hardware which doesn't support it).

PS. theoretically it is possible to light LEDs under pads as feedback on jog setting change, I mean pad 1 for 1/1, pad 2 for 1/2, etc. But pads should be in particular mode / bank. If snap settings can be changed, you will get the feedback in Sonar GUI, so that is just an idea.  May you you want that for something else, f.e. I used pads for mute/solo, with corresponding feedback. MPK Mini is a bit tricky there and the behavior was never documented, but I guess MK3 still support it.

[iakovkoshkin]

Thank you so much for a great job. Idea with ticks is amazing.
Tried that approach and it works basically correct with some flaw though.
When I use e.g. 8th (480 ticks), first jog jumps from 0 to 480, which is correct.
Next jog though moves the cursor to 512 (not 960 or next 0).
If I took 32th and set the cursor back to 0. First jog moves to next 120, but next jog moves to 128, not 240.
And all subsequent moves use that "Power of 2" approach.
I suspect that somehow connects to the max number of ticks in the list (1024) or maybe something else which has a base of 1024.

Regarding Tick per Quarter value. I'm not quite familiar with all Sonar API aspects, but you may try to find something like ppqPosition or MidiTransport or Host_GetTime in SDK. Also TIMEBASE variable in CAL scripts has that value. Maybe that'd give you some clues.

As far as Pad light goes, unfortunately MK3 does not support MIDI receiving except time sync from the host. Unlike MK2, which does support it. But that's not a big deal anyways.

Thanks for your help!

[azslow3]

Sorry, I have messed with tick alignment. The controller I have used for tests (Novation Nocturn) has horrible encoders, so I have not notices the behavior is not correct.
I have uploaded a fix (b431)

Unlike CAL scripts, Surface API is not dealing with the content at all. Ticks are used for jogging and to display current M:B:T (on devices which can do this), so I guess there was no much need explicitly expose PPQ there. I have checked IDL and I have not found anything.
But there is a good news: Sonar (at least X2) is always using 960 when interpreting Surface API. I mean even if you set 120 PPQ in the Project settings, so 1/8 is displayed as 60, jogging by 480 ticks is still jogging by 1/8...