Spire: Feature requests
- KVRian
- 1370 posts since 17 Jul, 2007 from Riversland Valhalla
-
- KVRAF
- 11282 posts since 2 Dec, 2004 from North Wales
Any plans to ever make Spire NKS compatible?
X32 Desk, i9 PC, S49MK2, Studio One, BWS, Live 12. PUSH 3 SA, Osmose, Summit, Pro 3, Prophet8, Syntakt, Digitone, Drumlogue, OP1-F, Eurorack, TD27 Drums, Nord Drum3P, Guitars, Basses, Amps and of course lots of pedals!
-
- KVRer
- 7 posts since 21 Jan, 2020
Will there be a VST3 version of Spire?
- KVRAF
- 5489 posts since 15 Dec, 2011 from Bucharest, Romania
-
- KVRer
- 7 posts since 21 Jan, 2020
Regarding VST 3 again... there has been a new announcement from Steinberg.
VST 2 will be discontinued. In a couple of years, Cubase and other Steinberg software will only support VST 3. Maybe also other DAWs will follow suit.
With this information, how about a VST 3 version of Spire?
VST 2 will be discontinued. In a couple of years, Cubase and other Steinberg software will only support VST 3. Maybe also other DAWs will follow suit.
With this information, how about a VST 3 version of Spire?
https://forums.steinberg.net/t/vst-2-di ... ued/761383The discontinuation of VST 2 marks the final step in the transition process to VST 3. Focusing solely on VST 3 will increase the stability of our products and allow us to fully leverage the advantages of the VST 3 platform.
As it stands, Steinberg hosts continue to offer VST 2 compatibility. But as Apple has transitioned its Mac line to Apple silicon, those Mac users will still be able to use their VST 2 plug-ins under Rosetta 2.
Moreover, within the next 24 months, Steinberg’s host applications and plug-ins across macOS and Windows will offer VST 3 compatibility only.
To ensure that you are prepared for these eventualities, we recommend to check if any third-party VST 2 plug-ins are in use and, if so, to contact the corresponding plug-in developers for details on supporting VST 3.
- KVRist
- Topic Starter
- 423 posts since 10 May, 2009
-
- KVRer
- 7 posts since 21 Jan, 2020
Great, thanks for info!
-
- Pick Me Pick me!
- 9698 posts since 12 Mar, 2002 from a state of confusion
One annoying aspect to Spire is the lack of backwards compatibility between versions. Right now I must have a 1.0.x version for older projects and a 1.5.x version for newer projects. So I have to retain two different versions of Spire to work on my Cubase projects.
Will I then have a third version of Spire in VST3 format once it comes out?
It would have been great had you just made Spire.dll and thus version 1, 1.5, 2, 5, etc would all use the same file name and structure to be backwards compatible.
- KVRian
- 1370 posts since 17 Jul, 2007 from Riversland Valhalla
Shouldn't this mean that DAW manufacturers have to implement CLAP host utility first?
- KVRian
- 823 posts since 27 Aug, 2020
Not necessarily.
EvilDragon wrote: ↑Thu Dec 30, 2021 3:09 pm It has the facility to replace both, since it's extensible, simple and efficient. So developers can write a CLAP plugin that would then basically be wrapped into other formats. New plugin developers would this way still be able to provide a "VST2" plugin (which is a CLAP wrapped into a CLAP-to-VST2 wrapper) even if they couldn't get the VST2SDK license from Steinberg since 2018.
EvilDragon wrote: ↑Thu Jan 20, 2022 10:02 pm The main issue CLAP is trying to solve is to have a clean and unencumbered license and a properly governed standard (VST is far from properly governed!) that makes it easy to develop a plugin once, then deply to other formats if need be. This is why host adoption is not a huge problem. If it happens, nice, if it doesn't, plugin devs are still benefitting from simplicity of CLAP (vs madness that is VST3).
I'm not even asking the guys at Reveal Sound to do that right away, since it's probably either hard or impossible at this point, it's just something to bear in mind going foward.mystran wrote: ↑Thu Jan 20, 2022 10:44 pm It's probably also worth emphasizing that in general plugin developers don't develope separate plugins for every API they support. Rather they develop their plugin against one API, whether that's some internal API, some toolkit (eg. Juce, iPlug) specific API, or some actual plugin API. Whatever other formats they support are then typically wrapped around that internal format. So if you're using some plugins that support multiple APIs, there's a very high chance that there's already some sort of wrappers involved.
When such wrappers are built into the plugin itself, it's essentially invisible to the users, but it can make quite a bit of difference to the developers and having a solid, open API can have quite a bit of value (to developers), even if no actual DAW ever supported it directly. If they do, then that's sort of a bonus.
-
- KVRer
- 7 posts since 21 Jan, 2020
Very interesting thread, by u-he, about that CLAP plugin format:
viewtopic.php?p=8296134
viewtopic.php?p=8296134