| Summary: | Copy pasting .mid data goes wrong every other time | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | kravanjunk |
| Component: | xwayland | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | nate, qydwhotmail |
| Priority: | NOR | Keywords: | wayland-only |
| Version First Reported In: | 6.4.4 | ||
| Target Milestone: | --- | ||
| Platform: | EndeavourOS | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Dotted notes become tied non-dotted notes, notes shift to higher strings when possible
Clipboard manager displays a folder Import local mid |
||
|
Description
kravanjunk
2025-08-20 07:15:34 UTC
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? |