|
|
|
06-08-2018, 08:00 AM
|
#1
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Incorrect calculation of the duration of beats tempo
Hello!
Reaper considers wrong interval time of gradual deceleration or acceleration of tempo. The tempo value changes linearly only beats, but the time marks change with the logarithmic function. Here is the correct universal calculation formula:
T2=T1+240*c*(a/b)*((lnF2-lnF1)/(F2-F1))
F2≠F1
F2>0
F1>0
T2 - final value time at the end of the gradual change of tempo (sec.);
T1 - initial value time at the beginning of the gradual change of tempo (sec.);
240 - constant, specific duration of beats signature (4beats*60sec);
c - number of bars in interval gradual change of tempo (can be either integer or fractional value);
a/b - signature (2/4, 3/4, 4/4, 5/8 etc.);
F2 - final value of tempo at moment time T2 (bpm);
F1 - initial value of tempo at moment time T1 (bpm).
It is imperative to correct the error that is present in the duration calculation.
|
|
|
06-08-2018, 01:53 PM
|
#3
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by Eliseat
|
Yes. That topic was created by a member of the local forum, but I think that the topic was created in the wrong section, and I can't delete that message. In that section, this topic will die, and here still the developers will pay attention. Because of this error, I can't buy a license and work in Reaper.
|
|
|
06-08-2018, 02:57 PM
|
#4
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
I don't think this is going to be changed as it would break so many projects...
|
|
|
06-08-2018, 04:19 PM
|
#5
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
I don't think this is going to be changed as it would break so many projects...
|
No, the projects are not broken. Only the tempo-markers values will be affected by the changes. Users will see the true value of BPM, because when recalculating the track binding will remain on the timeline. Moreover, the grid is displayed correctly, i.e. by the logarithmic function. It is necessary to redraw the line of the envelope of the tempo in the logarithmic form. There will be a lot of positive circumstances: it will be possible to correctly load and unload MIDI and audio data, correct exchange between notes editors, other DAW and Reaper, correct synchronization with other metronomes at rehearsals, concerts and in collective work, it will not be necessary to adjust the values of tempo-markers at known tempo values. Will Reaper be considered wrong until the end of the world? Moreover, the version is coming to 6.0. It's time to correct the mistake.
|
|
|
06-08-2018, 11:36 PM
|
#6
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
I had no problems exchanging MIDI files created in Reaper with other hosts, I didn't notice any problems with tempo ramps...
|
|
|
06-09-2018, 05:56 AM
|
#7
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
I had no problems exchanging MIDI files created in Reaper with other hosts, I didn't notice any problems with tempo ramps...
|
It means you don't have the jobs I do.
|
|
|
06-09-2018, 06:02 AM
|
#8
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
Quote:
Originally Posted by aveter
No, the projects are not broken. Only the tempo-markers values will be affected by the changes. Users will see the true value of BPM, because when recalculating the track binding will remain on the timeline.
|
Wait, if ANYTHING changes (you say tempo marker values will change), then the projects WILL be broken, because tempos previously used won't be as they were if this is changed, so things will play out at a different tempo because of this change. So, it's not a non-destructive modification... it seems unlikely that it'd change. But that it would be cool to hear input from devs on this, it sure would.
|
|
|
06-09-2018, 06:44 AM
|
#9
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
[edit] see post #13, below.
Last edited by schwa; 06-11-2018 at 05:59 AM.
|
|
|
06-09-2018, 03:59 PM
|
#10
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by schwa
What would change is the shape of the linear tempo envelope between two tempo markers -- it should not actually be a straight line. The actual playback would not change. I believe this is only a display issue, unless I'm misunderstanding the comment.
|
No, not just the images.
How I discovered this mistake. I wrote the vocal track in Guitar Pro 7. It has a gradual acceleration and deceleration. Then I uploaded the vocal track to a MIDI-file and a WAV-file, and uploaded those files to Reaper. At first, where the smooth tempo, tracks are synchronized,and since the deceleration began shift. At first I thought Guitar Pro 7 was not properly uploading the data, but then I loaded those files into Cubase and saw that the MIDI-track and audio-track were exactly the same. I calculated a formula by which I understood the error of the algorithm in Reaper, which considers deceleration and accelerating the tempo by a linear function - this is absolutely wrong. The script won't fix it.
Now I have a choice of buying: Reaper or Cubase. I like Reaper more, I don't really want to buy Cubase. However, if the developers are not going to fix this fatal error, then I will have to buy Cubase.
I made a video of the above procedure. The video was made for Arobas Music, but you have to show it here.
https://yadi.sk/i/LCzve-ui3XcQpP
Developers can add a checkbox in the settings version 6 that will switch the calculation algorithm from the old to the new, so that the current projects do not break. I am asking the developers to fix this error. If developers do this, Reaper will be the best DAW in the world, and Cubase will be discarded!
|
|
|
06-11-2018, 03:10 AM
|
#11
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Thanks for the detailed report and screen capture.
As I understand it, the report has two parts. First, a MIDI tempo map exported from Guitar Pro imports into REAPER with tempo changes in the wrong location. Second, after moving the tempo changes to the proper location, a gradual tempo change still does not import properly.
We'll try to reproduce this and see what's going on.
|
|
|
06-11-2018, 04:38 AM
|
#12
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
@aveter: MIDI export from GP7 is horrible, and in many ways wrong, when compared to exporting the same tab from GP5 or GP4. They screwed a lot of things up.
|
|
|
06-11-2018, 05:58 AM
|
#13
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
OK. There are not surprisingly a couple of issues here.
First, Guitar Pro is exporting time signature changes in the instrument tracks, which is not standard, in fact I would call it an error. This is what causes the imported tempo markers to be one measure off -- if the Guitar Pro project had multiple time signature changes, I think the markers would be even farther off.
Second, there is no MIDI specification for gradual/progressive tempo changes. REAPER discretizes (stair-steps) gradual tempo changes when exporting. Guitar Pro just exports them as regular tempo changes, so you have to manually change them to be gradual changes when importing into any other software.
Third, REAPER does interpret gradual tempo changes differently from Guitar Pro. Consider a gradual tempo change from 120 to 80, over 2 measures.
In REAPER, the tempo change is linear over time, so the time used to go from 120 to 100 is the same as the time used to go from 100 to 80. This is correctly displayed as a straight line in the REAPER tempo envelope, because the timeline is always linear time -- one second of time takes up the same space on the screen, regardless of tempo. This works out to a total elapsed time of 4.8 seconds.
In Guitar Pro, the tempo change is linear over beats, so one beat is used to go from 120 to 100 and one beat is used to go from 100 to 80. This works out to a total elapsed time of about 4.87 seconds. This would be displayed as a curve on the REAPER timeline, not a straight line.
I don't think there is anything to fix on the REAPER side, although I will take a look at the time signature issue to see if we can adjust for what Guitar Pro does. Since there is no MIDI specification for gradual tempo changes anyway, it probably doesn't make sense for us to add a second method of calculating them.
|
|
|
06-11-2018, 01:40 PM
|
#14
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by schwa
In REAPER, the tempo change is linear over time, so the time used to go from 120 to 100 is the same as the time used to go from 100 to 80.
|
Thank you very much for the answer!
What I need to manually set the gradual change of tempo - this is known to me, because it is MIDI standard. No problem. I'm talking about something else.
In your quote was based on the error, because the tempo change occurs linearly relative to the beats only, but on the scale of time is logarithmic function. Tempo is frequency (bps) - "x". The moments of time (seconds) is "y". y = ln(x), while the time itself is linear, and the tempo change is linear, but the dependence the values of the time moments from the values of the tempo change is a logarithmic function. Look, the rate of change of the function (derivative) depends on the initial rate, so:
- first, the interval from 120 bpm to 100 bpm, and from 100 bpm to 80 bpm can not be the same in time, because different initial rate of tempo change.
- second, if you change the tempo, for example, from 120 bpm to 40 bpm, the tempo will change at the beginning of the interval 119, 118, 117, etc., and at the end of the interval 44, 43, 42, 41 and 40. Thus, at the beginning of the interval there will be less time to tempo change, and at the end of the interval there will be more time spent. There is no linear function here, only a logarithmic function.
The fact that there are a lot of errors in Guitar Pro 7 is well known, but from Guitar Pro 7 to Cubase it was unloaded exactly "tick to tick". I'm making a video about it now.
Last edited by aveter; 06-11-2018 at 01:52 PM.
|
|
|
06-11-2018, 07:58 PM
|
#15
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by schwa
...I don't think there is anything to fix on the REAPER side...
|
This is video https://yadi.sk/i/jFoJgIle3Xmict
Before writing on the forum, I carefully prepared.
I gave you the formula, and you decide whether to correct the mistake or not. If you don't believe me, consult a mathematician. However, if the bug is not fixed and you think that Reaper is counting correctly then this DAW will be lost to me forever. I will not write here anymore because I have said everything I wanted.
Topic closed.
Thank you for your attention.
|
|
|
06-12-2018, 12:56 AM
|
#16
|
Human being with feelings
Join Date: Dec 2014
Location: The Dutch Mountains
Posts: 389
|
Would be a loss to close this, quite interesting… (one of the most interesting, elaborate posts I have read on this forum, very well documented) And it would mean REAPER maybe has a rather fundamental flaw under the hood...
Last edited by Robert Johnson III; 06-12-2018 at 01:00 AM.
Reason: Adding weight to substance
|
|
|
06-12-2018, 01:09 AM
|
#17
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
It's not a flaw if tempo changes are linear to time instead of beats. Reaper is counting correctly w.r.t. linear time from what I can tell, this is what schwa tried to explain.
However, if tempo/timesig markers timebase is set to "beats" in project settings, perhaps the gradual tempo change should also be calculated linear to beats, instead linear to time? Dunno. This would definitely impact existing projects in that timebase (unless a new timebase mode is introduced, with explanation).
Last edited by EvilDragon; 06-12-2018 at 01:16 AM.
|
|
|
06-12-2018, 01:16 AM
|
#18
|
Human being with feelings
Join Date: Nov 2017
Location: Heidelberg, Germany
Posts: 797
|
@aveter: When something is done not the way which fit your needs, especially after detailed explanation from the developer, calling the behavior "wrong"/"bug" and then writing "Topic closed" is not kind.
For the topic. Since at least Cubase (as in linked video), Sonar (it has no curve, but "insert series of Tempos") and Tracktion (with curve "0") use "Linear over beats" approach, I think that is a valid future request to add corresponding "shape" type for tempo change marker in REAPER. That way current projects will not be disturbed.
|
|
|
06-12-2018, 04:16 AM
|
#19
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Here is a discretization of the two methods, linear-time (REAPER) on the left, linear-beats on the right.
Code:
bpm beats seconds %beats %time bpm beats seconds %beats %time
120 0.00 0.00 0.00 0.00 120 0.00 0.00 0.00 0.00
118 0.48 0.24 0.06 0.05 118 0.40 0.20 0.05 0.04
116 0.94 0.48 0.12 0.10 116 0.80 0.40 0.10 0.08
114 1.40 0.71 0.18 0.15 114 1.20 0.61 0.15 0.13
112 1.85 0.95 0.23 0.20 112 1.60 0.82 0.20 0.17
110 2.30 1.19 0.29 0.25 110 2.00 1.04 0.25 0.21
108 2.73 1.43 0.34 0.30 108 2.40 1.25 0.30 0.26
106 3.16 1.66 0.40 0.35 106 2.80 1.48 0.35 0.31
104 3.58 1.90 0.45 0.40 104 3.20 1.70 0.40 0.35
102 3.99 2.14 0.50 0.45 102 3.60 1.93 0.45 0.40
100 4.39 2.38 0.55 0.50 100 4.00 2.17 0.50 0.45
98 4.79 2.61 0.60 0.55 98 4.40 2.41 0.55 0.50
96 5.18 2.85 0.65 0.60 96 4.80 2.65 0.60 0.55
94 5.56 3.09 0.70 0.65 94 5.20 2.90 0.65 0.60
92 5.93 3.33 0.74 0.70 92 5.60 3.16 0.70 0.66
90 6.29 3.56 0.79 0.75 90 6.00 3.42 0.75 0.71
88 6.65 3.80 0.83 0.80 88 6.40 3.69 0.80 0.77
86 7.00 4.04 0.88 0.85 86 6.80 3.96 0.85 0.82
84 7.34 4.28 0.92 0.90 84 7.20 4.24 0.90 0.88
82 7.67 4.51 0.96 0.95 82 7.60 4.52 0.95 0.94
80 8.00 4.75 1.00 1.00 80 8.00 4.82 1.00 1.00
Because the REAPER timeline is always linear-time, a linear-beats gradual tempo change (the right hand method) would appear as a curve on the tempo envelope. If we added support for linear-beats as a different method, it would have to be handled as a new envelope type, the same the way REAPER currently handles amplitude-scaled vs fader-scaled envelope types. Switching the tempo envelope type would change how the project plays back. We'll give this some thought as a feature addition to improve interoperability, but I do not believe this should be classified as a bug.
Last edited by schwa; 06-12-2018 at 04:22 AM.
|
|
|
06-12-2018, 04:55 AM
|
#20
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
That's because it is not a bug, it's simply different thing taken as being linear.
I'm curious if OP is going to return to comment some more the above numbers. schwa is not wrong at all. It's just a different method of counting, it is correct if linear time is considered. This should be moved to feature requests instead, asking for linear beats gradual tempo transitions.
|
|
|
06-12-2018, 05:08 AM
|
#21
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by schwa
If we added support for linear-beats as a different method, it would have to be handled as a new envelope type, the same the way REAPER currently handles amplitude-scaled vs fader-scaled envelope types. Switching the tempo envelope type would change how the project plays back. We'll give this some thought as a feature addition to improve interoperability, but I do not believe this should be classified as a bug.
|
I agree with this. Rather than increasing the complexity of the tempo envelopes (tempo ramps are already way too complicated!), it might be worth having an import option which recursively subdivides tempo transitions in a QN-centric way.
Edit: err, an action to peicewise convert, maybe?
Last edited by Justin; 06-12-2018 at 06:01 AM.
|
|
|
06-12-2018, 05:13 AM
|
#22
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
Just to add... I do agree with the OP that gradual tempo changes are supposed to be linear over beats rather than over time. It is no wonder why majority of DAWs do it like that - it's inherent to the way notation works, too.
|
|
|
06-16-2018, 04:05 PM
|
#23
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
Just to add... I do agree with the OP that gradual tempo changes are supposed to be linear over beats rather than over time. It is no wonder why majority of DAWs do it like that - it's inherent to the way notation works, too.
|
Hallelujah! First...
|
|
|
06-18-2018, 01:52 AM
|
#24
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
@EvilDragon Dear EvilDragon! I first dropped my hands, and almost lost heart, but thanks to you (your last statement) I still have hope that the developers will understand me. Thank you!
Quote:
Originally Posted by Justin
I agree with this. Rather than increasing the complexity of the tempo envelopes (tempo ramps are already way too complicated!), it might be worth having an import option which recursively subdivides tempo transitions in a QN-centric way.
Edit: err, an action to peicewise convert, maybe?
|
Dear Justin, Dear @schwa and all the developers of Reaper!
I hope you understand me.
All details in the video https://yadi.sk/i/WDa2gis13Y4M3v
Thank you!
|
|
|
06-18-2018, 01:55 AM
|
#25
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
As long as you are aware that this is not really a bug (this thread should be in feature requests section), it's just a different way of calculating gradual tempo changes. They can be either linear in time, or linear in beats. Both ways are equally valid.
By the way, the latest Reaper prerelease contains a fix for importing time signatures incorrectly attached to MIDI tracks, which should alleviate at least one faulty thing that GP exports.
Quote:
Originally Posted by aveter
and all the developers of Reaper!
|
Actually, Justin and schwa are the only developers of Reaper.
|
|
|
06-18-2018, 02:26 AM
|
#26
|
Human being with feelings
Join Date: May 2010
Location: Norway
Posts: 7,318
|
Quote:
Originally Posted by schwa
I don't think there is anything to fix on the REAPER side, although I will take a look at the time signature issue to see if we can adjust for what Guitar Pro does. Since there is no MIDI specification for gradual tempo changes anyway, it probably doesn't make sense for us to add a second method of calculating them.
|
I can confirm inaccuracies regarding Repers midi tempo export.
They can be quite notable.
My finding was Reaper to Reaper
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
|
|
|
06-18-2018, 03:07 AM
|
#27
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
As long as you are aware that this is not really a bug (this thread should be in feature requests section), it's just a different way of calculating gradual tempo changes. They can be either linear in time, or linear in beats. Both ways are equally valid.
By the way, the latest Reaper prerelease contains a fix for importing time signatures incorrectly attached to MIDI tracks, which should alleviate at least one faulty thing that GP exports.
Actually, Justin and schwa are the only developers of Reaper.
|
I did not know that this is all the developers. The better for the good of the cause.
You can count as you like, even on hyperbole, but this is wrong. The physical process of tempo change itself takes place according to natural laws. Therefore, the developers of Cubase, Sibelius, Dorico (here the same developers as Sibelius), Guitar Pro and many others, are counting on the natural logarithm. Only one Reaper developers think linearly and think that's right. In nature, all changes occur in the natural logarithm: the waterfall falls in the natural logarithm, the spectra of light and sound are decomposed in the natural logarithm, the change of pace also occurs in the natural logarithm. When a musician gradually slows down or speeds up his performance, this process is not linear, but by the function of the natural logarithm. That's why the developers of Cubase, Guitar Pro, Sibelius and Dorico modeled this process, calculating the law of natural logarithm. This logarithm is therefore called natural. No wonder mathematics and physics discovered the exponent (number e) and discovered the logarithm, and the natural logarithm. Everyone can count as you like. Here is only will whether correctly?..
Do you even know what a logarithm is? What is it? Why are there different kinds of logarithms? Why a decimal logarithm? Why natural logarithm? Please answer these questions. Just like that? The whim of mathematicians and physicists to play with toys? No. It shows the mathematical weight of a value in a set of values. It is the weight. So the natural logarithm shows the weight of the beat in a variety beats by gradual uniform change in tempo. Moreover, Dorico and Sibelius is possible to set uneven changes in tempo, for example, when a musician is first slowly accelerated, and then accelerated faster and faster. This is an even more complex function, since the second order derivative of the logarithmic function is calculated.
I apologize for my English, but I think you will understand me. And developers too.
|
|
|
06-18-2018, 03:09 AM
|
#28
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,790
|
I know math, I know what a logarithm is (and so do developers) - and also, natural logarithm is not called "natural" because it's found in nature It is not wrong to do it how Reaper does it. It's just another way of doing things. Just like there are many ways of doing the same thing in math, too.
Also, I will argue that a live performer most certainly doesn't slow down by any mathematical formula, it can be very nonlinear and not even logarithmic, depending on how he/she feels at the moment.
Quote:
Originally Posted by aveter
You can count as you like, even on hyperbole, but this is wrong.
|
Who are you (or anyone else) to say that it's wrong? In Reaper it makes sense because timeline is ALWAYS LINEAR TIME. That is how it was concieved from the get go. If you cannot understand this, and cannot understand why this ISN'T wrong, it's hard to continue this discussion.
In Cubase, you can choose the timeline mode to be linear time or linear beats. Reaper doesn't have this option. That doesn't mean it's wrong (since obviously Cubase also has an option for linear time!).
Last edited by EvilDragon; 06-18-2018 at 03:23 AM.
|
|
|
06-18-2018, 03:32 AM
|
#29
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
By the way, the latest Reaper prerelease contains a fix for importing time signatures incorrectly attached to MIDI tracks, which should alleviate at least one faulty thing that GP exports.
Actually, Justin and schwa are the only developers of Reaper.
|
Did you watch my last video till the end? Export-import has nothing to do with it. ReWire!
|
|
|
06-18-2018, 03:38 AM
|
#30
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
I know math, I know what a logarithm is (and so do developers) - and also, [url=http://mathforum.org/library/drmath/view/52562.html]Who are you (or anyone else) to say that it's wrong? In Reaper it makes sense because timeline is ALWAYS LINEAR TIME.
|
So it is not about the time itself, which is linear in nature. The next second, equal to the previous second. Yes. But here the time intervals are calculated! A Cubase just toggle the display of the scale and grid, but the calculation is ONE.
|
|
|
06-18-2018, 03:50 AM
|
#31
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
Just like there are many ways of doing the same thing in math, too.
|
That is, the developers of Dorico (Daniel) decided: let's count on the natural logarithm, because we like it better. Come on.
The musician can, of course, play differently, depending on the mood. He is in the throes of passion may play other notes. But if you take an academic musician who needs to play academic music, then its slowdown or acceleration will be close to the law of natural logarithm. It's nature! The snail has a shell that reflects the Fibonacci numbers, but this does not mean that the snail created its shell by the formula.
|
|
|
06-18-2018, 03:58 AM
|
#32
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by EvilDragon
|
If you know, please explain to me the very essence of the logarithm and the natural logarithm too. Not formula, not a definition, and the essence. What is it?
|
|
|
06-18-2018, 04:00 AM
|
#33
|
Human being with feelings
Join Date: May 2010
Location: Norway
Posts: 7,318
|
Quote:
Originally Posted by aveter
|
You jump the conclusions here,
assuming everything is Reapers fault.
Know that midi tempo export is square. There is no support for midi linear tempo afik.
There is a few different perspectives to this subject:
- What is a theoretical correct way of handling tempo in a DAW?
- What is a practical way of handling tempo in a DAW?
- What is Arobas Music way of doing this vs. Reaper?
- What is the Midi standard for embedding tempo?
- What is a practical solution for your export from Arobas Music to Reaper?
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
|
|
|
06-18-2018, 04:12 AM
|
#34
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,750
|
Really, this isn't about linear vs logarithmic. It's simply about the unit of accounting.
If I asked you to walk a certain distance, starting at velocity X and ending at velocity 2X, would you accelerate so that your velocity was 1.5X after half the distance (linear-beats), or so that your velocity was 1.5X after half the total elapsed time (linear-time)? The former would appear as a curved line in the REAPER tempo envelope; the latter (the current method) would appear as a straight line. You would accomplish the former by making sure you accelerate steadily with every passing meter; you would accomplish the latter by making sure you accelerate steadily with every passing second.
We do recognize that interoperability would be improved if we supported linear-beats tempo changes, but it would be a deep change and it would be difficult or impossible to convert existing projects without completely mangling them. It would have to be a decision made permanently when the first linear tempo change is introduced.
|
|
|
06-18-2018, 04:14 AM
|
#35
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by G-Sun
You jump the conclusions here,
assuming everything is Reapers fault.
Know that midi tempo export is square. There is no support for midi linear tempo afik.
There is a few different perspectives to this subject:
- What is a theoretical correct way of handling tempo in a DAW?
- What is a practical way of handling tempo in a DAW?
- What is Arobas Music way of doing this vs. Reaper?
- What is the Midi standard for embedding tempo?
- What is a practical solution for your export from Arobas Music to Reaper?
|
Do not forget to add here Steinberg Cubase, Dorico, Avid Sibelius... Don't just get attached to Arobas Music Guitar Pro.
First, watch my latest video to the end about ReWire, which features only audio data, not MIDI.
|
|
|
06-18-2018, 04:24 AM
|
#36
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Quote:
Originally Posted by schwa
We do recognize that interoperability would be improved if we supported linear-beats tempo changes, but it would be a deep change and it would be difficult or impossible to convert existing projects without completely mangling them. It would have to be a decision made permanently when the first linear tempo change is introduced.
|
That says it. This is not possible for you because the fix will affect the platform in a fundamental way. For me, work on ReWire and data exchange between DAW, Score editors are very relevant, and Reaper will conflict with other programs. This was my last attempt to get you to understand the problem, but it is closed with a cross. I'm sad! Very, very.....
Thank you.
|
|
|
06-18-2018, 05:19 AM
|
#37
|
Human being with feelings
Join Date: May 2010
Location: Norway
Posts: 7,318
|
Quote:
Originally Posted by aveter
First, watch my latest video to the end about ReWire, which features only audio data, not MIDI.
|
So, you've highlighted that:
1) Guitar Pro and Cubase handles linear tempo-changes different from Reaper
(and schwa explained what this difference is)
2) There might be an issue with using Reaper rewired to Cubase for linear tempo-changes.
(But, you might expect to much from Rewire here)
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
|
|
|
06-18-2018, 05:33 AM
|
#38
|
Human being with feelings
Join Date: May 2010
Location: Norway
Posts: 7,318
|
Quote:
Originally Posted by schwa
We do recognize that interoperability would be improved if we supported linear-beats tempo changes, but it would be a deep change and it would be difficult or impossible to convert existing projects without completely mangling them. It would have to be a decision made permanently when the first linear tempo change is introduced.
|
I guess this could be a preference.
I agree: Old projects needs to be bullet-proof backwards.
A more practically question: Dealing with 2 sets of linear tempo-envelopes points -what would the possible benefits from that be? And drawbacks?
I guess improving:
- Midi tempo export accuracy
- The handling of Rewire tempo-date from eg. Cubase
could be a better approach
There could maybe also be possible to fake linear-beats tempo changes, displaying it as a continuum, writing it as square.
But, in aveters case the midi tempo import seems totally down to the program he's using for creating that midi-file.
For export the other way, I believe Reaper + SWS is better (breeders actions should be perfect conversion)
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
|
|
|
06-18-2018, 05:57 AM
|
#39
|
Human being with feelings
Join Date: May 2018
Posts: 18
|
Gentlemen, I have forgotten one law of nature, which was discovered by two famous scientists. I got my education long ago, 30 years ago, so I forgot it. But now I remember this law. Developers Cubase, Dorico, Sibelius, Guitar Pro and many others, their calculations built on this law. That's why they calculate the gradual slowdown or acceleration of the tempo of the music by the natural logarithm, not by the linear function. They walked right into this topic. They're good! Good job! And you're wrong about your linearity. What kind of law is this? Weber-Fechner Law. Your further remarks are a pathetic excuse for your powerlessness and lack of knowledge. Reaper is definitely lost to me.
|
|
|
06-18-2018, 06:37 AM
|
#40
|
Human being with feelings
Join Date: May 2010
Location: Norway
Posts: 7,318
|
Quote:
Originally Posted by aveter
Gentlemen, I have forgotten one law of nature, which was discovered by two famous scientists. I got my education long ago, 30 years ago, so I forgot it. But now I remember this law. Developers Cubase, Dorico, Sibelius, Guitar Pro and many others, their calculations built on this law. That's why they calculate the gradual slowdown or acceleration of the tempo of the music by the natural logarithm, not by the linear function. They walked right into this topic. They're good! Good job! And you're wrong about your linearity. What kind of law is this? Weber-Fechner Law. Your further remarks are a pathetic excuse for your powerlessness and lack of knowledge. Reaper is definitely lost to me.
|
Good bye!
You have a peculiar way of not accepting reality.
If you ever come back, and write in such language again,
I'll put you on my ignore-list (and although we have a few people with bad manners here, few are actually on that list)
On the positive side: I'm sure you have an ability to improve your social skills
__________________
Reaper x64, win 11
Composer, text-writer, producer
Bandcamp
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:23 AM.
|