[Bf-committers] blendercasts reloaded...

[Piotr Arlukowicz]

You know what, I would love in fact to have a small subset of the feature
you've mentioned.

My dream is to have a possibility to quick record a simple macros, and
repeat them (like in VIM for example). This will be very helpful with each
workflow, where some buttons have to be pressed in the same order, etc. You
name it.

Now it seems we aren't so far from this - we have info windows with some
commands already expressed in python, we can put them by hand to a file for
execution later, we have contextual selections, etc. The only think we
don't have yet is to being able to press a record operations button, and
let they be collected in text editor for later use. Problems here arises
also, but they are relatively smaller than making your first idea. But
maybe we can ask somebody experienced to think about such simple
'macro-recorder'?

Or maybe it already exists?


pz
piotr
--
Piotr Arlukowicz
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/ED/IT/S d++(-)>--pu s(+):(+)> a C++(+++)$@>++++$  ULAVISC*()$>+++$
P++(+++)$>++++ L++(+++)$@>++++$ !E---(---)>++ W++(+++)$@>+++ N(+)>++ o--?
!K-(-)>-$ w++(+)>-- !O-(-)>- !M-(-)>-- !V-(-)>- PS(+)>++ !PE()>+  Y PGP>+
t(-) !5? !X R()>* tv- b++ DI++ D+(++)>+++ G++@ e++++>+++++ h---()>++ r+++
y+++
------END GEEK CODE BLOCK------


2013/11/23 blenderleo <blenderleo at gmx.de>

> Macros sound interesting, and the function is close to the idea of
> blendercast.
>
> Does a script (addon) have access to the latest operations (and their
> settings!)?
> If every op is recognized by the script and stored in a way like
> "bpy.ops. ...", then each op could be redone easily, I think.
> I'll trust in the dev's opinion ;)
>
> Am 23.11.2013 17:41, schrieb patrick boelens:
> > A long, long time ago I remember there being a discussion about macro's
> in Blender. Iirc the core concept of those was the same: allow a user to
> record a set of actions and replay them.
> >
> > To me it seems like the proposed Blendercast would rely heavily on such
> a feature. If macros ever get developed in the future, this may be
> something to keep in kind. For example, they could be extended to allow
> saving to and loading from files (i.e.: boxModelHouse.macro), jumping to a
> particular time or "step", setting a playback speed and show the name and
> parameters of the action being performed in real-time (i.e.: Extrude face
> (0, 0, -0.5), Scale face (0.2, 0.2, 0.2)).
> >
> > Perhaps something like that would be a more feasible alternative. It
> could then be used as an addition to tutorials for instance, both written
> and screencasted, as well as having a wider use-case.
> >
> > Just my two cents.
> >
> > -Patrick
> >
> >> From: brechtvanlommel at pandora.be
> >> Date: Sat, 23 Nov 2013 17:11:59 +0100
> >> To: bf-committers at blender.org
> >> Subject: Re: [Bf-committers] blendercasts reloaded...
> >>
> >> On Sat, Nov 23, 2013 at 4:44 PM, Gaia <gaia.clary at machinimatrix.org>
> wrote:
> >>> On 23.11.2013 15:30, Brecht Van Lommel wrote:
> >>>> For me the reasons not to do this are:
> >>>>
> >>>> * It shifts work from tutorial makers to developers, and it's the
> >>>> developers that are already the bottleneck at the moment, we have many
> >>>> people making tutorials. So developer time seems a more rare resource
> >>>> at the moment.
> >>> I am not sure why this would shift work from tutorial makers to
> developers.
> >>> Or do you mean "creating this tool would need developer resources" ?
> >>> Otherwise why would tutorial makers not use such a tool ? Its not so
> >>> different
> >>> to use compared to creating screen casts ...
> >> I think you would want to implement this feature to make it easier for
> >> people to make tutorials or to help them make better tutorials? So
> >> basically that means you will have developers spending time helping
> >> out by implementing this feature (which is really complex), and it
> >> seems like those resources would be best spent elsewhere.
> >>
> >>>> * I have never seen such a system done well in other applications, the
> >>>> few times I've come across it, it's always been pretty frustrating.
> >>> What made these tools frustrating ? Is this a bad concept or did you
> >>> only step
> >>> into tools which had it badly implemented ?
> >>>> I'm not sure why, maybe it's just a coincidence and there are
> >>>> applications (of Blender's complexity) out there that do this very
> >>>> well.
> >>> This actually keeps me on track :) Actually this is a good argument for
> >>> continue thinking about how it could be done better :)
> >> My guess is that it is a bad concept because it's a fragile high tech
> >> solution to a problem that already has a proven low tech solution
> >> (video tutorials), where the tutorial creator has more control by
> >> being able to take their recorded video into a video editor to cut and
> >> enhance it, without working within the inevitable limitations of a
> >> solution like blendercast.
> >>
> >> Brecht.
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>