Now GO versions look like 0.3.1.Svn number.

After migrating to GitHub we might change tis,

My suggestion is

• to remove leading 0. from the version number. GO is mature enough for starting with 0.
• To increase 1 to 2.

So to make 3.2.0 after 0.3.1.2342

I will add some logs in a further message, but for some versions releases, GrandOrgue behavior is weird at launch and at closing (execution during play is ok).

• OS: Ubuntu 22
• GrandOrgue: 3.9.0

Sometimes, GrandOrgue launch does not ... launch GrandOrgue at all.

Sometimes, GrandOrgue closing is causing freezes on some windows (and the OS windows 'GrandOrgue is not responding' is displayed).

A nice-to-have feature would be, imho, to auto-close already open organ upon loading a new one. At present, GO keeps any organ open until memory is full (considering the large ram request of most samplesets, this happens very often, even after loading just 2 organs). When memory is full, GO does crash without warning and closes itself, disappearing from desktop. I write this post here (not in discussion/ideas) because it could be considered an issue as GO brutally closes.

Hello, I don't know if it's a grandorgue bug or a bug in my computer, but when I start grandorgue, the position of my panels is never remembered.

I am using Linux Mint with grandorgue version 3.2.0.1, and two touch screens. When the computer starts up, the two panels with stops (right jamb and left jamb) are placed on my right screen, while the main menu of grandorgue is placed on the left screen.

Systematically, I move my left panel to the left screen then I save the settings, but when restarting it is identical the two panels go back to the right screen ...

It would be helpful if you could include some scripts to enable deploying of AppImage bundles as well as DEB/RPM packages.

I already have a recipe for building AppImage for GrandOrgue in my forked OBS repository: https://build.opensuse.org/package/view_file/home:lbssousa:grandorgue/grandorgue/appimage.yml?expand=1 , but I'm still having problems with JACK support. Maybe I should build GrandOrgue AppImage without JACK support.

This Github action can be handful: https://github.com/marketplace/actions/build-appimage

Hi @e9925248 @larspalo,

I've created this repository and made a first migration of SVN original repository embedding the commit history and authors (with github sync when I found it).

I'm waiting your feedback on this to go forward. I hope soon. Thanks

Resolves: #700 Resolves: #886 Resolves: #950 Resolves: #1049 Resolves: #1119

This PR summarises a quite large amount of work on the Organs tab of the Settings dialog.

• The package list is got rid. The packages are maintained automatically with the corresponded organs #950
• Several organs may be selected a time. It allows to do same actions with several organs at once
• Additional information is shown including the Organ hash that allows to identify GrandOrgue files in the Cache and Data folders (#700)
• Capability to delete cache and saved presets for organs
• Capability to change the filesystem path of organs after the files were moved

I would very much like to report what could be a possible GrandOrgue error. Let's see. I went to perform a test with the convulation reverb feature enabled. It seems to work normally, provided that a valid impulse response has been selected. What happens, however, is that if the user changes any impulse response file or even turns the feature on or off when the organ is still running, it seems to me that GrandOrgue starts crashing and showing a lot of instability, with strong bursts in the audio that are only resolved either by closing the program or sometimes by pressing the "panic" button. I ask, in this spirit, if this could be some bug in the program or if the convolution reverb should not be changed when the organ is still running?

Ubuntu 22.04 GO 3.9.1

No matter the audio settings even simple stereo or multichannel audio is glitchy almost like not enough polyphony!? RT or PA and audio buffer settings of 128 256 512 1024 doesn't fix.

The discussion was already started in https://sourceforge.net/p/ourorgan/discussion/962124/thread/980e53e5f4/?limit=25&page=3#fa69/6bd9/c233 and then was continued in https://github.com/GrandOrgue/grandorgue/pull/2#issuecomment-913387050

I think it's better to start a separate thread for discussing the process of merging.

We have several options, each of them have their advantages and disadvantages.

1. Merge all changes without code review
2. Merge all changes after some small amount of code review but without lots of modifying
3. Merge all changes with exact code review in the same order as they were in the fork
4. Merge only some of changes. It is quite easy to merge small changes but it is difficult to extract large changes with a lot of related commits
   1. Minimal approach. If there are two changes A and B; B works only with A. We want to merge B but don't want to merge A, then we modify B and A before merge that to get the maximum from B and the minimum from A.
   2. Maximal approach. If there are two changes A and B; B works only with A. We want to merge B than we also take A. It can recursivelly require additions of other changes, so the PR becomes very large. Some example of this approach is #2
5. Not to merge any changes at all

i tested latest r3631 under linux (raspbian) and WIndows 10 and found several issues. linux: help dialog opens but Settings dialog looses focus and cannot be anymore selectable. In addition, if the minimize button in the Help modal dialog is selected, then it disappears and cannot be reopened anymore (even if it can be seen in the top app bar). As a result, as both Settings, Help and GO windows/dialogs are no more focused they all cannot be closed and it is necessary to kill GO process from terminal. A less important issue is that Help dialog on first open is 0-size and appears as a small vertical bar (look at last screen recording).

Windows: more or less the same issues apart there is no need to kill process. When opening Help, its dialog stays always over the Settings dialog: this is not good in Windows as it should get fore and back as the two dialogs take focus (see the screencam on Treesize that is a small tool i ran just for example). And again, if the minimize button is choosen then it doesnt appear anymore, even pushing again the Help button. No Help is later on available even from Menu. The only way to reset situation is to close and restart GO.

Pls look at the screen captures below.

https://user-images.githubusercontent.com/50132661/156633497-2e2ccb01-96e0-4ceb-a8ea-73b89fb0ca99.mp4

https://user-images.githubusercontent.com/50132661/156633676-944fb7f9-a297-49c2-8b54-765e684b197f.mp4

https://user-images.githubusercontent.com/50132661/156633719-d291543e-5151-4ea8-a8a1-78ec391cca71.mp4

https://user-images.githubusercontent.com/50132661/156643002-5c9ce9b0-dbe2-47c0-b952-6881d5d5db1b.mp4

https://user-images.githubusercontent.com/50132661/156644170-071babea-0b0b-469b-99b0-3b5909d21e6e.mp4

Toward to elimination dependencies on GOOrganContoller I renamed and moved GOOrganController::m_PipeConfig to GOOrganModel::GOOrganModel.

So all GOPipeConfig instances are present in the model and noone is in the controller.

Resolves: #1271

This PR documents restriction of working on wayland.

The wiki page https://github.com/GrandOrgue/grandorgue/wiki/FAQ has also updated.

Linux Ubuntu 22.04 GO 3.9.1

Loading samplet freisach for eg window is full screen. Move it and position it - save - close down and start up again goes back to full screen.

Since some time, at least dating back to commit 3a861221a252c4ec60aa93e1ce2c031c99cc1744 but could be older, the device id of USB audio devices seem to randomly change again at boots. This requires re-setting the audio device to get working sound again since wrong id is stored since last boot. A matching solution like that of the MIDI devices perhaps would be in order?

Discussed in https://github.com/GrandOrgue/grandorgue/discussions/1236