[ANSWERED/LOGGED] Inconsistency Between v2.x and v3.x Timecode Related Actors?
-
Hello izziheads,
I do have at least one project that contains and uses the timecode trigger user actor, created by @fifou and extended by @mark (https://community.troikatronix...).When I tried to port it from Izzi 2 to V3.02 the project didn't work at all. After searching a bit I recognized following difference to V2:
It seems, that every timecode value in any regarding actor, only handles timecode in V3 and nothing else anymore. Thus resulting in the logic calculators used in the named user actor, can't hand over their values to the timecode comparator anymore.
I guess, this is a result of the new implemented timecode features introduced in V3, which are nice! Following this assumption, it is meant to be used with the timcecode mode of the movie player. But I'm missing a kind of actor that is filling this gap as it could be complicated to decide between the timcode and percentage mode. I would like to have a Media Percent to Timecode (instead of the already existing 'to time') actor or an converter actor that acts like the old timecode values, or even better, give back the conversion ability to the timecode values itself.Or do I miss something, that makes it possible, to have both scenarios in one path using the percentage mode and timecode actors with one movie player as source?
Best
Dill
-
Ok, I just recognised, that the opposit way still works. Timecode value outputs are still recognized by other types of inputs, like timecode calculator output to percent of media percent to time actor. Leaving me with the question, why not the other way around...
-
Michel's Timer Tool might also be helpful
Also out the Isadora 3 Release Notes and see if the answer to what you're looking for is in one of the two consecutive sections about Timecode.
-
@dillthekraut said:
It seems, that every timecode value in any regarding actor, only handles timecode in V3 and nothing else anymore. Thus resulting in the logic calculators used in the named user actor, can't hand over their values to the timecode comparator anymore... Thus resulting in the logic calculators used in the named user actor, can't hand over their values to the timecode comparator anymore.
Dear Dill,
You make several points in your post, but I want to start with this point because it indicates incompatibility with old patches...
I just looked over the User Actor you mention (I downloaded the one called timecode-jump-1.0) and I don't see anything about this that would be incompatible between v2 and v3. You say "Thus resulting in the logic calculators used in the named user actor, can't hand over their values to the timecode comparator anymore." -- but actually connecting the output of the User Actor you mention in v2 results in what I would consider to be an incorrect value.
You also say "It seems, that every timecode value in any regarding actor, only handles timecode in V3 and nothing else anymore" which is true. But what was the source of timecode in your v2 patch?
The percentage 50.0033% is converted to 50 frames, which is a nonsense value because there is timecode rate taht has 50 frames as a value. To me, it makes no sense to connect a percentage value to the old Timecode Comparator.
Similarly, connecting the seconds output of the Media Percent to Time actor produced nonsense results.
Here, 91.98 seconds is converted to 1 min, 103 seconds, and 7 frames. Really, the whole notion of timecode was poorly implemented in v2.x.
So let's start with the inconsistency part, because I want to understand that first.
Best Wishes,
Mark -
Thank you for the explanation. But I explicitly meant the 'timcode trigger' actor. (direct download: https://community.troikatronix...)
At the end of the calculation chain, inside this user actor, there is a 'timecode comparator' actor in the upper right side.
This actor gets input from a 'logical calculator' in the lower right, which works well in V2, but not in V3.
I have to admit, that I don't realy understand how the 'logic calculator', therefore the user actor in its details and why this combination of the 'systems basic' actor specificly does work, but it does it very reliable in V2...Writing this, I'm getting curious how I can get a comparison between timecodes with the comparator, if the timecode comes from somwhere else then a movie player, eg a data array, like I use to build cue lists with timecode cues to trigger actions?!
Thank you for your hints. I know the timer tool very well and used it alot, but the time code it generates, is more for a visual purpose, but not helpfull at calculations for automations.
-
@mark This comes down to the old Hex based timecode having been replaced.
This user actor may be useful. Its part of a timecode based playback engine I built sometime back.
DX - create Video TimeCode from Percentage.iua
In Isadora V2 the 'TimeCode value' output could be connected direct to the 'Timecode Comparator', this is not true in Isadora 3.
I just tried to text format timecode using the above user actor, but didn't get it to work.
The image below shows my attempt, but as you can see the text wasn't accepted as input. Is there another format I should try? ( I tried periods also)
-
@dillthekraut said:
Writing this, I'm getting curious how I can get a comparison between timecodes with the comparator,
Ok, @DusX, we should add a bug report saying that the Timecode Comparator and Calcuator actors need to accept a string as an input as well as a floating point number.
For the moment, here kind a hacky, but nevertheless successful way to do it. The Listnener actor *will* convert a string to Timecode. But the problem there is that you won't be able to have multiple instances of the same user actor in the scene if the channel number is the same. So I'm using a Random actor to generate a random channel number for both the Listener and the Broadcaster actors. This could still fail if two instances ended up, by chance, with the same channel nubmer. But it's likely to work.
Media Artist & Creator of Isadora
Macintosh SE-30, 32 Mb RAM, MacOS 7.6, Dual Floppy Drives -
thank you for the 'hack'. For now I will stay with V2 with this project! I just wanted to try it in V3 and only if it would be running save tested I would move it to V3.
But maybe it helps someone else until the bug fix release.
Best
Dill -
@dillthekraut said:
thank you for the 'hack'. For now I will stay with V2 with this project! I just wanted to try it in V3 and only if it would be running save tested I would move it to V3.
Well, the entire formatting of timecode shifted in this version, and I can see now how it has become incompatible with the older version. Thank you for bringing it to our attention.
I'm going into a bunch of detail here that some of you might not care about. But I want this as a record for the team as we address this bug.
That said, I wanted @DusX and @Woland (and everyone) to know that there is definitely a bug when it comes to converting strings to Timecode. It should work, but doesn't if you haven't explicity set a frame rate in the target. You'll find that the Movie Player timecode inputs convert from a string reliably, but that the Timecode Calculator or a Timecode Comparator do not. The reason is as follows:
Try the following:
1) Add a Timecode Calculator or a Timecode Comparator
2) Enter 00/30 into both the 'time 1' field and hit return
3) Enter 00/30 into both the 'time 2' field and hit return
4) Attach a Trigger Text actor to the 'time 1' input and set the input field to 01:02:03:04/30
5) Trigger the trigger Text Actor
6) The Timecode Calculator or Comparator's input correctly converts the timecode stirng to 01:02:03:04/30You can now also try
1) Connecting a Calculator actor to the 'time 1' input
2) Enter '35.5' in the 'value 1' field
3) The Timecode Calculator or Comparator's input correctly interprets this floating point number, converting it to 00:00:35:15/30Why is this happening? Because the initial setting for a Timecode Calculator or Comparator inputs to use the "Default Timecode Rate for Show" setting of the patch, as specified at the bottom of the User Interface window. The user interface issue here is that this default setting is not apparent to you. That's a mistake on our part we need to consider.
To see what I mean, do the following:
1) Add a new Timecode Calculator or a Timecode Comparator
2) Change the Timecode Rate at the bottom to 23.976
3) The newly added Timecode actor changes the rate to show 00:00:00:00/23.976 but the one you modified above still shows a rate of 30. That's because you explicitly initialized the actor to a timecode rate of 30 by typing a value ending with a valid frame rate, e.g. 01:02:03:04/30 into the 'time 1' and 'time 2' input fields. This means that this input will no longer use the default Timecode Rate, but the one you explicitly typed.
I'm sure this might feel confusing for you all, but this ambiguity exists there for a reason. Isadora is not like an editing program where you set a single Timecode rate and force all clips to be converted to that rate when you edit. It allows you to import movies, and interactively change the movie player, to movies which might be a mix of 24, 25, 30, etc. (even though I think we can all agree this is a very bad idea!)
When you change the 'movie' input in the Movie Player, the output timecode is going to have the correct rate for that movie. And so if you feed that output to a Timecode Calculator or a Timecode Comparator, the results will be clear. But for actors like the Timecode Calculator or a Timecode Comparator that do not have a source of timecode with an explicit rate, we don't have a clear source of timecode rate until we manually enter it.
I have already fixed this bug for a post 3.0.6 release, allowing a fully specified timecode string (01:02:03:04/XX) to force the Timecode input to the specified frame rate so the conversion will always work. But, Ryan and Lucas, we need to talk this whole thing through, because I want to be sure that we do the right thing when we make these conversions.
Best Wishes,
Mark -
