Historically for these abandoned devices, I'd just use MIDI for communicating with it; since MIDI hasn't changed in decades, it all continues to work just fine (in Windows and Linux). But, it's certainly convenient to just plugin the synth itself via USB and have it all Just Work.
But, yeah, to speak to your point: There are mountains of old software (and hardware!) that won't work on Windows anymore, but will run fine on Linux with Wine. That's pretty amazing to me. I couldn't believe how smooth it all was; I remember spelunking docs for hours to figure out how to make things work. Now, I just run the installer (or just run "wine app.exe") and there it is. I'm sure there are exceptions, but damned if I'm not still impressed.
I rarely consider any program important enough to reboot to use it, since I'm most comfortable and productive in Linux, and Wine becoming so good over the past few years makes it even less of an issue. I still keep a Windows partition on my laptop, Just In Case, but I haven't needed it in months.
Have you found that a linux machine has noticable latency when playing/recording music and applying filters?
I don't notice the latency, but I also haven't measured it, and I just do it as a hobby, so spending some of my time tinkering with quirky stuff is fine (though it's not really that quirky anymore...tons of stuff Just Works).
If it were my job, I would probably consider a mac. It's not; my job is software, where Linux is the clear winner. But, I don't think it's nearly as clear as it used to be that Linux isn't suitable for pro audio work. I think a reasonable person might give it a try, whereas five (or ten, or twenty, which is when I first started poking at audio on Linux) years ago it would have been madness to try to do real audio work on Linux.
Nevermind the lower latency, it does feel way better to use. It's like using a different operating system, one that's actually a decent desktop OS.
I just use whatever RT features are shipping with current Fedora, and it works well enough for me. I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.)
The same sort of opt-in as in mainline. SCHED_FIFO or SCHED_RR. Yes, it makes a difference even without opting in.
By all means. Arch makes trying linux-rt very easy. Try rt-tests on Linux and on Linux-rt. See the examples at: https://wiki.archlinux.org/index.php/Realtime_kernel
I get spikes beyond a ms within minutes on mainline, on all my hardware.
In practice, without even setting SCHED_FIFO or SCHED_RR, I can play sfc(snes) games on higan on linux-rt. This is not possible on mainline, not even with SCHED_FIFO, as even with higher audio buffer sizes, it cuts constantly. Same with audio work with jackd and low latency buffer sizes.
>I just use whatever RT features are shipping with current Fedora, and it works well enough for me.
No such luck for me, and I've even tried ck's patchset and such. It barely provides any improvement. Yet linux-rt is radically better.
And, while unrelated, even the usual disk i/o stalls that plague Linux (on any hardware, using any common distro standard kernel) haven't happened at all to me on linux-rt. It's as if using an entirely different OS. It feels responsive.
>I don't miss patching a kernel every couple of weeks as was required back in the bad old days of doing audio on Linux. (Though CCRMA made it easier with their package repository, so it hasn't really required a completely DIY process for many years.)
Me neither, as AUR makes linux-rt very convenient.
The only problem I encountered with Reaper under Wine is that it needs a lot of time to buffer a very big audio track when it's being added to a project. Say I record my band on our portable recorder then I drag and drop the big sample (2-3 hours stereo 44.1khz x16bit stereo uncompressed .wav) on a Reaper track, it starts eating all PC's memory to buffer it hanging the machine for a a good minute. Once the track is added, the memory gets released and it works perfectly though, so it's not technically a bug and I have no idea if it depends on Wine or Reaper.
A few months ago I also started to use the native Linux Reaper port which is fantastic and lately got a lot more stable, but all my attempts to have Windows plugins working in parallel with it through Wine failed although they say it is possible, so although there are some interesting plugins out there, they're not remotely comparable to what is available for Windows (but that would be the case for every other native application): using Wine is still the best option if you are not just strictly recording and need external plugins. I also explored the possibility to have musical software working on a Windows VM with disconforting results so far: computing power is there, but latency is a nightmare. As of today, to me Wine still offers the best options if one needs both low latency and compatibility.
It would be funny if someday Microsoft decides to include Wine with WSL, but I wouldn't be surprised to be honest.
[1] https://www.amazon.com/Mountain-Three-Wolf-Short-Sleeve/prod...
Don't overuse commas. After you get a complete idea out there, just end and start a new sentence. For example: "Please let me know how I can improve my phrasing and what mistakes I made. I am not a native speaker, so I am aware I can build my phrases in a weird way."
It is a small book that can be read in an afternoon - you can probably find pdfs online.
https://msdn.microsoft.com/en-us/library/aa384249.aspx
> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.
That links to lmkl posts like https://lkml.org/lkml/2014/4/14/207
>> Afaik 64-bit windows doesn't support 16-bit binaries, so I just assumed Wine wouldn't do it either on x86-64. Not for any real technical reasons, though.
> Yes, there is still a significant number of users, and we still regularly get bug reports about specific 16-bit apps. It would be really nice if we could continue to support them on x86-64, particularly since Microsoft doesn't ;-)
[1] https://www.microsoft.com/en-nz/download/details.aspx?id=800... [2] https://en.wikipedia.org/wiki/Windows_Virtual_PC
Pretty sure it's also used in some Atom tablets.
Edit: It's also worth noting that 32bit and 16bit instructions are different because of register size operands.
So to speak you're absolutely right... a 16bit read/write COULD do that... but it's a feature, not a bug.
In all, I assume that it was droped mostly because it involved too much work for somewhat questionable benefit.
[1]https://www.winehq.org/pipermail/wine-devel/2017-January/115...
One common example of a use case for wine is games, so maybe we can measure it as the number of games wine has it in its database over the years.
> it’s certainly true for recent versions of Windows.
Sounds very much likely given the fact that D3D 11 is now supported. D3D was an enabler or catalyst if you could call it like that, for the games and GPU industry. Who knows what’s in store with UWP
There were other enablers as well like infiniband networks. I wonder what the performance currently is in the niche market of HPCs with infnibands enabling RDMA networks: https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet