Author Topic: extended layout/preset for TouchOSC  (Read 10344 times)

Offline symetrk

  • Newbie
  • *
  • Posts: 29
extended layout/preset for TouchOSC
« on: September 25, 2017, 12:47:34 AM »
Hi again...

So I've been working on a version of your TouchOSC layout/preset combo and I'm fairly happy with where I've got it so far but I think I may need a bit of expert advice at this point. It started because I kind of wanted a horizontal version of the layout, to run on a tablet which can be propped up horizontally on its case which folds into a stand. So I started by trying to rotate your layout but keep functionality the same, which led me to some interesting discoveries: a) the TouchOSC editor software does not have any rotation functionality (among other limitations and quirks); b) even if it did, the way you've laid things out would be broken unless I dug into the details of how it works; c) although I think the way you've set things up is pretty clever and quite functional, changing the layout opened up some opportunities to try to do things differenty; d) once I started doing that, it became a very interesting challenge to get things to work the way I wanted them to; and e) eventually, not surprisingly, I ran into things I just don't understand and can't find a way around through my usual method of stumbling around trying things half-at-random until something works. Yes, I'm a musician, not a programmer.

That said, I got a lot of things to work and I'm happy with the direction it's going in. I'm going to try to attach my version of the layout and the corresponding preset for the plugin, so you can see what I've done. (I had to give the preset file an extension of txt for your forum software to accept it, hopefully you can just remove that extension and load it up; if not, let me know and I can send it privately.)

First I added a few little things, like Undo, REW/FF and RTZ/END buttons, nothing revolutionary there - easy stuff, no problem  - though if possible I'd love to get the REW/FF buttons to work as hold-and-release, rather than touch-to-start, touch-again-to-stop as I have them now.

Then I thought I'd try to add a mixer page with 8 volume sliders, and that was a bit more complicated but I think I have it working pretty much perfectly now, at least the way I think it should work, following the WAI around the same way your 'tracks' page does (I reworked that as well to make it 8 channels only, like the Mixer, for consistency).

Since that went well I did the Sends page, which was easy, and then finally dove into the ACT Plugins page. That was a *lot* more complicated. I could have replicated exactly what you've done horizontally, and I still might, but I thought I'd try something different, which is a page full of dedicated and dynamically-labelled knobs and sliders, rather than one single central control whose functionality is switched by buttons as you have it. In getting this working I began to slightly affect the functionality of your existing layout, which I was trying not to do but which kind of happened as a result of me not always understanding exactly what I was doing ;) - nothing is 'broken' per se but, well, you'll see. But in principle the preliminary results are very nice and I think would be a great way to work with plugins if I can get it all to work.

Here's the big problem I've run into: In order to have separate, dedicated controls which can simultaneously control different on-screen elements through ACT, I started to use multiple 'slots' in the preset - where your existing layout uses only one, since there's only one big controller so you can pass one selected parameter at a time to that single 'slot'. I want a lot of controls active at once. I have the first two of each group working - knobs, faders and buttons - and can easily populate the rest of the page (there are placeholders there now), BUT I realized that when cycling through pages to access more ACT controls (for more complex processors), this means I will run out of 'slots' - there seem to be only 32 in the plugin. And of course it would take a lot more of them to handle a processor with many pages of controls, which happens sometimes. So I'm wondering if either a) it's possible to make more 'slots', or b) you can think of a better way to do what I'm doing, or possibly c) a reason why neither is possible so I should give up without putting too much more energy into it.

Finally, I have noticed some instability, which might be a result of my poking around in things I don't fully understand, or may reflect inherent issues in Sonar and/or ACT (which is known to be buggy) and/or your plugin. First, sometimes my layout loses sync with regards to track names and button states - controls still function but the labels stop updating correctly - and the only way to get it back is to load your original layout, sync, change to the tracks page, then reload my new layout, sync again and proceed. This gets it going again, for a while, but would likely be too annoying for someone who's looking for something that "just works" to bother with. Second, since I started working with the ACT page I've managed to crash SONAR a few times, which doesn't generally happen - it's usually pretty stable on this system.

OK that's all I've got for now. If you have a moment to load up and check out what I've done... it might even be interesting for you, and it would possibly help me break through some of these roadblocks in understanding and using your remarkably flexible plugin!

Thanks in advance...

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: extended layout/preset for TouchOSC
« Reply #1 on: September 25, 2017, 05:08:08 PM »
I ran into things I just don't understand and can't find a way around through my usual method of stumbling around trying things half-at-random until something works. Yes, I'm a musician, not a programmer.
That approach is problematic in this particular case... While changing something in music VST can produce interesting effects and in any case will not "break" anything, changing things without understanding within a program (yes, AZ Controller "presets" are not really presets, they are programs) is in general looking for trouble.

I am ready to help you with advises, examples, etc. but any time you should completely understand what, why and how is working. Otherwise the result will not work at all, will not always work and produce instabilities up to Sonar crashes (Control Surface plug-ins was supposed to be written by pro programmers, CW has no protection against wrong using the API, also plug-in programmers had the same assumption about DAW programmers so plug-in parameter controlling should be done "right").

It is hard to understand what a complicated program from other person is doing, my OSC preset is not an example nor simple.
It will be simpler for you  and me in case you write own preset from scratch. Or wait till I have time to make a preset fro your OSC layout.

Quote
Here's the big problem I've run into: In order to have separate, dedicated controls which can simultaneously control different on-screen elements through ACT, I started to use multiple 'slots' in the preset - where your existing layout uses only one, since there's only one big controller so you can pass one selected parameter at a time to that single 'slot'. I want a lot of controls active at once. I have the first two of each group working - knobs, faders and buttons - and can easily populate the rest of the page (there are placeholders there now), BUT I realized that when cycling through pages to access more ACT controls (for more complex processors), this means I will run out of 'slots' - there seem to be only 32 in the plugin. And of course it would take a lot more of them to handle a processor with many pages of controls, which happens sometimes. So I'm wondering if either a) it's possible to make more 'slots', or b) you can think of a better way to do what I'm doing, or possibly c) a reason why neither is possible so I should give up without putting too much more energy into it.
Slots was required to make one fader to work with many parameters, selecting the parameter by button. In your case all that is not needed, "Quick start" approach will work in your case for input, "Feedback for buttons and LEDs" approach can send the feedback from monitoring. F.e. for /actf1:
ACT S1 + <ActBank>*8
Direct Linear
Value Monitor (Ultra, priority 3)

With the monitor definition:

Text ''
Text Parameter value
OSC Send to /actf/1/1/value/label <text>
Function "Mon. par not changed" Final
Text ''
Text Parameter name
OSC Send to /actf/1/1/label <text>

Should do the trick.

Quote
Finally, I have noticed some instability, which might be a result of my poking around in things I don't fully understand, or may reflect inherent issues in Sonar and/or ACT (which is known to be buggy) and/or your plugin. First, sometimes my layout loses sync with regards to track names and button states - controls still function but the labels stop updating correctly - and the only way to get it back is to load your original layout, sync, change to the tracks page, then reload my new layout, sync again and proceed. This gets it going again, for a while, but would likely be too annoying for someone who's looking for something that "just works" to bother with. Second, since I started working with the ACT page I've managed to crash SONAR a few times, which doesn't generally happen - it's usually pretty stable on this system.
See my first comment... You have 5 monitors in /actf1, and 3 in /actf/1/1, instead of one. So you are "hammering" Sonar and the plug-in 8(!) times more then required (I was using 2 monitors because just one was not possible some time ago). Probably you know what usually happens with Sonar when your add 8 times more CC changes on a MIDI track... Here you can get the same effect (each monitor asks Sonar and it asks Plug-in 13 times per second, 24 controls means 24*13 requests per second, 24*13*8 is in kHZ region. Normally not a problem, but some plug-ins do not like that)
Also note that original preset was using "pages" to not monitor/send some information. If you have somehow "disturbed" the schema, "labels stop updating" is an expected  result.

Sorry that my reply has some "negativity", I just do not want that your are "lost" in your own labyrinth  ;)
It is my fault it is too easy to make such labyrinth without visual representation.

Offline symetrk

  • Newbie
  • *
  • Posts: 29
Re: extended layout/preset for TouchOSC
« Reply #2 on: September 25, 2017, 09:03:07 PM »
Hey. Thanks!

No problem about 'negativity' - I get it, and I can imagine it must be frustrating to try to help someone who is behaving like a bull in a china shop with your plugin... And trust me, I know how "problematic" my approach can be in some instances... but I'm afraid you're not likely to dissuade me, as it's basically just my general playful approach to learning and creating and overall it serves me pretty well, and I'm way too old and set in my ways to start doing things differently. Knowing exactly what I'm doing is just not my thing. I break things sometimes, but I have a lot of fun and I very often get things working eventually, sometimes with a little friendly help from people who actually know what they're doing... for which I am very appreciative!

I will take what you've said and look at it some more, and try to not have the preset make excessive calls to Sonar as I do understand (and already suspected) that that's the cause of the instability I've been seeing.

I may see what I can build from scratch with the Quick Start and Feedback starting points, and I'd also be happy if you felt like building something "the right way" around my horizontal layout ideas, but please don't do it just for me - it's really only if you think it might help others who might be interested in a wireless, tablet-based control surface. I don't have a desperate need for it, I'm just interested in the possibilities and genuinely enjoy poking around with things I only half-understand. As long as they're not, you know, physically dangerous.

If one of us gets it going, I'm happy to champion it on the forums and see if I can drum up some interest. I know you are sometimes a little disappointed with how little interest there seems to be in your work, given how powerful and flexible the plugin is. Even though I might be annoying with my resistance to digging in and understanding everything properly, at least I am very enthusiastic and appreciative!  8)

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: extended layout/preset for TouchOSC
« Reply #3 on: September 25, 2017, 09:33:01 PM »
As long as you have fun with that, no problem!  :)

I will try to help you answering on questions and with some tips.

So one more answer, about FF/REW. TouchOSC send value "1" when the button is pressed and value "0" when it is released. AZ Controller tries to ignore releases, since they are useful for minority of buttons. That is implemented by default implicit "Note:ON" condition. But you can explicitly overwrite that condition, so let say for FF, you add "Note:Any" to "Command Start/Stop Fast Forward". That it will be called on press and on release, producing desired effect (for more bullet prove solution, f.e. you can define 2 actions, one "Function Transport/Fast Forward/On" with (default) "Note:On" and "Function Transport/Fast Forward/Off" with explicit "Note:Off")

And one tip: in TouchOSC editor, name controls meaningful. F.e. now you have "/actf1", "/actf/1/1/value/label", "/act/1/1/label" and implicit "/actf1/z".
Better names are "/ACTFader/1", "/ACTFader/1/label", "/ACTFader/1/value/label" and "/ACTFader/1/z". Just simpler to understand what means what in the AZ Controller later:
/ACTFader/1 - That is what TouchOSC will send when you move fader,
/ACTFader/1/z - TouchOSC sends when you touch the fader (before you move), that is a "button", so it also sends it when you release the fader (useful for (re)writing automations in Sonar and preventing sending values when you touch)
/ACTFader/1/label - parameter name text you should send from monitoring
/ACTFader/1/value/label - parameter value text you should send from monitoring
The example in my previous post should work, but it is "not perfect" since "Touch" is not used. I can write you complete working example for one fader, with all "bells and wishes" (if you want).

Offline symetrk

  • Newbie
  • *
  • Posts: 29
Re: extended layout/preset for TouchOSC
« Reply #4 on: September 25, 2017, 09:56:54 PM »
Hey again, and thanks again!

I suspect it will take me some time to make sense of all that enough to put it into action, but I'll do my best. I think I get the FF/REW issue, that's simple, and I do appreciate the value of clear labeling - some of the fairly random naming conventions I used were based on trying to refer to what you'd done but not break functionality with your existing layout, since I was using that as a reference point for everything, but I can see that it's probably better in almost every way to start from scratch and build things the way they should be built for the purpose, rather than trying to adapt what you have done to what I want to do. It's just that that's how I learn, by jumping in and splashing around and trying not to sink. I know, it's crazy, but I'm stuck with it.  ;)

I'll let you know how I get on. Might be a few days. If you want to write up a working example, that would be great too, no pressure...

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: extended layout/preset for TouchOSC
« Reply #5 on: September 26, 2017, 03:12:22 PM »
Unlike with music, in programming every single character should be right!
No one likes when Sonar or other program crash, even musicians. But less people realize that can be a consequence of one single character mistake. May be just a typo, may be it comes from a hurry development or not understanding what is going on (there is such example with TouchOSC, in this preset there is a workaround with an explanation).
So, independent from how you learn things, if you want good working result, everything should be "perfect". From your replies, I do not expect you will follow that rule. But I want you understand which result produce every tiny "bit" in my example preset, and so what will happened if it is not there or set incorrectly. As an illustration to my "philosophical" statements, to show what that means in practice  ;)

I attach TouchOSC layoout (vertical... I only have a phone at the moment) and AZ Controller preset in SPP format. If you attach presets, please do this in SPP using Cakewalk Plugin Manager and not "Export..." in the Options Tab.

TouchOSC side
All essential parameter for establishing communication I have explained in the OSC Phone installation instructions/video. So I just want to mention that "ping" (explained later) and "touch" (also explained later) should be turned on.

In the layout, names are arbitrary. They are not a part of communication. But OSC message names, while also arbitrary, is. As I have mentioned, it is good to keep them organized. To simplify presets writing, it is better to keep all names related to the same Control with example the same "prefix". F.e., /volume -> /volume/label, /volume/origin, etc.; /enc12 -> /enc12/label, /enc12/value, etc.

For buttons, set "Local feedback off". Otherwise buttons will light when you press them and that can be not correct on Sonar side. F.e. "Mute" button for not existing track will light when you press it, but not existing track can not be muted. When you release, the light will go off, even when on Sonar side it should be On (f.e. you have muted existing track). So AZ Controller preset should take care about correct lighting, not TouchOSC.

"Text" and "Buttons" are independent controls in TouchOSC, even when the text is just to label the button. Using proposed naming convention, from AZ Controller perspective they both can be like a one control. F.e. /stop and /stop/label, when /stop is the button and /stop/label is the text. Sometimes more then one text field is desired for one control, in this example /volume, /volume/value, /volume/origin and /volume/parameter are all related to the fader (/volume).

Colors can be controlled, but most of them stay as originally configured.

When "touch" is enabled, all active controls produce /<name>/z messages when you touch them. Obviously it is a bad idea to name some control with "/z" at the end. The same is true for "/<name>/color".

AZ Controller side
Options Tab
"OSC Configure" dialog should have correct values and enable the communication. Explained in OSC Phone installation instructions/video (I have already mentioned that, I know...)

For this example preset, I have defined one "SyncDone" Software State Set, with two states "No" (default) and "Yes". The reason is explain in "/ping" and "/sync" controls.

Each control should be first created in the "Options" tab as a "Hardware control".  In these example preset, there are 4 controls defined. All of them correspond to messages sent by TouchOSC (that is not always the case, controls can be used as a "function" or just for monitoring). Important here are control types:
* /sync is a Button on TouchOSC side, it sends "/sync 1." when pressed and "/sync 0." when released (in OSC world, like in VST and mostly in Sonar, all values are between 0. and 1., f.e. pan center is 0.5, left 0, right 1. In the MIDI world, most values are between 0 and 127, without floating point. So in the MIDI world, pan center is 64, left 0, right 127. AZ Controller is "both worlds" oriented, sometimes MIDI approach is used sometimes OSC/VST one. It is important to realize that when in AZ Controller something like "Value:127" is used, that means "value == 1." in OSC). The hardware type is set to "Pad", because we are not interested in "release" message.
* /ping is a special message. When enabled, TouchOSC periodically (also when just started) sends "/ping". That is used in this preset to detect TouchOSC is started and so it is time to send current Sonar situation to it (labels, values, etc.). Since it is periodically sent, it can be annoying. You modify your preset and than it comes... AZ Controller switch to "/ping" control immediately. To avoid that, it is declared as "System" control. The only difference to "unknown" is not showing the message in the "Last MIDI event" and so not switching to "/ping" control. If you want to see when it comes, you can temporarily switch the type to "unknown" (and then back, the result is immediate as everything in AZ Controller)
* "/volume" is the fader, hardware type "Slider". Unlike "Pad" and "System", there is no special processing. So that is like "unknown" just labeled differently, for clarity.
* "/volume/z" is tricky. TouchOSC send "/volume/z 1." when the fader is touched and "/volume/z 0." when it is released. So from logical perspectives that is "a button". But I find it also annoying - every time you have moved the fader, you see "/volume/z 0." as the last action. So I define touch messages as "system". But there is a consequence... "system" controls have no special "pad" processing, both press and release will be processed by default. See the control definition how to deal with that.

Hardware Tab
Here all 4 controls was attached and assigned ("attach" is for many logical controls associated with one phisical control, f.e. when hardware surface has several "presets" and can send different messages from the same control, that is rarely used at all and make no sense for OSC).

There is one trick to note when assigning from TouchOSC. Since with enabled touch every control sends "/<name>/z" after finger release, when you want to lean the control itself "/<name>" you should press "Assign OSC" button while physically still touching the control on surface. Just check that "OSC Address" has no "/z" at the end when you do not want it.

Touch make sense for faders and encoders, but TouchOSC also send it for buttons... annoying. After you have OSC Assigned all controls, you can set "Do not show unknown messages" in the "OSC Configure" Options dialog.

Logic Tab
Here is defined what each control does "directly", when particular assigned to control message is received (part is used in "Monitoring", but I simplify this particular description for clarity)

"/sync". I have defined "/sync" button in the layout, it sends "/sync 1" (pressed) and "/sync 0" (released). It also send "/sync/z" on touch, but we have not assigned it and the message is ignored.
 "/sync 0" (release) will not be processed, all action have default "Note:ON" condition, so they all are skipped because "/sync 0" for "Pad" control type set "Note:OFF".
So the action list is effectively called on Press only. The purpose is to (re)"sync" the Layout with Sonar.
In a "good" preset, all "feedback" should be in so called Monitors. It is possible to send OSC in direct reaction, but that is in general "bad style" because syncing is much harder to implement then.
But this preset is "good", so I just have to re-trigger ALL monitors (the first Action in the list).
I also set "SyncDone" to "Yes" (explained in /ping) and set color of the button to "green". The later is not strictly required, but I set initial color to "red" in the layout. So as soon as AZ Controller can sync with TouchOSC, the button become green. That is a simple visual indication everything is "right" (in an empty project, it can happened no parameters exist and the whole layout is not changed much after syncing).

"/ping". I have already written that TouchOSC sends this message once started and then periodically. In the first case, I want AZ Controller is automatically sync. So manual syncing is not required when you start TouchOSC after Sonar. But I do not want "sync" periodically, so I have to somehow remember I have already synced. "SyncDone" is used for that, once synced it is set to "Yes". So in "/ping" I check if sync was already done and "exit" execution in this case ("*" after Undefined means that). For syncing I just call "/sync", since it does what I want (I could "copy/paste" Actions there).
In both cases, a "good style" is to response on "/ping" ("Hello!") with "/pong" ("Hello!"). Touch OSC will know it is welcome then.

"/volume". Here the whole practical functionality of this preset happens.  First I select "Current Track Volume" as the parameter. On that can be anything, you can change "Volume" to "Pan", you can replace it with "ACT S1" or you can add "Send"/"Filter"/"FX" parameter. You will immediately notice on your tablet new parameter.
After parameter is selected, I change its value with "Value" Action. In case of OSC Fader, "Direct Linear" is the best option. It set parameter to direct position of the fader (remember, each parameter is 0. to 1. and the fader sends from 0. to 1., so that "works" for any parameter!). For encoders, that will be "Endless" type of change, with particular "resolution" (freely definable for your taste). For buttons (like Mute,Solo), "Toggle" is the right option. It checks current value (0 or 1) and reverse it. Another important option in our case is "Manual touch". Our OSC fader explicitly inform us when it is touched, so we do not need default "automatic guess", "timeout touch". When transport is stopped, that option has no big sense. But when you (re)write Track Automations, that option is crucial. Sonar should know when you want overwrite current value and when not. Without explicit (manual) touch, there is no deterministic way to detect that. With explicit touch available, you can indicate that you want overwrite the automation by touching the fader, even when you do not move it, current constant position will overwrite whatever changes was already written. As soon as you release the finger, the fader will again start to follow already written changes.
The last action is "Value Monitor", I will return to is later in the "Feedback Tab", where it is defined. That is most complicated topic in AZ Controller, but for this example it is sufficient to know whatever parameter was selected before (in our case "Current Track Volume") will be "monitored" for changes, in value (f.e. you move fader by mouse, or it was moved by previous "Value" action, or there is Volume Track Automation) or for parameter itself (f.e. when you focused another track, changed "Volume" to "Pan" in the preset, etc.). Options are important there! So the type is "Value Monitor" (many different things can be monitored, including unconditional timer). The speed is set to "Ultra". That will check for changes ~13 times per second (fastest speed for Control Surfaces). Other speeds will check for changes slower, so labels will be updated not immediately and OSC fader will move is significant "steps" even when the automation is smooth. For old computers, some slow hardware surfaces, slow monitoring can make sense. But not for OSC (so make all your monitor "Ultra"). Priority specify in which order different Monitors are checked. In complicated cases that is important, but not in this example (we have only one Monitor). I prefer "3" for all feedback monitors, to leave "0-2" for "priority" monitors when required (f.e. if you want "track" which pane is Sonar has focus, track or bus, that Monitor should have lower priority since we want "current strip volume" in this case, the the "strip" can be "outdated" till corresponding Monitor is executed... wrong order normally does not break functionality, correct situation is sent 1/13sec after, but that produce some "flickering" on display).

"/volume/z". As I have mentioned, "/volume/z 1" and "/volume/z 0" are sent by TouchOSC when you touch and release the fader. And as I have explained, we want to use that as "Manual touch" for the parameter we operation by the fader. But that does not happened "auto-magically", we should explicitly instruct to do this. On "Touched" we call "Touch Touch /volume", on "Released" we call "Touch Release /volume" (and let AZ Controller find currently controlled by the fader parameter).
Do you remember we have specified "system" as "/volume/z" control type? It is important now! The list is called the same way on touch and release, so we need some way to find when we are called. Touch sends value 1., release value 0.. Do you remember my comment about MIDI value range? Here I use "Value:0" and "Value:127" condition (so 0. and 1. in OSC) for Actions I want to execute. In case the control defined as a "pad", we have to use (default) "Note:ON" and (explicit) "Note:OFF" conditions instead.
In the last action, I explicitly reset "/Volume" Value Monitor... That is a part of "workaround" for the TouchOSC logical bug, explained a bit later.

Feedback Tab
When we define a Monitor in the Logic Tab, we specify the conditions to trigger it. So which parameter to monitor, how and how often. When the monitor is triggered, its own list of Actions is executed, and that list is specified in the Feedback Tab.
The tab is called "Feedback" because originally Monitoring in AZ Controller was to allow the feedback to Control Surfaces. In the mean time monitors are also used for other purpose, but we use it here for the feedback only.

In the example, we have just one Monitor. As I have explained, it is triggered every time something related to our fader parameter is changed (the value, track, the parameter, etc.).

As first, we send current parameter value text to "/volume/value" TouchOSC label (placed on the fader in my layout). For that, I first prepare the text. It can happened the parameter does not exist (we have no tracks in the project), we still want overwrite/reset the text. So I set it to "" (empty) and then try(!) to set it to parameter value (can fail). We send it to TouchOSC then. Since I have a good naming convention, I use "<Ctrl>" as the prefix. I could use "fixed" /volume/value here, but this way I potentially can change OSC name for volume with just reassigning it to the control or I can use the same "code" for many controls ("functional programming" paradigm... too far away from the music, I know...).

As next I send the parameter value (as a number, not as text) to the fader itself. If parameter does not exists, I want to send "0.". But I do not want send it every time, so I first try with real value and send "0." if that "does not work" (Last action:failed). I could use the same for Text before, but text Action does not send anything, so one "extra" initialization is not significant. If I do the same here, TouchOSC will always receive "0. , <real value>". That is not what I want.
But... you see one more condition, I check we have not "touched" our fader. It is time to explain TouchOSC logical bug.

Original "touch sensitive motorized faders" (on hardware surfaces) are "smart". When the fader is touched, the device does not try to "fight" with your finger in case a DAW set it position. Instead DAW position is "remembered" and set only after the fader is released. TouchOSC developers "forgot" to implement that, so when we move the fader on tablet, in case DAW sends position value, the fader is "jumping" all the time between DAW position and finger position. Not only that is visually odd effect, that influence values which TouchOSC sends! When you move slowly, the changes in values are tiny. Sonar, and so AZ Controller, does not "apply" new values instantly. So there is some "delay" between new value is visible in the Monitor, and so fast movement produce quite bug jumping. Not nice.
To "workaround" the problem, I do not send values as long as we touch the fader. But what happens if we manually selected "impossible" value? The fader will become not in sync with Sonar. So, I explicitly "reset" the monitor after the touch is released (in the "/volume/z"), that explicitly sends current Sonar value. And so we have exactly the same (nice) behavior as with correctly implemented hardware faders.

As next, I want to send text with the "origin" and with "parameter name" to corresponding TouchOSC labels. Note that "default" text for not existing parameter can be not empty, I send "Not exist" to origin. And I do not want to send these labels every time only value is changes, I know the labels are still the same. So I "exit" before sending them using "Mon. par. not changed" function (which succeed in case only value is changed, notice "*" at the end indicating the action is "Final" when it succeed).
Notice that while Text Action is represented just as "Parameter Name" in the list, there are different parameters, the first use "Origin name", the second "Parameter". That is an "imperfection" of AZ Controller interface, the list will be too "busy" if I mention all possible Action parameters there.

Final words.
I hope you can understand now, that changing Action order, "forgetting" some Action, even changing one parameter in any Action can make the preset useless/broken or at least inefficient.

During the second car driving lesson, I have unintentionally crossed the street on red light, with tempo 90kmh (in the town, tempo limit 60 and there way many cars and people on that crossing...)
My driving teacher has allowed (!) me to do this, but he has stopped the car 100m later and said:
"You will drive over speed limit, you will drive on red light, you will drive completely drunk... That is live. But you SHOULD NEVER break driving rules without clear understanding which particular rules you are breaking at the moment!"
I had a huge luck with most teachers in my live  ;)
« Last Edit: September 27, 2017, 05:17:54 PM by azslow3 »

Offline symetrk

  • Newbie
  • *
  • Posts: 29
Re: extended layout/preset for TouchOSC
« Reply #6 on: September 26, 2017, 11:06:24 PM »
Whoa. That is a lot of information! Thanks so much for taking the time!

Meanwhile I've been poking away at it in my own way (I know, you don't encourage it, but really, I've learned a lot!)... I got the REW/FF working as desired, per your instructions, that was obviously easy. I removed all the extraneous monitor calls I could find, and then dug back into the ACT page armed with the information you gave me, specifically that the SLOT thing was not required at all to do what I wanted to do. That simplified everything a lot, and believe it or not I now have everything working the way I imagined it should. And Sonar stability is pretty much back to normal as far as I can tell.

HOWEVER I realize there are probably still lots of things I've done wrong, and/or inefficiently, and/or in ways that are problematic for stable communication with Sonar and the plugin. So I will definitely try to dig into your incredibly detailed notes here, and look at the preset and layout files you've provided, comparing them to what I've done. I'm obviously quite sure your way is better, but I want to try to understand specifically why (not just in a philosophical way).

One thing I am confused about that perhaps you could help me with a very short answer... I would like to clean up some of the mess in my current preset version, and it seems like in order to delete unnecessary controls once I've created them on the Options page, I need to detach them from the logical control and then delete the context they are associated with, which then allows the delete button to be used. This is great, but I am then left with Detached logical controls that are still floating around. Is there any way to delete those? I haven't been able to find any mention of it in your documentation.

OK thanks in advance for that and again for the time and energy you have put into this, I will look at it and try to see where I've gone wrong - again, even though everything seems to be working I understand that it may not be working *well*...

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: extended layout/preset for TouchOSC
« Reply #7 on: September 26, 2017, 11:36:41 PM »
To remove logical (already detached) control, delete all actions from it in the Logic Tab first (you can Shift select top to bottom in the Actions list...).

Quick removing (may be with a confirmation dialog when the control is not empty) could be a better solution. But as you probably notice from my lengthy texts (sorry for that), AZ Controller is a huge program (some people think that 500kB program can not be long these days... but everything is hand written in the same style as when computers had 1-2MB of RAM) and I am a lonely free time developer. So I do minimum "beautification", only when I hate something too much (that way Shift selection was introduces, along with copy/paste for multiple actions and "Dup" button).

Offline symetrk

  • Newbie
  • *
  • Posts: 29
Re: extended layout/preset for TouchOSC
« Reply #8 on: September 27, 2017, 03:15:07 PM »
Hi again. OK thanks for that - I actually had already deleted everything in the detached logical control, but couldn't figure out *where* to actually delete it, but I found it, on the Hardware tab kind of halfway down. I was trying to delete it from the actual Logic page, which is impossible. No big deal, now I've deleted the extraneous logical controls AND in the process removed the final instability from my current version, which now updates tracks as it should on initial Sync and maintains that sync without having to jiggle it, as it were, with another (working, non-messed-up) layout.

With regards to your example layout and preset. I had a look at it and I'm pretty sure I understand, with the help of your documentation, what you've done, and will begin to implement it in my own preset properly, but in all honesty based on initial experimentation I don't see any difference at all in the response of the controls. In fact, in your layout the way it stands, with the fader set to 'Relative', I feel the fader is acually 'fighting me' as you put it, not physically obviously but the control is jittery and seems like it's trying to resolve too much conflicting information. I had already set all faders and controls on my layout to 'Absolute', which seems - on my tablet at least - to be much smoother and perfectly fine for my purposes. When I set the fader on yours to 'Absolute', it also became much smoother.

I realize that this causes problems for automation - if you are trying to use it as a touch-sensitive controller where touching a control detaches it from reading automation and overrides it with the actual input as long as the control is touched. I did some experimentation with it and yes, obviously the 'Relative' mode is better for writing automation over existing automation - otherwise the control simply 'skips' to the new value when the control is touched. However, the tradeoff - that moving faders and controls is kind of jittery and jerky literally all the time... I'm not sure it's worth it to me. Is there a way to smooth that behaviour out, or is it just inherent to the system - or inherent to *my* system somehow?

Anyway, I'll continue to experiment but at the moment I've got a surface that does everything I wanted it to do and seems to do it in a stable and consistent way. Plus I learned a lot about your plugin. So that's a win!

Offline azslow3

  • Administrator
  • Hero Member
  • *****
  • Posts: 1679
Re: extended layout/preset for TouchOSC
« Reply #9 on: September 27, 2017, 05:42:57 PM »
A nice point with "Relative" fader mode!

I have just tested it with my phone and "Absolute" works smoother also on my system. I have thought that "jittery" comes from the way I process OSC. I am still not sure when it is "safe" to call Sonar and when it is not, my latest test version is more "aggressive" with that then "safety first" versions before. But the response still was not smooth. So, that is TouchOSC imperfection... Now I have learned something new, thanks  :)

I have relatively small old phone, and I was using OSC Phone when I was near my DP. With "Absolute" setting, I unintentionally changed the volume several times, and unlike with buttons, that is harder to notice and revert (only with "Undo"). The second reason you have already found yourself. So, I have used "Relative" for everything.

I do not think "smoothing" on my side is worse the effort. That should be done on tablet side, where hi precision finger information is available. I mean "relative" tries to do exactly that, our observation means the implementation is just not optimal.

Offline symetrk

  • Newbie
  • *
  • Posts: 29
Re: extended layout/preset for TouchOSC
« Reply #10 on: October 10, 2017, 02:56:45 PM »
Hi again.

So after a couple of people expressed interest over in Sonar-land, I am uploading my current OSC Sonar Tablet implementation. I *think* I've ironed out most of the issues from my last upload here - extraneous monitor calls, etc... as well as adding a few new things, hopefully without being dumb about it ;)

The functionality is I think fairly self explanatory, since the OSC layout is labelled. As in Alexey's original setup, you need to press Sync once - it's on the first (Control) page, at top right (a duplicate of it is on the Plugins page, beneath the track name). In order to put in some more functionality without adding stupid amounts of buttons, I've added dual functions on a few buttons, where a short press and a long press do different things (using a timer, as Alexey did on his preset for the up/down buttons on the Tracks page). As follows:

1) short press on Dock toggles the multidock; long press toggles Maximize
2) short press on INSP/PC toggles the Inspector; long press toggles the Pro Channel, or calls it up if the Inspector is minimized.
3) short press on BRWSR/SYNTH toggles the Browser; long press toggles the Synth Rack, or calls it up if the Browser is minimized.
4) short press on LOOP/PUNCH toggles Loop; long press toggles Auto-Punch.
5) short press on BUS/CONS toggles the Bus Pane; long press calls up the Console.
6) short press on the up/down arrows on the Tracks and Mixer pages moves the WAI focus one up or down, respectively; long press moves by 8, which makes more sense then Alexey's original 16 given the 8 tracks on my layout.

As mentioned on the Sonar thread, I haven't implemented feedback on all buttons because I'm not sure it's possible or how to do it if it is - if Sonar makes its Inspector or Browser state available to the plugin, I can't figure out where. Maybe Alexey can point me in the right direction.

Other than that I think it's fairly self-explanatory. In terms of what functionality has been implemented, I've kind of prioritized things I use a lot, but obviously it can be extensively customised if someone else wants different controls - especially in terms of simple things like the dedicated buttons.

Installation should be the same as in Alexey's tutorials for his OSC Phone setup. In terms of stability, if I have *only* this preset functioning, Sonar seems pretty stable; it's possible to crash it by button-mashing wildly, but in normal operation it seems pretty solid. I can crash it a lot easier if I have multiple AZController plugins active (as previously mentioned, I'm a bit controller-crazy), so I don't recommend that.

So here are the files...