Re: Asio Bindings?
I'm a little late (1.5 years) to the ASIO discussion party, but I recently wrote something for myself that may be useful to others: https://github.com/dewf/DASIOClient I haven't published to DUB yet because 1) it's a pretty naive implementation and 2) I'm still very new to D, and 3) there's a built-in logging thing that will probably annoy everybody (which is why I need to spend more time with D, so I can learn The Right Way) It's "batteries included" (DLL+LIB files for Win32/64), so you don't have to compile the C library yourself. Note: it currently only really supports the ASIOSTInt32LSB sample type, because that's what all my test hardware uses; I have no idea if the other sample types are in common use with modern audio interfaces. But the C library also passes through ASIOSTFloat32LSB/ASIOSTFloat64LSB, so it would be very easy to modify the D wrapper to accommodate those, as well. If the included example program plays silence, then you'll probably need a new sample type :)
Re: Asio Bindings?
On Saturday, 11 June 2016 at 04:11:59 UTC, Joerg Joergonson wrote: Are you using any of their source code from the vst sdk? If you hand re-write any of their source code, it is yours. That could actually be considered to be a translation and a derived work. If you implement from a specification you might be safe, although some claim that APIs are copyrightable (questionable IMO).
Re: Asio Bindings?
On Wednesday, 8 June 2016 at 23:19:13 UTC, Andrej Mitrovic wrote: I do have (Steinberg) ASIO binding in D. The problem is I couldn't release the bindings. I've asked Steinberg if it was OK to release D bindings and they were strongly against it unfortunately (and this was over 3 years ago..). Any kind of direct use of ASIO requires their approval first.. meaning you had to register on their website. I would recommend using third party libs that abstract the underlying engine, like PortAudio or RtAudio (the later of which I'm going to release a port of soon!). I had a binding to PortAudio but the devs of that library insisted on only supporting interleaved audio, RtAudio supports both interleaved and non-interleaved audio, and the library is easy to port. Any news on this?
Re: Asio Bindings?
On Friday, 10 June 2016 at 20:52:46 UTC, Andrej Mitrovic wrote: On 6/9/16, Joerg Joergonson via Digitalmars-d-learnwrote: [...] Just to show that I'm not full of shit, here's the e-mail chain: On 6/3/11, Andrej Mitrovic wrote: [...] On 6/7/11, Yvan Grabit wrote: [...] On 6/23/11, Andrej Mitrovic wrote: [...] On 6/23/11, Yvan Grabit wrote: [...] On 6/23/11, Andrej Mitrovic wrote: [...] Unfortunately this is the last I've heard from them at the time.. Well, I definitely didn't think you were full of shit! But I see no negative statements against doing what you did. They simply said that you can't include their code directly... they want people who download your code to have to download the sdk from Steinberg. You own your code, no one else, not even Steinberg... but you don't own or have the right, as they mention, to publish their code with yours. Creating bindings is not a license infraction. [...] Are you using any of their source code from the vst sdk? If you hand re-write any of their source code, it is yours. You say that the only two files from the sdk are aeffect.h and aeffectx.h, right? Is it these: https://github.com/falkTX/dssi-vst/blob/master/vestige/aeffectx.h https://sourceforge.net/u/geyan123d/freepiano/ci/54f876d52c6f49925495f7ed880bd2434bda0504/tree/src/vst/aeffect.h?format=raw http://www.dith.it/listing/vst_stuff/vstsdk2.4/doc/html/aeffect_8h.html https://source.openmpt.org/svn/openmpt/branches/devBranch_1_17_03/include/AEffect.h etc... If so, as you can see, people already do what your wanting to do and their is probably a reason they stopped responding, and it's because they can't do much as long as you don't include anything from them. Of course, don't take my word... maybe ask on stack overflow or something? If you are simply worried about being sued then that problem is relatively easily fixed! Just ask Walter or Andrei to fund your defense ;) Don't let your hard work go to waste! ;) I think you should be more afraid of all the questions I'll be asking you on how to use it rather than being sued by Steinberg! ;)
Re: Asio Bindings?
On 6/9/16, Joerg Joergonson via Digitalmars-d-learnwrote: > 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 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 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 GmbHFax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > On 6/23/11, Andrej Mitrovic 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 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 GmbHFax : +49-40-21035300 > Neuer Hoeltigbaum 22-32, D-22143 Hamburg/Germany > http://www.steinberg.net > On 6/23/11, Andrej Mitrovic wrote: > On 6/23/11, Yvan Grabit 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
Re: Asio Bindings?
On Wednesday, 8 June 2016 at 23:19:13 UTC, Andrej Mitrovic wrote: I do have (Steinberg) ASIO binding in D. The problem is I couldn't release the bindings. I've asked Steinberg if it was OK to release D bindings and they were strongly against it unfortunately (and this was over 3 years ago..). Any kind of direct use of ASIO requires their approval first.. meaning you had to register on their website. I would recommend using third party libs that abstract the underlying engine, like PortAudio or RtAudio (the later of which I'm going to release a port of soon!). I had a binding to PortAudio but the devs of that library insisted on only supporting interleaved audio, RtAudio supports both interleaved and non-interleaved audio, and the library is easy to port. Why would bindings have any issues with licensing? People release VST source code all the time. Sure they will be against it because they are muddlefudgers! They can't officially endorse it without having to dealing with the user end to some degree and Steinberg is known for that kind of behavior(just look at all the hoops one has to jump through to get asio in the first place). Of course, I can't convince you but and I'll probably have to re-create your work, but hosting something like that on git shouldn't cause any problems. At most, SB will send you a cease and desist type of letter. In which case you take it down. Think of mono, it essentially duplicated .net and MS hasn't done a thing about it(they can't do much but flex their big muscles, in which case they didn't). I would appreciate it though if you thought about it again, it would save me a bunch of work! If the problem is that you have included SB source code, then that can easily be remedied by removing and and placing an abstraction in it's place where others can plug in the source when they d/l it from SB. I haven't got into writing any audio stuff yet but when I look in to it more I'll check out the options. I don't need anything overly complex but do need low latency IO.
Re: Asio Bindings?
I do have (Steinberg) ASIO binding in D. The problem is I couldn't release the bindings. I've asked Steinberg if it was OK to release D bindings and they were strongly against it unfortunately (and this was over 3 years ago..). Any kind of direct use of ASIO requires their approval first.. meaning you had to register on their website. I would recommend using third party libs that abstract the underlying engine, like PortAudio or RtAudio (the later of which I'm going to release a port of soon!). I had a binding to PortAudio but the devs of that library insisted on only supporting interleaved audio, RtAudio supports both interleaved and non-interleaved audio, and the library is easy to port. On 6/2/16, Pie? via Digitalmars-d-learnwrote: > On Thursday, 2 June 2016 at 11:15:59 UTC, Guillaume Piolat wrote: >> On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: >>> On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: > Does anyone know if there is any Asio bindings or direct D > available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. >>> >>> Oh, lol, I should have mentioned I meant for audio! ;) >> >> It doesn't seem to exist but using bindings for FMOD you should >> be able to access ASIO as an audio driver. > > If FMOD is that commercial sound lib then I'm not interested. I > guess I'll have to try and write some type of asio lib when I get > around to it. Hopefully it is not too difficult. >
Re: Asio Bindings?
On Thursday, 2 June 2016 at 11:15:59 UTC, Guillaume Piolat wrote: On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;) It doesn't seem to exist but using bindings for FMOD you should be able to access ASIO as an audio driver. If FMOD is that commercial sound lib then I'm not interested. I guess I'll have to try and write some type of asio lib when I get around to it. Hopefully it is not too difficult.
Re: Asio Bindings?
On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;) It doesn't seem to exist but using bindings for FMOD you should be able to access ASIO as an audio driver.
Re: Asio Bindings?
On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;)
Re: Asio Bindings?
On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things.