Christian Thaeter schrieb: > > I'd rather separate plugin rendering functionality, parameter passing > > and the gui. > Am Dienstag, den 29.01.2008, 19:11 +0100 schrieb Burkhard Plaum: > IMO GUI and rendering can (and should) be separated. But > - parameters are affected by the GUI > - rendering is affected by parameters > - parameters can change during rendering > > For rendering we already concluded to use gavl to pass data arround, I > > didn't yet checked if gavl has some provisions for passing > > metadata/parameters along, if not, this might be a nice feature someday. > > For passing additional data, you have 2 options: > ...
Hi Burkhard, you are right, parameters can be tricky, because the different layers of the app need to cooperate. For the middle layer I used up to now interfaces "Param" and "ParamProvider". (Postponed any details for now). ParamProvider will be implemented by a automation data source while rendering and will be implemented by some connector to the GUI layer while setting up plugin instances. In our current design, the middle layer has the job to set up all connections (but never cares about the actual data types passed, as long as it can figure out what connections to make) and the render nodes never to any checks or configuration tests while rendering... You should note though that the individual render node *must not* hold any time varying data because of thread safety. Any data will be passed in as "frames" (video, audio, control data) with the individual "pull" calls for rendering. The render network is shared, and the backend needs complete freedom for pulling rendered frames as it sees fit. > If it turns out, that one priv pointer isn't enough, I can add a priv2 > pointer :) gavl never touches these anyway. this is fine because the other layers will for sure have some opaque data to pass along here too (and it wouldn't be wise to define everything to the last bit now before even kowing what the upper layers will need) > > Distributed plugins which just do the work on a renderfarm will just > > work, the GUI is only needed for the front node where the user sits. ...and this includes marshalling parameter/automation data over the network. The middle layer will be able to work in a "headless"/scripted setup too, including all editing operations. cheers, Hermann V. _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
