Rewrite methods
Rewrite methods
The plan was to take Blocks, Groups, and Beats from the existing script and reuse and rewrite them as I build a newly structured version.
My original thought was to open two instances of Causality and copy and paste from the old script to the new one.
Opening two versions of Causality doesn't appear to be possible.
My next approach was to Create a new Lane and try copying and pasting from the old lane to the new,
Copying and pasting Blocks, Groups, and Beats in the whiteboard doesn't appear to be possible.
Do you have a suggestion for the best way to go about this, or do I just have to create all new elements and settle for copying and pasting raw text?
Not a massive deal if that's the case, but at some point it would be great to be able to duplicate elements so the original text can be referenced during rewrites, and then deleted when done.
Max
Banquetburger
01-05-2024, 07:08 PM #1I'm undertaking a kind of Frankenstein-rewrite of a script.
The plan was to take Blocks, Groups, and Beats from the existing script and reuse and rewrite them as I build a newly structured version.
My original thought was to open two instances of Causality and copy and paste from the old script to the new one.
Opening two versions of Causality doesn't appear to be possible.
My next approach was to Create a new Lane and try copying and pasting from the old lane to the new,
Copying and pasting Blocks, Groups, and Beats in the whiteboard doesn't appear to be possible.
Do you have a suggestion for the best way to go about this, or do I just have to create all new elements and settle for copying and pasting raw text?
Not a massive deal if that's the case, but at some point it would be great to be able to duplicate elements so the original text can be referenced during rewrites, and then deleted when done.
Max
I think you're minimizing your problem, I think this is a major lack in Causality, both the ability to go between documents, and copy/paste within documents.
What has stalled it was frankly that we didn't know how to approach it. Causality is not just like a Word document were you have a single linear piece of text that you can extract and repurpose somewhere else. In Word or Final Draft, you have no linkages, beyond maybe a style, so it's easy to move around. Causality on the other hand is a witches brew of connections between things, and that makes it harder to decide what should happen when you paste.
Presumably, nobody is expecting that if you copy a beat, that we create new lanes, block, groups, research folders, tags etc for it. You'd want to reuse as much as possible of the surroundings. That's doable within a single document, and harder between two separate documents, because if we're trying to reuse e.g. a lane, do we do it based on the name, or its unique ID, or do we create a new lane every time you paste. And if a beat as multiple versions, should we copy every version or just the current one.
The bad version of this is putting up a dialog with 20 checkboxes for how to paste. The good version is that we make a decision that works for most use cases, so it's on auto.
Here's where we are:
* Beats should be copied in their entirety, including all versions. This is because in a rewrite, you build the rewrite on the side, and eventually delete the old beats. Therefore, the new beats have to be able to stand on their own from the get-go.
In terms of links (between beats, snippets, tags, emotions (upcoming), lanes, blocks, research folders, timeline orders etc), we should try to reconstitute links first by unique ID, and then by name if no ID found.
When pasting in the whiteboard, we won't keep the link to the old block if you're pasting into a new block. If you're pasting out in the open in a lane, we'll paste into existing blocks if they're nearby, or create new blocks with new names (e.g. (2)) if they're further away. There are more such decisions to make.
This is *vastly* easier to do within a single document, because we have the whole database unpacked, so we might do this just inside of a single document for now, because it solves 90% of the problem. The use case for multiple documents is most the legacy workflow of just copy/pasting between document boneyards, and that need goes away if you can do this properly within a single document.
I'm just explaining this to say why it has been stalled. I consider this fundamental functionality that should have been there long ago. But with limited resources, we have to go where the screaming is loudest, and that's around collaboration, sync and mobile apps.
For you, the best workflow would be to save under a new name, and then just start butchering it, with the ability to always open the old document to see how something was done before. You can also create some empty beats as placeholders in a new lane to work on the new structure, and ultimately drag the real beats down. These are workarounds, not ideal solutions.
Hi,
I think you're minimizing your problem, I think this is a major lack in Causality, both the ability to go between documents, and copy/paste within documents.
What has stalled it was frankly that we didn't know how to approach it. Causality is not just like a Word document were you have a single linear piece of text that you can extract and repurpose somewhere else. In Word or Final Draft, you have no linkages, beyond maybe a style, so it's easy to move around. Causality on the other hand is a witches brew of connections between things, and that makes it harder to decide what should happen when you paste.
Presumably, nobody is expecting that if you copy a beat, that we create new lanes, block, groups, research folders, tags etc for it. You'd want to reuse as much as possible of the surroundings. That's doable within a single document, and harder between two separate documents, because if we're trying to reuse e.g. a lane, do we do it based on the name, or its unique ID, or do we create a new lane every time you paste. And if a beat as multiple versions, should we copy every version or just the current one.
The bad version of this is putting up a dialog with 20 checkboxes for how to paste. The good version is that we make a decision that works for most use cases, so it's on auto.
Here's where we are:
* Beats should be copied in their entirety, including all versions. This is because in a rewrite, you build the rewrite on the side, and eventually delete the old beats. Therefore, the new beats have to be able to stand on their own from the get-go.
In terms of links (between beats, snippets, tags, emotions (upcoming), lanes, blocks, research folders, timeline orders etc), we should try to reconstitute links first by unique ID, and then by name if no ID found.
When pasting in the whiteboard, we won't keep the link to the old block if you're pasting into a new block. If you're pasting out in the open in a lane, we'll paste into existing blocks if they're nearby, or create new blocks with new names (e.g. (2)) if they're further away. There are more such decisions to make.
This is *vastly* easier to do within a single document, because we have the whole database unpacked, so we might do this just inside of a single document for now, because it solves 90% of the problem. The use case for multiple documents is most the legacy workflow of just copy/pasting between document boneyards, and that need goes away if you can do this properly within a single document.
I'm just explaining this to say why it has been stalled. I consider this fundamental functionality that should have been there long ago. But with limited resources, we have to go where the screaming is loudest, and that's around collaboration, sync and mobile apps.
For you, the best workflow would be to save under a new name, and then just start butchering it, with the ability to always open the old document to see how something was done before. You can also create some empty beats as placeholders in a new lane to work on the new structure, and ultimately drag the real beats down. These are workarounds, not ideal solutions.
Yes, I hadn't considered all of the linking and processing plugged into each element - that's a massive undertaking.
My two cents regarding placement of resources: Frankly, copying and pasting between documents sounds like an unnecessary luxury - being able to do that work within a single project would be a perfectly legitimate solution.
Causality has helped my productivity so much that having to employ a few hacks here and there as it develops isn't a big deal.
Mostly wanted to make sure I wasn't missing something.
Thanks
Max
Banquetburger
01-05-2024, 07:57 PM #3Thanks for the thorough insight, Per -
Yes, I hadn't considered all of the linking and processing plugged into each element - that's a massive undertaking.
My two cents regarding placement of resources: Frankly, copying and pasting between documents sounds like an unnecessary luxury - being able to do that work within a single project would be a perfectly legitimate solution.
Causality has helped my productivity so much that having to employ a few hacks here and there as it develops isn't a big deal.
Mostly wanted to make sure I wasn't missing something.
Thanks
Max
Footnote, every time we've had the feature request to work in multiple documents, I've asked into the use-case, and it's always the workflow of having many open "boneyard" documents and moving stuff between them, which is a word-processor centric workflow we have difficulty with, just like video editors do. They try to hide the complexity, but they're actually importing a ton of infrastructure with every file you can see in order to pretend that moving things between documents is easy.
So that's what made me conclude that the only problem worth solving is copying things within a single documents, and we have a lot of spec for how to do that now, so I see it happening relatively soon.
Thanks again!
Thanks!
Footnote, every time we've had the feature request to work in multiple documents, I've asked into the use-case, and it's always the workflow of having many open "boneyard" documents and moving stuff between them, which is a word-processor centric workflow we have difficulty with, just like video editors do. They try to hide the complexity, but they're actually importing a ton of infrastructure with every file you can see in order to pretend that moving things between documents is easy.
So that's what made me conclude that the only problem worth solving is copying things within a single documents, and we have a lot of spec for how to do that now, so I see it happening relatively soon.
Thanks again!
Also, what if lanes were in a container? You Could see all the containers and their lanes on the whiteboard. Lanes in one container do not affect lanes in another container. You could duplicate a container with all its lanes and name it, for example, "Book 1 revision 2". Containers could be minimised to save space.
This way you could also have a series of books in one file. All the research and characters would be shared. The timeline and Script windows would update depending on which container you are active in.
What if there was a type of lane that had no impact on items in the other lanes?
Also, what if lanes were in a container? You Could see all the containers and their lanes on the whiteboard. Lanes in one container do not affect lanes in another container. You could duplicate a container with all its lanes and name it, for example, "Book 1 revision 2". Containers could be minimised to save space.
This way you could also have a series of books in one file. All the research and characters would be shared. The timeline and Script windows would update depending on which container you are active in.
1 Guest(s)
1 Guest(s)