tmyoung wrote:My understanding is yes and it's one of the next major features they're working to add. According to previous posts from the devs, there were some implementational issues and overhead issues with voicing and micro-tuning that prevented those features being available at launch.
That would be very exciting -- if/when that happens OTQ will go straight to the top of my wish-list...
+1 on the tuning. Pianoteq's tuning system is pretty epic (and actually follows the SCALA standard correctly!!!).
Other requests:
- hammond b3! Jeez so much easier to model this circuit than freakin chiff chaos.....
- the ability to automate the tuning of each pipe (to ANY frequency, not +- 50c...)
- automation in general.
My understanding is yes and it's one of the next major features they're working to add. According to previous posts from the devs, there were some implementational issues and overhead issues with voicing and micro-tuning that prevented those features being available at launch.
That would be very exciting -- if/when that happens OTQ will go straight to the top of my wish-list...
]]>Are there plans to add the same tuning support as in Pianoteq? I was really surprised to download the demo and find this element missing.
My understanding is yes and it's one of the next major features they're working to add. According to previous posts from the devs, there were some implementational issues and overhead issues with voicing and micro-tuning that prevented those features being available at launch.
As a side note, I've wondered about a solution that temporarily "bakes" some pipes/ranks into RAM as samples to reduce processor overhead with larger registrations.
Isn’t it an option to use the multiprocessor features (256 cores or even more) of modern graphics cards? That might even allow per pipe voicing, given the speed of modern data buses.
I'm not sure that GPU acceleration will be coming soon to either PTQ or OTQ because of cross-OS and cross-brand issues (CPU instructions are fairly universal whereas GPU instructions aren't nearly as standardized, and I don't know if the float precision of consumer-grade GPUs could create audio artefacts that a CPU wouldn't), but I'd love to see GPU support!
]]>Other items might include
- Asio is still advised for the audiodriver, but doesn’t WSAPI in Windows10 take its place? I have to admit that I did not yet see many manufacturers of audio interfaces providing other than Asio drivers.
- The processor has to work hard, with a maximum of 1000 pipes sounding for a quad core. Isn’t it an option to use the multiprocessor features (256 cores or even more) of modern graphics cards? That might even allow per pipe voicing, given the speed of modern data busses.
Bass coupler! But only the lowest note would be send to pedal!
This feature is provided by in Hauptwerk and Grand Orgue and not having it it's deal breaker for me.
I would think that wouldn't be too hard to program. Hopefully it will be added soon!
]]>Both are probably correct. See http://www.organstops.org/n/Nasard.html
Yes, I see Nasard more commonly while around German and some French organs (and I support the German "Nase" etymology theory because it's how I feel about the pipe sound in bad registrations), while I've only ever seen it spelled Nazard in the States. They should be interchangeable in essential function and sound, but they might not be exactly identical between one organ design/tradition or another.
I know on the 1903 Église Notre-Dame-de-l'Assomption de Metz Cavaille-Coll, it's spelled Nazard and on the 1902 Église Saint-Eucaire Cavaille-Coll (also in Metz), it's spelled Nasard. So either that means Charles Mutin (who oversaw organ building at Cavaille-Coll after 1900) wanted the 1903 organ to show that it was being renovated and still used Baroque pipes or design on the stop (and showed that with a different spelling as the 1902 organ was completely new), the new pipes were designed or tuned slightly differently than were used on the 1902 organ (which is very possible with fifths depending on how you want them to balance), or he couldn't keep his own spelling consistent on two organs in the same city built with a two year period.
]]>This feature is provided by in Hauptwerk and Grand Orgue and not having it it's deal breaker for me.
]]>Hello
Maybe I'm wrong but it seems that the correct spelling for "Nasard" is "Nazard"
Both are probably correct. See http://www.organstops.org/n/Nasard.html
]]>I use a Launchpad Mini to control features of Hauptwerk - which is able to toggle the lights on the touchpad on and off in response to button presses (this is done by sending MIDI messages to the Launchpad).
Launchpads work well with Organteq but - of course - the lights don't toggle. Might extend the reach of Organteq a bit if you could make it work with such hardware.
I am building an TouchOSC design for the organ, but this sits on a device (eg a tablet) that by design does not tend to stay lit for long periods, or it you force it to do so, will go flat unless plugged into a power-supply or computer and is also somewhat less robust than a launchpad or similar MIDI controller. You also need to install bridging software to get the MIDI messages through to Organteq, so not quite so convenient to use either.
Just a thought, anyway!
]]>organi wrote:16. A melody and bass coupler would be nice if I only had one manual available.
This is already possible, couplers are fully adjustable.
EvilDragon can you explain where?
In demo version you can only couple all Pedal notes to the manual. But is should be only the bottom note.
Melody is optional but Bass coupler is a must.
Since at least in my case I would use Organteq when I need to play on remote locations. I really don't want to carry pedalboard with me.
In any case Coupling all notes from pedal to any of manuals is unusable.
]]>And yes, that would be very nice, particularly if we could further "localize" the console layout and text based on German Baroque, American Symphonic or Theatre, and English Symphonic organ consoles in addition to the terraced French layout we currently have.
]]>