New Linux builds, updated to rev. 9775

Post Reply New Topic
RELATED
PRODUCTS

Post

lentferj wrote: Thu Jan 30, 2020 5:54 pm Hmm... tried Twangström and MFM2 on Debian Buster, Mixbus 5.3.0 (VST2) - crashes immediately on gui startup.
They do work on Bitwig 3.0.3, though (both VST2 and VST3).

EDIT: closing the gui in Bitwig takes around 5 seconds... that seems a bit long.
Hmm, a crash when trying to open the plugin GUI usually happens either because of graphics issues with a specific Linux distribution, or it's because of problems with the preset database.
If the database cannot be accessed, or if the location it resides in does not have the needed read&write permissions, then such a crash occurs.

But since you can open the plugins in Bitwig, both cases seem unlikely.
And yup, five seconds to close the GUI are weird.
So maybe it's a graphics issue in combination with the Linux version and the host.

Were the previous versions (rev. 8272) working fine in the same environment?
That QA guy from planet u-he.

Post

Subarumannen wrote: Fri Jan 31, 2020 10:11 am On a side note, Every linux build has a changelog file called LinuxChangeLog.txt but the last entry in the file is dated 2017-12-12 so it is not that useful.
I think Alex usually just adds changes specific to the Linux distribution there.
If there were no significant changes, then there might simply be nothing to add there. :)

You can always refer to the release notes on the plugin's page on our website to see what's new for official updates.
That QA guy from planet u-he.

Post

tasmaniandevil wrote: Fri Jan 31, 2020 10:47 am Were the previous versions (rev. 8272) working fine in the same environment?
Yes, no problems here with 8272. Would have to check the closing time in Bitwig, though. u-he plugins not playing well with Ardour/Mixbus isn't an uncommon problem, though ;).

The card is:
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460] (rev cf)

using the amdgpu opensource driver.

Kernel is 4.19.0-6-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux
debian_version is 10.2

Post

What about a 32-bit build? It would be great to have that, too

Post

lentferj wrote: Thu Jan 30, 2020 5:54 pm Hmm... tried Twangström and MFM2 on Debian Buster, Mixbus 5.3.0 (VST2) - crashes immediately on gui startup.
They do work on Bitwig 3.0.3, though (both VST2 and VST3).

EDIT: closing the gui in Bitwig takes around 5 seconds... that seems a bit long.
I could reproduce it. I'll look into it.
You can click on the window icon in Bitwig's device to open/close quickly.

Post

unius wrote: Fri Jan 31, 2020 11:57 am What about a 32-bit build? It would be great to have that, too
By pure curiosity, why do you need a 32 bit build?

Post

tasmaniandevil wrote: Fri Jan 31, 2020 10:50 am
Subarumannen wrote: Fri Jan 31, 2020 10:11 am On a side note, Every linux build has a changelog file called LinuxChangeLog.txt but the last entry in the file is dated 2017-12-12 so it is not that useful.
I think Alex usually just adds changes specific to the Linux distribution there.
If there were no significant changes, then there might simply be nothing to add there. :)

You can always refer to the release notes on the plugin's page on our website to see what's new for official updates.
Yeah maybe we could get rid of the Linux Changelog.

Post

Twelve updates counting HZ? :hyper: :party: :tu: :party: :hyper:
Wish I was 18, again :scared:

Post

abique wrote: Fri Jan 31, 2020 1:07 pm
unius wrote: Fri Jan 31, 2020 11:57 am What about a 32-bit build? It would be great to have that, too
By pure curiosity, why do you need a 32 bit build?
Hmmm ... there may be a lot of letters here :), but in short:
1. I use a very optimized special distribution. Before it was 64 bit, but now it is only 32 bit and faster ... than before
2. I have several applications that are fundamentally important to me, and they are only 32-bit. And no one will ever port them to 64, because it's stupid for them

Post

unius wrote: Fri Jan 31, 2020 3:12 pm
abique wrote: Fri Jan 31, 2020 1:07 pm
unius wrote: Fri Jan 31, 2020 11:57 am What about a 32-bit build? It would be great to have that, too
By pure curiosity, why do you need a 32 bit build?
Hmmm ... there may be a lot of letters here :), but in short:
1. I use a very optimized special distribution. Before it was 64 bit, but now it is only 32 bit and faster ... than before
2. I have several applications that are fundamentally important to me, and they are only 32-bit. And no one will ever port them to 64, because it's stupid for them
Why is it faster in 32 bits? Because of smaller pointer size?

Post

Just a detail.
In Bitwig, to close a plugin interface, just press again the small button on the device you use to open it, don't use the X button... takes picoseconds.
Fabrizio

Post

All works well so far here! I've been testing since last night. This weekend I'll have more time.

Same here with 'slow close' issue upon Bitwig. It takes ~3 clicks on the (x) button in order to close. The behavior is somewhat inconsistent, yet happens consistent enough. :?

I'm using Fedora 31, KDE (x11 with Nvidia latest).
Here is what xev outputs during the first three (x) clicks, about two messages per click:

Code: Select all

LeaveNotify event, serial 18, synthetic NO, window 0x6400000,
    root 0x1e6, subw 0x8800000, time 2607972077, (1046,-1), root:(2486,1319),
    mode NotifyNormal, detail NotifyVirtual, same_screen YES,
    focus YES, state 16

UnmapNotify event, serial 18, synthetic NO, window 0x6400000,
    event 0x6400000, window 0x8800000, from_configure NO

Expose event, serial 18, synthetic NO, window 0x6400000,
    (0,0), width 1130, height 680, count 0

DestroyNotify event, serial 18, synthetic NO, window 0x6400000,
    event 0x6400000, window 0x8800000

UnmapNotify event, serial 18, synthetic NO, window 0x6400000,
    event 0x6400000, window 0x6400000, from_configure NO

FocusOut event, serial 18, synthetic NO, window 0x6400000,
    mode NotifyNormal, detail NotifyNonlinear

DestroyNotify event, serial 18, synthetic NO, window 0x6400000,
    event 0x6400000, window 0x6400000
Upon the third click, the window is finally destroyed.

Bitwig outputs no messages or errors that I can see during this behavior. I believe the first time I encountered this behavior was BWS ~2.5.something. All prior versions worked without any trouble.

Wish I understood this better so I could help ...

Post

I'll look into it no worries. I could reproduce it.

Post

abique wrote: Fri Jan 31, 2020 3:19 pm Why is it faster in 32 bits? Because of smaller pointer size?
I think so. But there may also be something extra. In any case, on my 6-core Core-i7 at a good load, it's even clearly audible :)

IMHO 32 bits is the most optimal size of a machine word. It is a multiple of a byte, which is convenient. Less is bad, more is not optimal (despite all sorts of tricks). In reality, IMHO has very few tasks where a larger machine word is really needed.
Last edited by unius on Fri Jan 31, 2020 8:25 pm, edited 1 time in total.

Post

abique wrote: Fri Jan 31, 2020 6:22 pm I'll look into it no worries. I could reproduce it.
Okay, cool. Thanks!

Post Reply

Return to “u-he Linux support”