Beiträge von oleg68

Zitat von martin

The manual config is easy: Organs just feature one pedal and 1 - 3 (or 4,5 less likely) manuals. Same for enclosures.
...
ODF and settings are district for reason:
ODF is a stable file format, which theoretically could be implemented by any program.
The settings are a dump of the GO internal state and may change in any way, as the GO internals change.

So storing the audio distribution rules in a separate file (or in $HOME/GrandOrgueConfig in the [OrganXXX] section) would be the simplest solution.

Zitat von martin

* According to your posts, you will probable have a "audio group without reverb", a "audio group with rear reverb", a "audio group with full reverb" [or even more].
* A stereo user will just have one audio group.
* Another user will have a front and a rear audio group.
* The example in our help includes a rear, front, "front (soft)", left and right audio groups.

So what audio group names should a ODF creator specify in the ODF?

Three audio groups would be enough in most cases: "default", "front" and "rear".

One extra group may be useful for for composite sample sets only: "dry", that requires external reveberation.

Zitat von martin

In regard to storing audio groups in the ODF:
Any proposal must be universal - it should work from a simple stereo setup to a giantic multi-channel setup. Simply allowing to store random strings will not ensure that.

The same approach was used for attaching manuals to midi devices: you have introduced the MIDIInputNumber value. Each setup has own quantities of midi keyboards, but MIDIInputNumber allows to match ODF settings with certain hardware.
Storing the preferred audio groups for stops/ranks would bring the same capability.

If you are talking about the universal solution, another approach would be
1. Make the single flat scope of parameters for ODF and setting files. All parameters must be the same
2. The settings in the setting file override ones in ODF
3. Store only the overriding values in the setting file. All absent values should be inherited from ODF

This solution would be the most universal. This would dramatically improve the merging capability of changed ODF with the old setting file. But I understand that this approach would be more convenient for IT specialists than for organists. Most of organists would prefer that you decide for them, which setting they should or shouldn't change.

Zitat von martin

From the GO perspective, use less larger buffers. 2-3 buffers of 128 should provide an equal GO latency as 5 buffers of 64 with a lower CPU usage.

I've already tested this. 5*64 is more stable and brings less xrun's than 3*128.

I use 5*64*96000 only for headphones. I use 5*64*48000 for loud speakers, because the intel hda hdmi sound chip embeded in the nvidia videocard works unstable at 96000 with small buffers. Of course, the AV receiver brings additional latency - about 20ms.

Another my suggestion is to separate rank-to-audio channel distribution and midi settings from another organ settings.

I often change my organ definition file. Mostly I change pitch tuning or a volume of some pipes, but sometimes I replace stops with another or redistribute them between manuals. Because merging of modified odf with the old organ setting file brings unpredictable results, I always delete the organ setting file each time the ODF is changed. But I always loss the distribution of stops among audio groups. Because the quantity of stops is big and the distribution rules are coplex, it takes a lot of my time. I'd prefer to have capability not to loss the stop distribution after changing odf.

One possible solution would be to store sound distribution setting separatelly from another organ settings. Another possible solution - to have preffered audio group names for ranks in odf and match them with existing audio groups.

Zitat von martin

Could you please explain this in detail?

https://sourceforge.net/p/ourorgan/feature-requests/52/

Zitat von martin

GO binaries can directly connect to the Jack Server - what kind of jack modules do you need to load?

My multichannel setup is quite complex. It has two front speakers, one subwoofer and two back speakers. I use

Because I use a composite set from different organs with different reverb time: both dry and wet, I need to make some additional software reverb for dry stops only. I use another software reverb for back speakers for stops that are stereo-only (without back channels recorded). I need a low pass filter for subwoofer and a high pass filter for back speakers (otherwise my AV receiver raises a protection and switches off when I play bass voice). I use four instances of Jack Rack. with Zita Reverb, stereo amp and simple filter plugins and a complex distribution of ranks among jackrack modules.

If a stop is wet and 4-channel, its front channels are connected to the front speakers directly and its back channels - to the JackRack with the high pass filter for the back speakers.
If a stop is wet and 2-channel, I connect it to the front speakers directly and to the JackRack-Reverb for back speakers.
If a stop is dry and 2-channel, I connect it to two JackRack-Reverb instances - one for front and another for back (they are have different parameters). And all stops are connected to Jack-Rack-Low Pass Filter for the subwoofer.

So the PS & RTA approach that GO connects to only one soundcard or program is not suitable for me. No I connect GO to some 8-input-port jack fictive client and then didtribute each GO output port to several outputs with Jack Patchbay. This jack stacks bacame complex and using a fictive jack client adds more complexity. If GO could only expose jack output ports without connecting them byself, I wouldn't need to use the fictive client.

Zitat von martin

RtAudio Jack is a dumb wrapper around the jack libraries - what kind of the RtAudio code introduces further latency?
Portaudio Jack support reblocking. Based on the desired latency and the GO + jack samples per buffer, it adds some buffering - this also provides more stable audio output.

PS: If you want to reduce latency, reduce the GO Sample per Buffer setting.

I use 64 samples per buffer with 5 jack buffers at 96000 hz for m-audio delta (headphones) and at 48000 hz for HDMI output. If I se up less samples per buffer or increase freq, the sound distortion appear: the power of my i7-2600K 4.8Hhz bacomes not sufficient for handling this. Eliminating some jack clients would reduce the amount of work for my CPU and would allow me to set less samples per buffer without sound distortion.

Zitat

Which sample sets do you use with GrandOrgue?
Which sample sets do you miss for GrandOrgue?
Are you satisfied with GrandOrgue?
Do you have some suggestions to integrate in GrandOrgue for the future?

1. I use a composite sample set made by one from a doozen of another free sample sets III/P/80. It takes 24 Gb of RAM. Loading this sampleset takes about 1 minute from RAID0 2*SSD.
2. I always enchance my sampleset with new interests free stops. I often replace my old stops with new ones that sound better. Sometimes I enchance tuning of my stops.
3. Yes, I do
4. I'd like to have native jack support (without PortAudio or RTAudio). It would require loading less jack modules and it would decrease latency.

Zitat von mike

• Where did you first hear about GrandOrgue?
• When did you hear about GrandOrgue?
• Do you use GrandOrgue as your only virtual organ?
• What is the kind of your hardware using with GrandOrgue (Computer, Keyboards, e.g.) ?
• Which sample sets do you use with GrandOrgue?
• Which sample sets do you miss for GrandOrgue?
• Are you satisfied with GrandOrgue?
• Do you have some suggestions to integrate in GrandOrgue for the future?

1. Somewhere in internet. I do not remember exactly
2. About 4 years ago
3. Yes, I do.
4. I use a gametable with three manual keyboards an a pedalboard. Each one is connected directly throught USB.
I use a desktop computer (i7 2600K overcklocked to 4.8 GHz, 32 Gb RAM, SSD RAID0 2*128 Gb, HDD RAID1 2*2 Tb).
There are two seats connected with the computer: the first one has a monitor, a keyboard, a mouse and an USB Hub). The second one has a game table, two monitors, a keyboard and a mouse. There are two Nvidia videocards for handling two separate seats. There are no touchscreens.
There are two audio interfaces used with GO: MAudio Delta 1010 lt - for headphones, and HDMI output on a videocard for multi-channel sound speakears (through a AV Receiver). MAudio Delta provide less latency than nvidia hdmi output
The computer is powered with Linux (Fedora 23). I always use the latest versions of OS and GO.