Steinberg sending DMCA takedown notices for the VST2 SDK
category: general [glöplog]
dunno how big its userbase is, probably nowhere near ableton or cubase, but its still well known and has a pretty lively community
Quote:
You are pointing me to LADSPA. What part of "simple" did not you understand ?
LV2 is the successor of both LADSPA and DSSI. You can still claim that no one uses it. If Steinberg alienates the VST userbase enough they might.
VSTi will kill all your work... not believin...? wait...!
Here's how VST 2.4 has been extended in Reaper
https://www.reaper.fm/sdk/vst/vst_ext.php
https://www.reaper.fm/sdk/vst/vst_ext.php
vendor extensions, not a big friend of that. also, reaper isn't bigger. pro tools is. aax anyone? you need to sign an nda to even get started with it.
can we please make this a "what is the best DAW" discussion until ppl start posting garfield pics? ktnxbye
Renoise, of course.
The best DAW is Milkytracker, obviously.
It's blatantly buzz.
If by DAW you mean "Desperate Agony Workstation", then yes.
Quote:
window management (try and make a resizable ui with vst2)"
Actually vst2 supports window resizing, but in later Cubase version it's just not implemented anymore, don't know why they removed this feature from their host.
Quote:
there are more issues with vst2, like output configuration (ever encountered a plugin which comes in multiple variants for different output configs?)
Multi-Io is supported till ages in vst2.
Quote:
vst2 does not support sample accurate automation
Yes it doesn't, but they could easily add a new event type. Also a host could circumvent the latter by doing variable size processing, FLStudio does this for example. Or just run the host with small buffersizes, not sample-exact but sufficient.
I didn't know Polac shows up if you mention Buzz. :D
Nope I was watching the nectarine thread and just saw the steinberg thread. :)
It's only when you mention buzz and vst, then the magic happens :)
A tracker is not a DAW.
Depends on what your definition of a DAW is; most trackers may not fit that bill, but Renoise and Buzz might.
obTopic: out of all the options that have been mentioned, translating BeRo's Object Pascal version to C/C++ seems like a workable solution. Something like... person A does an initial translation which creates a version that isn't a straight drop-in replacement, and person B fixes the names of constants and types so that it can be dropped straight into an existing VST2.4 project. If, for some reason, Steinberg attacks person B's work, the initial thing is still there for other options.
(and just fixing names might not be enough, I didn't look that closely yet)
A tracker is a DAW in the same way that a C64 C is a "personal computer" :)
polac, multi io yes, but it's basically a number of ins and outs, you can't define how these are to be interpreted.
the variable buffer sizes fl studio calls the plugin with are a fl studio based workaround, and it fucks up your simd optimizations. ideally there would be a buffer with timestamped events, like midi data. could be done, but it hasn't been done ;)
I cannot sympathize with any eagerness to offer one's backside for Steinberg to utilize again, even after seeing what happened with VST2. "VST3 my ass", no thanks.
yzi: I don't think an extra stage that's not a direct drop-in would gain you anything legally, because the cleanroom work has already been done. I already started translating BeRo's header to C++ and it can be used directly as a drop-in, depending on how much you rely on the original SDK (OpenMPT for example makes use of the opcodes directly, so I did not bother translating any of the helper functions that would just redirect to those opcode calls).
Awesome that you're doing it. I looked at it and it looked so boring I thought I'd rather watch football instead. ;)
I was speculating that if all the names are the same, Steinberg could claim that you must have looked at their SDK in order to come up with those names. And in the worst case, it would still be possible to adapt the application to use BeRo's naming.
I was speculating that if all the names are the same, Steinberg could claim that you must have looked at their SDK in order to come up with those names. And in the worst case, it would still be possible to adapt the application to use BeRo's naming.
Quote:
Awesome that you're doing it. I looked at it and it looked so boring I thought I'd rather watch football instead.
I should say that this translation is specifically tailored for my needs and will need a few modifications to be used by other projects. I'm not doing it because it's fun but because it has to be done. :)
Quote:
I was speculating that if all the names are the same, Steinberg could claim that you must have looked at their SDK in order to come up with those names
BeRo has documented very clearly which third-party sources he used as documentation, and all the opcodes are named there - coincidentally, those names are identical to those in the original SDK...