> The idea was to have each source in the timeline point to a source > definition, but not explicitly include a list of source definitions with > the intermediate format. Rather, let the file export module handle > extracting that. For the case of cPickle, it makes sense not to build it > at all. I'm not sure that this approach would have adverse consequences > for off-line editing.
I see where I was confused before.. Sadly, I continue to be confused. ;) If you didn't explicitly include a list of source definitions, how would the project know where the sources are located? You mention the export module... Isn't the intermediate format also an exported format? In essence, the native format? I still see a problem with any media which is included in the project, but which isn't referenced anywhere, such as takes that currently haven't been cut. Those sources still have to be referenced somewhere, even if the project hasn't been exported yet. I'm sure I'm still missing the bigger picture. > All the factories derive from one parent. The discoverer looks at the > uri and figures out how to create the appropriate factory. So, all we > really need to keep is the uri. We don't serialize the factory > completely, but currently each factory does "serialize" itself in the > sense that it implements "serializable" and builds a representation of > itself in the intermediate format when asked. It doesn't seem to be a > complete representation, but edward wrote that part of the code, so i > don't really know what his thoughts are on this. IMO, so long as the format provides a mechanism for instantiating a particular object/factory, without having to actually serialize the factory itself, the objective is met. So it sounds like the solution is sufficient. > I sent out a second email with some corrections to this section, so I > apologize for that. It was supposed to look like: > > .... > volume: [...] > > I.e. we're still dealing with an intermediate python data structure. One > of the keys of an effect/transition is called "parameters", which would > store all of the effect/transition specific keys/values. > > In python, mappings (dictionaries) are fairly easy to work with. Most of > the intermediate format is composed of dictionaries. > > I think the main difference in your approach is that you're mapping > keyframes to lists of parameters, whereas I was suggesting mapping > parameters to lists of keyframes. I think Edward can maybe comment here > on which is the better approach to take. I'm leaning towards the latter > because it is my understanding that we'll have separate "controller" > objects for each parameter we want to change over time, rather than one > controller that handles a monster list of parameters. So, it seems the real question is: Does each parameter have its own set of key frames? It's more information to store by parameter, but it's also the most flexible solution. > I'm just suggesting doing some sanity checking on input to prevent > dangerous things from happening. So, yes, unusable data would be > ignored. At least minimally users would be warned, and where possible > given a choice about how to handle problems. This kind of scenario would > be ideal... I think this is a given (no argument from me). I do think there should be some thought given about how different types of data are validated and how those exceptions are handled by the application. For example, missing sources is an obvious user input. Vegas gives multiple options anytime sources are not where they should be, including leaving it offline, searching other locations, or replacing with new material. However, it doesn't make sense to be presenting the user with a dialog to ask them to correct some invalid, and probably meaningless parameter number. Kyle ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Pitivi-pitivi mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pitivi-pitivi
