hi, i have two questions regarding vst2->vst3 compatibility:
vst3 chunk header
according to the faq, the vst3 chunk should be loaded like:
IBStreamer stream (state);
stream.setByteOrder (kBigEndian);
// try to read if it was from old VST 2 based project/preset
int32 firstID = 0;
if (stream.readInt32 (firstID) && firstID == kPrivateChunkID)
{
FStreamSizeHolder sizeHolder (stream);
sizeHolder.beginRead ();
int32 version = 0;
stream.readInt32 (version); // should be 1
int32 bypass = 0;
stream.readInt32 (bypass); // here the saved Bypass (was saved separetely with VST 2)
if (bypass != 0)
mustSwitchToBypass = true; // delay bypass update if wanted
sizeHolder.endRead ();
stream.seek( 16, kSeekCurrent ); // padding???
}
in order to read the vst2 chunks correctly, i need to have an additional seek by an additional 16 bytes (see “padding???” comment). is the documentation out of date, or am i missing something?
vst2 chunk endianness
when simply reading the chunk, it seems to be byte-swapped. the vst2 version of the plugin loads/stores it’s chunk in little-endian (which should be independent from the host), but reading the vst2 chunk in the vst3 transition, this chunk appears to be big-endian. what is the exact reason for this? maybe i’m missing something obvious?
modelling multiple plugin flavours
my vst2 plugin comes in different flavours (instrument/effect and different channel configurations). these vst2 flavours would map to a smaller number of vst3 classes (e.g. vst2 flavours A and B would map to a single vst3 class C). for project compatibility from vst2 to vst3, i would have to provide two vst3 classes C and C’, while from a user perspective, i only want to see a single vst3 plugin C.
what is the preferred workflow to cope with this situation? e.g. is it possible to create a vst3 class which is invisible to the user, but can be used in the transition from vst2 to vst3? or is the only solution to provide a C’ with a name that indicates that users should not use this version of the plugin in new projects.
when simply reading the chunk, it seems to be byte-swapped. the vst2 version of the plugin loads/stores it’s chunk in little-endian (which should be independent from the host), but reading the vst2 chunk in the vst3 transition, this chunk appears to be big-endian. what is the exact reason for this? maybe i’m missing something obvious?
The vst2.x preset file (.fxp) is saved in big-endian format. The binary chunk inside is not defined. So you may have used little-endian for the chunk, then you have to use little-endian to read it.
If you used the code from the FAQ, you have to change the byte order of the IBStreamer object before reading your own stuff.
in order to read the vst2 chunks correctly, i need to have an additional seek by an additional 16 bytes (see “padding???” comment). is the documentation out of date, or am i missing something?
I don’t know for sure, but this indeed looks wrong.
modelling multiple plugin flavours
Please describe exactly what you have today in vst2. We maybe have an advise, but we need to know this exactly before.
the vst2 plugin reads/writes the binary chunk in little-endian (it uses programsAreChunks(true)). i’m using IBStreamer like in FAQ code only to read the vst3 chunk, but my own to code after seeking the 16 bytes forward. but i have to byte-swap the data from IBStreamer::read before i can read them in little-endian again.
i have a plugin with 2 flavours: 2-in/2-out (A) and 8-in/8-out (B). in the vst3 world a single plugin (C) could support both via setBusArrangements. but for the compatibility this plugin C should be instantiated by two different fuids (generated by convertVST2UID_To_FUID from the IDs of A and B). i could register two plugins with two different fuids (and the same factory function (C and C’)), but then the user will see both vst3 plugins. however it would be better if users will never use C’ in new projects.
the vst2 plugin reads/writes the binary chunk in little-endian (it uses programsAreChunks(true)). i’m using IBStreamer like in FAQ code only to read the vst3 chunk, but my own to code after seeking the 16 bytes forward. but i have to byte-swap the data from IBStreamer::read before i can read them in little-endian again.
As already said, just set the byte order of the IBStreamer to little endian when reading your chunk data:
stream.setByteOrder (kLittleEndian);
i have a plugin with 2 flavours: 2-in/2-out (A) and 8-in/8-out (B)
I’m sorry, but I don’t have a solution for this case.