On Tue, Oct 28, 2008 at 4:13 PM, Jean-Michel Pour? <jm at poure.com> wrote: > On Tue, 2008-10-28 at 15:33 -0700, Dan Dennedy wrote: >> A module can choose to do it is own way for any >> property, and some of them do. The point is that I want to make this a >> framework facility for any type of mlt_property so that it remains >> consistent across modules. As for naming them, well, I don't see a >> reasonable way to do that without fucking up the concise syntax that >> we have thus far. I suppose an app could figure out a way to do it. >> Or, a side-property like foo.key.names=[frame=]Name[;[frame=Name]]* >> might work. > > Just to understand. MLT Keyframes are attached to an effect, as they are > properties.
kind of. I watched the Final Cut tutorial you pointed me towards. We are getting hung up on terminology and perspective. I think we have the same idea. > But in other environments keyframes are objects, which can be defined > anywhere. Effects apply to keyframes and not the converse. I can see how some UI may give you that perspective except for the "anywhere" part, but I think you mean that any and all effects' settings work with keyframes. > I don't know MLT XML syntax to tell if keyframes can be independant > objects in MLT. But if you create an XML syntax for keyframes, defining > them as XML objects, you would not break backward compatibility. MLT, the _framework_, currently does not require any XML; XML is actually limited to the westley _module_. I don't want to have to write a XML document that describes something as simple and concise as [frame=]value(s)[;[frame=value(s)]] that works with inigo, MLT API function arguments, westley XML, SMIL, or even some future YAML/JSON-based syntax. When I watch that video, I do not see keyframes as you describe it. Rather, I see keyframes for groups of property values similar to what MLT already has in mlt_geometry. How they are represented in a project file is a separate matter and outside the scope of discussion here because you do not write the XML; rather, you use the kdenlive UI. As I tried to explain, today only mlt_geometry implements keyframes, and it affects up to 5 floating point values. This is convenient for x, y, width, height, and opacity, which was the reason for the name "geometry" - the composite, region, and watermark effects use it. All I am saying is that mlt_geometry should be more generic. Let's rename it as mlt_keyframe. Then, I can make it not just support 5 floats but 1 or more of any property type including (non-interpolated) strings. So, that changes things more to what you describe. mlt_keyframe is an object that manipulates over time (animates) the values of a _group_ of settings/properties. As a generic thing, this mlt_keyframe would be available _anywhere_, but not _everywhere_. The way a particular module is implemented determines that. Some effects might only see the initial value and do nothing if that value changes within the same instance of that effect. That could be seen as a shortcoming, but I do not want to impose a requirement because sometimes a module is a bridge to another system (frei0r, ladspa) or library (sox) where animation is not supported. That is why the MLT YAML-based metadata[1] schema contains an attribute named "mutable" for the definition of a property. The pre-requisite to this work is #1 on my ToDo[2] list because instead of something like "[frame=]value[;[frame=value]]," it really should be "[time=]value[;[time=value]]." I put more notes[3] about this on my wiki. [1] http://www.mltframework.org/twiki/bin/view/MLT/MetadataRequirements [2] http://www.mltframework.org/twiki/bin/view/MLT/ToDo [3] http://www.mltframework.org/twiki/bin/view/MLT/PropertyAnimation -- +-DRD-+
