Topic: Feature Request
Please add the following independent stops:
Flute at 2ft
Mutations at 17 and 19:
Tierce 1. 3/5'
L'arigot 1. 1/3'
Please also add an Tremulant (freely selectable for any stop or group of stops.
Please add the following independent stops:
Flute at 2ft
Mutations at 17 and 19:
Tierce 1. 3/5'
L'arigot 1. 1/3'
Please also add an Tremulant (freely selectable for any stop or group of stops.
I am waiting for these addition of stops as well! Please consider adding!
Some fantasies to extend Organteq beyond to the current 10 stops per manual/pedal.
Currently, Organteq has 40 stop positions that can be filled in by the user from a palette of 20 voices. That makes it a very versatile instrument, suited for a variety of music under study. One might want for instance on the recit a voix humaine in one piece, which can be traded in for a bourdon 16' in another. The 1000 step sequencer is a luxery. To be honest, the clear and direct sound as heard on the console, the small delay, and the adaptable acoustics makes Organteq my preferred study-instrument, next to my old and reliable analog 13 stops Heyligers.
A powerfull processor is preferred. Tutti with mixtures on all manuals requires an 8-core processor, and even with that it looks like approaching the limits. Loading my fxp registration files into my friend's system was definitely overloading his quadcore computer. Of course, the number of active stops can be reduced without too much changing the sound. But, if having only a limited processor, how can one compare the full sound to the reduced version?
We could wait for Modartt to come up with a newer version. Or, suggest them to take a mixed approach to reduce the processor load: pre-calculate and record an Organteq stop as if it were an actual organ, key per key. And build and integrate a sampled stop with that. A computer audio system does not know whether its data are prerecorded or generated on the spot. And then make a very carefull decision about which stops should be calculated real time and which could eventually be prerecorded. In fact, one then trades processor power for memory; but the latter can often be added to a PC and is relatively cheap compared to a new processor and motherboard.
Also, a calculated 32' subbas or other pitched stops could be obtained, be it with limited quality due to interpolation. Or a recit with many more stops, as is often the case on a real Caviallé-Coll.
As indicated by the title: it is a wild fantasy that may sound like a heretic preaching in the church. The main concern should be to maintain the clear sound and accurate reaction Organteq currently provides. In an alternative approach, I should perhaps save some money for a future 16 core. But in case Modartt looks for beta-testers of the mixed approach: I know at least two of them, with different computers.
Some fantasies to extend Organteq beyond to the current 10 stops per manual/pedal
... take a mixed approach to reduce the processor load: pre-calculate and record an Organteq stop as if it were an actual organ, key per key. And build and integrate a sampled stop with that. A computer audio system does not know whether its data are prerecorded or generated on the spot.
What an interesting idea. Especially if a user could choose one or several stops or voices, then--with a click of a user-interface button--ask Organteq to pre-calculate and generate in static audio form (like a recorded sample) the single or combined sound of the chosen voice(s) or stop(s) and save that sample set as a custom voice, a static "sample" for each note of (for example) the 61 keys of a standard organ keyboard. Of course, transposition on-the-fly would probably not be possible or limited, but as you mention, utilizing available RAM (or adding more RAM), rather than demanding more of the CPU, could be an effective strategy for maximizing the use of one's computer hardware resources.
...suggest them to take a mixed approach to reduce the processor load: pre-calculate and record an Organteq stop as if it were an actual organ, key per key. And build and integrate a sampled stop with that.
I 2nd this idea enthusiastically.
I was going to suggest pretty much the same thing to Modartt, but since I'm not yet a customer I wasn't sure if it would carry much weight.
I've tried the trial version on the fastest machine I have on hand to dedicate to my organ project, but it had audio break-up problems with anything more than 50% stop load and simple chords.
My suggestion would also have been to allow for the user to specify how many variations to "pre-sample" for a given stop, as one of the advantages of physical modeling is that the same note can sound subtly different with each new play. But having, say, 8 varied samples of each note on a given stop (memory permitting) would give a lot of that feel of natural variation without burdening the CPU.
If that's just too much of an architectural hurdle to be worth Modartt's time, I separately suggest that they publish a list of off-the-shelf machines from name brand vendors (Dell, Apple, etc.) that would run Organteq at full organ in realtime without problems. I know that's also a big ask, as machine specs change all the time.
Perhaps a program to certify 3rd-party companies to sell pre-built PCs that will reliably run Organteq?
In my own case I'm looking for something to replace two Ahlborn Archive units in an instrument I built back in 2002. (Can't believe its been 18 years already!).
Back to the original suggestion... I pledge that if Modartt adds pre-sample functionality that will run on a broad variety of machines, I'll buy Organteq instantly.
If that's just too much of an architectural hurdle to be worth Modartt's time, I separately suggest that they publish a list of off-the-shelf machines from name brand vendors (Dell, Apple, etc.) that would run Organteq at full organ in realtime without problems. I know that's also a big ask, as machine specs change all the time.
Perhaps a program to certify 3rd-party companies to sell pre-built PCs that will reliably run Organteq?
I have just purchased Organteq, after a few weeks fiddling under the bonnet of the trial version, so I may not have reached the limitations of my current installation. It is installed on a five year old Lenovo ThinkCentre M73 with an Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 4 cores processor and 8 Gb of Ram. The operating system is Debian 9 with a Linux 4.9.0-14-rt-amd64 on x86_64 kernel. So it is basically a relatively old, under-powered desktop computer with an operating system that I should get round to upgrading, when I have a spare few hours.
According to the specifications provided by Modartt, I should theoretically be barely able to run Organteq, and if I could get it to run then I should be getting absolutely woeful performance with annoying audio breakups. However, this is not the case.
Admittedly, I did upgrade my kernel to the RealTime version, which did resolve a number of issues with XRUNS ie there were far to many of them with the normal kernel and unless I had Frames/Period setting of over 1028 and a Latency above 50 msecs, any performance was ruined by constant loud screeched/clicks as my system ran over another XRUN. With the RealTime kernel operational, I can run Organteq with a Frames/Period of 256 and a Latency of less than 11 msecs, and have no XRUNS, apart from when I am doing something complex on another program or waking the computer up after it has gone to sleep and I have to call stuff back out of memory.
In terms of performance, Organteq, in a resting state runs with less than i% CPU usage and about 2% of Ram memory. Of course, starting the program does consume a massive amount of CPU, but as it starts up in less than 3 secs, which professionally I would use as a performance touchstone, this is not an issue. When loading another preset, or a new FXP file, Organteq may reach 50% CPU for a few seconds, but I am limited by the granularity of my monitoring applications, so I can't be more detailed
As a stress test of Organteq, I have been playing a 6 stave midi recording of a Bach Chorale on a Four Keyboards setting, with the 6 staves assigned across the three console and the pedal midi channels. With four stops pulled on each of the consoles and the pedals, and everything playing at once, I have 10% CPU usage and 5% RAM usage, which to be honest is less than normal usage on an Internet Browser. If I then pull out Plein Jeu III and V and the Cornet each on a different console, I barely touch 20% CPU usage and 5% Ram usage, so in other words I an still using less than one of my Quad Cores, and have capacity to spare.
I have gone into some detail purely to point out that even on my ageing, underpowered computer system with an operating system that needs updating, Organteq is still lean, mean and efficient, and after a minor bit of tweaking, I have no problems with it so far, touch wood. I certainly can't use Organteq to justify buying a new computer for my music, which is a mixed blessing I suppose.
One of the problems that I had with using sampled VPOs was the amount of time it took to load the pipe organ into memory and, unless I was playing one of the simpler sampled sets, my system didn't have enough memory to load the more complex organs. I realise that memory is cheap, but it still takes time to load data into it and I don't want to start utilising SWAP memory simply to hold a VPO.
I doubt, therefore, whether I would utilise the ability to pre-calculate and record an Organteq stop or stops. since the resulting data will have to be loaded into memory and then accessed as required, which will make the application flabby and less responsive. At the moment, for my system, the on-the-fly calculation of each note with multiple stops and consoles is barely taxing my I5 Quad core processor, so why would I require on-demand sampling.
Perhaps, the answer lies, as it always does, in improving the documentation available to the Organteq community, specifically in the area of system configuration and optimisation, so as to tune the system the Organteq application is running on for optimum performance. I know that I spent a couple of weeks under the bonnet, muttering to myself and running down various rabbit holes chasing the meaning of a passing comment in yet another Blog, before I got the tuning done, and I have some decades of experience in system tuning. If Linux kernel configuration is an arcane art, then Linux Audio configuration must require a couple of contracts signed in blood.
From past experience, it may be easier and faster to re-design and re-write the application than it would be to produce decent. detailed documentation that would allow users to improve their performance. I would prefer more detailed documentation to honest rather than to muddy the design concept.
Michael