New toy and new problem

[Cary B. Cornett]

I am still using SawStudio in 32 bit version. I wanted to be able to use 64 bit and VST3 plugins, so I bought a plugin bridging host from Wusik that is called X42. It is still quite new, and I am still in learning curve mode with it.

My concern here is that one of the things X42 does is add to the amount of plugin data that must be stored in an EDL file. In an early test, when I save a session, I got an error message that there was too much plugin setting information to be stored. This leads me to wonder if SawStudio has a set limit for how much plugin preset data can be stored in a session. Is there some hidden "gotcha" here?

I have also posted about this on the Wusik user forum to loop the developer in on this.

[Bob L]

Yes... there are large limits but there are limits... plugins that drag down the edl performance are not acceptable to me... a plugin can easily store a path pointing to a huge file of data if it needs huge amounts of storage rather than adding all that data to the edl kludging up the works.

By the way... VST 3 plugins are not supported... only vst 2.x plugins... consider trying JBridge to bridge between 32 and 64... seems to work pretty good.


not expensive either.

Bob L

[Cary B. Cornett]

Yes... there are large limits but there are limits... plugins that drag down the edl performance are not acceptable to me... a plugin can easily store a path pointing to a huge file of data if it needs huge amounts of storage rather than adding all that data to the edl kludging up the works.

Thaniks for that information! I will pass this along to the developer of X42.

By the way... VST 3 plugins are not supported... only vst 2.x plugins... consider trying JBridge to bridge between 32 and 64... seems to work pretty good.

Think of X42 as sort of a JBridge on steroids. Besides bridging 64bit VST2s into a 32bit environment, it will also bridge VST3s into a VST2 environment. It also has other features that can be enabled on a per-plugin basis, such as oversampling.

As for cost, I went for their 80% off deal for April, which made it a $20 purchase.

[Carl G.]

Thaniks for that information! I will pass this along to the developer of X42.

Think of X42 as sort of a JBridge on steroids. Besides bridging 64bit VST2s into a 32bit environment, it will also bridge VST3s into a VST2 environment. It also has other features that can be enabled on a per-plugin basis, such as oversampling.

As for cost, I went for their 80% off deal for April, which made it a $20 purchase.

THANKS for the tip!!! But if it plows data into the EDL, it can make a session very bogged down.
Let us know which way it actually stores data, or if there is an option work around from developer.
It sounds interesting.

[Carl G.]

By the way... VST 3 plugins are not supported... only vst 2.x plugins... consider trying JBridge to bridge between 32 and 64... seems to work pretty good.


not expensive either.

Bob L

Also... thanks for the info, Bob.

[Cary B. Cornett]

Bob,
I relayed your comments to William Kafelz, the developer of X42.
His reply:

This is a weird one for sure. Check out my code, it adds very little to the data, so is not a problem from my side. :cry: Maybe you could show this to the developer just so he sees that I'm not doing anything crazy? If you are not using any MIDI Processor, we are talking about less than 1k. Crazy eh?

He included this code:

void WusikX42_pluginAudioProcessor::getStateInformation (MemoryBlock& destData)
{
if (hasLoaded && pluginInstance != nullptr)
{
MemoryBlock xData;
pluginInstance->getStateInformation(xData);
//
MemoryOutputStream outStream(destData, false);
outStream.writeByte('W');
outStream.writeByte('S');
outStream.writeByte(1); // Version
//
outStream.writeInt64(xData.getSize());
outStream.write(xData.getData(), xData.getSize());
//
outStream.writeBool(showTopMenu);
outStream.writeInt(getCurrentProgram());
outStream.writeDouble(overSample);
//
outStream.writeInt(midiProcessors.size());
ARRAY_Iterator(midiProcessors)
{
outStream.writeString(midiProcessors[index]->getName());
//
MemoryBlock xData;
midiProcessors[index]->getStateInformation(xData);
//
outStream.writeInt64(xData.getSize());
outStream.write(xData.getData(), xData.getSize());
}
//
outStream.flush();
}
}

Does this help any in figuring out the problem?

By the way, the exact error message I get is
"plugin settings data is oversize
some or all settings may be lost"

I was doing of editing of midi data in MWS, and every few changes, without saving the EDL, the above message would pop up.

I verified that X42 was involved by setting all 32 bit plugins in its list to "unbridged" which leaves those plugins working as if X42 was not there.

[Bob L]

The code does not really help solve the issue....

Try this test to see for sure if X42 is involved.

Unpatch the plugs and save the edl... then patch the plugs and adjust their settings and then save the edl as a different name... compare the sizes of the two edls... if the one with the plugs is much larger, then something in the plugin group is storing large amounts of data to the host.

Bob L

[Cary B. Cornett]

The code does not really help solve the issue....

Try this test to see for sure if X42 is involved.

Unpatch the plugs and save the edl... then patch the plugs and adjust their settings and then save the edl as a different name... compare the sizes of the two edls... if the one with the plugs is much larger, then something in the plugin group is storing large amounts of data to the host.

Bob L

Ah. I suppose I could do that. What I DO know is, by running the plugins directly instead of bridged thru X42, the problem goes away.

[Cary B. Cornett]

Just got a beta for a bug fix in X42. Sounds like William K. may have found the problem. I'll report on testing in a few days.

[Cary B. Cornett]

After testing, I find the beta bug fix of X42 did not fix the problem. I decided to compare EDL file sizes. The session has close to 60 tracks. Track 54 and track 55 have VSTi's on them, in both cases Plogue Sforzando. For test purposes, these were the only bridged plugins in the session when I got the
"plugin settings data is oversize
some or all settings may be lost"
error message.

I finally did what you told me and ran a file size comparison using the same session. I created three versions:
The first is without the two VSTi's, size listed is 263 k.
Next with the two VSTi's in, but not using X42, size listed is 265 k
Then with the two VSTi's bridged thru X42, size listed is 265 k.

I don't get it. This says that x42 is not affecting EDL file size, or at least not enough to show. Could a difference in settings data size of less than 1 k cause this error?