MIDI Kinetics Forum

Edit:
I'M STUPID
I have no idea how I seemed to get the results I did earlier. And yes it seems like Lemur is doing exactly what it should...
And yes it seems to be Nuendo that is actuallu causing this somehow. Iwas sure I didnt have it on, but I must have had it running in the background and not realizing that it was.
Sorry for taking up all your time.
The issue remains but it does look like a Nuendo issue and not a Lemur issue!

Shenever I touch and hold anything, the touched item (example:multi ball) is not "un-touched" immediately but theres a significant lag from removing my finger to Lemur actually sending out the mesage that I have indeed stopped touching the multi ball.
Switches and pads react fast enough on both touch and release, but not faders, knobs and multi balls. Can this be controlled somehow?

Im assuming you are using "z" for getting if an object is touched or not yes?

If so, are you actually lifting your finger from the object or just dragging outside of its "screen area"? If the latter, pay attention to the "capture" attribute....you need to disable it otherwise "z" will become 0 only when you lift your finger off the screen even if its already "far away" from the object in question.

I'm not actively using Z to define "touched", but I guess that is what Lemur will use internally.
I tried changing the capture status, but it made no difference.
I can see using a midi monitor app on the computer that it indeed arrives late.
If I do the same control with the mouse on the screen, and just watch how lemur reacts to outside control it all responds as I would expect.

Hi
If you want to access 'touch' state then you have to use 'z' - otherwise you aren't looking at touch . . The problem is not in how Lemur is responding but in what you are expecting . . .

If you mean MultiBall.x values keep going after you let go - then look again your finger is moving as it lets go, objects have a small amount of physics to them in normal state . . .

Try this - put a MultiBall on your page and 3 Monitors with value set to MultiBall.x, MultiBall.z, MultiBall.z -Also set x, y , and z to send CCs . .
If you let go whilst moving finger quickly you will see x and y keep moving even though z has gone to 0 - Hold it still and and z will be final message sent
This should also be confirmed by watching a midi monitor on your computer - Using a hardware connection will be fastest generally, followed by ad hoc, router-based can add delays . . ..

I guess if you wanted to you could script around the inherent behaviour fairly easily - a script something like stop() executing on z returning to zero and x=x;y=y;
This should set x and y to whatever value they are on when you let go of z and thereby stopping there movement . . .

Cheers

Thanks ill have a look at that!

A follow up question...

Any suggestion on how to understand how to control delaying commands using the time variable?
Link to a simple module/example would be awesome!

What macciza said actually....but to help you grasp the difference......

x and y values are what a multiball sends when it moves, a fader sends x values when it moves - in your mind, this is the same as "being touched"...is it though? So what if we have physics enabled, and the ball moves even when we do not touch it, or the fader gently slides a bit more millimeters after you stop touching it? it DOES send x, y values doesnt it? Its not touched though, is it?

And THATS why, there is NO OTHER way to detect and "use" as a message "is touched" any other parameter besides z for any object!

As for delayed actions, you have to be more specific in order to give you an example....Generally speaking you need a onframe script, a "gate" if hypothesis, which will exit the script unless a value is higher from a defined threshold and then use a script to add to that value with time, so that it reaches the threshold....

here's a rough example I made - it sets a fader to maximum value after a delay specified with a knob - the whole "timer" has a start-stop button and a reset timer button....Just to get an idea!

Ok I get the z parameter. But why DOES it work without it and how?

Example take a multiball have it control some parameter. Automate that parameter .
Now in touch automation mode, drag the multiball to a corner, from the moment it arrives at the corner it no longer moves, and now the values at that corner will not change and the ball will not be" released" and the daw will not stop writing that data until the ball is "released" (stop touching the ball with a finger). When it is released first there is a delay then there is a midi signal sent out on the midi port. Why is this data sent and why is it delayed if objects have no touch and if they can't be un-touched without the use of the z value?

I don't get that.
I'm sure I might be missing something obvious here... But I can't see what it is.

Oopsssss, I was posting before reading your post lol....read above!

One: your finger, no matter how you think is still - it still is not "still" enough - minor fluctations still cause the ball to "spit" values.....


ORRRRR two: ......physics! lol

Well if I have capture active and my finger is outside of the multiball area in the corner, it just isn't registering any changing data. It definetly isn't sending any data over midi until about a second after I stop touching it.
The touch resolution on the iPad can't be better than a pixel, and I can assure you that it's nt at all impossible to not move you finger within a pixel based resolution.

To test this fact just do this easy test: create a fader,a large one. Create a monitor. Monitor fader.x at full precision.
Keep you finger still. Is the value changing?
No it is not.
Send midi controller data with this fader controlling a volume fader in your daw. Do the touch automation release test again. It is not untouched because it has moved. It is untouched because it is untouched! It has to be.
And still the last midi message after releasing the fader is sent about a second later. Why?

EDIT: I hope I don't sound like I'm whining or anything. I genuinely am trying to understand...