Marker Batch Rename Panel

[IAmVigneswaran]

@milanvarady This is somethings we can look into after the release of 1.0.0.

Maybe during version 1.2.0 or 1.3.0.

Just made a quick mockup.

1. The Rename Panel can be place after Queue Panel.
2. Users could drag and drop FCP Timeline or FCPXML into the dropzone.
3. Marker Data would retrieve the entire list of the Marker names with Notes.
4. Users can select which Marker that would like to rename.
5. They would click the Rename Options tab to set and configure their preference.
6. Once done, they can press Batch Rename Marker Data would write back / save into the FCPXML file.
7. There can be a option to automatically open FCP to import back the FCPXML file into the target Library.
8. The i or gear button would have pre-defined codes/syntax.
9. The Rename Panel is somewhat standalone. The settings are not part of our json configurations.

Some ideas
https://www.publicspace.net/ABetterFinderRename/index.html
https://renamer.com/

@orchetect I am wondering if we could add any special API call for MarkersExtractor or DAWFileKit to achieve this in a optimal fashion?

1. When Marker Data reads the FCPXML to retrieve the entire list of the Marker names, it could use a special MarkersExtractor or DAWFileKit API call to create local json cache file.
2. The json file, contains all the Marker Name and its associated Notes Name.
3. This could be a hidden feature that is not available in our CLI.
4. Marker Data would read the local json cache file to execute the rename tasks for writing.
5. Once done, another API could be used to write back the values in the original FCPXML file or create a new one (making sure all other data are not touched).

Open to suggestions and ideas.

Thank you.

[orchetect]

A few thoughts -

I'm familiar with A Better Finder Rename - awesome tool and I've been using it for probably over 10 years. Worth every penny!

I am wondering if we could add any special API call
[1. ... 4.]

As I've stated in the past, MarkersExtractor is just a data extractor with limited formatting options for pre-determined output profiles. Once you get its output, you are free to do what you like with it. Post-processing or additional formatting of data is primarily a Marker Data feature here. What you decide to do with it is, again, up to you. If you want to write it back to the JSON/CSV/TSV file, that would be your responsibility and discretion.

I suppose there could be an access point in the MarkersExtractor library (not CLI) that would allow manipulation of the data model before exporting the manifest and other files to disk.

5. another API could be used to write back the values in the original FCPXML file or create a new one

This is a new feature all on its own - essentially a "FCPXML Export Profile". It would make more sense in a hypothetical future when more input data sources than just FCPXML may be possible. Currently DAWFileKit has the ability to edit existing FCPXML and/or author a new FCPXML from scratch. We just haven't needed it since we've only been treating FCPXML as a source and not an export format/profile.

Which leads to a bigger question of: what exactly are you wanting to achieve? It feels like batch processing just the Name and Notes fields is an arbitrarily limited application of the necessary engineering that would be needed to build to achieve it. You could do a lot more with it.

A few other thoughts:

• Before and After tabs feels clunky. I would combine them into a table with 4 columns (Name, Notes, New Name, New Notes) so you can directly correlate the data transformation.
• If you want to allow power user features easily, implement RegEx replacement as an option

[IAmVigneswaran]

Thanks for the input, Steffan!

I've been using it for probably over 10 years. Worth every penny!

Same here!

Which leads to a bigger question of: what exactly are you wanting to achieve?

While creating Marker database for VFX/Review/Editorial is the main purpose of Marker Data. The seconday purpose would be the creation of Personal Shot/Frame Library for Reference. Something similar to Shot Deck. It was one of the primary motivation to add colour palette #17.

1. It is extremely easy is to add markers in FCP (using m key).
2. FCP defaults to Marker 1, Marker 2, Marker 3 and so on.
3. But when the users has 20 or more markers, it can be really tedious to rename the markers.
4. Users can have clips of different movies, commercial, tv shows in their timeline.
5. But in order to name them correctly, they would have to rename Marker 1 to Speed Racer - 001, Speed Racer - 002 or even Batman - 001, Batman - 002. Respective to their clips. It can really be tedious.

Marker.Rename.Idea.-.1.mp4

Once they have renamed their markers, they can perform extraction using Name has the Naming Mode with Swatch enabled.

Marker.Rename.Idea.-.2.mp4

User can upload to Notion database.

Marker.Rename.Idea.-.3.mp4

---

If you want to write it back to the JSON/CSV/TSV file, that would be your responsibility and discretion.

I strongly believe, Marker Data manipulating the JSON/CSV/TSV file is not the best or ideal approach. Users would always want to have a backup of their Library with movie reference clips. They would want to make sure that the markers listed in the Timeline is identical to JSON/CSV/TSV file. Which means, manipulation occurs not at the final JSON/CSV/TSV stage, but rather at the FCPXML stage.

This is a new feature all on its own - essentially a "FCPXML Export Profile". It would make more sense in a hypothetical future when more input data sources than just FCPXML may be possible. Currently DAWFileKit has the ability to edit existing FCPXML and/or author a new FCPXML from scratch. We just haven't needed it since we've only been treating FCPXML as a source and not an export format/profile.

1. A new FCPXML Export Profile could be one way.

2. But the above mentioned reason, since DAWFileKit or MarkersExtractor library is already parsing the Markers, it would great if we can have a API call to "Temporarily" read the list of markers. Marker Data could use the cache data to rename the markers. Once done, another API to write back to the FCPXML using the cache data.

3. Users can open/Import the FCPXML into their existing library. FCP would create a new (duplicate) timeline with all the markers renamed respectively.

4. Users can perform the extraction with Marker Data, as per normal.

If you want to allow power user features easily, implement RegEx replacement as an option

Yes, RegEx would be a great feature.

This batch marker rename could also be useful for batch renaming VFX Shot IDs.

[orchetect]

it can be really tedious to rename the markers

Final Cut really doesn't help here, yeah. You can't even drag markers to reposition them. Feels very claustrophobic and archaic. I'm pretty sure it has no batch rename either - you're relegated to editing single markers at a time.

manipulation occurs not at the final JSON/CSV/TSV stage, but rather at the FCPXML stage

Right, and I wouldn't recommend editing the output files any way.

can have a API call to "Temporarily" read the list of markers. Marker Data could use the cache data to rename the markers. Once done, another API to write back to the FCPXML using the cache data

There's kind of 2 different things going on here. One is the concept of mutating the FCPXML data before MarkersExtractor performs its extraction. Another is rewriting a FCPXML file, regardless of whether we actually want to continue with extraction or not. I'd want to clarify the use cases so that the API makes sense.

[IAmVigneswaran]

You can't even drag markers to reposition them. Feels very claustrophobic and archaic.

https://commandpost.io/faq/#why-did-you-remove-moveable-markers

One of the reason why most FCP users would usually place markers on Title. It give a little more customisation.

There's kind of 2 different things going on here. One is the concept of mutating the FCPXML data before MarkersExtractor performs its extraction. Another is rewriting a FCPXML file, regardless of whether we actually want to continue with extraction or not. I'd want to clarify the use cases so that the API makes sense.

Not sure if an intermediate json cache file would make sense. Marker Data would read/write to the json cache file. During the writing process, the API would use the json cache file to write/update the FCPXML.

[orchetect]

intermediate json cache file

That's a lot more work than necessary really. The library could be adapted to just give you its manifest data model without writing any files to disk. Would just require a few changes in the code to make it accessible.

[milanvarady]

This feature would be a small app in itself. We should first see how users actually use Marker Data, and then we can decide if enough users would use this feature. Maybe we can poll to see if this is a feature people would like to see.

[IAmVigneswaran]

This feature would be a small app in itself.

True. But since Marker Data, deals with Markers, it somewhat makes sense to have this feature. That way, Marker Data becomes an all encompassing application for FCP's Makers. As a user of FCP, I kinda hate the idea installing multiple apps to solve and augment different workflows needs.

Maybe we can poll to see if this is a feature people would like to see.

Certainly. But, this batch rename feature can be vital toolkit of Maker Data, because of the above mentioned reasons.

[milanvarady]

@IAmVigneswaran This is how I would implement the rename panel.

Instead of the Before, Rename Options and After panels I would combine everything into a single panel. Also I would simplify the process a bit. This is how I would do it:

• Select .fcpxml(d) file
• We would have 2 options: replace all markers or only replace markers which contain a certain text
• Matching markers would be renamed to a newly defined name follwed by the numbering (001)

We can do the same for notes.

We don't need any intermediate JSON or anything. Because we are only renaming notes and markers we don't need any complicated logic, I can just use an XML parser I think. Maybe @orchetect can help with reading and writing the actual .fcpxml(d) files if I need help.

[orchetect]

You shouldn't be touching XML at all. That's what MarkersExtractor is for.

library could be adapted to just give you its manifest data model without writing any files to disk

Like I said, I can add API to return all marker data that would otherwise be contained in a CSV as an object in memory instead.

Is this process pre- or post- processing with a profile?

That gets a bit more complicated because you would need to modify the data at some point in the middle of the process that MarkersExtractor performs.

[orchetect]

I think this reveals the fact that MarkersExtractor is really doing two jobs. It's parsing out markers from FCPXML, but it's also processing the data in order to conform to output profiles.

Those two processes could be split and it could be possible to invoke them separately.