On 6/9/16, Joerg Joergonson via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote: > Why would bindings have any issues with licensing?
Just to show that I'm not full of shit, here's the e-mail chain: On 6/3/11, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote: > Hello, > > I'm currently porting the Steinberg VST and ASIO SDKs for use with the > D programming language. I would like to know if there are any special > licensing requirements before I can publish the source code to a > public repository. > > Specifically, do I need to print out the licensing agreement PDF > document, sign it, and send it via snail-mail to Steinberg? I'm > currently unemployed, so there shouldn't be any issues from my part > with regards to signing any licensing agreements, if that's required. > > The bindings themselves won't distribute any C/C++ header or > implementation files from the SDK, as the D language can't use C > header files directly. > > > Kind regards, > Andrej Mitrovic > On 6/7/11, Yvan Grabit <y.gra...@steinberg.de> wrote: > Hi Andrej > > i will speak with our internal Product planning people about your > concern... > I will keep you inform about our decision as soon as we have a decision... > > Cheers > > Yvan > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Yvan Grabit mailto:y.gra...@steinberg.de > Technical Manager - Technology Group Phone: +49-40-21035125 > Steinberg Media Technologies GmbH Fax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/23/11, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote: > Hello Yvan, > > I apologize if this e-mail is unnecessary and a decision is yet to be > made. If you are too busy should I try to contact one of Steinberg's > official representatives? > > I am willing to provide the source code for examination to Steinberg > if this could help verify that I'm not breaking any licensing > requirements. > > Have a nice day, > Andrej Mitrovic > On 6/23/11, Yvan Grabit <y.gra...@steinberg.de> wrote: > Hi > > we have examine your request, and decide due to our current VST/ASIO > license that you are not allowed to deploy/distribute a copy of the > VST/ASIO SDK (partially or full). > We will investigate a way to change our licensing for research or > educational use. > > In your concrete case, could it be not possible to ask the people you give > your source using the VST SDK (or ASIO) to download the VST-SDK (or ASIO) > (and agree the agreement) and provide a compiler macro (or something > different) which will convert the VST /ASIO interface to something D > compatible ? > > By the way how can we guaranty that the VST plugin or ASIO component > developed in D could be load by a host developed in C ? > > Cheers > > Yvan > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Yvan Grabit mailto:y.gra...@steinberg.de > Technical Manager - Technology Group Phone: +49-40-21035125 > Steinberg Media Technologies GmbH Fax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/23/11, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote: > On 6/23/11, Yvan Grabit <y.gra...@steinberg.de> wrote: >> In your concrete case, could it be not possible to ask the people you >> give >> your source using the VST SDK (or ASIO) to download the VST-SDK (or >> ASIO) >> (and agree the agreement) and provide a compiler macro (or something >> different) which will convert the VST /ASIO interface to something D >> compatible ? > > Yes, I believe I can do that. For ASIO, I have the following: > > - A "Loader", which is a source file made from scratch which searches > for ASIO entries in the Windows Registry and provides a class which > can load and initialize any found ASIO drivers. Through this class > user code calls functions like "canSampleRate", "outputReady", etc. > > The Loader only requires the type definitions found in the > asiosdk\common\asio.h header file. This header file can be > automatically converted to D via an existing tool, and the Loader > would then import the newly converted header file and use the type > definitions. > > The Loader requires the OpenAsio DLL that can be found here: > http://www.martinfay.com/openasio.htm > > The reason OpenAsio is required is because the ASIO COM class has the > "thiscall" calling convention which is not directly supported by the D > language. It might be possible to use inline assembler to simulate the > "thiscall" calling convention, but this would require some work on my > part to get it working. > > No other ASIO SDK file is required. > > From my current understanding, you would require me that *no* ASIO SDK > files are to be distributed with the library. Therefore I should > provide only the Loader source file, and provide the links to the ASIO > SDK Developer homepage where the users can agree to the license terms > before they can download the SDK, after which they can extract the > asio.h header file which is then converted to D. I would also provide > a link to the OpenAsio DLL download page which is required for the > 'thiscall' workaround. > > The library would not be able to compile without the header file, and > therefore users would not be able to use the ASIO technology without > agreeing to the license terms found on the Steinberg website. > > The VST binding (v2.4) is still in development and not ready yet. I > have two C header files converted to D and a D host application > example that can load VST DLL's and inspect their properties. The two > needed header files are: > aeffect.h > aeffectx.h > > The D Host sample application can load a VST plugin and inspect its > properties, process audio, and instantiate the GUI of the plugin (if > available). > >> By the way how can we guaranty that the VST plugin or ASIO component >> developed in D could be load by a host developed in C ? > > D is a C ABI compatible language, meaning that it can directly call > into C code and be called from C code without any need for wrappers or > technologies like P/Invoke. All that is required is that the parameter > types are typed the same, and that the calling conventions match. > Calling conventions are specified in the D code by using > "extern(C)"-style syntax, and this can be used to either export a D > function to be used by C code, or import C functions to be used by D > code. > > A D ASIO device driver could be written, however I don't think a > manufacturer would ever consider using D for writing ASIO drivers, as > it is a fairly young language and lacks the performance benefit of > using pure C. > > A D ASIO host can directly use ASIO driver buffers, with no need for > conversions between types. This is exactly why I have started the D > ASIO bindings projects, as other solutions (such as PortAudio) use > interleaved buffers and generally introduce additional overhead where > it is not required. > > A D VST plugin can be created and loaded by a C host. A D VST Plugin > can communicate with a C host and provide callback functions, which > the C host can then directly call. > > A C VST plugin can also be loaded by a D host. > > I will provide example code for each of the above case, except writing > an actual ASIO device driver in D, which I would discourage > manufacturers from doing as there wouldn't be much benefit over using > C directly. > > Kind regards, > Andrej Mitrovic > -------- Unfortunately this is the last I've heard from them at the time..