• 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

Screencasts about using GO

e9925248

New member
That's great, but my suggestion goes further than that (besides that it would be a much neater way to solve the problem). It's about creating logic from how a real organ works with its divisions on different windchests and also have another motivation to why different windchests should be modelled in the odf. Think about it, please!

The GO organ modell is more flexible.

Before introducing the multi-rank support, GO used organ->manual->stop->pipe listing in the organ dialog. The manual was a non-functional label to get a little bit of structure in the list.
With the multi-rank support, the stop was replaced with the rank. As there is no association between rank and manual and a plain rank list is not very user friendly, I needed something new. The only possible replacement was the default windchest of the rank.
GO allows to place indiviual pipes of a rank on different windchests - the rank windchest is just the default windchests, if no override is in effect.
Therefore the windchest was introduced as non-functional grouping.

Allowing to specifiy settings on windchest level can lead to strange behaviour: While pipe A inherits its settings from the default windchest, pipe B of the same rank can inherit its settings from a different windchest - but the user can't recognize this.

In my option we can only help the user by eg. translating a click on a windchest into the selections of all its ranks.
 

L.Palo

New member
GO allows to place indiviual pipes of a rank on different windchests - the rank windchest is just the default windchests, if no override is in effect.
Therefore the windchest was introduced as non-functional grouping.

Allowing to specifiy settings on windchest level can lead to strange behaviour: While pipe A inherits its settings from the default windchest, pipe B of the same rank can inherit its settings from a different windchest - but the user can't recognize this.

Yes, I agree that windchest is the proper parent of a rank. Any rank = a group of pipes with similar sound quality intended to be played together must still stand on some kind of windchest to be able to speak (or at least get its air from the windchest) - thus it will usually be physically located together somewhere in the organ. And yes it's possible to have multiple windchests for a manual and even divide different parts of a rank among them. For instance we have that case with Cavaille-Coll that usually had a bass windchest, a mid range windchest and a treble windchest (with different wind pressures) for certain divisions. (not to mention the anches windchests that would be pre registrated but not put under wind pressure until activated)

What should be done then is to not only list the default windchest for a rank but if certain parts of the ranks (pipes) are placed on another windchest they should also be listed there instead under their rank name, because it's there they are physically placed. Thus it's meaningful to be able to quickly route the audio output from that windchest in the same manner.

In my option we can only help the user by eg. translating a click on a windchest into the selections of all its ranks.

Here I don't agree. It's still dysfunctional because you cannot have different amplitude/gain and tuning info if you multi select entries! The solution I propose is to have the windchest as parent that could have an audio routing set that will propagate down it's children if not the user himself wants to override that behaviour on certain ranks/pipes. The realistic usage of that is when ranks/pipes are not really physically placed on the windchest but conducted out elsewhere (like in the facade).

Kind regards

Lars P
 

e9925248

New member
What should be done then is to not only list the default windchest for a rank but if certain parts of the ranks (pipes) are placed on another windchest they should also be listed there instead under their rank name, because it's there they are physically placed. Thus it's meaningful to be able to quickly route the audio output from that windchest in the same manner.

Then we will have the same rank two times in our tree with only one backing set of configuration settings.

Here I don't agree. It's still dysfunctional because you cannot have different amplitude/gain and tuning info if you multi select entries! The solution I propose is to have the windchest as parent that could have an audio routing set that will propagate down it's children if not the user himself wants to override that behaviour on certain ranks/pipes. The realistic usage of that is when ranks/pipes are not really physically placed on the windchest but conducted out elsewhere (like in the facade).
The multi select allows to override only specific settings, so you can eg. change the audio group without touching the the rest. If you want to change the volume: Amplitute and Gain are redundant and no ODF will probably use both - so one should be free for a volume change.
 

L.Palo

New member
Then we will have the same rank two times in our tree with only one backing set of configuration settings.

Yes, but if a single rank has pipes that really are on different windchests then they must have some way of differentiating (overriding) the settings, right? Also, if the rank is appearing twice in the tree it's still different pipes in each entry (otherwise they wouldn't be listed twice). As far as I know you cannot have the same pipe physically appearing on different windchests, right? It would surely defy the laws of nature... Actually, you could even argue that if pipes are on different windchests they are not really part of the same rank, but a stop that's composed of different ranks!

The multi select allows to override only specific settings, so you can eg. change the audio group without touching the the rest. If you want to change the volume: Amplitute and Gain are redundant and no ODF will probably use both - so one should be free for a volume change.

No, not on my system. If I try to multi select the stops on the great in Bureå sampleset all the settings and load options will be blanked out and if I change the audio group and try to apply it a dialog stating that amplitude is invalid (eg. blank) pops up. This is tested on ubuntu 12.04 32 bit, but it's clearly not a working solution at the moment. If we could have such a change that selecting a windchest would select all it's children but keep their individual settings until one of them is actually changed, then I could accept the simplistic solution even if I see logic problems with it. For the moment it's not working though.

The moment we wish to implement true appells acting on different windchests as they would in real life, or have other means of utilizing the windchests as sound affecting enteties (wind model etc.) then a clean solution must be found anyway that really link the pipes (of a rank) together with the windchest they are standing on. Therefore I'd like if we could in the modelling logic stay as close to real life as possible.

Kind regards

Lars P
 
Last edited:

e9925248

New member
No, not on my system. If I try to multi select the stops on the great in Bureå sampleset all the settings and load options will be blanked out and if I change the audio group and try to apply it a dialog stating that amplitude is invalid (eg. blank) pops up. This is tested on ubuntu 12.04 32 bit, but it's clearly not a working solution at the moment.

The error dialog is a bug, I fixed yesterday (r1171).
 

L.Palo

New member
Thank you, now multi selection and apply is working! If you also add the selection of all child elements if a windchest is clicked, then I'll be content to close this issue for now. Great work! I'll start making plans for a follow-up screencast of this feature and extended (more elaborate) multi channel audio output.

I must say that I'm impressed with how well the multi channel audio output works, I'm almoast tempted to try out all the 7.1 channels I can use on my soundcard. Easiest for me will be with 4 different stereo amplifyers/small speaker systems for now as my current speaker setup otherwise is insufficient. Thanks for lifting GrandOrgue to such a capable level!

Kind regards

Lars P
 
Last edited:

e9925248

New member
Maybe displaying the setter panel (with the elements, that you trigger via MIDI) would be helpful to some users.

Regarding the MIDIInputNumber: your statement about EnclosureNumber = MIDIInput Number is probably, what will work for most user and organs. The 100% correct statment would state: leftmost enclosure = 1, .. as GO does not enforce that the left most enclosure is [Enclosure001]
 

L.Palo

New member
Do you mean showing the setter panel in the initial MIDI screencast to make it clear what I'm pushing on my console? Or did you mean a new screencast only on the setter panel more in depth? I tried to explain in words what I was doing, also it's possible to see the combination numbers change in the toolbar.

No, of course the swell pedals can be positioned anywhere, but my point is for the most basic positioning coming from the built-in layout. Also, a good practise for an odf-creater would be to specify the leftmost enclosure first in the odf == [Enclosure001] regardless and keep the natural order of appearance, which is what I've tried to recommend in the help section.

Kind regards

Lars P
 

e9925248

New member
Do you mean showing the setter panel in the initial MIDI screencast to make it clear what I'm pushing on my console? Or did you mean a new screencast only on the setter panel more in depth? I tried to explain in words what I was doing, also it's possible to see the combination numbers change in the toolbar.

While a screencast about the setter is probably also interessting for some people, I just meant to open the setter panel as further illustration. The combination number in the toolbar is a little bit small.
 

L.Palo

New member
Here comes another screencast about different ways of using reverb with GrandOrgue. I show both the built-in convolution reverb and my favourite way of using external reverb with Jack and multi-chanel audio. Watch it on http://youtu.be/h-GiUgWNGf8 if you think it's interesting.

Kind regards

Lars P
 

e9925248

New member
You declared one time, that IR is something different than a impulse response. Otherwise, I didn't spot any errors.
 

L.Palo

New member
Ha! Yes, at 2.45 I say Impulse reverb file... It's of course impulse response. Well, I think it's ok enough as it is. I don't have any script for doing the screencasts so it can very well happen that I slip with my tounge sometimes. :)

Kind regards

Lars P
 

L.Palo

New member
I tried to explain it in the screencast. I use the rear speaker pair for only the reverb output from zita-rev1. The other channels are used for different divisions in GO and they all connect to the inputs of zita. Thus I have direct sound from front, side, center and sub and reverb sound (only) from the rear speakers.

Kind regards

Lars P
 

oleg68

New member
Lars, I've understood it. I use the rear speakers in the same manner (I do not have sub, center and side yet).

My question is about what zita-rev1 settings do you have (Delay, Low and Mid RT60, Xover, HF Damping, EQ1, EQ2)?

I've set delay = 100ms, Low and Mid RT60 = 8s, Output Mix = Wet, all other knobs - by default. When I switch the front speakers off, the organ sounds like romantic one.

And I use zita-rev1 LADSPA-plugin instead of zita-rev1 application because zita-rev1 can not store its settings persistently.
 

L.Palo

New member
Oh, sorry. My main reason for using zita-rev1 is that I can change the settings according to organ and what room I feel that I want to play in both easily, quickly, without restarting sound or having to dig in the menus so much. For really high quality reverb I still fall back to using jconvolver with classic text config files from the command line but I thought that showing an easier path to getting a good sound in the screencast was more user friendly... Sometimes I do use the built-in reverb too though.

The only thing I have constant in zita-rev1 is the output mix completely to wet, all other settings I tend to fine tune for different organs. I usually don't play with so much reverb for long times though but usually stay with Low and Mid RT60 around 4 - 5 seconds give or take a little.

Kind regards

Lars P
 
Top