Linux public beta (4408)

[Subarumannen]

Ok, thanks a lot

/Anders

[Subarumannen]

Abique

No other users reported "out of tune" issues after pitch bend or modulation occasionally?

Ps: have not tested win or OSX versions of the software so I have no idea if this is specific to Linux builds.

/Anders

[fortklang]

No other users reported "out of tune" issues after pitch bend or modulation occasionally?
/Anders

I´m using Zebra since there is a Linux Port. Never noticed hanging pitch bend or other controllers, except when the controller data got cropped by the host. Do you have this issue while playing with keyboard or
while sequencing? What host are you using?

[Subarumannen]

I have been experiencing this both with Carla as host and Ardour 4.7

This is when playing on my m-audio oxygen 61 controller and it does not affect all presets but some. Using Moog patches and other really expressive stuff seems to trigger this. I can imagine not all people noticing the pitch problem but it certainly is a problem and as I wrote, no other software have had this issue running on the same hardware. I could record a short clip where the problem occurs so you can hear.

/Anders

[abique]

Please try to send an email to support@u-he.com. Your issue does not seem to be linux specific.

[bmrzycki]

Anders, don't rule out a controller problem. As keyboards age the springs that hold the pitch wheel can lose their strength and prevent the wheel from going back to center. You mentioned "expressive" stuff: does this mean you're using more of the controller features on these presets? Does it only happen when you touch the wheels?

You might want to try recording a sequence and checking the note and control data lanes.

[lentferj]

I'm using Archlinux, with the stock kernel, a recent i7 (and fast), and bitwig as an host.
Works very well.

So, finally I got a refurbished Lenovo Thinkstation with 2x6 Core Xeons at 2,9 GHz and 16GB RAM .. what a difference .

[Subarumannen]

Anders, don't rule out a controller problem. As keyboards age the springs that hold the pitch wheel can lose their strength and prevent the wheel from going back to center. You mentioned "expressive" stuff: does this mean you're using more of the controller features on these presets? Does it only happen when you touch the wheels?

You might want to try recording a sequence and checking the note and control data lanes.

I just noticed that my trusted old m-audio axiom 61 is indeed acting up. Sometimes (way too often) the pitch bend goes back to midi value 63 or even 62 instead of the much preferred and correct value 64

Thanks for this heads up. I need to change this keyboard or try to adjust it sightly.

No bug and sorry for the OT noise.

/Anders

[josander]

Hi,

I'm really not sure that this is an u-he (4408) problem or not, but I choose to start here because this problem only occurs with the u-he plugins on my system:

Diva, Presswerk and Uhbik (A) does not respond to click in the chassis part in the GUIs and right clicking when using Mixbus 3.6, Mixbus32C 3.6 and Ardour5 as hosts. Everything is fine when using Carla and Qtractor as hosts.

So on the Ardour (GTK) based hosts, when I'm clicking at the u-he logo or try to bring up a menu, nothing happens. This also goes for scaling the UI and. In Presswerk, I can't for example get the "INIT VIEW" menu up so I can choose the simple skins either. All buttons and knobs seems to work.

This are among other working plugins I use: Pianoteq 5, Discovery PRO, Aspect and String from Loomer. Just sayin' in case it might be a toolkit issue.

I'm using Kbuntu 14.04 LTS 64 bit lowlatency with the KXstudio repos connected. The PC is an Intel based one and I'm using the CPU's GPU.

I hope you can figure it out. If not, then I contact the Harrison folks in the hope that the problem is there.

Thanks for making Linux versions of you excellent stuff, I have already purchased licenses for Diva, Presswerk and Uhbik and they have opened a new universe for me!

Jostein

[kmatheussen]

Hi,

I don't know if it's supposed to be like this, or if it is a general bug not specific to the Linux version, but here it goes:

In the Filterscape plugin, the step sequencer is not started from the beginning when starting to play. Perhaps there is some button I need to press for this to happen? In case, I haven't found it in the GUI or the documentation. The step sequencer is not synced until after 2 bars have been played.

I have tried both Radium and Ardour, and it's the same behavior in both hosts. I've also checked the values of the VstTimeInfo object sent to the plugin from Radium, and I'm pretty sure it's correct. "tempo", "timeSigNumerator", "timeSigNumerator", "timeSigDenominator", "ppqPos", "barStartPos", "kVstTransportChanged", etc. are all correct. This is of course further confirmed since Filterscape behaves the same when when used in Ardour.

I've also searched the u-he forum here, and googled it, but haven't found anything about the issue.

[kmatheussen]

Seems like it's the same behavior in the Windows version. I also see that the "Trigger" value determines how many bars to wait until the step sequencer will be synced. I don't understand this though. Why isn't the step sequencer synced immediately when starting to play, instead of waiting a defined number of bars? (and it's not possible to set the trigger value to 0).

[StudioDave]

Hi,

I'm really not sure that this is an u-he (4408) problem or not, but I choose to start here because this problem only occurs with the u-he plugins on my system:

Diva, Presswerk and Uhbik (A) does not respond to click in the chassis part in the GUIs and right clicking when using Mixbus 3.6, Mixbus32C 3.6 and Ardour5 as hosts. Everything is fine when using Carla and Qtractor as hosts.

So on the Ardour (GTK) based hosts, when I'm clicking at the u-he logo or try to bring up a menu, nothing happens. This also goes for scaling the UI and. In Presswerk, I can't for example get the "INIT VIEW" menu up so I can choose the simple skins either. All buttons and knobs seems to work.

Hey Jo,

I just checked this behavior with Ardour 5.1.15, my build from latest git sources. I tested ACE and Diva, right-clicking worked as expected, all menus appeared and work. What build are you using for Ardour ?

Btw, the GUI resizing doesn't work properly in A5 here, the display is truncated. Closing/reopening doesn't help, I'll report it as a bug. Resizing works in Bitwig.

Thanks for making Linux versions of you excellent stuff... they have opened a new universe for me!

Amen to that.

Best,

dp

[tasmaniandevil]

Seems like it's the same behavior in the Windows version. I also see that the "Trigger" value determines how many bars to wait until the step sequencer will be synced. I don't understand this though. Why isn't the step sequencer synced immediately when starting to play, instead of waiting a defined number of bars? (and it's not possible to set the trigger value to 0).

The trigger feature will reset the step sequencer (also the lfo as well as the snapshot morph) to the first step (or the step that you determine as the starting step) each time the specified number of bars has been played. It will/should also reset to the first step whenever the host starts playback. If it does not do that, then it's simply a bug (thanks for spotting the issue). I cannot test this on Linux, but it works on Mac. So it might eventually be a bug specific to Linux and/or Windows. Another possibility is that it only happens in some hosts but works correctly in others. For example, there is currently a problem in Reaper, where this reset does not work every time the host playback jumps back to the start. This does not happen in other hosts (as far as I am aware).

[Subarumannen]

Btw, the GUI resizing doesn't work properly in A5 here, the display is truncated. Closing/reopening doesn't help, I'll report it as a bug. Resizing works in Bitwig.

Removing the resized plugin and adding it used to work and make the plugin display correctly with new size.
Have not tried with latest Ardour yet

[kmatheussen]

Seems like it's the same behavior in the Windows version. I also see that the "Trigger" value determines how many bars to wait until the step sequencer will be synced. I don't understand this though. Why isn't the step sequencer synced immediately when starting to play, instead of waiting a defined number of bars? (and it's not possible to set the trigger value to 0).

The trigger feature will reset the step sequencer (also the lfo as well as the snapshot morph) to the first step (or the step that you determine as the starting step) each time the specified number of bars has been played. It will/should also reset to the first step whenever the host starts playback. If it does not do that, then it's simply a bug (thanks for spotting the issue). I cannot test this on Linux, but it works on Mac. So it might eventually be a bug specific to Linux and/or Windows. Another possibility is that it only happens in some hosts but works correctly in others. For example, there is currently a problem in Reaper, where this reset does not work every time the host playback jumps back to the start. This does not happen in other hosts (as far as I am aware).

Hi, I've tried Radium under OSX too now, and it doesn't work. I guess it must be something in Ardour, Reaper and Radium that makes filterscape fail. As I said, I've checked the timing data sent to filterscape from radium, and it was all good as far as I could see. Is there a different way to tell the plugin that we start playing than setting the kVstTransportChanged and kVstTransportPlaying flags?