Yes, I know there was a long thread about this before, but it was locked. Martin's response at the time was:
Martin, I'd put it to you that the business case is more than healthy for a Linux version. It comes down to reliability and flexibility, especially in a professional context e.g. churches.
When the nasty little electronic organ at one of my local churches broke down, my dad, who was standing in for the organist, got chatting with the organ technician who was called round to repair it. My dad suggested replacing it with a Hauptwerk organ, as it already has a MIDI console and speaker system, and of course because my Dad is used to practicing on Hauptwerk at home with the machine I set up for him.. (We've been Hauptwerk users and customers since before it was Crumhorn Labs.. Must be almost 10 years now I think)
The technician's response was full of vitriol about Hauptwerk - It was something along the lines of:
So basically, it seems as if Hauptwerk has a bad reputation, at least amongst those of us who have to repair the organs but do not have the joy of playing them.
This is because both Windows and MacOS - the only currently-supported platforms for Hauptwerk - are NOT designed to run on embedded systems (which is what a dedicated organ console is). Users can play their games, browse the web, and pick up a plethora of viruses and malware, because underneath is a powerful general-purpose computer, designed for desktop use.
Then the second problem is that you have Windows Updates (and the same for Mac) which can completely break an embedded system where you have removed the mouse and keyboard in an attempt to address the first problem.
If Hauptwerk were on Linux, then you could disconnect the network (and it wouldn't eventually complain that it can't contact Microsoft/Apple to validate its license), script everything to your liking to integrate your hardware buttons with the OS, and even set the disk read-only (with writes cached in RAM) so that nothing bar a hardware failure can ever cause the organ to break down.
And as for Flexibility, you might be interested in my setup.
I am running Haputwerk (full) on Linux (sort of). The intention was to move the console away from the big, sometimes noisy server that does all of the processing.
I have a watercooled beast of a machine, with 128GB RAM, an overclocked 8-core i7-6900K running at 4.5GHz, 8x 500Gb/s SSDs in RAID6 and a GTX 1080 which I use for games. It's running Linux (Debian Sid). (yes there are games on Linux - have a look at Steam if you don't believe me. Plenty of other people have made the business case for Linux)
Partly because it doesn't make sense to have a second high-performance PC in the house, and also because such a machine would be noisy and take up space, I have embarked on a project to try and run Hauptwerk from my Linux machine.
This is rather convoluted, because as you know, Hauptwerk doesn't actually have a Linux version.
So I am running Hauptwerk in a Virtual Machine (cheat!! I hear you shout), and I am using two raspberry Pi computers for the two touch screens.
To transfer the screens and touch events, the raspberry Pis are running rdesktop to connect directly to my virtual machine, using the domain argument to specify which virtual screen to connect to (this is a feature of VirtualBox's built-in RDP server)
To transfer the USB for the MIDI console and HASP dongle, I am using a USB-over-IP program called VirtualHere which I highly recommend - it runs on most windows and Linux architectures, and is entirely self-contained. It "just works". All USB devices on the Pi can be accessed over the network from Windows (only one client at a time of course).
So all that remains is to send the audio out from the VM. This I am doing via a USB to TOSLink adapter which I have attached to the VM using VirtualBox's USB passthrough, and the ASIO4All interface layer on the Windows side.
Unfortunately this last part is the weakest link in the chain. While ASIO4All seems to make the sound less crackly, or less likely to be crackly, it is sometimes still crackly. I'm not sure what sets it off, but it's not polyphony. Sometimes I can play full organ on Salisbury Willis Volume 3, and sometimes just one pipe will crackle and pop like Rice Krispies.
I've narrowed this down to a bug somewhere between VirtualBox and Windows 10, and limiting the VM to one CPU core helps a lot, but once it has started crackling only a reboot of the VM will fix it.
IF Hauptwerk had a Linux version, then half of this nonsense could be avoided and I could use native PulseAudio, and X11 forwarding instead of rdesktop and the whole thing would be much more reliable. It also wouldn't eat gigs of my memory even when Hauptwerk isn't in use or is running a light organ.
But what I hope would be interesting to Martin Dyde and co, is that this kind of set up would be perfect for a big-ticket professional installation of Hauptwerk, e.g. in a big church or concert hall. (Perhaps without the raspberry Pi's of course. You could perhaps use this multii-monitor thin client instead.)
Personally, I'd be more than happy to pay extra, perhaps double for a Linux version of Hauptwerk. (the base software, not the sample sets). Or else, if you're worried about having another system to support, then you could offer it to all paying customers as a "beta test" trial, with no official support or guarantees.
There's always a way forward, despite your fears about development cost. And given that your software already works well on both Mac OS (which is UNIX-based, like Linux) and on Wine (with the exception of the HASP USB Dongle for the paid versions) I expect the process of porting your software to Linux should be a smooth one.
By the way: You mentioned the need for technical expertise to use Linux for audio/MIDI. Actually Linux has come a LONG way since you last used it. MIDI is standards-based and works out-of-the box with USB interfaces, even Wine supports it (which is why the free version of Hauptwerk works) and audio is a piece of cake with all distributions moving to PulseAudio, which is a lot like the new audio framework Microsoft introduced with Windows 7. And if porting to Linux was as much time/work/money as you say it is, then how on earth could all of those games developers that you see on the above Steam store page, ever justify building for Linux? The answer is Because it is nowhere near as hard as it used to be.
mdyde wrote:Hello notdefined and sonar11,
Sorry -- at this point in time we don't have plans for porting Hauptwerk to Linux.
We do of course appreciate that there are a few people who prefer to use Linux, and who do have the level of technical expertise to be able to set up and use it for audio/MIDI, but please understand that porting to any new platform, and then subsequently maintaining and supporting it, are very, very major undertakings (it most certainly isn't a trivial task of 'flipping a switch'!) -- it costs a lot of time/work/money, and we have finite resources available to us. We have to prioritise what can do within those resources.
Thanks for your understanding.
Martin, I'd put it to you that the business case is more than healthy for a Linux version. It comes down to reliability and flexibility, especially in a professional context e.g. churches.
When the nasty little electronic organ at one of my local churches broke down, my dad, who was standing in for the organist, got chatting with the organ technician who was called round to repair it. My dad suggested replacing it with a Hauptwerk organ, as it already has a MIDI console and speaker system, and of course because my Dad is used to practicing on Hauptwerk at home with the machine I set up for him.. (We've been Hauptwerk users and customers since before it was Crumhorn Labs.. Must be almost 10 years now I think)
The technician's response was full of vitriol about Hauptwerk - It was something along the lines of:
Hauptwerk??? Don't even get me started on Hauptwerk! Those things break all the time - completely unreliable. You might not know, but they use a PC inside - a Windows PC. When I'm called out to those it's always the PC that's broken down.. etc etc
So basically, it seems as if Hauptwerk has a bad reputation, at least amongst those of us who have to repair the organs but do not have the joy of playing them.
This is because both Windows and MacOS - the only currently-supported platforms for Hauptwerk - are NOT designed to run on embedded systems (which is what a dedicated organ console is). Users can play their games, browse the web, and pick up a plethora of viruses and malware, because underneath is a powerful general-purpose computer, designed for desktop use.
Then the second problem is that you have Windows Updates (and the same for Mac) which can completely break an embedded system where you have removed the mouse and keyboard in an attempt to address the first problem.
If Hauptwerk were on Linux, then you could disconnect the network (and it wouldn't eventually complain that it can't contact Microsoft/Apple to validate its license), script everything to your liking to integrate your hardware buttons with the OS, and even set the disk read-only (with writes cached in RAM) so that nothing bar a hardware failure can ever cause the organ to break down.
And as for Flexibility, you might be interested in my setup.
I am running Haputwerk (full) on Linux (sort of). The intention was to move the console away from the big, sometimes noisy server that does all of the processing.
I have a watercooled beast of a machine, with 128GB RAM, an overclocked 8-core i7-6900K running at 4.5GHz, 8x 500Gb/s SSDs in RAID6 and a GTX 1080 which I use for games. It's running Linux (Debian Sid). (yes there are games on Linux - have a look at Steam if you don't believe me. Plenty of other people have made the business case for Linux)
Partly because it doesn't make sense to have a second high-performance PC in the house, and also because such a machine would be noisy and take up space, I have embarked on a project to try and run Hauptwerk from my Linux machine.
This is rather convoluted, because as you know, Hauptwerk doesn't actually have a Linux version.
So I am running Hauptwerk in a Virtual Machine (cheat!! I hear you shout), and I am using two raspberry Pi computers for the two touch screens.
To transfer the screens and touch events, the raspberry Pis are running rdesktop to connect directly to my virtual machine, using the domain argument to specify which virtual screen to connect to (this is a feature of VirtualBox's built-in RDP server)
To transfer the USB for the MIDI console and HASP dongle, I am using a USB-over-IP program called VirtualHere which I highly recommend - it runs on most windows and Linux architectures, and is entirely self-contained. It "just works". All USB devices on the Pi can be accessed over the network from Windows (only one client at a time of course).
So all that remains is to send the audio out from the VM. This I am doing via a USB to TOSLink adapter which I have attached to the VM using VirtualBox's USB passthrough, and the ASIO4All interface layer on the Windows side.
Unfortunately this last part is the weakest link in the chain. While ASIO4All seems to make the sound less crackly, or less likely to be crackly, it is sometimes still crackly. I'm not sure what sets it off, but it's not polyphony. Sometimes I can play full organ on Salisbury Willis Volume 3, and sometimes just one pipe will crackle and pop like Rice Krispies.
I've narrowed this down to a bug somewhere between VirtualBox and Windows 10, and limiting the VM to one CPU core helps a lot, but once it has started crackling only a reboot of the VM will fix it.
IF Hauptwerk had a Linux version, then half of this nonsense could be avoided and I could use native PulseAudio, and X11 forwarding instead of rdesktop and the whole thing would be much more reliable. It also wouldn't eat gigs of my memory even when Hauptwerk isn't in use or is running a light organ.
But what I hope would be interesting to Martin Dyde and co, is that this kind of set up would be perfect for a big-ticket professional installation of Hauptwerk, e.g. in a big church or concert hall. (Perhaps without the raspberry Pi's of course. You could perhaps use this multii-monitor thin client instead.)
Personally, I'd be more than happy to pay extra, perhaps double for a Linux version of Hauptwerk. (the base software, not the sample sets). Or else, if you're worried about having another system to support, then you could offer it to all paying customers as a "beta test" trial, with no official support or guarantees.
There's always a way forward, despite your fears about development cost. And given that your software already works well on both Mac OS (which is UNIX-based, like Linux) and on Wine (with the exception of the HASP USB Dongle for the paid versions) I expect the process of porting your software to Linux should be a smooth one.
By the way: You mentioned the need for technical expertise to use Linux for audio/MIDI. Actually Linux has come a LONG way since you last used it. MIDI is standards-based and works out-of-the box with USB interfaces, even Wine supports it (which is why the free version of Hauptwerk works) and audio is a piece of cake with all distributions moving to PulseAudio, which is a lot like the new audio framework Microsoft introduced with Windows 7. And if porting to Linux was as much time/work/money as you say it is, then how on earth could all of those games developers that you see on the above Steam store page, ever justify building for Linux? The answer is Because it is nowhere near as hard as it used to be.