Hello,
I'd like to write a plugin which will start a remote zynaddsubfx. However, 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. The reason for this is that I try to program new features in zyn, but can not make songs with them, since the zyn version is fix in LMMS. (And no, I don't want to go the LV2 way and install Carla. A direct plugin will be much more handy). Connecting a plugin via inter-process communication (IPC) can be done in multiple ways. My idea was to, by now, restrict the plugin to jack connections: If the user/distribution did not compile with jack support, the plugin is not available. Otherwise, when instantiating the new plugin, a jack server will be started if it has not already been (autostart works the same way in zynaddsubfx), and then lmms will be connected to the zynaddsubfx plugin. A downside of using jack is that if I'll give the song to someone else who has no jack support on his PC, that person can not play the song (it's a bit like the issue of artists uploading windows-VST songs to the sharing platform). On the other hand, jack should have the best latency behaviour and is imo the cleanest approach (it's *the* audio connection toolkit for Linux). The alternative is to use something else than jack, like raw UDP or shared memory (the latter is being used by the current implementation of remote zynaddsubfx). What should I do? Thanks + regards, Johannes ------------------------------------------------------------------------------ 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
