Although it seems to detect the controller and its data right (can display it with your cool Display Token block) after MIDI-learning the controls again, nothing happens after that when I turn or press the knob...;-(
Also none of the used variables get any value. What am I missing here ?
The things I've changed / entered are:
checking back that the knob data is actually working / getting in
entering the appropriate screen position in the first green block (to position of on-screen plugin knob)
Again copying the TriggerValue data for the Button press part in the second green block ("Scroll"/"Note 12")
Changed the Pause to 1 second in order to test the macro more slowly
Update. Strangely, after de-activating and re-activating the "Cancel Previous Instance" it kind of works now.
But there's still some flickering / jumping going on (assumably after one second after a certain data package) during turning / operating the knob for longer....so your approach of cancelling doesn't seem to work properly...I'll experiment a little more with it now
Btw I also changed the "Jump to Position" Block to "relative to absolute position" which was "relative to front window corner" before....
Yes that's exactly what happens - the pause (which I extended to 3 sec for testing this) just doesn't start again and again during turning the knob - it always brings the mouse back 3 seconds after the first turning event, also when I keep turning for approx. 2 seconds...
I assume that the values of the "ScrollerCancel" variable change too fast with the incoming data, so KM seems to miss some instances to be adressed as the "previous instance" which may result in some instances "slipping through"...
In the meantime I'll give Nige_S's approach a try....seems to work good as far as I can say as for now...
Update:
This works but also only with a button press and not with a "stream" of trigger events like produced by turning the MIDI knob....working on modifying it now...
Phew!!! My own experience with triggering from endless encoders is that they produce a very fast stream of triggers that can ramp CPU usage up pretty quickly if you're turning fast/continuously. So yes, it may be that there's just too much going on for my method to work. I only tested with the button, and it did solve the mouse return problem. Presumably @Nige_S' version is the one that's working, which is nice to hear after he was a bit hesitant to recommend it.
I think my method will also fail if the rate of incoming commands is high -- there's a limit to how fast events can be processed, and you'll also be heading into "asynchronous" territory.
In other words, what can work OK when limited by the speed at which you can tap a key could fail with faster input.
Silly question @uliauer, but why do you want to put the pointer back where it came from? It would be a lot easier to leave it on the virtual knob until your next command/macro needs it elsewhere!
This comes from my workflow on a quite big setup (see image above) with four monitors and the "place of control" (= where the knobs on the screen are) usually not being on the screen I'm doing the work with the mouse first and foremost.
This results in always needing to "collect & bring back" the mouse manually after turning a know inbetween lets say editing work with the mouse....understand ?
Looking at the last image of the studio think the knobs I want to control are on the touch screen on the right (laying on the desk) and the editing with the mouse happens mostly on the bigger display on the top of everything....now imagine bringing back the mouse over this distance passing two displays everytime you've moved a knob....that's awful....
I mean, controlling the knobs with a rotary controller unit is the exact opposite (or a complementary but different element) of controlling GUI objects with the mouse...so the purpose for all that IS not neccessarily being at the same spot or area at where the mouse is at that moment...
I assume you looked into direct midi control of plugins via encoders and it was too limited. That was my experience with Logic Pro, so I wouldn't be too surprised if it was the same with PT.
I did have two thoughts along the way but didn't mention them before as I didn't want to derail us from getting the macro working:
Bome Midi Translator Pro can convert relative midi to mouse scrollwheel movements. Perhaps that might simplify things a little. Perhaps it might complicate things a little. Worthy of investigation nonetheless, I think.
I know you don't want to press a button to target a control with your mouse (like nObcontrol does), but how about a button that just returns the mouse to the starting position after you're done tweaking controls. This would massively simplify the macro logic and solve the issue of dragging your mouse back across screens.
Having said all that, you said one of the versions was working now. Reliably?
The problem at the moment is the timer. Would it be too much of a pain if you triggered the macro to do the knob-twiddling, then punched another button to return the pointer back to where it was? Otherwise the only way round this may be to increase the pause in the check-loop and increase the "inactivity" time, perhaps to the point where you are always sat waiting for the timer to return the pointer to where you want.
Another solution might be to use a timestamp that the timer macro compares against rather than manipulates. Unfortunately neither OS X (nor KM, AFAIK) can natively return time at greater than 1 second resolution, which will leave us reaching for gnucoreutils (installed via homebrew) or a Perl or Python script. That means the extra execution overhead of a call outside of KM -- would that matter?
Edit to add...
These variants use perl to generate 1/10th of a second timestamps -- if Tiimer 2's timestamp is more than 1 second newer than the last timestamp of Knob Tweaker 2's, you're done and the pointer is returned to its old position. It works for as fast as I can mash keys -- but I don't know if it'll cope with your data stream!
Exactly ! PT is awesome in many aspects - supporting 3rd party units and concepts is definitely NOT one of these...
I have and use BMTP - I don't think that this will help much....but I'll try to wrap my brain around this idea...
@Nige & Neil: The idea of a button press after turning the knob is of course a possible way but not very elegant and not what I want - as long as I'm not sure that it's impossible to do I'll keep investigating....
Also, as described I've found a solution already. Interestingly, it works absolutely perfectly with only the knob turning parts (INC/DEC) but I now have problems with the part that appears to be easier - the button press.
It seems to be that any performing of a mouse screen position jump takes more time than continueing with the next step in the macro actions. I can see that while using the macro as there's a short instance where turning the knob causes text in a window underneath the initial mouse position move a little before performing the mouse jump ! So it scrolls just a little on the old position and THEN on the button although the scrolling command comes after the jump action....
I see what you mean but I indeed think that this makes things even more complicated. What would be the adavantage here ? I still need to incorporate the incoming trigger first in order to initiate the mouse position / timer thing....if the unit itself sends mouse scroll data already it should make the problem of scrolling before moving the mouse even worse...
, unfortunately the macro doesn't work here at all....
