-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add feature to export tracks #7119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Are you also sure these issues don't appear on the master branch? |
i'm on Windows, it's a pain in the ass to compile anything from scratch or build the master. |
Can't you simply install the nightly build? |
szeli1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also add #8086 MidiClipView.h SampleClipView.h. You can improve them with ProjectRenderer::availableDescriptions()
Please apply the changes according to your opinion.
Will try to apply this, thanks. It also might be easier to send me a |
|
I might do a refactor before this PR so it is easier to implement some stuff. |
What do you mean by this?
Maybe, it isn't a priority. |
szeli1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not test this PR. I miss the "drag n drop" functionality my PR provided. This PR does exporting clips better than my PR which is nice.
5c3097e to
0b1ee3c
Compare
Exporting clips brings fourth a bit more variables and complexity that should be handled separately.



The option to export a track was added to the cog wheel for anything but automation tracks. Users are presented with a file dialog for the output location and then the export dialog to specify the output configuration.
Future
This PR previously was for exporting clips as well, but this would require some refactor to do appropriately. This feature reuses some of the functionality already in
RenderManager, but the problem is that we will eventually have 3-4 different export modes to choose from, which means a possibility for a lot of conditional branching and complexity.My idea for a refactor might be to have a general
ExportContextobject, which holds the list of tracks and the time range to export, as well as if the tracks should be consolidated into one file or rendered into multiple files. This general approach should cover all the export modes we need, which will help streamline theRenderManagercode and reduce complexity. This is just my idea for now, its subject to change.Notes for Testers
If testing, test that:
Fixes #6666.