Set timing value by a refresh rate value

[AussiePhil]

It would seem that with the default timing grid a thing of the past it would make greater sense to nominate the desired refresh rate of your display and have the software output as required.
This would need some limits as getting data out and processed at 100hz is not feasible with current hardware.

One driver is a lot of people have a DMX environment as a destination for data and the nominal and normal refresh rate is 44hz (22.7ms), this does not align the nominal 25/50/100 ms timings very well and especially at 50ms fixed timing can result in visible artifacts due to misaligned timings.
Be nice to have
44hz - 40hz (25ms) - 30hz - 25hz - 24hz - 20hz (50ms) - 10hz (100ms)
the 25/24 settings align with common video record/playback rates.

Thoughts anyone

[sean]

I know that our timing grid has to be fixed and I believe it is an integer ms value. Would it help to offer 25,27,33 ms? Or whatever.   Ms values make sense. Gil, do I have it correct, integer frame timing?


Sent from my iPhone using Tapatalk

[Gilrock]

I'd have to check but even though it might be stored as an integer I'm sure we are converting it to a double to calculate the conversions to time.  But there are a lot of other things I would want to investigate.  Right now all the timings are multiples of 25ms and believe all the timeline and grid drawing is designed based on pixels fitting into a 25ms window.  At least I know that the zooming calculation have a fixed lookup table.  I'd kinda like to hear from Dave since he designs boards that are doing DMX and he designed this editor.  Is there really any advantage to these other timings because we are all locked into 50ms last year and people were running 10's of thousands of channels no problem.

[AussiePhil]

I'd have to check but even though it might be stored as an integer I'm sure we are converting it to a double to calculate the conversions to time.  But there are a lot of other things I would want to investigate.  Right now all the timings are multiples of 25ms and believe all the timeline and grid drawing is designed based on pixels fitting into a 25ms window.  At least I know that the zooming calculation have a fixed lookup table.  I'd kinda like to hear from Dave since he designs boards that are doing DMX and he designed this editor.  Is there really any advantage to these other timings because we are all locked into 50ms last year and people were running 10's of thousands of channels no problem.

Hi Gil and Sean,

As always I will speak plainly,

Yes there is a significant advantage to at least 25ms timing as it smooths out effects and motion across large pixel displays, smooths out fades as well.

I so missed 25ms timing last year and I could visible see the 50ms was not smooth. 20hz refresh is not smooth running effects/motion/video stuff. The move to have 25ms and 100ms this year is a great thing

As for the 30/25hz rates, this just provides alignment to common video camera frame rates and power line frequency.

The three most common DMX dongles used in the community all output at a fixed 44hz rate and whilst most don't notice anything the super smooth effects we can now have will have a potential for missed frames when using 25ms timings on DMX chains.
The discussion is largely irrelevant for E131 controllers and hence pixels in general

If your underlying code is still dependant on the fixed ms timing then no worries, I was only presenting some thoughts based on how the world in general talks these days in hz/fps for video/cameras/tvs/film etc.

Cheers and thanks for all the hard work you both to in providing a great sequencing tool.
Phil

[JonB256]

Not a new thread, but I was looking at this yesterday.

On my new P10 matrix, I was running various Text routines - left, right, up and down, etc....

I had defaulted to the old standard of 50msec (20 frames/sec) and could see some jerkiness. From a distance, it was "almost" unnoticeable, but up close (within 10 ft), I noticed.

I was concerned that it was an artifact of the P10 panels, so I recreated the sequence in 25msec (40 frames/sec) to see if it made a difference.

And, yes, it did. It is noticeably smoother. I haven't video'd it yet to see if it helps with the problem that P10 panels seem to have with video, anyway.

But, before you jump out and change everything to 25msec, be warned that the FSEQ file size is Doubled. Slower copy times over to my Pi or BBB.

And - this is more of a Falcon Pi Player thing, but when I put all 3 of these files in a single playlist (25msec, 50msec and 100msec), they played at the incorrect speeds. (technically, they all played at 50msec speed, so the 25msec was half speed and the 100msec was double speed) When played using the Test option to play an FSEQ file, they were fine.

[flyinverted]

Just curious how the power line frequency comes into play with this?

I know AC must go through a rectifier in the power supply and we get DC out the other end. DC has no frequency or a frequency of 0, so how does the AC input frequency affect DC lights?

[JonB256]

This is the Timeline frequency in Nutcracker. When you start a new sequence, it is one of first questions.  Nothing to do with power supplies or ac/dc.

[Gilrock]

Steve's referring to the "power line frequency" mentioned before your post.