-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Wilms schrieb: > I wouldn't rule out making Ardour also work on a per object level. ...which would mean throwing out and rewriting a good deal of the editing core (not the audio processing part and not gui specific things). Remember, the original poster asked why not build Lumiera on top of Ardour? Now, this is the answer!
> On Sat, 2008-05-17 at 18:44 +0200, Ichthyostega wrote: >> There seems to be a compelling idea buried within this approach, >> but we'd need to nail down how each of this "things" can be >> attached to this common automation. And, moreover, what to do if >> your "things" are moved and rearranged? Leave the automation where >> it is? Extract a part of the automation and move it alongside with >> the "thing". And is this really helpful for the user? Thorsten Wilms schrieb: > In the end you would have a nodal system with free routing of audio, > video and automation (perhaps several types of the later). Tracks and > busses would just be wrappers/proxies. > > Lets say automation tracks have outputs and everything that can be > automated has inputs (could be more than 1 type, though). ... > There can be 1:n connections just like with audio routing. There > should be plugins for at least simple math operations. > > Regions would have their own i/o, automatically connected to the i/o > of their track. Here you are giving a concise summary of what our current design and started implementation of Lumiera is about; so probably, we'll agree in the end result. :) > Regarding moving stuff around, there could be a locking feature (lock > point A on track 1 to point B on track 2). Lots of fun because you > might want to express the relative distance in wall clock time, > frames or bars:beats ... To deal with this problem, I devised a concept I call "Placement". Every Object in the Session is handled and attached by means of a Placement, which has the purpose to stick the object "at" some location. But "location" can be more general: some point in time, some point in our tree of tracks, a specific output destination port, some layer for layered video mixing or some pan position for sound. Properties of placement, which are not specified locally, are derived from the context, which gives us e.g. the automatic connections you proposed above, as well as a global or per track layer and pan (if we want it). Placement can be - absolute (fixed values) - relative to another object (clip, plugin, label) - relative to a specific source position in another clip (e.g. a flap) - attached to another object (for effects, transitions) without much problems, Placement could be extended to employ rules or e.g. to place an object repeatedly according to some pattern function. Meaning there is a lot of potential for interesting future extensions without changing the inner mechanics. Cheers, Hermann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIL28qZbZrB6HelLIRAtn+AJ9jax6MGsVvx6Dyg3S0H6tFgnE37wCfYY7h jaHjYTrHQLDiqlXVeLoEtLY= =Odhe -----END PGP SIGNATURE----- _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
