[Bf-taskforce25] Unique sequence strip names

[Shaul Kedem]

Wow. Cool.

I think that the summary is "Sequencer elements will be able to be use
by and use any other relevant mechanism in blender"


On Mon, Jan 26, 2009 at 8:00 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi,
>
> We went over this with some people in irc, a cool and interesting
> discussion! :)
> Tentative conclusions are (hope I word it correctly):
>
> - names for strips can (optionally) be enforced unique
> - having unique names should not be a requirement for the operators to
> work though.
> - we need to devise a good internal api (Blender side) that allows
> selection groups to exist, defined either by context (user input),
> stored, or created on the fly. The operator api can use this via
> itterators, python can define them.
> - generic 'selection groups' will also do great for future expansion to
> nodes, think of bones groups, vertexgroups, objects, whatever. Same
> goes for future construction history attempts. :)
>
> Promoting sequencer data to ID level ("Library") is a great idea, but
> it shouldn't be done on individual strip level, instead it's better to
> convert the current "Editing" struct into a generic "bSequencer" (or
> "bMovie" ?) ID library data block. That way we have the freedom to
> either re-use a single strip or a complete movie edit.
>
> That new ID entitity then can be used all over in Blender, like for
> textures, but also again to insert in the sequencer as meta strip.
>
> The current "Image" and the new "bMovie" can get a similarly functional
> api, giving image data on request by a user of it. Expanding on the
> idea, we should also allow:
>
> - to insert an Image strip in Sequencer (Blender Image)
> - to output the Sequencer result to either Image or Render Result
> - Compositor to output to Image.
> - Compositor to include a 'bMovie" node.
>
> Here we get a nice generic way to have both sequencer and compositor
> cooperate, with complex dependencies, but that's what we have depsgraph
> for! :)
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>
> On 26 Jan, 2009, at 1:41, Campbell Barton wrote:
>
>> Some of the sequencer operators would benefit from sequencer strips
>> having unique names, (Sequence * types)
>>
>> adding an effect for instance, would be nice if you could give the
>> operator args like this...
>> bpyop.sequencer.add_strip_effect(type='CROSS', seq1="anim1",
>> seq2="black")
>> ...rather then setting up the selection and running it.
>>
>> For most functions unique names per metastrip would be enough but
>> since you can make and separate metastrips while editing, making the
>> names per scene seems less likely to cause collisions while editing.
>>
>> Even though the Sequence struct is already pretending to be library
>> data, I cant see any reason to make strips true  library data (other
>> then for consistency).
>> It would seem enough that each strip has a unique name per scene.
>> since Sequence strips have no inter-scene relationships.
>>
>> The main advantage with strips being library data is for use in
>> multiple scenes.
>> But this (like multi user objects), would mean the position in the
>> animation would also be shared between scenes, so it seems a lot less
>> useful then a camera in multiple scenes for eg. A strip in multiple
>> scenes would be problematic if scenes frame rates dont match.
>>
>> having real Sequence Strip library data would allow appending strips
>> from another blendfile and access strips globally by name, but I'm
>> still not convinced its worthwhile.
>>
>> Sequence strip names can work like bone names, do_versions for older
>> files can make the names unique, nothing currently relies on matching
>> the names so this wont break anything.
>>
>> Id like to go ahead with this soon, let me know if there is any
>> problems with this proposal.
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>