@chasmiller46: If the #1 target has a start time set by user, there is no need to assign any start times to the following targets. As suggested, I have started using no start time, and an end time on all targets after the 1st target, which has both set. This is simpler to manage, since adjusting the end times for the various targets does not require any changes to start times, since they are all blank (except 1st).
On why I think " starting date should always be set to make target #1 start at a future date/time". If the sequence is started later in the night, after 1 or more targets have run or would have run (because I could not start the sequence when I intended), the sequence should run from that point in time the way I originally intended it to run. I think that requires the addition of this rule.
@DesertSky: I think your method would work reasonably well, except perhaps if I start the sequence at 10:00 am. Not sure if that would cause problems. chasmiller46’s rules are not time of day dependent if my rule above is added.
@jmacon I did suggest there was an issue like starting at 10AM. No matter the approach you take there is always a potential ambiguity about whether the user means start now or start the next cycle. That is why I suggested some “Wait until start time” UI to determine the user’s intent.
As to the other discussions, each target should be treated independently with regard to start/end times. The only interaction between targets should be the order of execution. That is, the first target within its start/end time should be the first to go. The start/end times of a target should not depend on other targets except to determine execution order.
@DesertSky, this brings up an interesting question. Is it expected that the targets should always run in their order sequence, or is it allowable for them to run in jumbled order if the user has provided start and end times for all of them, but they are not completely listed in time order sequence?
The manual states “Work is selected based on the order of the targets, from top to bottom”. But after each target is finished, does it look through all the targets again, starting with #1? If so, apparently random processing of the targets is possible. Is this good? Perhaps it should only look for work at the following targets, which is what I had always assumed, probably wrongly.
Either way, it would be good for the manual to explain these rules in detail (when they are finalized).
To me, if you start a sequence late, then SGP should not be guessing that the target with a start time that has passed should be started anyway. If you are starting a sequence late, why not adjust the target start / end times to compensate?
Unfortunately, target start / end times can only valid for a short period of time. If I have a target with start / end times that are appropriate for the first week of November, they will be off by two hours by the first week of December.
When it comes to the sequence of targets defined in the file, at sequence start, I would want SGP to look at the first target in the list to see if there is anything to do (start time, end time, frame counts, etc.). If so, start that target. If not, look at the next target to see if there is anything to do – continuing through the list. If a target completes (frame counts or end time), SGP would continue with the next target in the list that has something to do. When all the targets have nothing to do, the sequence ends.
@chasmiller46 I guess I don’t understand the concept of “starting a target late”. What we are talking about here is start/end time limits not to be confused with actual start/end times. If the current time is within the start/end time limits for a target then the target is eligible to be run. SGP should not “adjust the target start/end” time limits. This is something the user specified that should not be second guessed. My thought is that SGP should always select the first eligible target in the list regardless of the previous target. Each target should be considered independently and not dependent on another target having just finished or not.
You are certainly right about times only being valid for a short time which why the discussion about using twilight times and altitude. Both of these adjust automatically as the days progress.
So… this thread took a few different directions. If you would like to discuss something not specifically related to the inference of target start and end times, please start a new topic.
With respect to the the original issue, I chose simplicity. It does not address all problems, but it also does not add any new settings and should work for just about everybody (except @mads0100… it still does not support starting of a sequence at 06:00 with a start time at 19:00, SGPro still thinks that is yesterday and will start the target).
The current scheme / rule set is as follows:
Sequences now have a “sequence day”… a period of 24 hours in which the sequence will run (mostly).
The boundary for this is now from 0900 to 0900. I tried the “latest” time, but that was fraught with pitfalls and special cases. This should be fine in all but extreme latitudes (might add a way to override the inferred time later).
So… the use cases:
@jmacon brought this up with a target that ended at 22:00 (or whatever), starting at 22:15 started the target because the end time was inferred to be the next 22:00 and not the one that just passed. Now the “sequence day”, when the sequence is started at 22:15 will be from 0900 that day to 0900 the next and the target will be skipped because it is in the past (expected behavior). Conversely, starting at 21:45 would place the 22:00 end time in the future. Starting the sequence at this time will produce the same “sequence day”.
@Andy had an issue (after changes to fix the above issue) where the sequence was started at 16:45 and had a target with an end time at 05:00. The behavior was that SGPro inferred that this end time was yesterday and would skip the target. Now starting at 16:45 produces a similar 0900 (of the same day) to 0900 the next day “sequence day”. This means the end time is now properly placed at 0500 in the future and the target will run until that time.
In addition to this, I have placed some extra info in the target setting dialog to help users understand what they are inferring when they input certain dates. No user entry required… it is just info:
Please feel free to throw other use cases at this to see where this method stands in terms of general usability…
Actually, it was 16:57 . But other than that I think everything you said is great and this will be a nice solution.
Like you said, the only hole is the “early bird” case, and that is really an exceptional situation that is being sacrificed to make the vast majority of users happy. I do think this is another example where if you had an external API for SGP, users with unusual requirements like the “early bird” case could simply script it if that capability were available. Right now one would have to use something like AutoIt to click the start button after 9AM.
Thanks for listening to us users and coming up with an elegant solution. As usual, you guys are doing an outstanding job on this software.
I am thinking of (in a future release), putting a small button (or something…) next to the date that would allow a user to override the date to their liking…
Adding a specific date to the setting dialog is ambiguous because it represents the date when the item was set and not the date it is (or will be) run. It is not unusual for users to use a sequence for more than one night or to create a sequence a few days in advance so the date may not reflect the actual run date. Showing relative dates would convey the information without the ambiguity.
Looking at your example, it is hard to see how a user would be confused by the times since the end time is always after the start time. Also, your example is not representative of a real case since the check boxes are not checked.
Going back to basics - the only time a potential ambiguity exists is when only of the times is given. When they are both present, there is no ambiguity because it is understood that the end time is after the start time. If you are going to use the 9 to 9 “day”, then effectively the non-selected time is 9AM.
A couple of examples to clarify:
Only the start time is set for 7PM.
a. If the sequence is started between 7PM and 8:59AM then the target is eligible to run immediately.
b. If the sequence is started between 9AM and 6:59PM the target is started at 7PM or after.
Only the end time is set for 5AM.
a. If the sequence is started between 9AM and 4:59AM then the target is eligible to run immediately.
b. If the sequence is started between 5AM and 8:59AM then the target is started at 9AM or after.
As a look at these examples, they make perfect logical sense but case 2b is not likely what is desired and case 1a is also suspect. This makes me think the real solution is force the user to supply both a start time and an end time. Then SGP does not have to be guessing the user’s intent. So the user would have the choice of no start/end times or providing both start and end times. When I started writing this post, I had no thought of this suggestion but when I actually detailed all the cases it occurred to me that providing only a single time is inherently ambiguous. Perhaps for backward compatibility you could assume the missing time is 9AM but that is not a good long term solution.
To summarize my long winded post - what the user wants is to express a time interval when it is safe to run a target. When only a start or end time is given, that does not represent a time interval. No matter how you try to make a time interval out of a single time, it is a guess that is often wrong. Having the user specify a complete interval (i.e. start and end time) is not a burden and resolves the issue. Any start/end time pair can be resolved unambiguously by noting that the end time is always after the start time.
. But other than that I think everything you said is great and this will be a nice solution.