• Welcome to the Pipe Organ Forum! This is a part of the open community Magle International Music Forums focused on pipe organs (also known as "church organs"), organists, organ music and related topics.

    This forum is intended to be a friendly place where technically advanced organists and beginners (or even non-organists) can feel comfortable having discussions and asking questions. We learn by reading and asking questions, and it is hoped that the beginners (or non-organists) will feel free to ask even the simplest questions, and that the more advanced organists will patiently answer these questions. On the other hand, we encourage complex, technical discussions of technique, music, organ-building, etc. The opinions and observations of a diverse group of people from around the world should prove to be interesting and stimulating to all of us.

    As pipe organ discussions can sometimes become lively, it should be pointed out that this is an open forum. Statements made here are the opinion of the poster, and not necessarily that of the forum itself, its administrator, or its moderators.

    In order to post a new topic - or reply to existing ones - you may join and become a member by clicking on Register New User. It's completely free and only requires a working email address (in order to confirm your registration - it will never be given away!). We strive to make this a friendly and informative forum for anyone interested in pipe organs and organ music.

    (Note: If you wish to link to and promote your own website please read this thread first.)

    Many kind regards
    smile.gif

    Frederik Magle
    Administrator

    Krummhorn
    Co-Administrator

GO Combination Action / Memory Levels

wehtam721

New member
I'm sorry if this has been addressed before. I tried doing a search for something like this, but didn't turn up anything useful.

I'm using the latest development release of GO with an ODF that I've written myself that combines stops from several other organs. The ODF allows for 30 generals and 5 divisionals for each of 6 divisions (4 man, ped, and a floating). All of the pistons set just fine, but they're duplicating on all of the memory levels. When I set a piston (general 22 let's say) on memory level 1, then switch to memory level 2, general 22 is already set the same as it was on memory level 1. Altering the setting on level 2, also overwrites the setting on level 1. I'm not sure if I'm missing a small detail or if there's a line missing from the ODF that allows for the use of multiple memory levels or if maybe this is a known issue.

If anyone has had this problem or knows what I might be able to try to fix it, I'd appreciate any thoughts that you might have.

I'm running windows 7 (64 bit), service pack 1. If you need any other information about my system or my ODF, let me know and I'll pass it along.

Thanks in advance for taking the time to read this and help me out.

All my best,
Matt
 

e9925248

New member
The ODF allows for 30 generals and 5 divisionals for each of 6 divisions (4 man, ped, and a floating). All of the pistons set just fine, but they're duplicating on all of the memory levels. When I set a piston (general 22 let's say) on memory level 1, then switch to memory level 2, general 22 is already set the same as it was on memory level 1. Altering the setting on level 2, also overwrites the setting on level 1. I'm not sure if I'm missing a small detail or if there's a line missing from the ODF that allows for the use of multiple memory levels or if maybe this is a known issue.

Generals/divisionals only store one setting.

The "memory level" is something different than you expected - it is the combination sequencer (http://en.wikipedia.org/wiki/Combination_action)
Lock at the setter panel to see all functions.
 

wehtam721

New member
Ahh, I understand. I'm familiar with sequencers. As you said, it's just different than what I was expecting. Incidentally, it would be nice to have the ability to store multiple settings to sets of generals and divisionals in different memory levels in addition to having the sequencer. Is there any chance that something like this is in the works?

Also, in the menus it says that there's an option to export settings/combination. Could I use this option in the mean time to have multiple sets of generals/divisionals and then just import the set that I wanted to use?
 

e9925248

New member
Yes, you can export the settings and reimport the complete state or only the combination state.

GO also supports multiple presets (complette independend settings including the complete various combination state).

Every combination in GO can also be used scoped.

The sequencer allows allows direct access to 10 combinations, which can be used to "simulate" the memory level behaviour, you expected.
 

wehtam721

New member
Hi everyone,

I know that I'm backtracking a couple of months here but I've finally found the time to transfer all of my combination settings to the different banks of generals which are available in the built in Setter in GrandOrgue. The generals and banks are working great! It did bring up a few questions, however.

First, I've figured out that the next bank, previous bank, and bank label can be displayed as setter elements on the main panel using type "GeneralNext", "GeneralPrev", and "GeneralLabel". I did notice, however, that the element "GeneralNext" actually displays and functions as the previous bank button and vice-versa.

Second, I wanted to replace all of the ODF defined generals and divisionals in my ODF with the setter generals displayed on the main panel. I wrote the ODF, but when loading it I got a bunch of unused CMB errors and GrandOrgue eventually froze. I'm sure the errors are due to the fact that the ODF defined generals and divisionals are no longer there, but I'm not sure why GrandOrgue is crashing. As a workaround, I selected Preset 1 in the file menu of GrandOrgue instead of Preset 0. Now the exact same ODF, with no further modifications loads without errors and GrandOrgue doesn't freeze. I've tried re-exporting the .cmb files as well as erasing and recreating the cache, but this didn't do the trick. I'm not sure how to resolve this issue.

Both of these are minor issues, as everything is functioning perfectly. This is just what I've come across through my efforts. Any suggestions about how to deal with issue 2 would be welcome.

Take care,
Matt
 

scush

New member
Hi
At present this works in the odf, I have'nt tried banks though.


[SetterGeneral001]
NumberOfCouplers=0
NumberOfDivisionalCouplers=0
NumberOfStops=7
NumberOfTremulants=0
StopManual001=001
StopManual002=001
StopManual003=001
StopManual004=001
StopManual005=001
StopManual006=001

I just copy/pasted it from the cmb file.
 
Last edited:

wehtam721

New member
So, I've kept looking into this and it seems that the crash may have been caused by the sheer number of errors being generated (lots of unused lines in every single unused general/divisional). I could recreate the crash by importing settings from the old .cmb files even when using Preset 1. I solved this by just removing the lines of code related to the generals and divisionals in the .cmb files and now importing using the new .cmb files works as expected and doesn't return any errors at all.

I still can't load the organ under preset 0, however. It seems as though GrandOrgue has stored the cmb settings someplace and is trying to recall them. Is this true? Even an uninstall and reinstall didn't change this.

@scush
In my ODF I'm including the setter generals on the main panel by including them as setter elements with type general99. I believe this method of including them on the main panel is valid as the organ will load properly as long as it doesn't reference a cmb file which has the old generals and divisionals in it. Putting them in the odf as you have above seems like it would redefine the generals in addition to what already exists on the Setter panel whereas mine are just creating a main panel "link" of sorts to what is built into GO.

I have defined the setter generals on the main panel as follows:

[SetterElement043]
DispLabelText=So3
Type=General43
DisplayAsPiston=y
DispLabelColour=Black
DispLabelFontSize=Large
DispImageNum=1
DispButtonRow=100
DispButtonCol=3
DispKeyLabelOnLeft=Y

It's possible that I'm wrong or misunderstanding something, in which case please correct me. This definition seems to work, however. It doesn't kick back any errors at all and the organ loads properly under preset 1.
 
Last edited:

scush

New member
It seems the combination entries in the odf no longer matter once the organ has been saved , as this info is now read from the cmb file
 

wehtam721

New member
I agree that this seems to be the case generally, however it must also be coming from somewhere other than the user saved .cmb files as well. I can move the .cmb files that I've created to a different directory or delete them all together and I still experience the same error messages on Preset 0 as if it were still calling the old .cmb files. It seems as though pressing the save button may internalize these settings in some other place. In any case the behavior seems strange. If the errors were truly coming from the user created .cmb files then I would expect that changing the name of the file or moving it to a different directory would cause GrandOrgue not to find the file at all and load the organ using default settings in the odf, but this is not what seems to be happening.
 

wehtam721

New member
@scush
Thanks for the registry tip! I should have thought of that. It turns out that the problem wasn't in the registry values, but the registry did point me in the right direction to where GO was storing its copies of the cmb files. I deleted the necessary files and everything is back to normal. Thanks for the help! Issue two is taken care of.

Issue one (from my post above, number 5 in this thread), which really only matters to an odf developer, still remains. Seems that something may be backward in the source code. No big deal though as this still function fine as long as the odf writer is aware of the switch.
 
Last edited:

e9925248

New member
I did notice, however, that the element "GeneralNext" actually displays and functions as the previous bank button and vice-versa.

I'll commit the bug fix later.

Second, I wanted to replace all of the ODF defined generals and divisionals in my ODF with the setter generals displayed on the main panel. I wrote the ODF, but when loading it I got a bunch of unused CMB errors and GrandOrgue eventually froze. I'm sure the errors are due to the fact that the ODF defined generals and divisionals are no longer there, but I'm not sure why GrandOrgue is crashing. As a workaround, I selected Preset 1 in the file menu of GrandOrgue instead of Preset 0. Now the exact same ODF, with no further modifications loads without errors and GrandOrgue doesn't freeze. I've tried re-exporting the .cmb files as well as erasing and recreating the cache, but this didn't do the trick. I'm not sure how to resolve this issue.

Both of these are minor issues, as everything is functioning perfectly. This is just what I've come across through my efforts. Any suggestions about how to deal with issue 2 would be welcome.

The Log windows seem to have some O(N^2) code, which causes the freeze. I need to do further research.

PS:
The location of the GO data directories can also be seen in the GO settings dialog.

PPS:
The first bug is fixed in trunk. I hope, that the other changes improves the situation for the second problem.
 
Last edited:
Top