Push 2 Integration

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Ableton have announced Push 2 which will support native mapping of 3rd party plugins. It sounds as though the order of precedence for parameters will be down to individual developers to decide, but it's not exactly clear from what Ableton have said.

I wonder if anyone at u-he can comment? Would this be something that could be quickly implemented in the u-he product line and would we be likely to see it soon?

Could be that I've completely misunderstood how this works of course ;)

Post

wuh wrote:Ableton have announced Push 2 which will support native mapping of 3rd party plugins. It sounds as though the order of precedence for parameters will be down to individual developers to decide, but it's not exactly clear from what Ableton have said.
That's always been the case, any controller that maps params supposedly 'automatically' either does so on the basis of how the plugin developer has exposed params to the host and in what order, layout, naming conventions etc, or they rely on someone having set up templates in advance for the most common plugins (although that never gets them all - eg NI's new NKS standard).

Just as an example, CamelAudio Alchemy, which stopped being sold well before NI even announced NKS, has its performance controls mapped perfectly in NI Komplete Kontrol without any setting up whatsoever, the reason being that Ben and the team designed it to expose those params in a neat logical order in any host. I see no reason why the same would not be true with Push 2. Others need more work, some developers (not referring here to u-he) don't even bother to name params properly.

Post

You're right that it was possible before, but it was necessary to select which parameters to expose. Maybe that's the only thing that's changed - it happens automatically now. It sounds like u-he will probably not have to change anything.

Post

It's all slightly different. Live now automatically maps plugins that expose 64 parameters or less to the host. You could set this in previous versions via the options.txt btw, but it's now the default. I think in previous versions it was restricted to something like 8 parameters.
So, 64 parameters automatically, which means that none of the main U-He synths will be mapped by Live automatically, as they all have more than 64. You can still map them yourself like you said, and the big change in 9.5 is that you now can store these parameters as default (right click in the Device menu bar). So you don't have to do it manually each time, nor do you have to save them as a rack.
If you're not happy with the order in which the parameters are mapped by Live automatically, you can adjust them by clicking Configure in the Device, and dragging the parameters in the order to your liking.
So, all in all, for plugin developers, nothing has changed...

Post

I think the main thing is we would like is to name the pages, and also perhaps have some meta data about a parameter
(e.g. does a parameter represent dB, hz, pan etc)

and also I think the issue is many companies (including u-he) have move aways from the plugin file presets... this means to access your presets you have to save them as (e.g. aupresets) , or select them via pgm change (not nice as you don't get to see names on Push)

Does the NKS api allow plug-in developers to expose there own preset structures regardless of implementation... that would appear to be 'the missing link'

something I don't quite get though... NKS should be an open source protocol for both hardware and software manufactures, we really don't want a proprietary api, otherwise the likes of Ableton will come up with one too, and plugin manufactures will have to start implementing multiple preset apis (its already bad enough with vst/au/aax etc etc)

Post

Yeah, I wanted to rename the banks too. So I looked up the files that Live writes for each saved configuration, but I couldn't find a reference to the names of the banks (pages). I'm afraid we're out of luck there, but it would certainly be nice.
Btw, the metadata about the parameter is displayed by Push (sometimes as an abbreviation in Push 1), but it should be sent by the plugin. I've seen this requested to U-He before.

And I don't get the NKS thing either, if this really would work, it should be part of the VST standard so it's implemented across the board.

Post

Automapping sucks. Everyone has different preferences when it comes to what parameters and in what order they want to have access. I prefer to make the mapping my self.

From the developer side is more important that parameters show values in meaningful units.
dedication to flying

Post Reply

Return to “u-he”