SUMMARY When I copy and paste music notes (they're saved as .mid data on the clipboard according to the Clipboard manager) in Guitar Pro 8 (through Wine), the data will come out mangled when I try to paste it, but only every other time. The pattern goes as follows: 1. First copy, the data shows up in the Clipboard manager 2. Paste, the notes are replicated perfectly 3. Second copy, the data DOES NOT show up in the Clipboard manager 4. Paste, the notes have shifted in length, string position and several Rests (musical notation) have been added. For all intents and purposes, the data has been extremely mangled. STEPS TO REPRODUCE 1. Copy and paste music note data in GP8 2. Copy and paste music note data again in GP8 3. The pasted data will not be the same as what was copied the second time OBSERVED RESULT When pasting the second the time, the pasted data is not a perfect recreation of what had been copied. EXPECTED RESULT When pasting a second time, the pasted data should still be a perfect recreation of what had been copied. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.16.1-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION GP8 nor Wine had been updated or have been updated since this behaviour started to take place, and therefore shouldn't be the source of the bug. This started happening quite a while ago but I wasn't sure how to determine what program/component was at fault. Enabling the Clipboard manager gave me some feedback about the copy paste behaviour. I have reproduced similar behaviour (but not the exact same) with an old version of GP8 confined to a Bottle, where the Clipboard manager would often correctly show I had .mid data on my clipboard but sometimes would simply show a folder icon instead and still sometimes mangle the data, but not as often as regular Wine.
Are you copying files on disk, or content copied from within the GP8 app? If it's the latter, can you confirm that GP8 is a Windows-only app you're running through WINE? A screen recording that shows the issue happening might be helpful here.
Created attachment 184297 [details] Dotted notes become tied non-dotted notes, notes shift to higher strings when possible In this video you can see the shift in content. I think this might be because of the Clipboard replicating the data imperfectly. The contents are technically the same, but suddenly presented in a different format.
Created attachment 184298 [details] Clipboard manager displays a folder When copy pasting the same .mid data over and over, Clipboard manager will suddenly indicate a folder has been copied instead of more .mid data. I assume this will also happen when copy pasting different .mid data each time. This behaviour may not be directly related to the .mid data being "re-interpreted" but it might be relevant.
(In reply to Nate Graham from comment #1) > Are you copying files on disk, or content copied from within the GP8 app? > > If it's the latter, can you confirm that GP8 is a Windows-only app you're > running through WINE? > > A screen recording that shows the issue happening might be helpful here. It's indeed the latter. GP8 is running through standard WINE. Through testing I noted some of the specific behaviours: -Note lengths will only be re-interpreted if they're dotted notes, unless they're the first note of the bar (start of the copied data) From Wikipedia: "The dot increases the duration of the original note by half of its value. This makes a dotted note equivalent to the original note tied to a note of half the value – for example, a dotted half note is equivalent to a half note tied to a quarter note." In the video example, we see a dotted quarter note (3/8 value) turned into an eighth note (1/8 value) tied to a quarter note (2/8 value). This is therefor technically correct, but not the same data that was inserted into the clipboard originally. -Notes will be shifted to higher strings when possible, this occurs at the same time as the note length re-interpretation. Again: technically correct and the same value, but not the same data that was inserted into the clipboard originally. -I wasn't able to reproduce this now, but sometimes when I'm regularly copy and pasting different parts of a song, the previous clipboard content would be pasted instead of what should be the current clipboard content.
(In reply to kravanjunk from comment #3) > Created attachment 184298 [details] > Clipboard manager displays a folder > > When copy pasting the same .mid data over and over, Clipboard manager will > suddenly indicate a folder has been copied instead of more .mid data. > I assume this will also happen when copy pasting different .mid data each > time. > This behaviour may not be directly related to the .mid data being > "re-interpreted" but it might be relevant. Additionally, for some reason the Clipboard only seems to add a new entry every 2-3 times I cut or copy data, as you can see in the video (based on the folder entry moving down or not while I'm clearly cutting and pasting). I imagine the expected behaviour would be seeing a new entry added every time I cut or copy
Created attachment 184378 [details] Import local mid This looks like a bug in Guitar Pro 8. The temporary mid file saved in `~/.wine/dosdevices/c:/users/xxx/Temp/` is already shifted. If you export the current sheet to MIDI and open it in GP8 again, the file is also not the same, which might mean MIDI file doesn't support some features and it's a bug in GP8.
Moving to kwin as Klipper faithfully keeps the original clip content.
To add to this, I tried reproducing the bug in VirtualBox using the same OS (EndeavourOS) but with a different DE (Cinnamon) and I was unable to. X11 or experimental Cinnamon on Wayland didn't make a difference either. It seems like it's KDE specific. I tried checking the copied .mid data in `~/.wine/dosdevices/c:/users/xxx/Temp/`, but this folder simply does not exist in the Wine folder on Cinnamon. I copied and cut a few times to be sure it would've been created. Is it a KDE specific construction related to clipboarding? Can we be sure the data is already "corrupted" when it "leaves" GP8? Could it perhaps be that the means of storing the .mid data in the Temp location in the first place is what prompts the re-arrangement?