JSFX source to become LGPL open-source in coming months

[GavinRay97]

Amazing news!
See: https://www.askjf.com/index.php?q=5961s

[jpcima]

This is not likely to change much as this project is concerned.
It's interesting that they would go with LGPL rather than their choice for WDL which is the zlib license.
Regardless, this library would remain around as a liberally-licensed implementation.

Now this may question the integration of JSFX into Carla software.
Perhaps they would prefer to wait for the official implementation.
(Even though this vague comment is all we have atm.)
Do you have an opinion on this @falkTX ?

[jpcima]

Every plugin which I've tried has worked.
Atm I wish I could involve more people in the testing.

@jcelerier has let me know recently of experimental work to fit this into ossia score.
One thing is that I'd love a number of @gfx hosts available as contribs, in addition to the JUCE one, such that hosting software can embed the graphics with reduced effort.
This would possibly include Qt for ossia, DGL for DPF plugins, and so on.

When it comes to hosting, one thing is that the JSFX feature set is greater than the common denominator of typical plugin hosts (eg. toggling parameter visibility, per-port latency, MIDI latency, non-automating parameter changes, etc)
So a number of things don't fit 1:1 using a JUCE Plugin as a host, but perhaps Carla might support at some point a number of these extra features.

[jcelerier]

for my part embedding the graphics in Qt was fairly trivial at least to get it roughly working (I'm sure I have a couple bugs but overall it seems to work with the plug-ins I tried). If that can be useful my code for the gfx -> Qt window (rendered directly in a QDialog) is there: https://github.com/ossia/score/blob/master/src/plugins/score-plugin-ysfx/YSFX/ProcessModel.cpp#L147

[jcelerier]

just have to handle the remaining callbacks 😸

[jpcima]

@jcelerier
This may give you issue with @gfx being blocking, the function gfx_showmenu in particular.
In Juce, the only solution I found was to move all @gfx into a background thread.
You can look at the graphics_view source as a reference.

The API is not totally satisfying as well.

• parsing of menu strings, which is to move from the plugin to the library
• make the structure ysfx_gfx_config_t opaque; or at least versioned, permitting ABI-preserving changes

[GavinRay97]

This is not likely to change much as this project is concerned.

I was hoping mostly to:

1. Just make folks aware of it
2. Let you know, in the event there are some useful tricks/code patterns that might be found in the future when JSFX is released that might be helpful in ysfx

👍