Cutlist editor tweaks

[adoxa]

I use the cutlist editor a fair bit, so I've changed the keys to make it a bit quicker - RED to start cut, GREEN to end cut, long GREEN to remove before, long RED to remove after and YELLOW to go backward. I've also made RIGHT seek 2 seconds, as I found 1 second didn't always work. I've also fixed it so you can move freely in the file and stopped setting the last position. I've tested with Full-Metal-Wizard, but not easy-skin-aus-hd (but since they were originally the same, I don't anticipate any problems); other skins will still show the old keys.

Attached you'll find a patch for the source, a patch for the skins (from the release) and a zip for anyone wanting to try it out - extract, run setup.sh (and run again to restore the original), then restart the GUI.

[dRdoS7]

Hi,

I use the cutlist editor a fair bit, so I've changed the keys to make it a bit quicker.

I don't use the cut list editor, but I'm sure it will be a good improvement.

If you're ever bored, , there's a wasted coloured key (Green/Satellites) in the Channels screen which would be perfect if it was made to add the highlighted channel to a Favourites List. It's a long winded process ATM, especially if you have to do it a lot (like when travelling with a caravan).

Thanks,

dRdoS7.

[peteru]

I'm happy to take a look at this patch and provide feedback/merge it into the firmware if you could please generate pull requests against the corresponding Bitbucket repositories:

https://bitbucket.org/beyonwiz/easy-ui-4
https://bitbucket.org/beyonwiz/easy-skin-aus-hd
https://bitbucket.org/beyonwiz/skin-full-metal-wizard

[IanSav]

Hi Adoxa,

I never understood why the navigation buttons were repeated as the colour buttons. I would suggest that as you are making the colour buttons more like the normal use of the colour buttons that you should use the normal (templated) version of the colour buttons. That is, set the Label/Button variables key_red, key_green, key_yellow and key_blue. This would make for standard and easier skin modifications in *all* skins.

Regards,
Ian.

[adoxa]

@dRdoS7: Sure, I can take a look, start a new topic...

@peteru: Done.

@IanSav: Done (I think).

I've prevented ending a cut before starting it, which fixes the doubling up when you use remove after and then remove before. I've also added the duration of each mark to the list.

NB: remove with the previous script before installing with this one!

[dRdoS7]

Hi,

@dRdoS7: Sure, I can take a look, start a new topic...

Here's one I prepared (much) earlier:

http://www.beyonwiz.com.au/forum/viewto ... =47&t=9590

Thanks,

dRdoS7

[IanSav]

Hi dRdoS7,

If you're ever bored, , there's a wasted coloured key (Green/Satellites) in the Channels screen which would be perfect if it was made to add the highlighted channel to a Favourites List. It's a long winded process ATM, especially if you have to do it a lot (like when travelling with a caravan).

Boy is this *WAY* off topic!

Regards,
Ian.

[dRdoS7]

Hi,

Hi dRdoS7,

If you're ever bored, , there's a wasted coloured key (Green/Satellites) in the Channels screen which would be perfect if it was made to add the highlighted channel to a Favourites List. It's a long winded process ATM, especially if you have to do it a lot (like when travelling with a caravan).

Boy is this *WAY* off topic!

Regards,
Ian.

To quote Hudson: "Don't you ever let a chance go by."

dRdoS7

[adoxa]

@dRdoS7: I did a search, but had "green" as a term, so missed it.

[IanSav]

Hi Adoxa,

Please draw my attention to when the editor changes are finalised and I will update the OverlahHD skin to match. I have already added the colour buttons in anticipation of your change.

It would also be worthwhile submitting your improvements to the Dev branch of the master OpenViX repository so that they too get the improvements. It also makes PeterU's future merges that little bit easier.

Regards,
Ian.

[IanSav]

Hi Adoxa,

In the Movie list "ready to watch" state thread you wrote:

I find the automatic start bookmark to be very unreliable; the end bookmark is usually pretty good, but it's really the start of the next show, so may be a few minutes out (yeah, I like to be precise ). I prefer to explicitly cut the start and end padding; I only do the ads and execute for shows I record for someone else.

Would it make sense to have a way to select a bookmark and shift it to a new position? Sort of a nudge it earlier or later. Even better if the nudge distance can be specified.

While talking about the CutList Editor I have a few other wishes:

• All the jumps should be user configurable.
• There should be a clearly separate way of saving or abandoning changes.
• Add a playback mode that obeys the bookmarks to skip over the cut edits so you can preview an edit.
• Add a way to execute the cuts from within the editor to save a few button presses.

There are probably other wishes that would make the built in editor easier to use.

Regards,
Ian.

[Paul_oz53]

Love this line of thought - improving the edit function is no.1 on my wishlist!

Keep up the good work guys

[adoxa]

Would it make sense to have a way to select a bookmark and shift it to a new position? Sort of a nudge it earlier or later. Even better if the nudge distance can be specified.

Isn't it just as easy to remove it and add it where you want it? Maybe just stop the editor moving to the previous mark when you remove one. Although that means you can't ever move to the only mark, since the selection doesn't change and "OK = Menu".

All the jumps should be user configurable.

Possibly, but I find they're pretty good as they are, and that saves me some effort.

There should be a clearly separate way of saving or abandoning changes.

How about leaving EXIT as save and exit, and BACK as either reset (i.e. restore the original list, but remain) or cancel (restore the original list and exit). I think I'd prefer the former; maybe the menu could have both?

Add a playback mode that obeys the bookmarks to skip over the cut edits so you can preview an edit.
Add a way to execute the cuts from within the editor to save a few button presses.

Should be able to add those to the menu.

[IanSav]

Hi Adoxa,

Isn't it just as easy to remove it and add it where you want it? Maybe just stop the editor moving to the previous mark when you remove one. Although that means you can't ever move to the only mark, since the selection doesn't change and "OK = Menu".

Not moving when removing a mark would help. I find positioning in the editor so painful I rarely use the editor at all. I am another watch and delete type person.

On the other hand using the classic series Beyonwiz editing was so clean and easy it was hard not to clean up recordings. (Press YELLOW to set an A marker move the playback buffer forward and press YELLOW to set a B marker and then press POP-UP to get an edit menu. Options include "Delete A -> B", "Keep A -> B only", "Copy A -> B to a new file" and "Cut out A -> B to a new file". Simple but quite functional. )

How about leaving EXIT as save and exit, and BACK as either reset (i.e. restore the original list, but remain) or cancel (restore the original list and exit). I think I'd prefer the former; maybe the menu could have both?

In general the UI works with RED as Cancel and GREEN as Save. EXIT is generally always CANCEL. BACK is a far too neglected button but it wouldn't make sense in this context.

Regards,
Ian.

[adoxa]

In general the UI works with RED as Cancel and GREEN as Save. EXIT is generally always CANCEL. BACK is a far too neglected button but it wouldn't make sense in this context.

I've used RED/GREEN as start/end cut, so that's no good; EXIT is already save & exit here; and I thought BACK made perfect sense. I must be on a different wavelength to everyone else...

[IanSav]

Hi Adoxa,

I've used RED/GREEN as start/end cut, so that's no good; EXIT is already save & exit here; and I thought BACK made perfect sense. I must be on a different wavelength to everyone else...

I may help if you take a step back and just browse the UI to get a sense of how the buttons are used and the menus are organised. It will make things easier if you follow the general flow of the UI.

I am working on unifying many parts of the UI at the moment. The date / time task is done. The Setup menus are under way. The Menu menus will be next. The more we make things familiar the easier it is for users to find their way around.

Regards,
Ian.

[adoxa]

Would it make sense to have a way to select a bookmark and shift it to a new position? Sort of a nudge it earlier or later. Even better if the nudge distance can be specified.

Isn't it just as easy to remove it and add it where you want it? Maybe just stop the editor moving to the previous mark when you remove one[...]

I tried to stop '0' from moving back to the previous mark, but it didn't work, so I must be missing something (may need to explicitly map it and handle it directly). OTOH, at that time I did want it to seek back to the previous mark, so atm it remains. Using "remove this mark" from the menu preserves the current position, though.

All the jumps should be user configurable.

That can wait for another year...

There should be a clearly separate way of saving or abandoning changes.

Went with BACK, bringing up a menu to restore the initial cuts, restore & exit, or remove all.

Add a playback mode that obeys the bookmarks to skip over the cut edits so you can preview an edit.

Added "enable cuts" to the menu, which then switches back to "disable cuts".

Add a way to execute the cuts from within the editor to save a few button presses.

Added "execute cuts" to the menu, which runs the "Execute cuts" plugin and exits the editor.

I've also made it a proper full screen window and changed long YELLOW/BLUE to use the minute seek.

NB: remove with the previous script before installing with this one!

[prl]

...

All the jumps should be user configurable.

That can wait for another year...
...

It's not particularly hard, and there's code around to steal from (the recording and timeshift skip settings are in Screens/InfoBar.py).

[adoxa]

Made another update, showing the total length of IN & OUT cuts. Note this script's keymap includes my new seekAbsolute function, so I don't know if that will crash if you don't have it (just remove it before it installing).

NB: remove with the previous script before installing with this one!

[prl]

Missing (or extra) entries in a keymap.xml Context are unlikely to cause a crash. A missing entry is likely to mean that a remote button function won't work for that context. That may happen in any ActionMap that uses the Context.

[adoxa]

Changed BLUE to Step forward.

[Paul_oz53]

Hi Adoxa,

I'm intent on trying your tweaks but just want to be sure if they are a generic change in the latest version or are they still skin specific?

Was holding off on the prospect of them finding their way into the Beta but impatience has overcome me. Earlier you mention the changes are based on the Full-Metal Wizard or easy-aus skins. Having read the files they seem to be skin specific but I know very little of modern programming languages - just enough to get into trouble!

I use OverlayHD but I see IanSav has commented earlier so I'm guessing it's ok since Ian wrote the OverlayHD skin!

Cheers, Paul

[IanSav]

Hi Paul,

I haven't installed the patches so I haven't tested them with OverlayHD.

Adoxa has not provided any feedback, instructions or pull requests to OverlayHD explaining any required skin changes.

Regards,
Ian.

[Paul_oz53]

Hi Paul,

I haven't installed the patches so I haven't tested them with OverlayHD.

Adoxa has not provided any feedback, instructions or pull requests to OverlayHD explaining any required skin changes.

Regards,
Ian.

Thanks for clarifying that Ian. So your remarks are based on a benchtop review.

I'm certainly interested in trying out the patch. I am adept at using the cutlist editor but it is not at all ergonomic! Obviously this is what prompted the patch.

Paul

[IanSav]

Hi Paul,

Thanks for clarifying that Ian. So your remarks are based on a benchtop review.

I'm certainly interested in trying out the patch. I am adept at using the cutlist editor but it is not at all ergonomic! Obviously this is what prompted the patch.

When I noted the conversation about the colour buttons I simply added the colour button panel to the CutList Editor screen. Beyond that I haven't made any other changes until I am notified.

Regards,
Ian.

[prl]

...
When I noted the conversation about the colour buttons I simply added the colour button panel to the CutList Editor screen. Beyond that I haven't made any other changes until I am notified.
...

That will be necessary, but not sufficient. The up side is that (just looking at the skin diffs file in cutlist-editor.zip) the general layout now uses standard panel elements like FullScreenWindow, FullscreenMenuButtonPanel, FullScreenColourPane and FullscreenHelpButtonPanel and should now fit within the "standard" available screen area on the "official" skins. However, there's a fair bit of rearrangement and the template in the "cutlist" widget now has an extra field.

The ZIP file only contains diffs for the Full-Metal-Wizard skin. There is a matching pull request for the changes to easy-skin-aus-hd in the repository. The diff file can't be used with "patch" to update the OverlayHD CutListEditor screen skin, both "hunks" fail to merge. It may be possible to make the patch work by modifying the diff to work around underlying differences between the originals.

[adoxa]

Here's the latest version, adding new option end at this position, which deletes everything from the current position; and starts paused, jumping to the first mark if there are no cuts and no last position (assuming it to be new). It also includes a patch for OverlayHD 1.61.

NB: remove with the previous script before installing with this one!

[prl]

... It also includes a patch for OverlayHD 1.61. ...

And for easy-skin-aus-hd

[IanSav]

Hi Adoxa,

Thank you for the OverlayHD patch I will look at it when I get back.

Regards,
Ian.

[Paul_oz53]

Hi Adoxa,

Thank you for the OverlayHD patch I will look at it when I get back.

Regards,
Ian.

And thanks from me too. Much appreciated Adoxa.
Regards, Paul

[prl]

Am I right in thinking that if you do a "cut to end", the .ts file will be truncated, and the .ts.sc and .ts.ap files are truncated to match?

If so, that changes the Cutlist Editor from making reversible edits to (sometimes) making non-reversible edits.

[peteru]

The cut list editor should remain a tool that provides non-destructive editing. It should only manipulate the markers/metadata, never the underlying .ts file.

The execute cuts tool is the right place to apply the changes to the contents. This should be performed as a separate step, once all the edit changes have been generated. If a streamlined user interface is desired, then perhaps the cut list editor can offer two methods of exiting:

1. Just exit the editor.
2. Exit the editor and execute cuts.

Option 2. should invoke the execute cuts code so that the standard user interface is presented.

[Paul_oz53]

The cut list editor should remain a tool that provides non-destructive editing. It should only manipulate the markers/metadata, never the underlying .ts file.

The execute cuts tool is the right place to apply the changes to the contents. This should be performed as a separate step, once all the edit changes have been generated. If a streamlined user interface is desired, then perhaps the cut list editor can offer two methods of exiting:

1. Just exit the editor.
2. Exit the editor and execute cuts.

Option 2. should invoke the execute cuts code so that the standard user interface is presented.

Having had a chance now to use Adoxa's tweaks, I rate them highly. A very usable enhancement. All designed to reduce button presses but retain the existing functionality.

Thanks Adoxa.

In particular, the changes to the menu within the editor link to execute cuts, which is consistent with option 2.

Thus, permanently trimming a file remains a conscious choice for the user, but requires fewer keystrokes to implement.

[adoxa]

I've added the implicit cut at the start of the file, as well as an implicit marker for EOF (is that term generally understood? I was originally going to use END, but that could imply end of playback, rather than end of file). However, before I upload, seeking to EOF is giving me troubles, since sometimes it doesn't work. Currently I do this:

Code: Select all

				curpos = seek.getPlayPosition()
				seek.seekTo(pts)
				i = 0
				while i < 10:
					i += 1
					time.sleep(0.01)
					if seek.getPlayPosition() != curpos:
						break
				else:
					seek.seekTo(pts-45000)

Since seekTo is asynchronous, wait a bit to see if it worked, then go back a bit if it didn't. I could go back first, then seek to the next access point, but that has a flicker. Alternatively, I could just go back a bit and not worry about being precise. Is there a better way to determine if seek fails to move, or perhaps an alternative length method? (seekTo(-1) has the same problem, btw.)

[prl]

It's hard to work out quite what your code snippet is intended to do without knowing what pts is set to.

In OpenViX, when they want to set the play point to the end of the timeshift file, they do the equivalent of seek.seekTo(3600 * 24 * 90000).

As you've probably already discovered, the pts time units are in 1/90000 sec, so that tries to seek to 24 hours from the beginning of the file.

It's also probably not possible to seekTo() anywhere other than the start of an I-frame (i.e. the seek will go to the start of an I-frame, no matter where exactly you've told it to go). Skips of half a second or so are going to be on about the same order of magnitude as the I-frame spacing, and so aren't likely to work very cleanly.

YMMV.

[adoxa]

It's hard to work out quite what your code snippet is intended to do without knowing what pts is set to.

The length of the movie:

Code: Select all

		length = self.getSeek() and self.getSeek().getLength()

In OpenViX, when they want to set the play point to the end of the timeshift file, they do the equivalent of seek.seekTo(3600 * 24 * 90000).

Since the length may be about 0.16s after the last seekable position, I don't imagine seeking 24 hours will help.

It's also probably not possible to seekTo() anywhere other than the start of an I-frame (i.e. the seek will go to the start of an I-frame, no matter where exactly you've told it to go). Skips of half a second or so are going to be on about the same order of magnitude as the I-frame spacing, and so aren't likely to work very cleanly.

I just want to get to the last seekable position, which the length only does sometimes, not moving at all when it doesn't.

[prl]

The idea of the seek to 24 hours from the start is precisely to go straight to the last seekable point.

[adoxa]

For the few using it, here's an update (new users wanting to try will need the previous version first).

[Paul_oz53]

For the few using it, here's an update (new users wanting to try will need the previous version first).

As one of an exclusive club, I heartily endorse your changes Adoxa. Greatly simplifies editing, which I frequently do. I hope peteru sees fit to adopt this change as mainstream. Regardless, I will continue to use it.

Works fine if installed from a usb stick. The only problem I have had is with the install script for the patch with OverlayHD. When I preloaded the patch source files to a directory on the hdd though, it somehow did not install correctly.

I ran the script from /media/hdd/movie/software using file commander but did not install correctly. The messages indicated it did install.

From reading the script it seems it should have picked up the source directory in the variable 'src' so I was surprised it didn't work. All appeared ok but the coloured buttons had no text and didn't reflect your changes. Can't be sure but it would seem the patch version of ui.pyo was not installed in the destination directory when I first ran the patch.

Repeating the run of the setup script from the usb then corrupted the cutlist editor function. This led to a gui crash when I opened cutlist editor. The uninstall test is of the destination directory for ui.pyo~ so it should have uninstalled when I repeated running the script, albeit I ran it from a different source. However, instead it repeated the install, which caused something to be corrupted.

Worked fine though when I reinstalled the firmware and re-ran the patch from the usb stick.

My advice to other users in the short-term is to install the patch from a usb stick to avoid any chance of encountering the problem I encountered.

Cheers,
Paul

[paullings]

As one of an exclusive club, I heartily endorse your changes Adoxa. Greatly simplifies editing, which I frequently do. I hope peteru sees fit to adopt this change as mainstream. Regardless, I will continue to use it.

+1 from me. I just sat down and top and tailed quite a few files.

Adoxa, Is it possible to assign "execute cuts and exit" to long press yellow or blue.

Thanks,

[adoxa]

Adoxa, Is it possible to assign "execute cuts and exit" to long press yellow or blue.

Long YELLOW/BLUE currently seek back/forward by selected minutes (or maybe percentage, depending on your settings); I've hardly ever used those, so I might change them to execute/truncate (or truncate/execute?).

@Paul_oz53: sorry for your troubles. Once we decide on the above, I'll create a new installer (for 17.5 or 16.1 or both?).

[prl]

...
@Paul_oz53: sorry for your troubles. Once we decide on the above, I'll create a new installer (for 17.5 or 16.1 or both?).

I generally assume that people comfortable with running alpha tests will also be comfortable running the latest public beta.

[Paul_oz53]

Hi guys. Prl knows me too well - I run the latest everything when I can. Yep, it's 17.5 firmware.

No apologies are necessary - I'm happy to be at the cutting edge (pun intended)!

I like the long press idea for execute cuts. Curious to know what long RED/GREEN do if they do anything or are they available?

Really like your work guys. I'm struggling to find anything else to change now. The functionality I care about is really good nowadays.

Paul

[adoxa]

Long GREEN cuts everything before (sets the start) and long RED cuts everything after (sets the end). I'm favouring long YELLOW to truncate and long BLUE to execute. I'm still on 16.1, so when I finish what I should have been doing, I'll upgrade and update.

[Paul_oz53]

Long GREEN cuts everything before (sets the start) and long RED cuts everything after (sets the end). I'm favouring long YELLOW to truncate and long BLUE to execute. I'm still on 16.1, so when I finish what I should have been doing, I'll upgrade and update.

Brilliant - I should have asked sooner! The three long presses (RED/GREEN/BLUE) would eliminate almost any need to access the menu. Much more efficient.

Right now its working fine on my T3 and T4 - both on 17.5. I've only updated the patch on the T4, since it is the main workhorse now.

[singlefished]

Is there a single installer for this patch or is it 2 stage with the download from 19th April post followed by 5th July post?

On the current cutlist editor under the latest beta 17.5 (20171230 and the previous) I find the coloured buttons don't really do much hence the reason for trying out this patch.... Up/down jumps to the next mark, left/right for skipping.

Is there any options anywhere I've not found yet that will remove ALL manually placed marks from a movie without going back into cutlist editor and removing them one by one? I set marks for adverts a couple of seconds before the actual required cutlist trim points - this gives me a bit of time to concentrate and accurately start/end cuts..... this means again going back into the executed trimmed file as a separate exercise to clean up the now redundant marks placed purely for locating my trimming points.

I do realise I could place my dummy marks inside of the adverts to trim and have them removed during the execute cuts process..... would be nice to see the option to remove ALL marks though regardless how you use them.

[Paul_oz53]

Is there a single installer for this patch or is it 2 stage with the download from 19th April post followed by 5th July post?

Two stages. The second stage adds EOF functionality and is not absolutely essential but I still install it. From my experience, it is critical the first stage is done correctly though - the second stage patch depends on that initial state being correctly implemented.

...
Is there any options anywhere I've not found yet that will remove ALL manually placed marks from a movie without going back into cutlist editor and removing them one by one? I set marks for adverts a couple of seconds before the actual required cutlist trim points - this gives me a bit of time to concentrate and accurately start/end cuts..... this means again going back into the executed trimmed file as a separate exercise to clean up the now redundant marks placed purely for locating my trimming points.

I do realise I could place my dummy marks inside of the adverts to trim and have them removed during the execute cuts process..... would be nice to see the option to remove ALL marks though regardless how you use them.

I do the same process and would generally agree that a remove marks option would be nice.

Usually, my problem is that I accidentally remove all the marks while attempting to delete a misplaced cut!

[singlefished]

Thanks Paul,

I'll get them installed tomorrow and have a play ~ anything that makes life easier has to be good

Would a "remove all marks" option fall within the realms of the cutlist editor plugin? I envisage it would ideally sit in the same menu where the options "cutlist editor/execute cuts" reside.... and this is encountered before running the plugin.

[adoxa]

Press BACK to access a menu where you can remove all marks or restore the marks as they were initially.