midir icon indicating copy to clipboard operation
midir copied to clipboard

Published 20 hours ago • verified publisher icon Boddlnagg

Opt-in support for JACK backend on Windows

Open calvinkosmatka opened this issue 3 years ago • 9 comments

  • Adds winjack feature to allow using JACK as the backend on Windows (non-breaking)
  • moves VirtualInput and VirtualOutput out of the os module and into their own virtual module (breaking)

jack-sys doesn't provide a link to libjack on Windows, so consumers will need to supply their own. I included linking to JACK2 at the standard installation path for the integration test and examples.

calvinkosmatka avatar Jan 23 '22 00:01 calvinkosmatka

Thanks for the PR! I didn't know that Jack is available on Windows, too. How commonly is this used? I added a few review comments for you to address.

Boddlnagg avatar Jan 23 '22 17:01 Boddlnagg

How commonly is this used?

I suspect it's fairly uncommon, but it is at least supported by Ardour for example. As far as I know it's the only way to allow applications to create their own virtual MIDI ports on Windows, which is my use case.

I added a few review comments for you to address.

Your comments aren't showing up for me, stuck pending?

calvinkosmatka avatar Jan 23 '22 23:01 calvinkosmatka

Your comments aren't showing up for me, stuck pending?

Sorry, you're right, I forgot to actually finalize the review.

Boddlnagg avatar Jan 24 '22 07:01 Boddlnagg

While this may be useful for local development and use, it would not be practical to distribute applications using midir with this feature until dynamic loading is implemented upstream in jack-sys.

Be-ing avatar Jan 28 '22 00:01 Be-ing

it would not be practical to distribute applications using midir with this feature until dynamic loading is implemented upstream in jack-sys.

I suppose that doesn't really matter without midir dynamically picking the backend at runtime (#4). Even if libjack is dynamically loaded, it's not practical to distribute a Windows build using midir with the JACK backend if there's no fallback when libjack isn't installed.

Be-ing avatar Jan 28 '22 16:01 Be-ing

Just a note to myself: The PR should be merged as is (modulo the current outstanding comments), but eventually I want to do a semver-breaking change and

  • upgrade jack-sys to 0.2.3 or later (see also #99)
  • remove winjack in favor of just jack (I think it would then still be possible to use platform specific Cargo dependencies to enable jack on Linux and macOS, but not on Windows, if that is what one desires)
  • remove the os::virtual module completely

Boddlnagg avatar Jan 28 '22 19:01 Boddlnagg

Version 0.9 of the JACK bindings have been released together with version 0.3 of jack-sys. This brings major breaking changes for jack-sys because it now uses dlib instead of always linking libjack. Refer to my PR updating the documentation for details. This solves the problem of platform-specific ways to link libjack thereby obviating the need for a separate feature for Windows. So I suggest to close this PR without merging.

Be-ing avatar Feb 08 '22 18:02 Be-ing

@Be-ing To me this means that we should at least make sure (once we upgrade to 0.3) that Windows supports building with jack, i.e. adding it to the CI. This PR could be reworked in that direction. And @calvinkosmatka's concern is still valid that supporting the jack feature on Windows is a breaking change because currently it can be enabled without any effect on Windows.

Also, I assume that #102 would apply to Windows as well?

Boddlnagg avatar Feb 12 '22 16:02 Boddlnagg

supporting the jack feature on Windows is a breaking change

Yes, so bump the minor version to indicate that.

Also, I assume that https://github.com/Boddlnagg/midir/issues/102 would apply to Windows as well?

Yes, the OS doesn't matter for that.

Be-ing avatar Feb 12 '22 17:02 Be-ing