hi
remote control is a good idea but…why i can’t assign my mpk mini knobs with learn option???
if is impossible to map a generic controller to this, this new feature is useless…cubase needs learn on fly with all kind of midi controller!!!
Hi panox80,
Please kindly refer to the following guide for more details. Apart from that, you could also refer to the user manual too. Thanks
hi sming,
thanx for reply
you show me what i see on video tutorial…how to map that is not hard to understand…but is useless if i need a specific controller and i can’t use mine,i want to use what i have and i don’t want to spend money anymore…i really don’t understand that…sorry but i see too many stupid option for a remote control (6 option how to select the knob rotation??? are you kidding me???) …please please and please,correct this problem in the next program update
p.s…program crash often when i try to configurate this (without results)
Hi panox80,
Thanks for your notes.
As described in the corresponding thread/discussion/statements. The RCE is designed to help arranging the plugin parameters more conveniently for the hardware that supports direct Plugin access and editing in their existing design. So, the generic remotes that do not equipped with such direct plugin editing functions would not be able to make use of the RCE.
Ok, let’s put it this way for an easier comprehension: The app designed for iOS (namely the Ipads or Iphones) could be forcefully loaded or installed onto an Android phone if you insist to do that, but this doesn’t bring any useful meaning and may even cause the system to crash. This is simply because that particular app is not designed for the Android platform, even though both are categorized as smartphones… you see the analogy?
While you have the freedom and right to claim a feature useless with stupid options, etc. The truth is that, many other users out there who can make use of this are working happily with the improved situation. And certainly, this does not interfere with the established generic remote setup workflow that one could still achieve in the Device Setup as usual. Thanks for your understanding.
dear friend
i dont’ understand why you don’t create this for all controller midi,and you focalize on things that a normal or professional user maybe don’t use…anyway,i’d like that this remote controller can be used with all midi device because mapping on the fly a midi command on cubase is not fast,in the description of remote controller you had wrote this
Remote Control Editor supports Avid System 5 MC, Avid Artist Series, Mackie Control, Steinberg Houston, WK-Audio’s ID, Yamaha DM2000 and more right out of the box.
but in the option i see only the 4 device…it’s strange,and i don’t understand why you block to these device this great remote assign
anyway,I did not mean to be offensive but just say my point of view,and if you take into account to unlock all the midi controller this option, the program takes a giant step … you should listen to some 'of those who spend more money on your products, and do not limit yourself to a narrow point of view more
example…i want to map a filter on kick…well 2 click and its done with remote controller…i want to map a dry wet of my delay…well…2 click and it’s done,so i can try many way on production…withouth remote…i must to go…preference and bla bla bla…to many time to map a knob (this is my opinion)
cheers
Hi,
I totally agree that extending the RCE for supporting the generic remotes would make a huge step as a great improvement and we do realize that this is important to you and us. In fact, this has been discussed since a while ago in different threads, which have been merged into a single discussion in the following link. You can find the answer towards to end of the discussion: Steinberg Forums
Anyway again, the offered solution is targeted for a use case that is rather different from those of generic remotes, and you would understand this if you have been working with one of the mentioned devices, or at least are acquainted with the concept difference between general MIDI standard, Mackie Control and EuCon Protocol, etc.
So, it is definitely not that we intentionally block nor refuse to support the GR domain. It’s just that GR does not equipped with the necessary functionally in the first place (in this case, the direct VST plugin editing capability) while the similar solution for GR is itself an independent and powerful feature of its own, which is technically very different for the current RCE as mentioned before in the given discussion. And that would practically requires some time.
Hope that this clarifies. Thanks and appreciate your kind comments and suggestions.