• 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 and reverb

wehtam721

New member
Good evening everyone,

I've been using the latest Windows build for that past few days and have noticed the following things about it by comparison to revision 1185.

1) Regarding reverb, it seems (at least to my ears) that the transition between the wav file and the reverb is not as smooth as it was in rev. 1185. I seems like the reverb might be quieter so it's easier to hear the ends of the wav files and it doesn't blend together quite like it did. In revision 1185, I could set the releases to 175ms in GO and it blended just fine with the reverb. Now I can hear a difference. I don't know if anyone else is having the same experience.

2) It seems that there's a bug (in the Windows build at least) which is effecting the ability to read .cmb files. If I use the import settings command everything works as expected. If, however, I select import combinations, I receive an error stating that Divisional001 is missing the line "NumberofStops=". I have opened the .cmb files in an editor and the number of stops lines are present so, unless I'm missing something obvious, this seems to be a bug. Again, I don't know if anyone else is having the same issue.

All my best,
Matt
 

e9925248

New member
wehtam721 said:
2) It seems that there's a bug (in the Windows build at least) which is effecting the ability to read .cmb files. If I use the import settings command everything works as expected. If, however, I select import combinations, I receive an error stating that Divisional001 is missing the line "NumberofStops=". I have opened the .cmb files in an editor and the number of stops lines are present so, unless I'm missing something obvious, this seems to be a bug. Again, I don't know if anyone else is having the same issue.
Click to expand...
Bug confirmed. I need some time to test the fix.
 
Last edited:

wehtam721

New member
I have downloaded the build given in the links above (rev. 1225) and can confirm that the issue with importing combinations seems to be fixed. The ODF parser, however, is now showing that every stop, coupler, and tremulant entry for every ODF defined general/divisional is invalid ("Invalid combination entry CouplerNumber001 in General001" for example). There's also a whole bunch of "Unused CMB entry" warnings. None of these warnings/errors were present when using the previous build. If this is something I can fix on my end, how would I take care of this? At least for the Generals/Divisonals I was under the impression that they were correctly done. If this is a result of the work on getting the combination files to import, perhaps the fix to the import problem has caused some other troubles.

I'm not sure what information would be most helpful for you so if you'd like more details just let me know what you need and I'll provide it. As always, thanks for all of your continued work on GrandOrgue! The improvements that have been made even in the small amount of time that I've been using the software and following the project have been astounding!

Take care,
Matt
 

e9925248

New member
wehtam721 said:
The ODF parser, however, is now showing that every stop, coupler, and tremulant entry for every ODF defined general/divisional is invalid ("Invalid combination entry CouplerNumber001 in General001" for example). There's also a whole bunch of "Unused CMB entry" warnings.
Click to expand...
Should be fixed in trunk.
 

scush

New member
Confirmed, rev1225 showed me that this is the correct way to implement a general


[SetterElement005]
Type=General01
DisplayAsPiston=y
DispLabelColour=Black
DispLabelFontSize=Large
DispImageNum=1
DispButtonRow=100
DispButtonCol=1
DispKeyLabelOnLeft=Y
 

wehtam721

New member
I was under the impression that the implementation shown above is for displaying a general from the setter panels on the main panel of the organ but not necessarily for defining generals and divisionals via ODF.
 

e9925248

New member
wehtam721 said:
I was under the impression that the implementation shown above is for displaying a general from the setter panels on the main panel of the organ but not necessarily for defining generals and divisionals via ODF.
Click to expand...

This statement is correct.

Besides generals from the setter, an ODF can also contains [General999] sections. This can also contain a predefined, initial content and can be set write protected (= fixed combination).
 

scush

New member
Hi
Many organs I have seen using [general999], and not protected
Have all their content set to off, there seems no point in this.
when the setter method is used button 1 on the organ is button 1 on the setter.
Leading to less confusion.
 

L.Palo

New member
Hi!

The reason for "empty" divisionals/generals in odfs that's also not write protected was simply because one had to do it like that to enable the user to configure them at will, really to have them present at all. This is not a fault, it's a feature. Remember that this was before the current "global" panel generals and divisionals were implemented.

There are however still resons for keeping the old .odf way of defining divisionals and generals. It depends on the pre-defined activation method assumed for them according to the old spec. The divisionals react to program change messages on that channel that the manual/pedal in question is using, the generals respond to program change messages on any channel. (One could see the old system "feature" as a severe limitation also, but nowadays it's possible to connect any button to almoast any MIDI signal in an easy way if so desired). Some specific consoles might be setup to work in that way, and thus conforming to the old standard when creating odf divisionals/generals will minimize the amount of customizing neccessary to use a sample set on them.

However, I do agree that the new panel versions of divisionals/generals etc is a truly wonderful feature that makes it possible for a user to customize a sampleset in almoast any way he wants no matter what the sampleset producer had in mind.

Kind regards

Lars P
 

scush

New member
Hi

Speaking of the (not so old days) I was trying out reversible pistons with GOv1.
And found that they respond to program change messages on the same channel as the pedals.
By default GOv1 set this to channel 2, left at this they only respond to this channel.
However if the pedals are set to channel 1, they will respond to any channel.
I thought it worth a mention.
 

L.Palo

New member
Interesting! I've not been able to really play with GO for a while since I'm re-building/-designing my (physical) virtual organ console again.

However, you should be able to test if the old divisional/general channel feature works as it should by loading a vanilla version of Piteå MHS sampleset (ie. no customizing has been done) and set something into the divisionals. Then try sending program change messages (1 to 6) for the respective channels and then the pedal divisionals should respond to the same channel as actually is used to play the pedals (1), the great on channel 2 and so on. There are also ten generals (to the left above the pedal) that should respond to program change messages 11 to 20 on any channel.

Kind regards

Lars P
 

scush

New member
At present I don't have any buttons, just a stop rail on ch5 note on.
But i'm pretty sure pitea would work fine in the way you suggest.
Do you think it's time to have different odf's for GO3 and older versions
 

wehtam721

New member
I see on SourceForge that there's a new windows build (rev.1226) for 32 bit systems. Is there a 64 bit build in the works or posted someplace else?
 

e9925248

New member
L.Palo said:
The reason for "empty" divisionals/generals in odfs that's also not write protected was simply because one had to do it like that to enable the user to configure them at will, really to have them present at all. This is not a fault, it's a feature. Remember that this was before the current "global" panel generals and divisionals were implemented.
Click to expand...

Write protected is a newer GO 0.3 feature. The all off content also specifies a preprogrammed scope for the scoped mode.

The ODF creator has full control over [general999], while for general from the setter, the ODF contains only a link to predefined objects.
 

wehtam721

New member
After having downloaded and installed rev. 1226 tonight, everything seems to be taken care of. I still got a few warnings about unused lines in the CMB files, but I re-saved the .cmb files overwriting the previous ones and that solved the problem. GO is not showing any errors now when loading the sample set.

Also, I'll retract my previous statement about the blending between the samples and the reverb. I'm not sure what might have been causing the issue, but it seems to have gone away, so I'm a happy camper. Perhaps the audio just needed to be reset.

Thanks for all the work that went into making these fixes and builds. It is always appreciated!

Take care,
Matt
 

e9925248

New member
wehtam721 said:
Also, I'll retract my previous statement about the blending between the samples and the reverb. I'm not sure what might have been causing the issue, but it seems to have gone away, so I'm a happy camper. Perhaps the audio just needed to be reset.
Click to expand...
There are differences in the reverb between trunk and my build - the patch I mentioned above.
 

wehtam721

New member
Ahh, I understand now. That makes sense. I had originally assumed that the patch was incorporated into the previous build. Thanks again!
 
You must log in or register to reply here.
Top