Johannes,
Here's a nice writeup by Lukas-W concerning this problem...
https://github.com/LMMS/lmms/issues/296
> this zynaddsubfx will not be compiled into the LMMS sources, but instead
> just run zynaddsubfx from your "$PATH" variable and connect to LMMS via
> the OSC protocol.
Arguably, that's how we should be doing it today. Our 3rd party plugin
code is mostly a snapshot of the upstream sources and in most cases, we
could (and should) directly replace the libraries and/or executable binary
files with prebuilt binaries without issue. We should only care about
plugins at packaging time and have a continuous integration script test the
bundling of these for the various OSs.
My understanding is that Zyn and VSTs are special cases as they must run in
a separate process, so LMMS uses some IPC (with some cross-platform logic)
to attach to the process. This means that changes to Zyn can require a lot
of changes to the wrappers we've written. Here's an example:
https://github.com/LMMS/lmms/pull/1991
An important note of the above pull request is that when we include the
upstream code changes in our pull request, it makes for a very ugly code
review!
> it's a bit like the issue of artists uploading windows-VST songs to the
> sharing platform
Perhaps although I know of many Linux users which have installed Wine for
VST support. I don't know of any Windows users which have installed JACK.
In regards to using OSC messaging... LMMS was ready to adopt it internally
at one point ... Wallacoloo attempted this
https://github.com/LMMS/lmms/pull/2311. Mark McCurry, the author of Zyn
was very receptive to this.
Also related:
https://github.com/LMMS/lmms/issues/3204
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
