Hi David, In your account, you'll see it on the Course Downloads page.

We also receive touch events when they're available.

What is your input device? Mouse? Trackpad?

Hi, Scroll wheel on a mouse, or two-finger dragging on a trackpad.

Hi Darren, The crash that I see appears to happen after import. The import itself is successful, but something goes wrong in the rendering of the markers. We generate structure markers based on certain indicators in the FDX file. It's kind of hard to imagine how anything from the file could cause marker rendering to crash, but that's what it looks like is happening. Basically, this issue is so niche and unknown to us that we don't have even a chance at addressing it without an example of a document where it happens. We need to see it crash in the debugger, so we can examine the state at that moment, as well as examining the XML of the Final Draft document to see what's unusual about the act markers. We'd really love to get our hands on the FDX document, securely, of course. If this is acceptable to you, please send an email to support@hollywoodcamerawork.com, and I'll make a file transfer request.

Hi, But let me understand, it's the import process that literally crashes, doesn't just show an error? I'm just trying to get as much context as possible, as looking at stack traces can be a bit forensic. If that's the case, is there any chance we can see a copy of the FDX document that does this? It's just completely outside of what we know about our import process, so we have to see it happening. We can arrange secure file transfer that doesn't leave digital traces. Is that possible for you? I don't know how secret the document is, but if it's an actual crash, we've never seen that in the importer before, and we have to see it crash in the debugger, which means running it here.

Hi, What error do you get when importing an FD script? That's definitely unusual, and something we'd want to address. Most people start with importing an existing script, and we weren't aware of any issues. Copy/paste of beat text is robust, and we detect screenplay formatting quite well, whether it's coming from Final Draft or even Word or a web page. But it's important to realize that working in two documents means having everything stripped down to the bone every single simple you go across documents. This workflow worked when all you were moving was some text, but here, it's a whole database around the object. A beat is connected to characters and tags and blocks and groups and lanes and attachments. It's like time travel in the Terminator movies, everyone goes through naked. If you're doing this purely to have a separate area for things you aren't using, this is what Research is for. It's like the video editing bin. There's no need for separate documents, it's an old workflow that only worked with plaintext. But if you're having trouble pasting text in, it would be great to see how this goes wrong, as it's believed to be robust.

Good idea with a separate button to Make Current.

Not currently. There will be, but even so, it's no picnic to decide what should be moved between documents. When we interview people about it, it's usually because they're used to a word processor paradigm where they have various boneyards of things they've pulled out of the script that's being dumped in other documents. But in Causality, it's not just text, it's tons of objects that are linked together, like characters and tags and lanes and blocks and attachments and much more, and all of those links are broken when going between documents. We do have some hacks planned for e.g. recognizing that a lane has the same name, so we don't create a new lane called "Main Lane" every time you paste anything. But it's important to realize that Causality is like a video editor, and you're supposed to have all your resources in the same project. When you delete something in Causality, it doesn't go anywhere, it just becomes disused. So you don't need the old word processor workflow of having multiple documents and pasting between them just to have a staging area and boneyard. You can do all of it in research. And then you can also track which ideas you're currently using. What is your use case for multiple documents?

Hi Darren, Thanks for posting! This is a slightly bigger problem that we're trying to address. The thing is that there are actually multiple kinds of characters in the app: The actual character text in the script. The character objects in research. The links of character objects to beats (like tagging characters onto a beat). The detection words of characters that automatically link characters to beats where they're mentioned. The character name when mentioned in a beat title or synopsis. Everybody of course expects all of these to be in sync, but we haven't been sure how to address it. One thing coming in the next release is that we auto-create characters that we don't recogize. The downside is that even a typo will create a character with that name that you'll have to clean up, but that's the same in Final Draft. Changing a character name requires a search/replace, and we're very nervous about automating it. The search/replace dialog itemizes which area the character name was found in, so you can search replace in beat titles, character names, synopsis, script text etc. I feel that the best bet is using the search/replace for renaming characters, but perhaps getting you there via a wizard so you still get a button that says "Rename Character". This gives you a change to inspect the rename before it happens. Obviously, going between sophisticated names will always work, but we're worried about bulk replace from simple names to other simple names. Imagine renaming Q from Star Trek. How much other stuff are we scooping up? Do we really want that to be fully automatic? That's the kind of reasoning we're forced into.

Hi, 1.) I trust that creating dependencies works through the right-click menu? I feel like I have a vague memory of us stealing I and O for something else or reserving them, but it could just have been discussed, I can't remember if we did it. Please double-check that this is right after clicking a beat in the whiteboard. Keyboard shortcuts change based on which area is currently focused. 2.) It would be great to see it in action with beat versions not being saved. Are you certain this is not just about which version is "current"? 3.) The note functionality in the inspector is a bit half-assed. We been reluctant to do too much work until we can answer where notes fit into the bigger picture, which is clearer now.

Hi, I'm so sorry for the delay. The forum has been getting a lot of spam, and I missed this one in the noise. Is this still happening? This is of course way too late. I truly hope that you managed to work it out.

But again, you're not supposed to sign in. The app is ready. You just have to select a camera source for live view.

Hi, Green Screener is a paid app, so it's already activated when you run it even for the first time. The purpose of signing in is to get your purchase recognized in your Hollywood Camera Work account so that you can use the app on other platforms, or so that you can activated based on a purchase in your account that came from another platform.

Hi, It's important to be aware that the app thinks more abstractly about shots, and in principle doesn't care that you're shooting them in pairs, or even whether they're on tripod or handheld or whatever. It's about the angle being represented. The thing also about shooting multiple cameras at the same time is that the configuration changes a lot at the last minute, when you realize that it's more practical to get other pairs instead. So even if setup 1 will have angles 1A and 1B, and setup 2 will have angles 2A and 2B, you might end up shooting 1A and 2A together, and then 1B and 2B. So banking the cameras this early is often just a demo, except perhaps for a sitcom or live TV where the camera script is truly followed. That said, the app shouldn't stand in the way if you want to plan like that, because then you could at least get to think about camera banking, even if you'll change it up at the last minute. This was partly not imagined in the original data design, and is therefore being hacked on top. The 3D version of Shot Designer will have more free-form shot numbering. Internally, the camera or shot number is just an integer. The multicam numbering mode then spreads it out so that the first 27 integers belong to camera 1A-1Z, and the next 27 belong to 2A-2Z. I'm remembering this loosely, don't quote me. I think you could use the multicam numbering mode (Shot List menu) and get close to what you want.

Hi, The imported images are live and not remembered. There is something to be said for importing background images into a library, but in reality, that library would need a whole management layer, and a whole sync layer on multiple devices, so that single feature would take us months to do. And you already have that feature in your Camera Roll/iCloud/Dropbox/Google Drive etc. Just import the image you want, and to change it, you import another image. The numbered cameras are simply the cameras on your device, usually 3-4 rear-facing cameras, and 1-2 front-facing cameras. Just select them, and you'll see.

Lasso selection needed long-press, and this is a more deserving use for it. It was philosophically a bit wrong and also unorthodox to put duplicate on long-press, but we did it because we had no other use for it. On desktop, you can press Cmd/Ctrl+D to duplicate.

Thanks!!!

Hi, The next update will have more colors. We've waited on any document format-breaking changes because they were hard to do at the same time as infrastructure changes. We also want the colors to be repeatable, and not just an RGB color selector.

Hi, Great! Yes, Dropbox is a better way to "share", because it does whole files. And Dropbox also has versioning for emergencies. The path you mention is just the QML cache. The UI in Causality is written in a language called QML, which is compiled to .qmlc files just in time. The directory you're looking for is: ~/.local/share/Hollywood Camera Work/Causality I'll update the docs.