Uhe midi learn

Official support for: u-he.com
RELATED
PRODUCTS

Post

I have two u-he products (diva, colour copy) and two midi controllers, and for the life of me cannot get midi learn to work on either of them. The midi learn page does not map a parameter and neither does creating a listing in the midi table. Midi learn works fine with other vsts. I can usually get a parameter to map to a control using track automation (reaper). It has to be something simple.

Post

If you're using VST3, that's why. MIDI Learn was only just added to the VST3 spec and U-he synths will need to be updated to support that. Likely not anytime soon. Use the VST2 version for mapping and the mapping will work when you next launch the VST3.

Post

Good one!!!! Never thought the midi learn page was a mock up and the manual describing its use only applies to the old version. But I do feel the pain of a dev whose products break because new standards roll out that are not backward compatible.

Post

rsturge wrote: Tue Apr 23, 2019 2:36 am Never thought the midi learn page was a mock up and the manual describing its use only applies to the old version
Our VST2 and VST3 plugins are exactly the same version internally, the VST3 plugins are not newer than the VST2 plugins.

The MIDI learn page is not a mock-up, it's fully functional in any plugin format, except VST3.

The background here being that when VST3 surfaced, Steinberg dictated in the VST3 standard that MIDI controller assignments have to be handled by the host software, not the plugin. We went ahead and did it anyway, originally, but that created a world of trouble and irrational behaviour for both us and our users.

In the end, we decided to conform with the (then) ruling VST3 standard, and to just strip the MIDI learn functionality from our VST3 plugins entirely, which is what the current state of our VST3 plugins reflects.

A few months ago, it seems that Steinberg redecided. I believe the VST3 standard no longer "forbids" that plugins handle MIDI controller assignments, but now officially "allows" it.

Which is such great news for us, because now we can finally try to figure out how we can allocate the necessary time and resources to re-implement something that makes our plugins conform to the standard again, which we formerly had to un-implement in order to conform with the standard. :tu:
Cheers
Rob
u-he | Support | FAQ | Patch Library

Post

I feel your pain. To avoid clutter, I only installed the VST3 , but now that I have had to think about it, I can't see any reason to use the VST3 version, unless there is some feature you were able to add in the new format that makes it better than the old format.

Post

There isn't.

Post

rsturge wrote: Wed Apr 24, 2019 3:15 am I feel your pain. To avoid clutter, I only installed the VST3 , but now that I have had to think about it, I can't see any reason to use the VST3 version, unless there is some feature you were able to add in the new format that makes it better than the old format.
There is nothing substantially wrong with either format in general.

VST2 has been around longer, it's tried and tested, people have found stable ways to work around the limitations of the format. For example, although one of VST3's MSPs was that it "has sidechaining", it's totally possible to have sidechaining in VST2 plugins without too much trouble, it's been done for ages.

If VST3 works for you, there's no reason to generally avoid VST3. There may be differences in the plugin's overall workflow, e.g. the MIDI assignment, or things like the parameter automation queue, "speaker sets", browsing native patches in your host software, etc. But there should be no difference in performance or quality that would make one format preferable over the other.

On the other hand, the same goes for VST2.
If it works for you, then there's no reason to generally avoid it.

I am currently not aware of any disadvantages from mixing the two formats, i.e. using some plugins as VST2 and some as VST3, so just use whichever works for you. If you wish to use MIDI learning with u-he plugins, stick to the VST2 for now.
Cheers
Rob
u-he | Support | FAQ | Patch Library

Post

I'm after getting a novation slmk2 controller but I'm not able to get it working with midi learn, anyone have issues like me ?

Post

Lectropunk aka influx808 wrote: Sat Aug 20, 2022 6:28 pm I'm after getting a novation slmk2 controller but I'm not able to get it working with midi learn, anyone have issues like me ?
Which plugin type and host are you using? How is your controller setup? That can make a big difference.

For instance, from what I recall, if you used Studio One and mapped your controller keyboard in the DAW itself, then you were forced to use Studio One's internal remote control option because it would intercept the MIDI from the controller and kind of reserve it for the DAW - blocking the CC's from hitting any plugin.

Post

Ok thanks bud I'm using ableton live 11 with diva ,hive and repro

Post

Vst 2 and vst3 , also I should mention before I had the novation keyboard I was using a roland system 1 synth with midi learn with diva, hive etc .

Post

#rob wrote: Wed Apr 24, 2019 11:05 am But there should be no difference in performance or quality that would make one format preferable over the other.
For years I've been under the impression that vst3 handles cpu management better than vst2.
I thought that a vst3 plugin is shut off when not used, while a vst2 plugin is always a bit on.
My source for this is pretty much any web page regarding vst2 versus vst3, for example this comparison which came up as one of my first search results.

Have I been misled?

Post

We're not referring to performance of a plugin that does nothing and sits idle. Sure, DAWs can tell a VST3 plugin to turn off when it's not doing anything.
What matters is the performance of a plugin that executes its task, generates sound or processes audio. When it does that, there's no noticeable difference between our VST2 and VST3 versions.

Post

krans wrote: Wed Aug 31, 2022 8:21 am
#rob wrote: Wed Apr 24, 2019 11:05 am But there should be no difference in performance or quality that would make one format preferable over the other.
For years I've been under the impression that vst3 handles cpu management better than vst2.
I thought that a vst3 plugin is shut off when not used, while a vst2 plugin is always a bit on.
Have I been misled?
The daw needs to implement this feature and at least ableton hasn't done this (yet).

Post

markus.schloesser wrote: Wed Aug 31, 2022 9:37 am The daw needs to implement this feature and at least ableton hasn't done this (yet).
This feature is also a source of bug reports every now and then, as many users are not aware of this and are wondering why the sound suddenly cuts out.
That QA guy from planet u-he.

Post Reply

Return to “u-he”