Projects altered after clean project and upgrade Ubuntu

[kmchen]

Hi,

I used Reaper under Linux Debian 9, 10, Ubuntu 19.10 and I love it. But I recently upgraded Ubuntu to 20.04...and strange things occured.

Before describing those things I would add that before upgrading I used the "Clean current project directory" for all my projects before to backup them on an usb disk.

Most of projects do not seem to have been damaged but three of them did lost items time synchronisation (some items (midi or sounds)) were shifted in time line and some (not all) sound items do not play although the .wav files they're pointing to still exist.

If I open a damaged project, move a midi Item to its correct timeline, close reaper saving the project, the midi reamains in its false position when I reopen the project !!!

I think there is no simple way to recover these projects but as developper on other projects I wanted to let Reaper's developpers know, if they are interested, that there is a very bad bug somewhere around project cleaning or Ubuntu upgrade.
Unfortunately I don't have other elements than the projects themselves in the state that I can send if wanted.

[kmchen]

Too bad nobody responds. I spent a whole day trying to repair one project. When I repair one item or track others loose their timeline.
An horror. I believe I'll never see the end of that !

Could someone at least tell me how can one fix the time line of the entire project so when you change the time of an item others remain unchanged ?

[jiff 41]

Do you have the tracks *Grouped* as changing one track will affect all?.


And if you want to alter the timing of one track to match the others right click on the track header & look for *track timebase* & then choose *Time* instead of Project timebase?


Hopefuly this is what you want?.

[kmchen]

Only 3 tracks are grouped. The problem appears on any tracks groupes or not. Even midi items are constantly changing of time line.

I'm trying to play with the tracks timebase.

Maybe I found something that would help to understand what happens. With one ungrouped track, "Time" based:

If I cut a 2 bars audio and then past it on another independent track, see capture 1-3, the original item has:
start in source = 1:14.400
playback rate = 1,000000

the copy has:
start in source = 1:14.000
playback rate = 0,833333

If I "undo" what I just did (copy, past), see capture 4, the original item is replaced by the copy and the track has been shortened (of 0,833333 I guess) and the whole rest of the track is moved ahead so that all the timeline is lost (see the red marker) !!!

[jiff 41]

I'm on Windows now don't know if it makes a difference but maybe you should post in the *Linux* section you might get more response there?.

[kmchen]

I don't think it is related to the system. System bug would make Reaper always do the same error on the same action. Here copy/paste and undo lead to a change of time line. This for me is related to internal Reaper timing.

Another symptom I found. A drum loop I inserted on a track that had to be synched in tempo desappears after my manipulations

[akademie]

Test clean installation, without any additional extensions and scripts.

Read more about similar problem in another thread here (solution is post #11):
[Solved]Big problem with Reaper under Linux Mint
https://forum.cockos.com/showthread.php?t=244933

[kmchen]

HI, thanks for replying.

Downloaded Linux x86_64 REAPER v6.16 - 11MB today and opened the project with it. Same behavior, exactly, as the screen captures described it previously.

Extensions could not be in user directory so a fresh download could not contain extensions or should I verify that I do not have any extension installed ?

[kmchen]

I've isolated the bug from scratch:

On a completely new project created with las Reaper v6.16
1/ Change tempo to 200bpm (initialy was at default 120)
2/ Insert a .wav loop
3/ Record an audio on a 2nd track
4/ Copy past the audio on a 3rd track. Every thing OK. Capture 12

Now I load my project before open a new project (I expect something of my altered project will stay in memory) and I do exactly the same actions
1/ Change tempo to 200bpm (initialy was at default 120)
2/ Insert same .wav loop
3/ Record an audio on a 2nd track
4/ Copy past the audio on a 3rd track. The audio is copied with a 0,877... playback rate! (capture 13)

Please see the RPP file of the corrupted project attached

And more, if you undo the last copy the original item is playback rate changed !

[Glennbo]

Check this thread. Sounds like the same issue you are seeing.

https://forum.cockos.com/showthread.php?t=245407

-

[kmchen]

Thanks for the link. It gave me the idea to open the corrupted project on another laptop/Debian10/Reaper 5.x. A warning saying I could loose some functionalities but the project works perfectly. I could add tracks and compose new midi items without a problem.
I saved the project and tried to open it with Reaper v6.16 but still bugged.

Hope some developper will have a look on that thread, specialy #9, and give me a solution to make that project work again on my usual computer under Ubuntu 20.04/Reaper v6.16.

[kmchen]

Still no reply. Is it possible to contact the developpers or any bugs declaration page ?

[Glennbo]

Originally Posted by kmchen

Still no reply. Is it possible to contact the developpers or any bugs declaration page ?

REAPER v6.17 is going to drop any day now and should have a fix.

[kmchen]

The bug is known, so ?

Won't you give me a temporary solution though ?

[Glennbo]

Originally Posted by kmchen

The bug is known, so ?

Won't you give me a temporary solution though ?

Have you downloaded version 6.17? It's out now.

https://www.reaper.fm/download.php

[kmchen]

Hi,
I tried the v6.18 same problem.

I also tried to consolidate the project. No way.

I join here 2 .rpp files.

If you open bug_reaper.rpp you'll see track 2 and 3 contain a 4 bars item.

Next, open my_project.rpp project and then reopen immediately bug_reaper.rpp. Track 2 and 3 items no longer fit 4 bars.

So my_project.rpp has something that corrupts timing.

[kmchen]

Why no answers ? Don't the files provided show clearly the bug ?

I would give any further informations that could help

[akademie]

Originally Posted by kmchen

Why no answers ? Don't the files provided show clearly the bug ?

I would give any further informations that could help

I just tried your two example project files here (in Linux Mint 18.2 64bit LiveDVD), but there is no problem you are writing about. So cannot help

EDIT: I cannot re-open the files immediately, fast because there is always warning window about missing files, of course. So if it depends on extra fast switching of the to projects, then I could not simulate.

[kmchen]

HI,

here is a zip containing the project corrupted with only 3 tracks left plus a screen capture to verify that we see the same thing.

First track: 2 midi items with cockos synth as FX. First item do not sounds

Second track: 1 audio 4 bars item recorded with just a tap on laptop's microphone on beats.

third track: 2nd track duplicated. the item doesn't loop correctly.

[akademie]

I still don't get what's wrong.
If you you extend the right border of item on track 2, you reveal that the item is not 4 bars long but actually almost 5 bars long! So by dragging the right border of the item far to the right to get it looped, you end up with the state as on track 3, which is expected.

You have 2 choices:
1) glue the item on track 2 so it become a real 4 bars audio file (*)
2) in item properties (F2 hotkey), check the option "Section" in Take media source part of the dialog window (it is located at the bottom of that window) - it will tell the item where its loop boundaries are required, independently of the whole source item length.

* warning - keep in mind to have "Tail" parameter-option for render/freeze/applyFX/glue operations set to 0ms or disabled. If not then you will end up again with the item prolonged by the amount of time set by the "Tail" parameter!

[kmchen]

Thanks for replying.

Please note the "actually almost 5 bars long!" where recorded on a exactly 4 bars loop and the item properties say 4.0.00. The almost 1 bar more was added by Reaper and shows only if you extend the item as you said. But I did not change the original item length. Just kept the first take of 2 (SHIFT ALT T).

Next when I want to loop the original item on track 3 I expect to loop on 4 bars, not on "almost 5" ! The result should produce a tap on each beat start and track 3 produces a completely out of rythme performance.

But you perhaps touch the point with the ""Tail" parameter-option for render/freeze/applyFX/glue". Where do I see that ?

--
You said nothing about the first item track 1 that produces no sound for me. Does it for you ?

--
I tried to glue, under 19.10, all tracks of the project so that each tracks are only 1 item starting at 1.1.0 beat, but very unexpected things happend when I reopen the project under 20.04. First everything looks fine but when I save the project and reopen it, audio or midi items parts and FX effects dissappeared.

Please, could you try to repeat what I've done on that project. Record exactly a 4 bars loop selection, duplicate the item produced on another track and see what happens ?

[akademie]

Originally Posted by kmchen

...<snip>
You said nothing about the first item track 1 that produces no sound for me. Does it for you ?
<snip>...

The first MIDI item has set volume/velocity handle to 0, that horizontal line on MIDI item is at very bottom, also the item has darker backround because of that. And also it is noted in front of Take name .. that [Vel. x0.00] reading, you see.
Grab the line at the bottom of item and raise it up... Problem solved.

ADD: Or you can also use action "Item: Reset items volume to +0dB".

[akademie]

Originally Posted by kmchen

...<snip>
Please, could you try to repeat what I've done on that project. Record exactly a 4 bars loop selection, duplicate the item produced on another track and see what happens ?

I can only direct you to learn audio media and media items behavior in REAPER.

In short,
when you start recording, REAPER records (audio or midi) for whole time while record button is pressed. Even when you record into selected time-selection only - in such case, the media item is created only within the time selection, but actual recording of material still continues until stopped. So then when you extend the right border of item, you only uncover that continued recording and boundary of media for looping is at the end of recording.

You can quicky set behavior of item what should be a content of the loop by using following Actions (or properties for item, but action can be made into button in toolbar which is handy):
Item properties: Loop item source
and for your case especially
Item properties: Loop section of audio item source

Try to play with these to get familiar what happens when utilizing them.

[kmchen]

Well. It seems that I can't reproduce, isolate the bug but there is one. May I send you the complete project (~90Mo) for you to have a look on it ?

[akademie]

Originally Posted by kmchen

Well. It seems that I can't reproduce, isolate the bug but there is one. May I send you the complete project (~90Mo) for you to have a look on it ?

Upload it somewhere and send me the link in PM. I will try to load and look at it.

[kmchen]

did upload it and let you a private message. Did you see ?

[akademie]

Hi kmchen, I just downloaded Ubuntu 20.04 ISO and tried boot into "live" mode to try your project (and actually I am writing this reply from here .
Only thing I do not have is Carla, of course, so warnings about missing Carla on two tracks.
Otherwise it does load normally, see screenshots.

[kmchen]

Thanks to have taken time to this.

You did not load carla plugins and that's perhaps the point. I did remove all carla plugins to have the same config as yours and the project did load properly...
Then I re-introduced carla plugins and the problem came back.

Hope to not abuse of you patience on that silly affair but would you give a last try: I replaced the project you downloaded with another where you'll see carla.vst is included. You should get that project modified by exactly the same link I sent you by private message.

Would you mind to download it, unzip. You should now see a new folder carla.vst in it. Please open the rpp project and change its vst path:
options > preferences > Plugins > VST to fit the path to carla.vst you downloaded with the project. Should be something like:

yourPath/change the world.test/carla.vst/

Then click on "Re-scan" > "Clear cache and rescan for new/modified plugins".

Lastly verify that the FX "CLAVE" track still contains "Carla rack" with "Kit2bug" instrument loaded.
***
if carla rack is not added as FX, you should be able to add it, then click on it, then on "Configure Carla" > "plugin paths" > "SF2/3" put the path on your system, something like :
yourPath/change the world.test/soundfonts
Then click "ok" > "add plugin"
the soundfont kit2bug should appear. Choose it
***

You should now hear a kind of bell playing on that track.

Save the project and reload it. Are the 3 last tracks already unshifted ?
On my system they do are shifted left as shown in Capture 3.

[akademie]

Even when rescanned, the Carla still does not load.
It fails to add itself properly into available plugins as can be seen from part of reaper-vstplugins64.ini file.

[vstcache]
CarlaPatchbay.so=00864C763CD9D601
CarlaPatchbay16.so=00864C763CD9D601
CarlaPatchbay32.so=00864C763CD9D601
CarlaPatchbay64.so=00864C763CD9D601
CarlaPatchbayFX.so=00864C763CD9D601
CarlaRack.so=00864C763CD9D601
CarlaRackFX.so=00864C763CD9D601
reacast.vst.so=802BE9B552D5D601,1919246691,ReaCast (Cockos)
reacomp.vst.so=802BE9B552D5D601,1919247213,ReaComp (Cockos)
...

Project loads with tracks 3, 4 and 5 shifted left (before marker 2).
Saving and reloading the project does not solve this shift.

[kmchen]

Originally Posted by akademie

Even when rescanned, the Carla still does not load.

Perhaps should you install the plugin normally:

sudo apt install carla

Originally Posted by akademie

Even when rescanned, the Carla still does not load.
Saving and reloading the project does not solve this shift

Can you consider a bug then ?

[akademie]

I will try "installing" Carla later.

[kmchen]

I finally installed a multiboot with Kubuntu 18.04. On that distrib I can reopen and modify my reaper projects correctly.
So I certify that there is a problem with 20.04 version.
I can help and give any precision if needed.

[kmchen]

Looks like Reaper will never have a look on the bug I found

[kmchen]

Weeks have passed now and I do still have problems when I open Ubuntu 18.04 projects under Ubuntu 20.04

I'm sorry to have to say that I paid for a Reaper licence and would like that it work properly on the last Ubuntu version.

Here is a link to a zip file containing a standalone Reaper project without any plugin with a video included "out.ogv" that shows how to reproduce the bug.
https://www.webologix.com/media/public/reaper_bug.zip

Thanks to reply

[akademie]

Originally Posted by kmchen

...<snip>
I'm sorry to have to say that I paid for a Reaper licence and would like that it work properly on the last Ubuntu version.
<snip>...

I'm sorry to have to say that, but then maybe you should have read carefully first:

Citation from download page:
"Note: Linux builds are experimental and unsupported. Please read the included readme.txt for more information."

[kmchen]

Beautifull! So you admit the bug exists but refuse to solve it.

Are the unsupported Linux licences cheaper than the supported ones ?

[kmchen]

Installed 6.23 and still the same unusable reaper under Ubuntu 20.04.

I give all details and .rpp file if someone interested.

[kmchen]

I can't believe that nobody in Reaper team do not take a bug in account or at least try to give some solution.

[Lunar Ladder]

Originally Posted by kmchen

I can't believe that nobody in Reaper team do not take a bug in account or at least try to give some solution.

I downloaded the zip with the video instructions on how to reproduce the issue. Couldn't reproduce it, and when loading the project again, the looperman file loads with the timing intact as expected. This was in up to date MX Linux, using the most recent Reaper version. Carla is installed.

Regarding the Reaper team taking a bug associated with a specific Linux distro into account: if this is indeed related to the Ubuntu version as you say, and is indeed specific to Linux, it's not at all surprising that the bug is not readily taken into account. When you purchase a license, it says very very clearly on the purchase page: "Please go here to download and evaluate REAPER before purchasing", and in turn, on that download page when accessing the Linux builds, it says in red lettering "Note: Linux builds are experimental and unsupported. Please read the included readme.txt for more information." I don't think this warrants an "I can't believe that nobody... blabla" comment of any kind, really.

[cyrano]

I had a Reaper setup with Ubuntu studio 18. After some meddling with ALSA it was running pretty stable and doing all I need.

When I upgraded to Ubuntu studio 20, the machine started locking up after minutes. Sometimes 5, sometimes 20 minutes. Nothing in the logs. I suspected a hardware problem, but I have several other distros running on it without any problems. It also locked up if it wasn't running Reaper, just idling in the DE.

I don't usually do major upgrades, always clean installs on a new HD. Now I curse myself for that spur of the moment lapse from habit.

Maybe there's something odd when upgrading Ubuntu studio, going 2 major updates forward?