Issue with moving heads + Proposed solution (if needed)

[Steve M]

Issue /bug

Aim:
To move a moving head from one (non zero) DMX position to another smoothly over time. eg Tilt 127 –Tilt 200, Pan 127 – Pan 127. Moving head should rise from centre potion to vertically to new position and stop there.

Actual behaviour:
When using scenes to move from position to position when a fade in time is set the heads will jerk down and to the side as the fade in seems to come from the 0 position and not from the previous position, as stated in the manual. When running a sequence in a loop the heads will jerk on the first couple of steps before stabilising to the expected movements.
If no fade in time is specified then the head behaves as expected but the movement of the head always takes place at the maximum rate the stepper motors allow and is therefore too fast to create smooth controlled and aesthetic movement.
Although I have spent more than a day trying to get this working I have not been able to find a way of creating this simple movement reliably. The EFX function only provides a limited number of looping shapes and is not suitable for creating this behaviour.

The possibility exist that I am simply missing something that will allow the fixtures to operate as specified – In this case I would be very grateful for any help and could send you more details including project files showing the behaviour I am experiencing.

Assuming that this functionality is not desirable for certain uses I have provided the bare bones of a solution including skeleton code that allows the option to select this behaviour and also adds two new behaviours that are very important for using moving heads to keep in time with a musical beat, namely
a) setting the rate or speed of fade in movement and not absolute time (important for moving heads) and
b) ensuring that the scene will stop fading in if another scene is activated (this means that I can trigger movement to change with the beat of the music at varying tempos. If the scene continues to operate past the beat this has a severe negative aesthetic effect)


Solution:
Provide a check-box in the timer section called 'fade in from'.
Unchecked the fade in time will behave as it does at present.
When checked the scene with fade in from the current DMX channel value – as shown on the simple console view. At no stage will the DMX channel be set to 0.
For example if the tilt is currently 127 (centre) and the new scene sets the tilt to 200 the DMX channel will slowly increase from 127 up to 200 or until interrupted with a new scene.

The rate at which the DMX value will increase will be determined by the fade in time. The rate or speed of movement is set from the value in the fade in box. This time represent the time for 100 DMX steps to complete. eg if fade in is set to 1s then it will take 1s to move from a DMX value of 0 to 100 or from 127 to 227 or from 150 to 100. it will take 0.5s to move 50 steps eg from 50-100 or 1.5s to move 150 steps eg from 255-205 etc.)

The reason why rate is preferable to actual set timing is because it is the speed of the movement which is most important rather than the actual time taken to complete the movement. By setting a single rate all moving heads can be easily set to a constant speed no matter how far they are moving. Using absolute times would mean that the speed of the head would change depending on how far the heads had to travel. This looks un-aesthetic compared to a constant speed. If different speeds are required eg with four heads moving out to form a fan – the outer heads can be set to 3 time the speed of the inner heads to arrive at the same time, or left constant to give a concertina effect.

In addition the scene should stop fading in if another scene is triggered. The last scene activated taking precedence.

Coding: I have written a proposal for coding this. I apologise for the syntax and lack of variable declarations (although I have commented and named them to make it easier to understand). The code below is therefore simply an algorithm for explaining how the behaviour could be implemented. It will obviously have to be translated into the class architecture you are using.

On activation/initialisation of scene (where the normal fade in code goes)

If fadeinfromcheckbox = TRUE //Is the fade in from box checked
{ scene_start_time = current_clock_time // make note of clock time;
startDMXlevel = CurrentDMXlevel; //remember DMX value when we started
tempDMXlevel= CurrentDMXlevel; //the temp DMX value that will change
} else //behave as normal fade in timer

On fade in scene loop (where the normal fade in code goes)

If fadeinfromcheckbox == TRUE
{
If CurrentDMXlevel == SceneDMXlevel // If we have reached the DMX level set in the scene
OR CurrentDMXlevel tempDMXlevel // if anything else has changed the DMX
// channel then the scene will exit. (more on this
// later)
exit // stop scene we have finished
// we haven’t exited we are still running the fade in from.
elapsed_time = (current_clock_time – scene_start_time); //this may need to be converted
// with maths or library function
If SceneDMXlevel > tempDMXlevel
{tempDMXlevel = startDMXlevel + IntRound((elapsed_time / fade_in_time ) * 100));
// the required DMX level is greater than the start so we need to add. The times
// need to be in a format that allows division. The division and multiplication
//calculation needs to be rounded to an integer
If tempDMXlevel > SceneDMXlevel // If we've overshot
{ tempDMXlevel = SceneDMXlevel;
}

}
else // if the required value is less than starting we need to minus the value
{tempDMXlevel = startDMXlevel - IntRound(((elapsed_time / fade_in_time ) * 100));
If tempDMXlevel < SceneDMXlevel // If we've overshot (less than this time)
{ tempDMXlevel = SceneDMXlevel;
}
}
CurrentDMXlevel = tempDMXlevel;// we are now setting the DMX output from the
// scene. This will likely be a class function
}
else //behave as normal fade in timer

Apart from any issues that may arise due to the current code and architecture, I am uncertain of exactly how HTP and LTP in particular are implemented and what if any code exists to stop a scene fading in if another scene is activated. The code above assumes that if another scene is activated it will change the DMX value sent to the channel – this may not be the case in either HTP or LTP and a different solution might need to be found. At present it seems that the scene will complete it's fade even if another scene is initiated although I haven't tested the behaviour with LTP.

At present I don't have access to a compiler/programming suite, and I haven't programmed in C++ for a long time or I would offer to program this myself.
I am definitely able to contribute to the documentation and I plan to create tutorial videos explaining how to set up the system I am designing for synced live control of lights during a DJ set. I also plan to open source the project files and other files so that people can easily copy what I am doing.
This is a major project for me and the modified behaviour is vital for this. I've gone through program after program looking for what I want before eventually coming up with this solution.

I've found Q Light Controller + to be a fantastic project and thank you all for making it and I definitely want to become part of it. Please let me know how I can help – I've never been part of an open source project before so apologies if I am going about this in the wrong way.

Thanks again.

[OfficialBennyT]

It sounds like you just need to run your Pan and Tilt channels in LTP... I do motions like this and never have any sort of jerking problems. LTP would prevent it from, in your example, going from 127 to 0 then to 100.

[GGGss]

It sounds like you just need to run your Pan and Tilt channels in LTP... I do motions like this and never have any sort of jerking problems. LTP would prevent it from, in your example, going from 127 to 0 then to 100.

Do you know that you are answering a thread from 2015? The world has changed quite a lot since then.
I'm not going to investigate the old 'proposed solution' since it doesn't reflect the current state of development.