[Cin] OT: comments from youtube can be saved, too

[Andrew Randrianasulu]

чт, 17 авг. 2023 г., 15:37 Stefan de Konink <stefan at konink.de>:

> On Thursday, August 17, 2023 2:13:46 PM CEST, Andrew Randrianasulu wrote:
> >> Yes, it makes sense to do it directly in the resources. Or maybe in
> >> something like a more advanced 'view' window.
> >
> > question is (at least 1st question for  me) - but how exactly its
> > done? Either by embedded audio timecode or some ...beat comparing and
> > calculating offsets?
>
> 1) Embedded timecode
> 2) Alignment signals (or slate)
> 3) Computed audio alignment (we have it in CinGG for multicam, but it
> surprisingly can't be used on audio channnels)
>

Thanks for pointer, I looked into mixersalign.C and found there two
functions:

// shift armed mixer tracks by nudge                                  void
MixersAlign::nudge_tracks()

// move selected mixer edits by nudge
void MixersAlign::nudge_selected()

may be we can programmatically create 'hidden" mixer and then reuse those
functions?

PS: I only lately learned about '-r' (recursive) switch to grep, cinelerra
keep most core files in one directory but other projects not ... Now I know
how to search for function names recursively ;)



4) By ear, to allow moving a timeline
>
>
> > Adam posted some vid on use audio offsets in Cin-HV:
> >
> >
> https://www.youtube.com/watch?v=n0evGSOpwbY&list=PLv6Mn7I6pSmWivUKTvf_CzqHjnlKt5zCS&index=9&t=8s
>
> The nuding is good if you have sort of alignment, temperature compensated
> oscillators, and want to fine tune it.
>
>
> > Anyway, as c-kiddie I understand frustration with somewhat cryptic and
> > outdated codebase. I understand ppl unlikely to be amazed on first
> > sight, or even on second. So finding someone who can work  here is not
> > trivial, especially since we apparently cut from those big European
> > libre events like those meetings Krita, Blender and GIMP devs use for
> > face-to-face discussing ...
>
> I think, like with many projects, it starts with cutting an unreachable
> target into reachable pieces. Maybe it won't get the perfect architecture
> that way, but at least we can move forward.
>
> 1) Collecting the usecases: where do we suck, or what do others much better
> 2) Make a wireframe design what would it look like in the GUI
> 3) Make an sequence diagram for the steps that are required to achieve the
> result
> 4) Review it with the community
>
> --
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20230817/55083140/attachment.htm>