Closed jminor closed 2 years ago
Here is the current work-around for muted clips in the AAF adapter: https://github.com/PixarAnimationStudios/OpenTimelineIO/pull/335
This is a good feature request! I'd prefer "enabled" over "muted". Might of course just be me, but I think it better suits both audio and video items.
visible()
vs "enabled" is tricky. If my understanding of visible()
is correct, I think it would be more consistent to return True even though clip.enabled -> false
because the item is still "visible" from the top track in a flattening scenario for instance.
DAWs (Digital Audio Workstations) have the complementary features Mute and Solo. (Mute silences a track, Solo silences all but a track.) If you have multiple alternate clips for editorial to select amongst, Solo would mean "pick this one"; the alternative would be to mute each individually, and unmute one.
The question on visible() is important, and the fact that there is a question highlights that a design question shouldn't be "what's the interpretation of visible?" but three questions: "how do I ask for items that exist at this time", and "how do I ask for items that exist at this time and muted/not muted".
Note also that USD implements a rule over muting. For example, a nested composition
(a relationship (b! relationship c))
where b! indicates that b is muted would transitively mute c, depending on relationship. So, c may or may not be muted depending on the relationship, in other words. We should explore/describe what muting means in a composition.
I can imagine that there might be title tracks in different languages, the title tracks might have children (such as a gray box for contrast), and that soloing might be used to select French, and that the other title tracks, and their boxes, would be muted. On the other hand, a picture in picture might have an optional frame element, where muting the frame does not mute the in-picture.
~ two cents.
I'd be interested in having a go at this. I assume a start would be to:
enabled
Yes, that would be great. Other schema enhancements have started with a brief markdown document describing the new schema and API so that others can provide comments & discuss. This has been very helpful to provoke some research on how other formats and programs handle the same concept so we can make sure the schema covers any challenges that might be lurking later when support is added to the adapters.
I've created a first raft proposal here, is this this a reasonable start? I'm very new to the code base so there are undoubtedly things I've missed or not thought about. Also I wasn't sure where there best place to host the proposal was so let me know if there's somewhere better.
Feature Request
Many audio and video editing applications and formats have a toggle to "muted" or enable/disable individual clips, tracks, effects or other elements. OTIO is missing this feature, which has led some of the adapters to include work-arounds involving metadata, gaps, or other mechanisms to fill this need. We should introduce a new property which represents this concept as a first class feature.
Description
If we add this as a property on the Item class, then Clip, Track, and all of the other Item subclasses will inherit it, allowing code to treat them all uniformly. We should consider whether the
visible()
accessor should return True or False based on the muted status of an item (I could see this argued either way).Each adapter can then be modified to handle muted items as appropriate. For formats which support the muted concept, support should be straight forward. For formats which do not support muted items, the adapter should make a clearly documented choice to include all muted items, or to ignore them, treating them as gaps.
Context
Issues related to this: #483 #827 #1064
This should be an uncontroversial, and relatively straight forward schema enhancement. We would love to have a new contributor step up and give this a try. If you're interested and want some guidance, just ask :)