KVR Audio

camsr · Post by **camsr** » Sun Mar 22, 2015 9:55 pm

can the struct AEffect be redefined (in affect.h), or is this type "the standard" and hosts will depend on it?

Miles1981 · Post by **Miles1981** » Sun Mar 22, 2015 10:40 pm

The C interface relies on the structure being identical, so I would suggest not to change it, as it should be integrated inside the host, so recompiling it would not help.

camsr · Post by **camsr** » Sun Mar 22, 2015 10:51 pm

How does this code work? I see that with the preprocessor definition, the 'future' array is 4 bytes smaller. Is it supposed to be making room for the function pointer? If so, would x64 function pointer be 8 bytes?

Code: Select all

typedef void (VSTCALLBACK *AEffectProcessProc)

...

#if VST_2_4_EXTENSIONS
	/** Process double-precision audio samples in replacing mode @see AudioEffect::processDoubleReplacing */
	AEffectProcessDoubleProc processDoubleReplacing;

	char future[56];		///< reserved for future use (please zero)
#else
	char future[60];		///< reserved for future use (please zero)
#endif

Tale · Post by **Tale** » Sun Mar 22, 2015 11:15 pm

camsr wrote:If so, would x64 function pointer be 8 bytes?

Yeah, pointers are 64-bit i.e. 8 bytes on x64.

camsr · Post by **camsr** » Sun Mar 22, 2015 11:34 pm

My question is should I assume the struct is correct for both x86 and x64, and vst2.4? The resizing of that array is not making sense to me.

Miles1981 · Post by **Miles1981** » Mon Mar 23, 2015 9:57 am

I think you can't compare the 32bits to the 64bits versions. They are actually different interfaces with no real overlap. I don't know if there is any 64bits VST plugin that isn't 2.4 compliant, so the #if is always true IMHO.

edit: http://www.steinberg.net/index.php?id=334&L=1
If you try 64bits, you are at least 2.4 compliant, so no surprise here.

SQ4 · Post by **SQ4** » Mon Mar 23, 2015 11:39 am

camsr wrote:can the struct AEffect be redefined (in affect.h), or is this type "the standard" and hosts will depend on it?

Until char future[60] you can't modify, but you can add members after that.
On 64bit, all 8byte integers are 16byte aligned.

camsr · Post by **camsr** » Mon Mar 23, 2015 8:12 pm

SQ4 wrote: On 64bit, all 8byte integers are 16byte aligned.

Are you sure? Anything in a struct would be packed tight if I recall, but the struct would be 16 byte aligned.
If I am targeting 2.4, should I be using the future[56] declare? (I know it's obvious, just thought it's better to ask)

I am going through the sdk bit by bit to look for MinGW pitfalls and MSVC specifics.

SQ4 · Post by **SQ4** » Mon Mar 23, 2015 8:48 pm

camsr wrote:
SQ4 wrote: On 64bit, all 8byte integers are 16byte aligned.
Are you sure? Anything in a struct would be packed tight if I recall, but the struct would be 16 byte aligned.
If I am targeting 2.4, should I be using the future[56] declare? (I know it's obvious, just thought it's better to ask)
I am going through the sdk bit by bit to look for MinGW pitfalls and MSVC specifics.

You can check that easlily : "Magic" = 4 bytes, the next member is "*dispatcher".
In 32bit = offset of "*dispatcher" = 4 bytes
In 64bit = offset of "*dispatcher" = 8 bytes

The same goes for member "resvd1".

camsr · Post by **camsr** » Mon Mar 23, 2015 10:26 pm

At the beginning of the header there is a pragma pack(8), will this work the same for -m64?

SQ4 · Post by **SQ4** » Tue Mar 24, 2015 9:10 am

camsr wrote:At the beginning of the header there is a pragma pack(8), will this work the same for -m64?

If it doesn't, all you have to do is add 2 extra members to AEffect.

One before *dispatcher and one before resvd1 :

Something like this
VstInt32 fill4a;
VstInt32 fill4b;

But like I said, you can easilly test it with offsetof().

aciddose · Post by **aciddose** » Sat Apr 04, 2015 5:01 pm

Pragma pack is used to specify the struct packing.

Normally if you have a struct like this:

struct chars_t
{
int8_t a, b, c, d;
};

These are packed into a single dword int32_t as expected.

If you mix sizes however:

struct mix_t
{
int8_t a;
int16_t b;
int32_t c;
int8_t d;
};

Now each will be padded into the size of the largest element. This is something I'd normally need to use a reference to be sure of, but I guess it might work out like this:

a = 24.8 (low = a)
b = 16.16 (low = b)
c = 32
d = 24.8 (low = d)

This is not alignment, this is packing which is completely different.

The VST structs must all be packed to 8-bits.

You can modify everything about the aeffect struct but the offset of each element must remain the same. If you do not use the vst sdk classes pointed to by *object, you must use *user to point to whatever you require and zero *object.

camsr · Post by **camsr** » Thu Jun 08, 2017 5:54 am

So I have gone over this again, the size of all elements (without considering packing) in aeffect is 144 bytes x86 and 184 bytes x64, for the vst2.4 defines. Is that what everyone else has?
It should be correct to typedef VstIntPtr as long int on x64 (defined LP64) and int on x86?
And for everything else like vstint32 etc, it should be correct to use int32_t etc?

Christian Schüler · Post by **Christian Schüler** » Thu Jun 08, 2017 4:06 pm

If I am not reading the header backwards, sizeof( AEffect ) in 64 bit mode should be exactly the size of 24 pointers (or 192 bytes).

EDIT: for VstIntPtr, you use intptr_t
http://www.cplusplus.com/reference/cstdint/

camsr · Post by **camsr** » Sat Jun 10, 2017 2:46 am

Thanks. I have the x86 size at 144 bytes and the x64 size at 192 bytes. I think my confusion with this struct started when trying to load a x64 build of my plugin into a x86 host (FL using its built in bridge), while it loaded, parameter controls were not responsive and the parameter value display was not updating. It also will not pass audio. IDK if this is a bug in the FLv10 bit bridge, or my plugin, but the x64 versions work fine in x64 hosts.

vst sdk aeffect.h