Copying Pipe Offset to....

[Bumblebee001]

Hi,

I am copying last note in Pedal stops to 5 additional created notes. When I use Copy Pipe Offset to the selected pipes, all notes get corrected for pitch tuning to be one semitone higher. Fantastic.

BUT..... the last note changes to percussive. Why?

Same for Manuals going from 58th to 61.... just 3 additional notes. Last note changes to percussive!

[larspalo]

Unfortunately I got no idea (yet) as to why that would happen for you. Here the last note doesn't change to percussive when i try to do exactly the same thing.

[larspalo]

I cannot reproduce this issue on a windows build running on an old windows 7 laptop, neither on a build running on Linux. Could you please explain further all the steps to reproduce it? All the details, please, like exactly when you detect that the percussive value is changed (immediately after copying, after writing etc.).

I made sure to check in the source code that the percussive value for the pipe is copied from the source pipe to the target pipe in the procedure so something else must be happening for you.

[Bumblebee001]

I don't think I can add much to what I reported as having done and observed. I use your software in pretty much the same way. I click on the icon on my desktop, load the .organ file, I adjusted the total number of keys to 61 for the manuals and 32 for the pedalboard. I went into the internal rank tab, moved to key 58 that had the last pipe files, right clicked to get the menu, selected the "copy this file offset to", selected the last 3 keys (that had dummy), clicked "copy to selected" and that's where the last key turned immediately to percussive. The other two remain unchanged in that respect. I did not observe that happening initially but I recognised something was wrong when I tested the keys and the last note played once through like it ignored the loops and the duration of my clicking on key, whether briefly or for longer.... made no difference. (Here I said to myself .... WT$....). When I checked it was then that I noticed the percussive thing (repeating the expletive....) and paid attention to subsequent stops I was extending. It happened each and every time for all stops and I had to correct each one before move the focus away and eventually saving the odf. The last keys then played fine, as expected.... with a sigh of relief at having achieved successfully and with little toil and pain the extentions.

Now I don't think I can be more accurate than that... ;-) (I hope you are smiling at this!)

May I remind you that I am using Windows 11.0 64x updated with all the MS updates so far.

[You may recall I had experienced an issue with LoopAuditioner in Windows which unfortunately you never had the time to address because apparently it was not reproducible on linux or you were far too busy with other matters. I still have that issue and have to get around it as best possible because LA is the only software I have learnt to use for the jobs I need to carry out and it is otherwise pretty much good for what it is intended to do (other than I think the playback of the files are not quite what they should be, or so is my impression). Also finding loops sometimes is a downright painful, ear-piercing and mind-blowing, tedious exercise which I wish was better automated to perfection rather than relying on the end-user to listen deep into the sound and choose the best using cross-fading at the lowest level possible (usually around 6-10) and sparingly since it creates several visible artifacts when one looks at these files in audio editing software. Perhaps one day you will revisit this software]. Sorry for digressing..... but again a Windows related issue in part!

Mark

[larspalo]

I'm still tracking down this issue but I've discovered that it has actually nothing to to with the Copy Pipe Offset feature as such. It's apparently only happening on windows, as I cannot reproduce it on Linux, and at least on the windows 7 laptop where I do have managad to get something like this to happen, it's the pipe dialog's Next and Prev button top navigation that somehow causes the issue. It doesn't happen (IsPercussive forcibly changes to Y) if last pipe is directly selected in the pipe tree when opening the pipe dialog.

Regarding LoopAuditioneer, I hope you're aware that it has been moved to https://github.com/GrandOrgue/LoopAuditioneer where you're welcome to create issues after having tested the latest release version of it.

[larspalo]

@Bumblebee001 I think I've finally fixed the real issue/bug here. The real problem was that, in the msw port, when a radiobutton gets focus it also must be selected - and since the Next button (in the PipeDialog) would loose its focus when being disabled at the last pipe - the focus would move on to the next widget, which happened to be the Yes radiobutton for IsPercussive!

This is a very good lesson, not the least for you! What you see and think is misbehaving is perhaps not at all the cause, but instead an action is, that you fail to mention clearly enough, that you took just before you noticed that something was wrong!

Don't get me wrong in turn, I highly appreciate that you use GoOdf and help me improve it! It's just that what you think is obvious many times is not at all, and not even on the correct path in order to solve the real issue at hand. That's why it's so extremely important to have all the steps you've taken to trigger an issue documented so that I can find out what step was actually the important one!

So, in short - when doing a bug report - you can never be too detailed or "accurate" - in this case, clearly, what you thought was enough wasn't... Which is why it took me quite a few hours to investigate and fix. Time that could have been saved if you had noticed that it was actually using the Next button in the pipe dialog that always would change the isPercussive value when arriving at the last pipe.

The fix was committed with 4ac09e24f3e03497ba17b8d1cf2979096683e990 and you can find the intermediate build at https://github.com/GrandOrgue/GoOdf/actions/runs/9897811338/artifacts/1692671648 in order to test it.

[Bumblebee001]

The strange thing is I did not use the next button. So how I could report something I did not do? How could I ever have imagined what you discovered? I’m not a programmer so I have no clue as to the possible sequence of events. Even in your case, it took a lot of time to discover what led to the issue. But then not quite in the way you have concluded. I faithfully told you all the steps I did. Even with this knowledge now, there would have been nothing to add to what I reported. There may be another cause that produced this result and you may still have to discover it unless the issue gets fixed irrespectively in which case it probably would not matter except academically so to speak.

[Bumblebee001]

Since my last message, I had three further updates of Windows requiring rebooting. When I tested for the issue I could not replicate it myself but yes.... I do see what you were referring to in that you get the percussive turning to on when the next button is clicked..... It was not so with my original reporting of the bug.

I have tested your latest test build and I can say that both issues (this and the crashing when opening another .organ file) seem resolved.

However I have an additional observation, when I select Pipe 58 to copy attributes from, and the little window opens, the wrong key is shown to have been selected with consequent errors appearing for many of the last keys. I have to go back and click on Pipe 58 again to get it right. I noticed this to happen when I select the Key by right clicking on it, rather than selecting and then right clicking to open the little window.

[larspalo]

I noticed this to happen when I select the Key by right clicking on it, rather than selecting and then right clicking to open the little window.

Another difference in how the msw port of wxwidgets behave compared to the gtk (linux) version. It affects any direct right-click menu operation done (at least) in the rank pipe tree ctrl, not only the Copying Pipe Offset. Should be fixed with commit 80ebe46d160369b84fc6cea4cf4757d772d89f2e which as usual will create an intermediate build...

In the future I'd appreciate to get the issues reported separately instead of getting many different ones reported in a single issue. In other words, create a new issue for each specific topic, so that each can be closed when fixed.

[Bumblebee001]

What I never expected was that a change in a parameter should occur simply by a change in focus or clicking something else.

Any parameter should change when specifically addressed and actively / intentionally changed by the user.

[Bumblebee001]

I am glad I have helped in identifying bugs in this software. This program has been in my dreams for many years and only came to fruition now, thanks to you. If I knew any programming at all I would have worked on it years ago. I had even approached a friend of mine to see what we can achieve but I doubt he had a clue as to what I was talking about and whether we would have had the knowledge, intuition and ability to achieve anything remotely like what we have now.

I do feel a sense of gratification and self-worth in contributing towards the success of GOodf. For now what remains is to have an icon to identify it on a desktop. I am using one already from a small collection I inherited from the late Panos Ghekas, whose memory and sterling contributions to the VPO world remain as strong today as ever.

[larspalo]

the late Panos Ghekas, whose memory and sterling contributions to the VPO world remain as strong today as ever.

I too have quite fond memories of Panos. When I started somewhere around 2009 I soon came in contact with him, I think first at the https://www.magle.dk/music-forums/electronic-digital-organs/ forum that we at the time partly used for "open" GrandOrgue communication. But we also had some private mail conversations now and then.

I never got the chance to meet him in person, even if he graciously did invite me to Greece not too long before he died, but I never had the chance to go there at that time. Panos, Graham and I did the Piteå MHS sample set together, and even if most of the sample preparation was my work, the help, support and encouragement from both Panos and Graham was invaluable and their influence has certainly shaped me to some degree!

As for your contributions, I still hold fast with what I said in https://github.com/GrandOrgue/grandorgue/discussions/1746#discussioncomment-10000302, the help someone gives/provides just by using an open source program and reporting back is absolutely good enough!