Loading Windows VSTs within Carla

[tangerine]

It was synced to git a few hours ago. Now git pull revealed several changes. Looks like you updated the code while I'd been working my way through compiling it?..
Should I recompile?

[tangerine]

here:
mxe.cc

This time I'm on their "stable" branch.

MXE automatically downloads and compiles every single tool you use, incl. the compilers themselves. So it takes a LONG time to install. Note that you cannot move the installation folder as soon as you have the stuff compiled.
I can try a different mingw32 version, but as of the latest repository updates, I got very similar messages with carla-git from the repository, so I'm not sure it's about the version of mingw32. I'm not a dev, though, so my understanding is probably limited:

Code: Select all

joe@len-3000-C200:~/Desktop/Carla-compile$ carla
Using "carla" theme
Carla 1.9.4 (2.0-beta2) started, status:
  Python version: 3.4.0
  Qt version:     4.8.6
  PyQt version:   4.10.4
  Binary dir:     /usr/lib/carla
  Resources dir:  /usr/share/carla/resources
libjack.so.0 loaded sucessfully!
Carla Server Info:
  sizeof(BridgeRtData):    4244
  sizeof(BridgeNonRtData): 16400
starting app..
WINE realtime scheduling hack enabled, realtime base priority has been set to 15
wineserver running SCHED_NORMAL
libjack.so.0 loaded sucessfully!
CarlaEngineBridge::CarlaEngineBridge("Op8dqY", "uL76ML", "ZHBKPU")
Carla assertion failure: "shmRtDataSize == sizeof(BridgeRtData)" in file ../backend/engine/CarlaEngineBridge.cpp, line 304, v1 4244, v2 4248
Carla Client Info:
  BufferSize: 2048
  SampleRate: 48000
  sizeof(BridgeRtData):    4244/4248
  sizeof(BridgeNonRtData): 16400/16400
Carla assertion failure: "count <= pData->engine->getOptions().maxParameters" in file BridgePlugin.cpp, line 1543, v1 200, v2 200
CarlaPlugin::updateOscData(0x89b46e8, "osc.udp://len-3000-C200:17190/plug-4608")
CarlaPlugin::updateOscData() - source: host "127.0.0.1", port "17190"
CarlaPlugin::updateOscData() - target: host "len-3000-C200", port "17190", path "/plug-4608"
CarlaPlugin::updateOscData() - done
Thread 26015 at THREAD_PRIORITY_ABOVE_NORMAL set to SCHED_FIFO - priority 15
CarlaEngineBridgeRtThread::run() - got opcode: kPluginBridgeRtNull
CarlaEngineBridgeRtThread::run() - got opcode: kPluginBridgeRtNull
etc.

[tangerine]

in order to prepare all the necessary tools with MXE, you can run this command:
"make gcc pthreads-w32 liblo qt curl".

Then you can go, relax, have your coffee and probably a nap...

[tangerine]

I remember the compiler requesting curl, but maybe I was confusing the environments.
Regarding pthreads, I used pthreads-w32 from their toolset because it was easily available. They also have something called "pthreads" there, but I'm not sure if it will do, as it doesn't have the "win" part in it?

[tangerine]

Maybe that's a nonsense (again, I'm just an end-user, not a dev), but could the difference come from me using a 32-bit system?

[tangerine]

That's pretty neat!
Fixed in the latest git source.
Still prints this red assertion failure, though (see the last line):

Code: Select all

joe@len-3000-C200:~/Desktop/Carla-compile/Carla$ python3 source/carla
Using "carla" theme
Carla 1.9.4 (2.0-beta2) started, status:
  Python version: 3.4.0
  Qt version:     4.8.6
  PyQt version:   4.10.4
  Binary dir:     /home/joe/Desktop/Carla-compile/Carla/bin
  Resources dir:  /home/joe/Desktop/Carla-compile/Carla/bin/resources
libjack.so.0 loaded sucessfully!
Carla Server Info:
  sizeof(BridgeRtData):    4248
  sizeof(BridgeNonRtData): 16400
starting app..
WINE realtime scheduling hack enabled, realtime base priority has been set to 15
wineserver running SCHED_NORMAL
libjack.so.0 loaded sucessfully!
CarlaEngineBridge::CarlaEngineBridge("4vJUAP", "mCissS", "JuVNk3")
Carla Client Info:
  BufferSize: 2048
  SampleRate: 48000
  sizeof(BridgeRtData):    4248/4248
  sizeof(BridgeNonRtData): 16400/16400
Carla assertion failure: "count <= pData->engine->getOptions().maxParameters" in file BridgePlugin.cpp, line 1543, v1 200, v2 200            

No other errors and plugin seems to work, but I haven't tested it yet with a signal. Also the DSP load seems too low - about 0.5%. That's with quite an extreme oversampling turned on in it.

Further testing shows that when I add a second instance (with even higher oversampling), DSP load goes up dramatically, to about 25%.
In my test, after adding the second instance and connecting the two of them sequentially in the patchbay and to the inputs and outputs, I tried to remove the first instance (right from the patchbay), and that unfortunately messed something up:

Code: Select all

Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
Trying to get window...
patchbayConnect(2, 1, 4, 42 => system:capture_1, EQuilibrium (2):input_1)
patchbayConnect(2, 2, 4, 43 => system:capture_2, EQuilibrium (2):input_2)
patchbayConnect(4, 45, 3, 37 => EQuilibrium (2):output_1, EQuilibrium:input_1)
patchbayConnect(4, 46, 3, 38 => EQuilibrium (2):output_2, EQuilibrium:input_2)
patchbayConnect(3, 40, 2, 19 => EQuilibrium:output_1, system:playback_1)
patchbayConnect(3, 41, 2, 20 => EQuilibrium:output_2, system:playback_2)
ScopedPluginAction(1) - blocking START
ScopedPluginAction(1) - blocking DONE
CarlaEngineBridge::handleNonRtData() - got opcode: kPluginBridgeNonRtDeactivate
CarlaEngineBridge::handleNonRtData() - got opcode: kPluginBridgeNonRtQuit
app finished
Cannot read socket fd = 30 err = Interrupted system call
CheckRes error
JackSocketClientChannel read fail
Server is not running
Server is not running
Server is not running
Server is not running
Server is not running
Carla assertion failure: "portNameToId.group > 0 && portNameToId.port > 0" in file CarlaEngineJack.cpp, line 1486
Carla assertion failure: "portNameToId.group > 0 && portNameToId.port > 0" in file CarlaEngineJack.cpp, line 1486
Carla assertion failure: "portNameToId.group > 0 && portNameToId.port > 0" in file CarlaEngineJack.cpp, line 1486
Carla assertion failure: "portNameToId.group > 0 && portNameToId.port > 0" in file CarlaEngineJack.cpp, line 1486
CarlaEngineOsc::handleMessage() - invalid plugin id '1', probably has been removed (path: '/Carla/1/bridge_pong')
patchbayConnect(2, 1, 3, 37 => system:capture_1, EQuilibrium:input_1)
Server is not running
Connection failed: JACK operation failed

(that's when I attempted to connect the second instance to system's input)
Cadence shows that Jack is running, though, and on my master computer I see the slave as connected. Also Carla shows that the engine is running.

[tangerine]

Update: on second attempt the messages were the same, but this time plugins did produce DSP load and, as expected, a higher load when switching to FIR and increasing resolution. Not sure what made the difference, perhaps restarting Jack?
Connecting 2 instances and then removing one of them still produced the same error, though. But hey, it's working!
Loading the plugin with abique's VST bridge still produced the same results as before.

[tangerine]

Never heard of airware, and google came up with nothing useful...
Regarding vst-bridge, if it's of any help, it worked out of the box with Ardour3, though I haven't given it a proper testing.

Anyway, looks like you are making a good progress on Carla, and I'll be happy to help with further testing.

Regarding plugin removal bug, I noticed that even after Carla claims that server is not running, the remaining Carla plugins continue to produce DSP load, so it seems that the bug is somewhere in Carla's logic or awareness of the Jack state.

[tangerine]

Interestingly, I tried to reproduce this plugin removal bug with native plugins, loading random plugins from the collection, incl. ladspa, lv2 and vsts, with and without GUI-bridging, and I could remove them with no negative consequences. Even loading, for instance, 4 different plugins and then removing them didn't make Carla disconnect from Jack. My buffer size is quite a big one (2048), maybe that's what made the difference?
I did occasionally and seemingly randomly (as this might or might not happen to the same plugin) have this message in the console upon plugin removal (always doubled):

Code: Select all

Carla assertion failure: "oscData.path != nullptr && oscData.path[0] != '\0'" in file ../../utils/CarlaOscUtils.hpp, line 230
Carla assertion failure: "oscData.path != nullptr && oscData.path[0] != '\0'" in file ../../utils/CarlaOscUtils.hpp, line 230

Even removal of a winVST bridged by abique's vst-bridge was seemingly fine. Seemingly, as I didn't test it with an actual signal running.
On the other hand, removal of Equilibrium bridged with the built-in bridge reproducibly leads to the error. So it seems to narrow it down to the built-in winVST bridge, at least in my specific 32-bit networked high-latency setup.

[stanlea]

Midi out is now or later ?

thks

[tangerine]

Congratulations on the Beta2, fortunately, I don't have a cat

[stanlea]

heh, I completely forgot again

I made a note of it now, will be done later this month.

Cool

[StudioDave]

Never heard of airware, and google came up with nothing useful...

Try "airwave vst" instead of airware. First hit from Google:

http://www.kvraudio.com/forum/viewtopic.php?p=5834788

Best,

dp

[tangerine]

Try "airwave vst" instead of airware. First hit from Google:

http://www.kvraudio.com/forum/viewtopic.php?p=5834788

Thanks StudioDave, I have already started to think there is some underground winVST bridge hidden from mortals
Will give it a try.

[tangerine]

"make win32" [in mingw32 environment] produces a considerable amount of warnings related to CarlaString.hpp.
Such as:

Code: Select all

make -C source/bridges-plugin win32
make[1]: Entering directory `/home/joe/Desktop/Carla-compile/Carla/source/bridges-plugin'
i686-pc-mingw32-g++ CarlaBridgePlugin.cpp -Wall -Wextra -pipe -DREAL_BUILD -DNDEBUG -O2 -ffast-math -mtune=generic -msse -msse2 -fdata-sections -ffunction-sections -mfpmath=sse -fvisibility=hidden -std=c++0x -std=gnu++0x -DPTW32_STATIC_LIB -I/opt/mxe/usr/include -fvisibility-inlines-hidden -fvisibility-inlines-hidden -DBUILD_BRIDGE -I. -I../backend -I../includes -I../utils -isystem ../modules -I/opt/mxe/usr/i686-pc-mingw32/include   -I../backend/engine -I../backend/plugin -DJACKBRIDGE_EXPORT -m32 -DBRIDGE_PLUGIN -c -o CarlaBridgePlugin__win32.o
In file included from ../utils/CarlaBackendUtils.hpp:23:0,
                 from CarlaBridgePlugin.cpp:21:
../utils/CarlaString.hpp: In constructor 'CarlaString::CarlaString(long long int)':
../utils/CarlaString.hpp:144:50: warning: unknown conversion type character 'l' in format [-Wformat=]
         std::snprintf(strBuf, 0xff, "%lld", value);
                                                  ^
../utils/CarlaString.hpp:144:50: warning: too many arguments for format [-Wformat-extra-args]
../utils/CarlaString.hpp: In constructor 'CarlaString::CarlaString(long long unsigned int, bool)':
../utils/CarlaString.hpp:158:75: warning: unknown conversion type character 'l' in format [-Wformat=]
         std::snprintf(strBuf, 0xff, hexadecimal ? "0x%llx" : "%llu", value);

I really have no idea if these have any significance, but as it seems that Carla's bridge for winVSTs still has some stability problems (and the rest of the code is compiled without warnings), I thought I should point this out.