Adobe Premiere Support #3
Assignees
Milestone
Comments
|
Based on guidance from Adobe, we are not going to support the prproj format directly. Their format is gzipped XML, but the XML structure itself is not documented and is likely to change between releases of Premiere. Their guidance is to use the Final Cut Pro 7 XML format as this format is well documented and fully supported by Adobe for interchange. |
|
Final Cut Pro XML issue tracked here: #2 |
|
As noted, this was addressed via #36 |
jminor
pushed a commit
that referenced
this issue
Oct 9, 2018
Summary: This change merges the entire OTIO wiki into the main OTIO repo. This lets us version the documentation along with the code, and makes it easier to publish static documentation (e.g. to readthedocs.org). Details: * Remove old documentation files They are out of date, and the generated ones for the API should not be checked into source control. By creating them at build time you can run tests against the documentation and ensure that the examples in the documentation are up to date with the code that has been written. Additionally, I'm moving the doc folder over to docs in order to keep parity with the plurality of 'tests' * Add MANIFEST.in file By adding a Manifest file, we control what will get built into the final package so that we're not adding files that don't need to go into the package on pypi. This will be run in the tox step that will be added in a commit that is coming up which will build out a temporary distribution and check that the results in the output package file match up with what we've defined in here. I'd also like to exclude the examples folder, but if I exclude it, everything in my virtualenv goes nuts and breaks and I can't figure out why and I don't feel like putting more time into that. * Migrate Wiki over to tutorials and generate all API documentation Migrating the Wiki was actually the easy part. By adding the recommonmark sphinx plugin, I could just download the Wiki from Github and use the Markdown files that existed, with slight changes to fit into the sphinx-rtd-theme. NOTE that this isn't done or perfect, but it's 95% of the work done. So you might be wondering why one would want to move the wiki over to documentation in the project and the answer is simple - the wiki is not version controlled in alignment with the package and releases of the package. Building the documentation along with the version of the package allows the user to see changes and explanation alongside whatever version they're using, while the Wiki does not. Yes, they will have to generate it, but with the integration of tox (coming in a separate commit), we make that so much easier on the user with the command `tox -e build-docs`. This practice also helps encourage developers to keep updating their documentation and it's worked great at the last few studios I've worked at and implemented it at. * Add tox to dev dependencies and add tox file Since this is a new dependency, you'll have to rerun the install command with `pip install -e .[dev]`, deactivate your virtualenv, and then source it again. After that, you only have to run `tox` when you're sourced inside of your virtualenv to run all the tests, and you can run `tox -e build-docs` to build the documentation. This is not finished yet, I plan to add a couple more steps to the tox script in a coming commit, but for the purpose of running tests and building documentation, this works. If a tox environment ever gets funky, you can run `tox -r` to rebuild the environments. I have only ever had to do that once. * Update file documentation to build API docs properly Since I added the ability for Sphinx to build ALL of the API documentation, there were docstrings that were never touched by the build stuff that was set up previously, and thus had issues that prevented documentation from building. This was a rather annoying chore to have to go through, and I should not have messed with any code at all, it should have only been docstrings getting messed with (minus the import statements in tests). I would appreciate you all looking at this and making sure, though. * Documentation formatting updates Adding images, formatting, fixing tables, making links work. * Add ReadTheDocs configuration file * Add apidoc to Sphinx building and move module tree in index * Cleanup for conf.py file and adding documentation link to README * Flake8 cleanup and update manifest file * Remove pip installs from Travis, change pep8 to pycodestyle, add to tox * Test moving coverage call to tox * Change py.test command to module being called from python for Travis * Add tox-travis plugin to travis file * Fix coverage on Travis * Actually fix coverage on Travis and in Tox * Add coverage dependency to travis pip installation Didn't think about the fact that it should be needed outside of the virtualenvs that Tox creats * Minor fixes to new doc system (#3) * Fixed indentation issue in doc string. * Changed Makefile doc-html target to run new tox -e build-docs. * Put lambda idiom back the way it was. * Adjust version string in conf.py for documentation
alatdneg
referenced
this issue
in alatdneg/OpenTimelineIO
Nov 13, 2018
Summary: This change merges the entire OTIO wiki into the main OTIO repo. This lets us version the documentation along with the code, and makes it easier to publish static documentation (e.g. to readthedocs.org). Details: * Remove old documentation files They are out of date, and the generated ones for the API should not be checked into source control. By creating them at build time you can run tests against the documentation and ensure that the examples in the documentation are up to date with the code that has been written. Additionally, I'm moving the doc folder over to docs in order to keep parity with the plurality of 'tests' * Add MANIFEST.in file By adding a Manifest file, we control what will get built into the final package so that we're not adding files that don't need to go into the package on pypi. This will be run in the tox step that will be added in a commit that is coming up which will build out a temporary distribution and check that the results in the output package file match up with what we've defined in here. I'd also like to exclude the examples folder, but if I exclude it, everything in my virtualenv goes nuts and breaks and I can't figure out why and I don't feel like putting more time into that. * Migrate Wiki over to tutorials and generate all API documentation Migrating the Wiki was actually the easy part. By adding the recommonmark sphinx plugin, I could just download the Wiki from Github and use the Markdown files that existed, with slight changes to fit into the sphinx-rtd-theme. NOTE that this isn't done or perfect, but it's 95% of the work done. So you might be wondering why one would want to move the wiki over to documentation in the project and the answer is simple - the wiki is not version controlled in alignment with the package and releases of the package. Building the documentation along with the version of the package allows the user to see changes and explanation alongside whatever version they're using, while the Wiki does not. Yes, they will have to generate it, but with the integration of tox (coming in a separate commit), we make that so much easier on the user with the command `tox -e build-docs`. This practice also helps encourage developers to keep updating their documentation and it's worked great at the last few studios I've worked at and implemented it at. * Add tox to dev dependencies and add tox file Since this is a new dependency, you'll have to rerun the install command with `pip install -e .[dev]`, deactivate your virtualenv, and then source it again. After that, you only have to run `tox` when you're sourced inside of your virtualenv to run all the tests, and you can run `tox -e build-docs` to build the documentation. This is not finished yet, I plan to add a couple more steps to the tox script in a coming commit, but for the purpose of running tests and building documentation, this works. If a tox environment ever gets funky, you can run `tox -r` to rebuild the environments. I have only ever had to do that once. * Update file documentation to build API docs properly Since I added the ability for Sphinx to build ALL of the API documentation, there were docstrings that were never touched by the build stuff that was set up previously, and thus had issues that prevented documentation from building. This was a rather annoying chore to have to go through, and I should not have messed with any code at all, it should have only been docstrings getting messed with (minus the import statements in tests). I would appreciate you all looking at this and making sure, though. * Documentation formatting updates Adding images, formatting, fixing tables, making links work. * Add ReadTheDocs configuration file * Add apidoc to Sphinx building and move module tree in index * Cleanup for conf.py file and adding documentation link to README * Flake8 cleanup and update manifest file * Remove pip installs from Travis, change pep8 to pycodestyle, add to tox * Test moving coverage call to tox * Change py.test command to module being called from python for Travis * Add tox-travis plugin to travis file * Fix coverage on Travis * Actually fix coverage on Travis and in Tox * Add coverage dependency to travis pip installation Didn't think about the fact that it should be needed outside of the virtualenvs that Tox creats * Minor fixes to new doc system (#3) * Fixed indentation issue in doc string. * Changed Makefile doc-html target to run new tox -e build-docs. * Put lambda idiom back the way it was. * Adjust version string in conf.py for documentation
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OTIO needs support for reading & writing Adobe Premiere prproj files.
The text was updated successfully, but these errors were encountered: