> Here's a nice writeup by Lukas-W concerning this problem... > > https://github.com/LMMS/lmms/issues/296
he mentions it, but unfortunately he says that this won't be done. Anyways, I currently require such a plugin. > 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. I'd agree here. > 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! Not sure what you mean by code review. Anyways, the problem with zyn seems mostly that the LMMS team has always been cutting support for newer compilers... Btw, the mailing list does not seem very active... Does this even read any of the devs? Should such things better be discussed as feature-requests on github? ------------------------------------------------------------------------------ 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
