Help me love Mixbus in Linux

[jonetsu]

That's basically how the zyn interface is now... there's a more streamlined UI now which costs a few $ available, too.
Thanks for the link

Thanks - just got it now. Zyn is now a VST so no problem with Bitwig. Looks like the sounds are very nice, although haven't done much yet apart from adding a brass track to a project. The parameters do not show up in Bitwig but that's OK for now.

Then I upgraded to the just-released Bitwig 2.0 beta4 and they managed to sneak in a controller script error which prevents using any keyboard. And beta4 also needed a new activation key so I'm not sure about downgrading (dpkg -i) to beta3 right now. Darn. Will have to use Mixbus32C to explore Zyn a bit more

---

Well, it turns out that it cannot be used in Mixbus32C - it crashes each time the VST version is clicked on in the track strip. It inserts OK, although when the GUI is summoned it crashes instantly Mixbus. And works fine in Bitwig - just recorded a track, so it's hard to believe that it could be a GUI or other library problem.

[madmaxmiller]

Thanks - just got it now. Zyn is now a VST so no problem with Bitwig. Looks like the sounds are very nice, although haven't done much yet apart from adding a brass track to a project. The parameters do not show up in Bitwig but that's OK for now.

So are you using the provided sound banks or are you actually creating sounds?

Then I upgraded to the just-released Bitwig 2.0 beta4 and they managed to sneak in a controller script error which prevents using any keyboard. And beta4 also needed a new activation key so I'm not sure about downgrading (dpkg -i) to beta3 right now. Darn. Will have to use Mixbus32C to explore Zyn a bit more

I hated in Bitwig 1 that I couldn't use a midi keyboard together with JACK. I installed 2 beta in the hope I can now... but didn't try yet.

Well, it turns out that it cannot be used in Mixbus32C - it crashes each time the VST version is clicked on in the track strip. It inserts OK, although when the GUI is summoned it crashes instantly Mixbus. And works fine in Bitwig - just recorded a track, so it's hard to believe that it could be a GUI or other library problem.

I always use the standalone version with Rosegarden into a Mixbus channel...

MMM

[jonetsu]

So are you using the provided sound banks or are you actually creating sounds?

Definitively using the provided sounds. Can be tweaked, though. If I start making sounds from scratch until very nice sounding ones are made, I wouldn't be making much music.

I hated in Bitwig 1 that I couldn't use a midi keyboard together with JACK. I installed 2 beta in the hope I can now... but didn't try yet.

MIDI keyboards are working just fine with all Bitwig 1.x. configured to use jack.

I've been using Launchkey Mini, Launckey 49, Launchpad Mini and the M-Audio Pro88 keyboards no problem. It's actually much easier in Bitwig than in Mixbus since there's no need to run 'a2j_control ehw start' before the DAW can see the MIDI device and, there is no such thing as always choosing which MIDI device to use and switching the device off a track to switch it on for another track. Bitwig remebers devices. Plug a device, select a track and that's it, ready to play. Unplug the Mini, connect the 49 and play immediately. Select another track and the device automatically follows along. Very intuitive. One of those things that makes Bitwig so much useful for composing. The same in 2.0, apart from the beta4 script error they got into. So if you try it, use beta3.

I downgraded to beta3. I'll wait for them to fix the keyboard script issue. It seems to be related to a specific 8-buttons keyboard controller script.

   
   

[x42]

Well, it turns out that it cannot be used in Mixbus32C - it crashes each time the VST version is clicked on in the track strip. It inserts OK, although when the GUI is summoned it crashes instantly Mixbus.

zyn-fusion? That works fine both LV2 and VST in Mixbus and Mixbus32C on Debian GNU/Linux and Windows here. Can you get a crash report?

And works fine in Bitwig - just recorded a track, so it's hard to believe that it could be a GUI or other library problem.

BItwig process separates VSTs, Mixbus does not, so it could very well be a library problem (zyn VST isn't [yet] statically linked and shares libraries with the host) or even a gcc4/5 issue.

[jonetsu]

zyn-fusion? That works fine both LV2 and VST in Mixbus and Mixbus32C on Debian GNU/Linux and Windows here. Can you get a crash report?

Well, the one that costs $59. I'd like to try generating a crash report using Mixbus32C. How should I do that ? As soon as it is clicked to bring up the GUI it crashes everything instantly.

BItwig process separates VSTs, Mixbus does not, so it could very well be a library problem (zyn VST isn't [yet] statically linked and shares libraries with the host) or even a gcc4/5 issue.

Regarding this I would say that it should be fixed in Mixbus. Although I am sure I understand what you mean by 'Bitwig process seprates VSTs' - are these the independent plugin host processes ? If so, how can it affect loading a library ?

[x42]

OK, this is going to get rather technical.. but since you've asked

[quote='jonetsu' pid='24991' dateline='1487894399']
Regarding this I would say that it should be fixed in Mixbus.
[/quote]

It's not something that can be fixed in Mixbus.

[quote='jonetsu' pid='24991' dateline='1487894399']
Although I am sure I understand what you mean by 'Bitwig process seprates VSTs' - are these the independent plugin host processes ? If so, how can it affect loading a library ?

The library may already be loaded (also used by Mixbus). Furthermore Mixbus comes with its own set of libraries: dedicated know to work versions, which may or may not differ from system-wide available ones. (coincidentally that was the reason why u-he betas didn't work, they did use a mix of system-wide and Mixbus loaded libs, meanwhile fixed)

Plugins are supposed to be self-contained (statically linked) and not rely on a system or host provided shared libraries (except for the core system).
That's a must on OSX and Windows.. but as for Linux distros doing that: only AVLinux and KXStudio do that (if possible for a given plugin).

As for sandboxing, process separating plugins: That may work for Bitwig with 4 tracks and a couple of plugins, but it does not scale.
You may remember our previous discussion on the subject: http://lists.ardour.org/pipermail/ardour...27373.html

If you really must, use some meta-plugin (e.g. Carla) which can process-separate select plugins.

[madmaxmiller]

I've been using Launchkey Mini, Launckey 49, Launchpad Mini and the M-Audio Pro88 keyboards no problem.

I had no luck with Oxygen25 and KeyRig49. Maybe I'm just too "hardwired" to the normal Jack flow, will try again. Thx for the screenshots.

MMM

[jonetsu]

It's not something that can be fixed in Mixbus.

The library may already be loaded (also used by Mixbus). Furthermore Mixbus comes with its own set of libraries: dedicated know to work versions, which may or may not differ from system-wide available ones. (coincidentally that was the reason why u-he betas didn't work, they did use a mix of system-wide and Mixbus loaded libs, meanwhile fixed)

Plugins are supposed to be self-contained (statically linked) and not rely on a system or host provided shared libraries (except for the core system).
That's a must on OSX and Windows.. but as for Linux distros doing that: only AVLinux and KXStudio do that (if possible for a given plugin).

If a lib is alreadyloaded in Mixbus, it should be no problem to load it again in the plugin space, as required, no ? If I'm not mistaken, Mixbus has no say in this process eg. it will not ask a plugin what libs do you need and then proceed to find them and give them to the plugin. Instead, the plugin binary will load them as appropriate. Also, a plugin will not rely on libraries loaded by a DAW, no ? It would make things much more complicated.

All plugins I have seen so far in Linux are shared objects, .so. They are not static (.a). However I understand that it is certainly a very good thing to have everything included in the binary as the dependencies on the OS libs and their presence and versions is drastically cut.

So I do not understand the second part of your statement about only AVLinux and KXStudio doing that. They have no role at all in the delivery of 3rd party plugins.

If we look at the current ZynAddSubFX.so, they have no say in what get in there.

% ldd ZynAddSubFX.so
linux-vdso.so.1 => (0x00007ffd407ee000)
liblo.so.7 => /usr/local/lib/liblo.so.7 (0x00007f35a6659000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f35a643b000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f35a6106000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 (0x00007f35a5ea0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f35a5c98000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f35a5a7f000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007f35a5687000)
libmxml.so.1 => /usr/lib/libmxml.so.1 (0x00007f35a5479000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f35a5175000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f35a4e6f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f35a4c59000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35a4894000)
/lib64/ld-linux-x86-64.so.2 (0x00007f35a6c40000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f35a4675000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35a4471000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f35a424a000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f35a4038000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f35a3e35000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f35a3c2f000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f35a3a2d000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f35a3816000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f35a3611000)
libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f35a340e000)
libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f35a320b000)
libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f35a3005000)
libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f35a2e03000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f35a2bfd000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f35a29f1000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f35a27ed000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f35a25e7000)

It's not clear and this is why I'm afraid that since Bitwig loads and uses ZynAddSubFX just fine and Mixbus/Ardour does not that the problem very likely looks like it is on Mixbus side.

I have tried with Tracktion7 and it will also not load ZynAddSubFX. Eg. it will not show the user interface. T7 will not crash, though.

As for sandboxing, process separating plugins: That may work for Bitwig with 4 tracks and a couple of plugins, but it does not scale.
You may remember our previous discussion on the subject: http://lists.ardour.org/pipermail/ardour...27373.html

Yes, but what I see with my own eyes and different so this is why there is doubt about this.

12 Synths + plugins on other audio tracks. I don't think it sounds technically bad, out of sync, crackling noises, etc... Buta

Tracks were exported from Bitwig, loaded into Mixbus for mixing.

   

[x42]

Now we're really getting off-topic. but I prefer to elaborate rather than let it stand.

If a lib is already loaded in Mixbus, it should be no problem to load it again in the plugin space, as required, no ?

No, it is a problem. The symbol is already present and there is no "plugin space" every process just has one memory-space.

Some pertinent background info https://software.intel.com/sites/default...ohowto.pdf

To get a bit back on topic: It's worse on OSX where there's only a flat global namespace of symbols. Gotta love Linux for that at least.

If I'm not mistaken, Mixbus has no say in this process

It does have an indirect say. The runtime linker won't load it again or prefer already present library-functions (aka symbols). Besides Mixbus sets LD_LIBRARY_PATH.

All plugins I have seen so far in Linux are shared objects, .so.

That is the nature of a plugin, it is a shared object itself, but that plugin itself should be linked nor depend on external libs (except system-ones (e.g. libc, libm on Linux), and client/server dependent ones: e.g. X11 on Linux).

So I do not understand the second part of your statement about only AVLinux and KXStudio doing that. They have no role at all in the delivery of 3rd party plugins.

Right, I was referring to plugins that those distros package (ie free-software plugins). Also most commercial plugins are statically linked to not depend on external libs (u-he's beta's are currently an exception).

In Zyn's VST case liblo, libfftw3 and libxml are affected. The upstream zyn-fusion LV2 is already fixed to statically link against those libs.

[jonetsu]

Now we're really getting off-topic. but I prefer to elaborate rather than let it stand.

It is perhaps somewhat off topic from 'Help me love Mixbus in Linux' but not by that much as running Zynaddsubfx in Mixbus can very well be one of those things that helps the cause, although sqaurely technical now.

No, it is a problem. The symbol is already present and there is no "plugin space" every process just has one memory-space. [...] It does have an indirect say. The runtime linker won't load it again or prefer already present library-functions (aka symbols). Besides Mixbus sets LD_LIBRARY_PATH.

Right. Forgot about that. Darn host processes.

Right, I was referring to plugins that those distros package (ie free-software plugins). Also most commercial plugins are statically linked to not depend on external libs (u-he's beta's are currently an exception).

Well, I remember being able to run u-he plugins in Mixbus just fine at the beginning, before I switch all composition tasks to Bitwig. I see here and there that the u-he Linux offerings are termed as 'beta', but they run just fine. Hopefully this does no distract people away from using them.

In Zyn's VST case liblo, libfftw3 and libxml are affected. The upstream zyn-fusion LV2 is already fixed to statically link against those libs.

Bitwig is not linked against any of these so it makes sense in this case. Actually the libs Bitwig is linked against is quite a short and basic list, which could come accross as a good approach although this depends entirely on their architecture, eg how it was made, in this case using java I think which should come with its own set of utility libraries.

ldd $(which bitwig-studio )
linux-vdso.so.1 => (0x00007ffeb27bd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3d5efca000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3d5edac000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3d5eba4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3d5e89e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3d5e688000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3d5e2c3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3d5f1ce000)

Thanks for the info.