Thanks for working on the tempo shift stuff and explaining it Tim - this
will be a very interesting and useful addition to MusE when complete.

It seems a bit odd that you'd be working on this before latency correction
though - that is still a missing feature, right? You're 100% entitled to
work on whatever you please of course but audio time stretching seems like
a nice-to-have feature in comparison.

Any indicator of an obvious cut-off point to go 3.0 yet?

Thanks

On Tue, Sep 27, 2016 at 5:03 AM, termtech <[email protected]> wrote:

> On Monday, September 26, 2016 12:30:57 PM EDT Florian Jung wrote:
> > Hi!
> >
> > whoa, that sounds like quite a lot of work you did already!
> >
> > One thought about the tempo changes: you were talking about the
> > Stretching-Markers.
> > Currently, they are tuples of (the amount of seconds the wave part is
> > already played, the desired position in the wavefile) if i understood
> > that correctly.
>
> Yes it's /all/ frame based at the moment, heavily based on the
>  point of view of the wave file which is of course all in frames.
> There are no ticks involved anywhere at this time.
>
> > Howabout making them tuples of
> > (the position in the song/part (in ticks, not in seconds),  desired pos
> > in the wavfile in seconds)?
>
> Interesting thought.
> My marker list is a std map and each marker item is indexed by frame.
> So I would just change that indexing from frames to ticks to make
>  it work. (Well, actually the items are more complicated than that
>  with several more frame-based values, but they can be changed.)
> It seems then at least manually placed markers might automagically
>  adjust to tempo. After all, tempo map is just another layer
>  yielding frames from ticks.
>
> > This, together with automatically inserted (or "implicit") stretch
> > markers on each measure (or beat or whatever) should make it work.
> >
> > Ohh, or actually, how about letting wave parts have "their own tempo
> > map". And then the file is stretched automatically until the "wave
> > file's tempo map" and "the song's tempo map" are in sync?
> >
> > That was what i was trying in the audiostreams branch, but never
> finished.
>
> Yes I checked it out.
>
> The thing about tempo is I made a decision that when I get around
>  to it I will try to lean towards a /ratio/ map rather than a tempo map.
> I didn't want to make it rely on things like beat detectors and so on,
>  and didn't want the user to have to worry about such things as the
>  absolute tempo of a wave. For me a beat detector would be an
>  afterthought, not a requirement, so I want to avoid it if possible.
> So one of my ideas is a delta system that only stores a ratio map
>  based on changes in tempo, not absolute tempo.
>
> It might work or not, haven't finished the thought process yet.
> Actually I would have included tempo already but it is tricky and
>  I'm still kinda studying the tempo situation so I left it 'till the end.
>
> T.
>
> >
> > Cheers,
> > flo
>
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Lmuse-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
------------------------------------------------------------------------------
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer

Reply via email to