On Tuesday, September 27, 2016 9:18:45 AM EDT Dan MacDonald wrote: > 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.
Latency correction is coming. Step 1 has been taken: There is already a correction delay module in the stretching branch, called latency_compensator.cpp (Although, oops, I thought I had added it to master - will do.) It will be incorporated into the audio path later. That is the easy part. The really big challenge is the network analysis part at the start of each audio cycle. This is where the values of all the latency compensator delay units must be set. I made the decision at summer's beginning to work on stretching, rather than latency. I had just put in a whackload of effort on MusE bugs, Qt bugs, and then mixer redesign. So I gave myself a break and said: "pick a pet project to add, anything you want, you deserve a break". So I reasoned that stretching could be considered actually more important and long overdue. I mean, when somebody tries MusE for the first time and they see that changing tempo does not alter the wave parts, well, it's a bit odd and embarrasing, right? I mean it should 'just work', even though they may not be aware of just how complex and difficult stretching is, it should, logically, 'just work'. Also the fact that I had already started stretching long before, and the code was languishing in a mess for three years, so I really needed to complete it and move on. So now, having hit a snag with stretching, I realized the master was in need of some care, I was not entirely happy with the small sliders. So I stopped stretching and last week went to master and re-did the knobs thing. See what a four month break can do? Revitalize my efforts. In all my previous planning I did not think I could fit a three-section LCD midi patch editor on one line in the mixer strips. But lo and behold there it is! One irony is that stretching libraries may add their own special latency. Thus in way, it was good that I took care of that compensation first since it could have made things difficult if I had done the audio latency first. > Any indicator of an obvious cut-off point to go 3.0 yet? > > Thanks I do think we are good for another release candidate now. Important fixes are in there. Just let me fix up some of Robert's efforts with the strips. Multiple track selection is broken now, so I'm fixing that right now at this moment. Robert has been busy these days and I don't know how to prepare a release. Does anyone know the exact steps to do a release? Likely by tonight, or tomorrow, it will be ready to release. Cheers. Tim. > > 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
