JUCE framework still doesn't officially support LV2.
Well this is a kick in the nuts: VST2 plug-ins
-
- KVRian
- 618 posts since 12 Mar, 2013 from Russia, Vladivostok
Yes.
Do You need the official support? Pianoteq builds LV2 versions of their instruments (though they didn't publish their changes in JUCE). And you can do that so using https://github.com/DISTRHO/JUCE/
I have LV2 builds of your OB-Xd and OPL, are You interested?
-
- KVRAF
- 5427 posts since 18 Jul, 2002
I'd prefer the official and in-house way thanks for the offerKott wrote: ↑Sun Apr 18, 2021 10:56 am Do You need the official support? Pianoteq builds LV2 versions of their instruments (though they didn't publish their changes in JUCE). And you can do that so using https://github.com/DISTRHO/JUCE/
I have LV2 builds of your OB-Xd and OPL, are You interested?
-
- KVRian
- 618 posts since 12 Mar, 2013 from Russia, Vladivostok
Stalemate situation. JUCE won't add LV2 until Devs asks them, Devs won't consider LV2 until JUCE implement it.
Someone has to step first.
IIRC. There was PR with LV2 support but JUCE's team refused it with some reasonable obligations (for that time), who will support it in our team?
-
- KVRian
- 618 posts since 12 Mar, 2013 from Russia, Vladivostok
I must mention that JUCE fork support building LV2 plugins only.
Hosting is possible https://github.com/lvtk/jlv2/ and works, but it still unstable yet.
Hosting is possible https://github.com/lvtk/jlv2/ and works, but it still unstable yet.
-
- KVRAF
- 5427 posts since 18 Jul, 2002
-
- KVRian
- 618 posts since 12 Mar, 2013 from Russia, Vladivostok
I don't think so. Not ready in what terms? It's stable and very documented. Maybe it's not the best in the world
And I think that lack of popularity just because no one promotes it in commercial plugins world.
IMHO there is a corporation's phobia hovers
"If the standard is not owned, then we cannot blame anyone if something goes wrong."
- u-he
- 28063 posts since 8 Aug, 2002 from Berlin
Crazy.
I guess the time has come for someone to publish a non-proprietary plug-in format and SDK that is compatible with the VST2 standard. If someone wishes to do that, I'll be happy to share some thoughts.
I guess the time has come for someone to publish a non-proprietary plug-in format and SDK that is compatible with the VST2 standard. If someone wishes to do that, I'll be happy to share some thoughts.
-
- KVRAF
- 2565 posts since 2 Jul, 2010
The Vestige situation suggests that some legal threats could still be expected?
Maybe the recent Android/Java ruling is helpful here, but I can't see a small player taking the risk.
Maybe the recent Android/Java ruling is helpful here, but I can't see a small player taking the risk.
- KVRAF
- 2237 posts since 25 Sep, 2014 from Specific Northwest
I've never seen it, per se, but being based on XML tells me that it's 1) bloated and 2) most likely, done completely wrong as 99%+ of programmers don't know how to write XML properly. Whenever I see XML used as a format, I run the other way.imrae wrote: ↑Sun Apr 18, 2021 7:57 amAre you familiar with the story of OOXML? https://en.m.wikipedia.org/wiki/Office_Open_XML An absurdly bloated standard that MS rammed through the standards orgs and couldn't even implement themselves...
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better?
- KVRAF
- 4278 posts since 6 Nov, 2009
Yes. The DOSBOX of the audio world. Would be wonderful. VeSTige and others exist so this shouldn't be too hard unofficially. DAWs could just give an option to load in VeSTige support, like how MP3/LAME exporting was before the patent expired.
-
Richard_Synapse Richard_Synapse https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=245936
- KVRian
- 1136 posts since 20 Dec, 2010
I'm afraid a new format won't work unless the old one is dropped, or not introduced in the first place. Logic, ProTools or Reason (before VST2) are good examples for this.
Richard
Richard
Synapse Audio Software - www.synapse-audio.com
- u-he
- 28063 posts since 8 Aug, 2002 from Berlin
I always wonder, why not make a new plug-in format "API-less"? What I mean is, the format could be a single header file that contains a dispatcher and variadic functions where all semantics (opcode numbers, function arguments and types, e.g. bytesize of plug-in identifier) are defined in a configuration file that resides in a location relative to the binary, e.g. the root directory of the plug-in binary/bundle. This way the code is free of any 3rd party copyrights and can come with, say, MIT license or something. The actual specific API(s) are defined in text files that users extend to. This way a new plug-in format can start out as LV2, but easily be extended to compatibility with other formats by editing text files.