Hi!

Maybe you read my last posts about VST plugins ... just to clear that up, I don't want to leave wrong info here: They've got a C interface, so all my writing about linking C++ was bs. Just in case anybody wants to do some VST development in D. Go ahead, no problem with D either way (host or plugin - both works when one converts the SDK files to D). I'm already happily loading VST plugins and toying aroung with them.

Anyway, I've found something annoying, nothing really bad, but just terribly annoying for a medium-level coder like me.

From my code:

' void *proc = GetProcAddress(hlib, toStringz("main"));
' if(proc is null)
' {
'     [snip]
' }
'
' auto getNewPluginInstance = cast(mainFunc)proc;
'
' // get new instance
' AEffect *newInstance = null;
' newInstance = getNewPluginInstance(&audioMaster);

That works. Why? Because:

' extern (C)
' {
'     typedef AEffect *function(audioMasterCallback) mainFunc;
'     [snip]
' }

There's something that didn't work (Access violation when calling getNewPluginInstance) and it cost me hours of debugging and trying out insanely unlogical things, until I had the idea to define mainFunc as a type. Good thing is I found a lot of bugs in advance. Well, that's how it originally was:

' auto getNewPluginInstance = cast(AEffect *function(audioMasterCallback))proc;

Without the typdef. Access violation, because getNewPluginInstance has D linkage. And there's no way to cast that void * pointer to a C function. Defining the mainFunc type solves this.

Just wanted to point that out. After half a year with D - this was the first time I ever got angry at this language.

' auto getNewPluginInstance = cast(extern (C) AEffect *function(audioMasterCallback))proc;

That would be a logical and intuitive thing - at least for me. If you have a call-once-forget-afterwards function with C linkage you shouldn't be forced to define a type. I even had the whole module extern (C). Didn't work.

-Mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

mike wrote:
> That would be a logical and intuitive thing - at least for me. If you have a call-once-forget-afterwards function with C linkage you shouldn't be forced to define a type. I even had the whole module extern (C). Didn't work.

True, it's not very nice. (C++ has the exact same issue.)

On Fri, 08 Sep 2006 03:03:40 +0200, mike <vertex@gmx.at> wrote:

>Hi!
>
>Maybe you read my last posts about VST plugins ... just to clear that up, I don't want to leave wrong info here: They've got a C interface, so all my writing about linking C++ was bs. Just in case anybody wants to do some VST development in D. Go ahead, no problem with D either way (host or plugin - both works when one converts the SDK files to D). I'm already happily loading VST plugins and toying aroung with them.
>
>Anyway, I've found something annoying, nothing really bad, but just terribly annoying for a medium-level coder like me.
>
> From my code:
>
>' void *proc = GetProcAddress(hlib, toStringz("main"));
>' if(proc is null)
>' {
>'     [snip]
>' }
>'
>' auto getNewPluginInstance = cast(mainFunc)proc;
>'
>' // get new instance
>' AEffect *newInstance = null;
>' newInstance = getNewPluginInstance(&audioMaster);
>
>That works. Why? Because:
>
>' extern (C)
>' {
>'     typedef AEffect *function(audioMasterCallback) mainFunc;
>'     [snip]
>' }
>
>There's something that didn't work (Access violation when calling getNewPluginInstance) and it cost me hours of debugging and trying out insanely unlogical things, until I had the idea to define mainFunc as a type. Good thing is I found a lot of bugs in advance. Well, that's how it originally was:
>
>' auto getNewPluginInstance = cast(AEffect *function(audioMasterCallback))proc;
>
>Without the typdef. Access violation, because getNewPluginInstance has D linkage. And there's no way to cast that void * pointer to a C function. Defining the mainFunc type solves this.
>
>Just wanted to point that out. After half a year with D - this was the first time I ever got angry at this language.
>
>' auto getNewPluginInstance = cast(extern (C) AEffect *function(audioMasterCallback))proc;
>
>That would be a logical and intuitive thing - at least for me. If you have a call-once-forget-afterwards function with C linkage you shouldn't be forced to define a type. I even had the whole module extern (C). Didn't work.
>
>-Mike

I can't beleive that anybody except me is trying to write a VST host in D! :). I was thinking of a way to call the VST plugin from D through the C function pointer and was going to ask the NG members for help but mike was nice enough to do that for me! Isn't it a miracle?

Am 14.09.2006, 14:58 Uhr, schrieb Max Samuha <maxter@i.com.ua>:

> I can't beleive that anybody except me is trying to write a VST host
> in D! :). I was thinking of a way to call the VST plugin from D
> through the C function pointer and was going to ask the NG members for
> help but mike was nice enough to do that for me! Isn't it a miracle?

Hehe ... and there I thought I was the only one that had that idea :-)

When you're working with VST too ... any interest in setting up a VST API project on dsource.org for VST plugin developers? I was thinking of doing that since I've converted most of the header files anyway, but I'm stuck with some PHP and VBA development at the moment. I think that could be a good thing for D, getting all those freeware VST developers interested in the language.

-Mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

On Fri, 15 Sep 2006 00:59:20 +0200, mike <vertex@gmx.at> wrote:

>
>Hehe ... and there I thought I was the only one that had that idea :-)
>
>When you're working with VST too ... any interest in setting up a VST API project on dsource.org for VST plugin developers? I was thinking of doing that since I've converted most of the header files anyway, but I'm stuck with some PHP and VBA development at the moment. I think that could be a good thing for D, getting all those freeware VST developers interested in the language.
>
>-Mike

i was not planning to convert anything other than aeffect.h and aeffectx.h. IMO, this is quite a trivial task and apparently doesn't require a separate project at dsource. I'm developing a lightweight real-time VST host with freely routable signal paths. The whole thing is totally experimental and there is still not much to share with the community. Actually, nothing but scanning for plugins and extracting information about them for now.

Am 19.09.2006, 09:00 Uhr, schrieb Max Samuha <maxter@i.com.ua>:

> i was not planning to convert anything other than aeffect.h and
> aeffectx.h. IMO, this is quite a trivial task and apparently doesn't
> require a separate project at dsource. I'm developing a lightweight
> real-time VST host with freely routable signal paths. The whole thing
> is totally experimental and there is still not much to share with the
> community. Actually, nothing but scanning for plugins and extracting
> information about them for now.

Yeah, you're right. And after seeing how much stuff is there in the C++ side of the SDK ... no, better invest time in the project itself.
I'm also currently only extracting info, working on the UI for now, until I can at least build some simple setups for testing. I'm writing a host oriented for realtime composing and live improvisation, with OSC integration (MIDI should be dead by now, really). Got nothing fancy either, just a window with some basic controls and a console full of debugging messages :)

-mike

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

On Wed, 20 Sep 2006 17:47:12 +0200, mike <vertex@gmx.at> wrote:

>Am 19.09.2006, 09:00 Uhr, schrieb Max Samuha <maxter@i.com.ua>:
>
>> i was not planning to convert anything other than aeffect.h and aeffectx.h. IMO, this is quite a trivial task and apparently doesn't require a separate project at dsource. I'm developing a lightweight real-time VST host with freely routable signal paths. The whole thing is totally experimental and there is still not much to share with the community. Actually, nothing but scanning for plugins and extracting information about them for now.
>
>Yeah, you're right. And after seeing how much stuff is there in the
>C++ side of the SDK ... no, better invest time in the project itself.
>I'm also currently only extracting info, working on the UI for now, until
>I can at least build some simple setups for testing. I'm writing a host
>oriented for realtime composing and live improvisation, with OSC
>integration (MIDI should be dead by now, really). Got nothing fancy
>either, just a window with some basic controls and a console full of
>debugging messages :)
>
>-mike


If you think MIDI is dead, you might be interested to know that VST is almost dead, too:) At least this guy claims it is dying: http://www.bigbluelounge.com/forums/viewtopic.php?p=45249#45249

Am 21.09.2006, 13:59 Uhr, schrieb Max Samuha <maxter@i.com.ua>:

> If you think MIDI is dead, you might be interested to know that VST is
> almost dead, too:) At least this guy claims it is dying:
> http://www.bigbluelounge.com/forums/viewtopic.php?p=45249#45249

Thanks!

Now that was a great read, although he could have calmed down a bit. He really must hate VST a lot. I especially liked: "Yeah, VST may have been around for 5 years or so before AU came along, yet it still doesn't have any host documentation, example code, or anything!!! Every developer who wants to host AUs [sic! That should read: VSTs] faces a constant uphill battle, trying to figure out how to host VSTs via reverse psychological analysis of the plugin SDK, which is pretty damn pathetic itself already."

My only two reference sources available (probably the two everybody finds and uses) are one app written in delphi and another one written in C++, with an indentation level of 1 (one) space per level and a note from the author complaining that everybody steals his code so he won't release new versions as source code anymore. And the SDK doesn't help you in any case, just remember my first topic, I was so confused how to even load a VST. Now if only AU would work on Windows, everything would be perfect :)

-Mike

(I fear that's way off topic, maybe we should discuss via email?)

-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/