ARM updates galore beta round 01 revision 11152

[UmFuFu]

Real time scale changes are not implemented yet, it's something we are looking into, but it takes some time to make it work with the different voice circuit architectures of our plugins.

Okay thanks. Glad to hear that you're looking into it!

[cantaloupe]

I notice that the "PythA432-1" tuning sound different if i run it locally in Hive vs running it in MTS-ESP Mini. Maybe something i should write to ODDsound about, but thought i should mention it here anyhow.

[tasmaniandevil]

I notice that the "PythA432-1" tuning sound different if i run it locally in Hive vs running it in MTS-ESP Mini.

Yep, this might be something for Oddsound to investigate.
If you load it into Hive, and play the A at 440Hz, it is being tuned to 432Hz.
If you load the tuning file into the MTS-ESP plugin, it is getting tuned to 441.4Hz.

[saxofonbrian]

Thank you for this update!

It's so nice to have many Diva's in divine mode, on a silent MacBook Air M1. This is a dream come through. Just now enjoying 'BS Beauty Pad', now it's so smooth and wonderful sounding.

Kind regards
Brian

[nilhartman]

vst3 64bit, Live 11.0.2, Win10 20H2 : I can't get Live to detect most of these new builts, no matter if I uninstall / install these new versions, or proceed to deep scans of plugin folders etc. Had to reinstall previous versions instead.

[tasmaniandevil]

vst3 64bit, Live 11.0.2, Win10 20H2 : I can't get Live to detect most of these new builts, no matter if I uninstall / install these new versions.

Yes, we are aware of this.
But so far it's a total mystery to us what's going on in Live with the VST3 versions.
Some revisions do show up normally, and other revisions get scanned, but then simply vanish.
And sometimes a few of the plugins appear, while others with the same revision are not showing up.
We are currently investigating this issue.
It seems to be a Windows issue with Ableton Live (no problems on Mac), and only the VST3 is affected (VST2 plugins all show up).

[spacelake]

Anyway: I thought that with the introduction of the inverted scroll direction settings, the direction of the 2-finger up-down drag (trackpad) on a knob would also invert.
On every other plugin when you drag up the knob rotates right.

The scrolling direction preference for the preset browser already took multiple days to get it right, and this was just one control element.
Getting this done for all knobs and faders and menus in all plugins is a challenge we just couldn't tackle right now.

Can we at least hope the mouse scroll direction for knobs will also be implemented at some point? I often use Repro and bx_oberhausen (which uses the opposite, and imho natural, direction) together and it's frustrating to keep switching between them.

[tasmaniandevil]

yes, once we tackle this for the menus and control elements, the mouse scrolling direction will also adjust automatically.

[Weasel-Boy]

I apologize if this has been mentioned elsewhere in this thread. I have noticed that the new latest build of Hive 2.0.1 really creates quite an overload glitch as I switch from preset to preset. This is something that did not occur in the previous build.

This is within Cubase 11 running 10.14 on a 2010 12 core MacPro.
Not a showstopper, but reasonably annoying.

[muki]

[…]latest build of Hive 2.0.1 […]

2.0.1 (as of rev9709, january 2020) ?

the current afaik is 2.1 rev11037 (march 2021)...

also mojave here but on logicX
i can see a CPU load peak upon preset change but nothing too dramatic
(good old mini i7 from 2012)

[Weasel-Boy]

Typo. The latest build...the one at the top of this thread.

[tasmaniandevil]

There is no Hive beta in this thread, the current version is the release version 2.1 (revision 11037).
And we haven't changed anything regarding preset loading between Hive 2.0.1 and 2.1, it works the same as always.

[submerge]

First time checking in for a while, good to see these are available, thanks!

I just got an M1 MBA as a toe in the water to run alongside my production i9 Mac. I'm consciously *not* putting Rosetta on the MBA at the moment, but it seems even if these plugins are M1 native/universal, the u-he installer requires rosetta to run which was a surprise.. is this a temporary measure?

Thanks again for your efforts so far!

[Urs]

is this a temporary measure?

I don't really know. If I'm not completely mistaken, the Installer is not an application itself, it's an archive to be opened in Apple's own installation tool for non-Apple-Store applications. Looks like this isn't running native then...

[Lady Gaia]

I don't really know. If I'm not completely mistaken, the Installer is not an application itself, it's an archive to be opened in Apple's own installation tool for non-Apple-Store applications. Looks like this isn't running native then...

Installer packages are indeed considered documents to be opened by Apple's own installation app, but for compatibility reasons the installer can run in either Intel or Apple Silicon native modes. It is, itself, a Universal app but it looks for an overt signal in the package to confirm which mode to run in (defaulting to Rosetta mode as there are installer packages that contain scripts which may have made awkward assumptions previously.)

Your distribution package XML descriptor must include the following option to avoid the Rosetta requirement:

hostArchitectures="x86_64,arm64"

This should be the default behavior for the productbuild command on Big Sur, suggesting that perhaps the final packaging is being done on a system running an older OS build? In any case, hopefully that's enough of a hint to resolve the issue before your final releases go out.