General
[NOT a issue]Lemur Touch release delay
Started by ErikG on .
Sign in or create an account to join the conversation.
Edit:
[size=200]I'M STUPID[/size]
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?
[size=200]I'M STUPID[/size]
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?
Subject: Re: Lemur Touch release delayIf 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.
Subject: Re: Lemur Touch release delayI 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.
Subject: Re: Lemur Touch release delayIf 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
Subject: Re: Lemur Touch release delayA 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!
Subject: Re: Lemur Touch release delayx 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!
DelayedExample.jzml
Subject: Re: Lemur Touch release delayExample 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.
Subject: Re: Lemur Touch release delaySubject: Re: Lemur Touch release delayORRRRR two: ......physics! lol
Subject: Re: Lemur Touch release delayThe 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...
Subject: Re: Lemur Touch release delaySubject: Re: Lemur Touch release delaySubject: Re: Lemur Touch release delayIt's even easier to see what is happening just using a midi monitor program on your daw computer. All the below explanations are really unnecessary but perhaps interesting anyway.
Touch the fader and move fully up or down. then Just look at the midi controller data sent from lemur about one second AFTER you stop touching the fader.
I use automation all day every day, so it's all just second nature to me what all this means and how it's supposed to work.
I'm sorry for the long winded explanation below:
Do you have Cubase or logic (or even reaper)?
Then first record/ automate the movement of a volume fader, at what level is irrelevant, but just to make it easy push it to the top, do this using your mouse on screen. Automation in Cubase needs to be activated with R+W (similar in Logic IIRC.
Now backup and playback that automation. Now, while playing back drag the fader fully down with your mouse and then release it while the automation is still playing.
Result is that the fader jumps back to the old automated level as soon as you let it go.
The above result is what is generally called touch automation.
((Alternatively Cubase and Nuendo can also be set to work in latch mode (the modes are set in the automation panel window). This mode can't be used to check this issue.))
When you released your fader with the mouse it would return more or less immediately to the previously recorded automation level. That is a result we want also using lemur. I.e. when I stop touching the fader/knob/multiball it then stops sending data to the daw and thus the daw now returns the recorded automation level to what was previously recorded.
Now have lemur control that fader (send and receive), playback the automated level change, now grab the fader and record a drastically different fader level. Then stop touching the fader and notice the difference in time until the fader jumps back to the previously recorded automation level. In my case the delay is almost a second...
I can see that this is caused by the midi data that lemur is sending out as it is transmitting a new message about a second after I release the fader (I use midi monitor to check what data is sent to my daw). And it does not send any data at all at the actual time of release.
Subject: Re: Lemur Touch release delayI do however know the inside outs of Lemur especially in midi messages and I can reassure you something FROM your DAW is causing the fader to behave like that - I have never seen any object of Lemur send delayed messages.
Are you saying you are using a plain midi monitor in your computer, no Nuendo-Cubase connected, and the fader still behaves as you describe?
As a side note, DAWs generally speaking, are always sending feedback back to midi controllers with a specific delay to avoid "flickering" (discussed elsewhere in these forums, I think it was with you again? not sure, anyways).....Sometimes, the delayed feedback is some 500ms slower....Are you sure this isnt the culprit with your case? (delayed feedback, causing a slight change of value to the fader, fader resends the last value gained) In some DAWs you can even customize that "feedback delay" or "controller surface update rate" as needed!
Subject: Re: Lemur Touch release delayUsing Lemur 4.1.
Lemur sends one additional message approx 1 sec after the fader is untouched. And no message when it IS untouched.
I really should go to sleep now (01:27 am) but if you guys can't reproduce, I'll shoot some iPhone video tomorrow showing the behaviour using nothing but midi monitor, and also separately the resulting issue when using a daw and automation.
EDIT: to answer your question better. No the fader with just midi monitor will not behave "physically" on the lemur in the same way as I have described in earlier posts as it IS the DAW that causes it to actually change position after release. But it will clearly send its last message about a second after it is released when tested using midi monitor only.
Subject: Re: Lemur Touch release delaySubject: Re: Lemur Touch release delayLemur latest version, iPad2, Daemon, LoopBe virtual midi ports, Windows 7 32 bit PC....
I cant reproduce the problem, the fader correctly stops sending messages as long as it is still - touching it or not, as you correctly noted, doesnt matter if for example your finger is always at the far "top" or far "bottom" position of the fader....
And in fact I used a "through router" connection (not ad-hok, PC connected to router and internet, iPad connected to router and internet) which actually is the LEAST recommended connection, noted as somewhat "slow"
Still cannot reproduce! Can you send me a sample template of yours, already midi mapped, all set to go so I can test it?
Subject: Re: Lemur Touch release delayYou really need to include some sort of example project to show what, and how you are trying to do, what you are doing . . .
I can't really guess how you are doing things - ie You say 'No message when it is untouched' but do you have anything mapped to 'z'? That is the 'touch' variable
If you are just looking at the 'x' var then it may send late for various reasons explained already . . . Also what message is sent? The Fader CC? Touch CC?
Are you using whatever message you are sending from 'z' ? Logic allows you to set 'touch/release' for Faders to work with console faders with touch control?
Do you have such a hardware controller that you can compare results against? I dare say the response from a hardware fader will be different to onscreen mouse control also.
Remember there is a communication element in all this as well - you still have not said how you are connected? If through a router then literally 'ANY' message can be delayed by the network . . .
Also, even adhoc setups can encounter delays for various reasons - connecting via a decent MIDI interface on both ends should give best/fastest response times . . .
Edit:
[size=200]I'M STUPID[/size]
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.
[color=#804040][b]Sorry for taking up all your time.[/b][/color]
The issue remains but it does look like a Nuendo issue and not a Lemur issue!
[size=200]I'M STUPID[/size]
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.
[color=#804040][b]Sorry for taking up all your time.[/b][/color]
The issue remains but it does look like a Nuendo issue and not a Lemur issue!
lol Dont be so harsh on yourself!
Glad to see you sorted it out! As for actually making the thing work as you wanted, perhaps the key feature here would be to make your DAW use that extra functionality of being compatible with "touch controllers" like macciza said and of course, incorporate the "z" attribute into the whole thing!
Glad to see you sorted it out! As for actually making the thing work as you wanted, perhaps the key feature here would be to make your DAW use that extra functionality of being compatible with "touch controllers" like macciza said and of course, incorporate the "z" attribute into the whole thing!