LiveCode Forums.

Posted: **Sun Apr 19, 2020 2:13 pm**

Hi,
I am working on an editor that allows users to create karaoke versions of speeches. The editor also contains a sort of media timeline in which users can change timecode and duration of words. This timeline contains a number of fields - for each word of the speech I have one field - the width of each field represents the duration of that word, left and right position of the field represents the timecode of that word in relation to an audiofile. I have grouped all the fields into a group and I can scroll this goup (=my timeline) with a scrollbar object. So far all is good, but I run into a problem with long speeches. i did not know that there is a limit to how far outside of the stack you can place objects. In my case I would need something like this:

Code: Select all

set the left of field "wort 378" to 125000

Have you run into a similar problem? What would be an elegant solution to circumvent this limitation? Could we expect that this limitation is lifted in the near future considering the ever increasing screen resolutions?
Thanks!
Oliver

Posted: **Sun Apr 19, 2020 3:26 pm**

Hi Oliver,
Indeed the limit is 32767.
I builded a time line and i used a collection of groups but i doubt that is relevant in your case.
Best regards
Jean-Marc

Posted: **Sun Apr 19, 2020 3:53 pm**

okk wrote: ↑
Sun Apr 19, 2020 2:13 pm
In my case I would need something like this:
set the left of field "wort 378" to 125000
Could we expect that this limitation is lifted in the near future considering the ever increasing screen resolutions?

HOLY CATS MAN

I can't even begin to imagine the monitor that will ever come along that would hold resolution that would come close to that. It would have to be roughly the size (or larger) of a drive in movie screen. Well, maybe that is slightly exaggerated, but it would be 49 times wider than my 2k 40" monitor, almost 33 times wider than a 4k, etc .

I think you stunned my poor brain into a shudder. Shame on you!

Posted: **Sun Apr 19, 2020 5:49 pm**

Lifting the group buffering size limit would appear a simple solution, but in practice can easily eat up enough RAM to become impractical.

Most apps made with anything else would solve this problem through paging the displayed items, rendering only what the user can see at any given time.

This is tricky, but doable. The DataGrid compound object that ships with LC does that for vertical scrolling, and may serve as a model for one that works horizontally.

Posted: **Sun Apr 19, 2020 8:30 pm**

Hi and thanks for the replies. My current assumption for a workaround is to split the timeline in several groups of say 20000 pixels width and then kind of stitch them together on the fly when the user scrolls. It is certainly doable but feels not very elegant. More sophisticated ideas are welcome. In the dictionary it says:

Note: The current architecture uses 16-bit signed integers for all co-ordinates, which means that the value range is -32768 to 32767.

Wouldn't it be easy to switch to 24 bit ? Then I could fit a quite long speech into just one group.

I have use livecode for programming some large interactive video installations spanning quite a few monitors, I did not come close to the limitiations of the 16bit coordinates, but with 8K monitors already getting kind of normal I could imagine a use case scenario where you want a stack that is wider than what is currently possible.

Best
Oliver

Posted: **Sun Apr 19, 2020 8:55 pm**

okk wrote: ↑
Sun Apr 19, 2020 8:30 pm
...with 8K monitors already getting kind of normal...

Really? Where, pray tell, would that be happening?

In any case, 8k would be 2x 4k, which is 2x 2k. What does that xK thing mean, anyway? Hmmmm...

Wikipedia wrote: 8K resolution refers to an image or display resolution with a width of approximately 8000 pixels. 8K UHD is the highest resolution defined in the Rec. 2020 standard.

8K display resolution is the successor to 4K resolution. TV manufacturers pushed to make 4K a new standard by 2017. The feasibility of a fast transition to this new standard is questionable in view of the absence of broadcasting resources. It is predicted that 8K-ready devices will still only account for 3% of UHD TVs by 2023 with global sales of 11 million units a year.

But enough of that, even if everybody moved to 8k tomorrow, you'd have roughly 16x the availability of width that they could possibly see with what you currently have to work with. To reach the end of what you already have to work with, you'd need a 125k resolution monitor, so I think your reasonably safe for at least the next couple of weeks

*Edited for math error

Posted: **Mon Apr 20, 2020 8:11 am**

Hi, let's not go too much off topic and speculate about future resolution of devices, in my concrete use case the limit is clearly an issue because I need to place objects outside of my stack. I was looking for advice on some possible workarounds.

I also do not fully comprehend why LC could not have 24bit integers for coordinates, what would be so bad about it? Would it really slow down things considerably or increase memory usage radically? Is this some legacy issue? In my layout program and in my game engine I can choose much larger canvas sizes than 65K pixels wide.

Best
Oliver

Posted: **Mon Apr 20, 2020 8:30 am**

okk wrote: ↑
Mon Apr 20, 2020 8:11 am
I also do not fully comprehend why LC could not have 24bit integers for coordinates, what would be so bad about it? Would it really slow down things considerably or increase memory usage radically? Is this some legacy issue? In my layout program and in my game engine I can choose much larger canvas sizes than 65K pixels wide.

Lifting the group buffering size limit would appear a simple solution, but in practice can easily eat up enough RAM to become impractical.

If I'm doing the math right, 64k px wide at a 9x16 ratio would be roughly 60 feet of scrolling and require just under 1 GB RAM for a single copy of the group buffer in memory. Depending on the contents within the group and how they're composited, I can imagine total RAM use could easily be a multiple of that.

The layout program and game engine you mentioned - are you referring to things you've made in LC, or something else?

If something else, I'd be surprised if they render the whole thing in one buffer. Most apps made with anything else would solve this problem through paging the displayed items, rendering only what the user can see at any given time.

Posted: **Mon Apr 20, 2020 3:39 pm**

Hi Oliver,

I set up a very simple sample stack that swaps groups for scrolling on the fly.
It contains a main group "g0". The main group contains 4 subgroups "g1" to "g4"

There is one scroller that scrolls the subgroups within the main group.
Only two groups are shown at any one timepoint.

I thought that comes close to your setup.

Maybe that helps.

Kind regards
Bernd

Posted: **Mon Apr 20, 2020 4:54 pm**

Hi Bernd,
thanks a lot for your response! I am studying your demo stack at the moment.It seems a very elegant workaround and it goes into the direction I was thinking about. The scrolling works great. What seems for me still (at this moment) a problem with this workaround is when the user wants to change the duration or position of a field in my timeline. Each field represents a word of the speech and its duration and the user might want to change the IN or OUT point or both. If everything stays within one subgroup that's not a problem, but what if the user drags the outpoint over the edge of the subgroup into the next subgroup. I would need to somehow create a new field in the second subgroup, I have then two fields representing one word of the speech etc. This makes a simple problem which I already had solved for shorter speeches quite complicated. But I will figure something out.
I am also thinking of not using the native scrolling of a group, but rather move only the individual fields of my timeline when their timecode is within the visible section of my timeline. (Not sure if I could explain that clearly... ) Thanks again for your help, it is highly appreciated!

Best
Oliver

Posted: **Mon Apr 20, 2020 6:37 pm**

You may find that positioning things dynamically based on the scroll value in response to a scrollBarDrag message can be surprisingly snappy. That's how the DataGrid works.

Posted: **Tue Apr 21, 2020 12:28 am**

Hi Richard, thanks for the tip. I actually just did as you suggested and indeed this is snappy. Based on the position of the scrollbar I just place and show the fields that are within the visible part of my timeline, the rest I hide. So instead of scrollling one ore multiple groups of fields I just place and show dynamically the individual fields that should be visible. I did not expect that this is so smooth, I expected some lag in scrolling, especially when I have long speeches.

Code: Select all

on scrollbarDrag tccurrent
   lock screen
   put tccurrent + (width of this stack)/zoomfactor into tcmax -- calcualtiong the timecode of the visible limit of timeline on the right
   repeat with i=1 to the number of fields of group "speech"
      put  word 1 of line i of field "speech" into tcstart -- getting the timecode of the IN-point for this field
      put "wort" && i into fieldname
      if tcstart > tccurrent AND tcstart < tcmax then -- the field is within the visible area of the timeline
         set the left of field fieldname to round((tcstart-tccurrent)*zoomfactor)
         show field fieldname
      else
         hide field fieldname
      end if
   end repeat
   unlock screen
end scrollbarDrag

Despite this rather surprising easy workaround I would maintain my position that a canvas-size of maximum 65K pixels is getting sooner or later outdated. Why not switch to 24bit integers for positions?
Best
Oliver

Posted: **Tue Apr 21, 2020 2:43 am**

okk wrote: ↑
Tue Apr 21, 2020 12:28 am
Why not switch to 24bit integers for positions?

viewtopic.php?f=10&t=33953&sid=ddff9b0a ... ce#p190610

Posted: **Tue Apr 21, 2020 7:26 am**

Pretty much what Richard says. I am not the brightest bulb in this forum, but I have been programming a goodly amount of my life in various languages and all the ones I've ever used use paging or double buffering to display large amounts of items, This is going all the way back to CGA monitors in languages such as C, BASIC, and Pascal.

Does that mean that no language is that reckless? I am sure there are languages or game engines that state they do it, technically I suspect they are paging it behind you.

Your (as you put it)...

okk wrote: ↑
Mon Apr 20, 2020 8:11 am
...concrete use case...

...exists solely because, as you asked about in the first post, it was not the most elegant solution to the problem, there are other better ways to resolve it.

I sure hope you don't take that the wrong way, btw, I am hardly the most elegant coder on this forum either, and I do not mean to insult you. Simple solutions are always worth trying first IMHO.

Now, when quantum computers and 200K monitors are in wide spread use, you and I may have a completely different discussion on the whole subject. I'll make sure I rise from the dead to join in to that one

BTW, if these tips in the dictionary were yours -

: I get by with a litle help from my friends....

I have always wanted to say thank you, they really saved my bacon a few times

Posted: **Wed Apr 22, 2020 8:29 am**

Hi Richard and bogs,
thanks for trying to answer my perhaps silly question. I still do not understand fully why it would be a bad idea to have larger numbers for coordinates. In my case, I have about 500 fields in a group. My stack is 1000 pixel wide. From the 500 fields only a few are visible at the time. What eaxctly would be the difference memory or performancewise if I would be able to set my first field on the left to say -80k px compared to the current limit of -32k px. I have the same amount of fields. I cant think of anything more "elegant" than to create a group of fields with each field placed at the correct coordinates right away and than just set the scroll of that group to whatever position is needed.

Best
oliver

LiveCode Forums.

Creating a media timeline beyond the maxWidth limit

Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit

Re: Creating a media timeline beyond the maxWidth limit