MIDI Remote, Relative value mode

[thomas_martin]

Hi @vagglyren,

Well learning coding for the API wouldn’t take this long. There are tutorials online which could bring you up to the task in a few hours.

As for your problem, what is your controller actually? Is it using endless encoders or a potentiometers? Does it come with a software that allows you to change its configuration?

There are different MIDI messages and they’re not all made equals. The most common message used by a MIDI controller to send a message is standard CC which can range from 0-127 (7 bit message).
RPNs and NRPNs use several CC messages to give 14 bit resolution, ranging from 0 to 16383 but your device has to support it.
Some devices with endless encoders will also send different values for clockwise / counter-clockwise movements. Now the number of steps is the one that Cubase uses natively. Again, your device has to support it.

MIDI remote can be set to receive all these different messages, but if your controller can’t send it, then you might try to write a script for it yourself, hire someone to do it for you or buy a different device.

Bests,

Thomas

[mlib]

Just wanted to say I fully agree with both @skijumptoes and @thomas_martin.
What make and model is your controller? There is a chance that someone owns the same device.

[vagglyren]

@mlib
I do not think anyone does since it was just released basically.
It is the Icon P1-M from Iconproaudio.

By the way, do you know how I do those slick image quotes that is really handy to use when someone has made several points in one post. (light blue background)

[u-man]

@thomas_martin

Well learning coding for the API wouldn’t take this long. There are tutorials online which could bring you up to the task in a few hours.

DREAM ON. Absolutely not true. Documentation wise, is the midi remote and very especially the API, one of the worst i have seen in my entire life.

@vagglyren

@u-man
I see you mention Bome Midi Translator pro here as a workaround. I have 0 experience with coding, but perhaps this is much simpler? And does it work well?

Bome Midi Translator pro is a very powerfull MIDI tool, that is WAAAAAY easier to learn, then any Steinberg related midi remote+API stuff. Most of the time, a user will use (midi) terms and language that is familiar to a musician. Therefore most of the tasks can be done by a total noob. If you need to learn something, then these things you learned can be used in other (midi) projects too. So you did not learn something that is completely useless unlike the JavaScript API, where outside the scope and task you might ask yourself, where you can use that “knowledge”, as JavaScript is NOT something common for MIDI communication.

With Bome Midi Translator pro and my Mackie C4 midi controller, i can control my complete midi hardware studio setup: TWELVE Synthesizers, one drummachine, three FX units and my mixer. All with one controller, all very powerful and with every aspect that these machines have to offer: 7-bit, 14-bit, RPN, NRPN, Pitchwheel etc. No matter what you throw at the C4, it handles everything well. If you can understand the (midi) manual of your hardware, you can do basically everything what the manual offers… easy peasy.

In Cubase however, i can not do a $hit with the very same controller to control the DAW. Its practically useless and the (very) limited things that are supported, are not even close to the potential that this controller has to offer.

If the API would be something like Bome Midi Translator pro, then it would be gorgeous and a fantastic thing, but sadly it is only something for coders and not musicians.

Bome Midi Translator pro can NOT help you much regarding this topic and if you are not familiar with JavaScript. Regardless it is still a very nice and powerful tool. A must have, if you want to do serious midi-communication stuff.

BUT BACK TO TOPIC:
I am really buffled and wondering, what kind of people develop or work for Steinberg, that they are NOT AWARE of what relative encoders have to offer or what it really means to have the full scale range and what you can do with this. Maybe they think, it does not make a huge difference if you have 127 steps or 1024. I know at least the EQ case would benefit from a better scaling.

[thomas_martin]

@vagglyren

I do not think anyone does since it was just released basically.
It is the Icon P1-M from Iconproaudio.

Why not? Icon are quite popular control surfaces.
And anyway, it givers us a lot more information.
Using the imap software, you should be able to set encoders to relative mode and therefore have the best resolution. If you use the device in macki control mode, encoders will be in relative signed bit.

@vagglyren

By the way, do you know how I do those slick image quotes that is really handy to use when someone has made several points in one post. (light blue background)

Select the text you want to quote and click on “Quote”.

[vagglyren]

Hi @thomas_martin

Coding API - Could you link some of. these tutorials and maybe I dare to put myself to the task?

My controller - Icon P1-M by Iconproaudio using encoders.
It comes with “imap” that allows it to change various things, but I am not sure it does the things necesary (I am somewhat of a rookie)

I THINK the values are different for the directions which would be 1 and 65?
I have to use Value Mode - Relative Signed Bit to make the encoders work properly.

To my understanding my controller is not able to put out 14 bit resolution on the encoders. However within. the software, it says that I am able to change the encoders to output pitchbend, which is higher resolution? I experienced with this but the results within Cubase ended up in only 2 values being altered, almost like an on/off switch.

Unless I have missed something that I can do within the software, my go to:s should be:

1. Script via API
2. 3rd party software
3. Pray

[thomas_martin]

@u-man

DREAM ON. Absolutely not true. Documentation wise, is the midi remote and very especially the API, one of the worst i have seen in my entire life.

Maybe you’re right but what i said is base on my own experience with the API and I’m not a developer at all. I’m building a full console with thousands of different controls, various sysex feedback, tens of subpages for various areas. and it all works pretty well to me.

@u-man

I am really buffled and wondering, what kind of people develop or work for Steinberg, that they are NOT AWARE of what relative encoders have to offer or what it really means to have the full scale range and what you can do with this. Maybe they think, it does not make a huge difference if you have 127 steps or 1024. I know at least the EQ case would benefit from a better scaling.

Relative encoders are very well handled by MIDI remote. There’s a choice of different relative mode and all parameters can benefit from it.

[vagglyren]

@thomas_martin

Why not? Icon are quite popular control surfaces.
And anyway, it givers us a lot more information.
Using the imap software, you should be able to set encoders to relative mode and therefore have the best resolution. If you use the device in macki control mode, encoders will be in relative signed bit.

I was thinking since it was just released, there would not to be any script at this moment. Icon did mention something about a potential script in their youtube comment for their “V1-M” which maybe also implies the “P1-M”
Quote from them:
“Currently it’s still best to utilize Mackie Control protocol with Cubase, but we are working with Steinberg on the MIDI Remote script.”

@thomas_martin

Select the text you want to quote and click on “Quote”.

Thank you for this

[thomas_martin]

@vagglyren

I was thinking since it was just released, there would not to be any script at this moment. Icon did mention something about a potential script in their youtube comment for their “V1-M” which maybe also implies the “P1-M”
Quote from them:
“Currently it’s still best to utilize Mackie Control protocol with Cubase, but we are working with Steinberg on the MIDI Remote script.”

In mackie control mode, it should work with user released scrtipts for icon platform M+ or other MCU based script. (x-touch…).

[mlib]

@thomas_martin

Relative encoders are very well handled by MIDI remote.

Wholeheartedly disagree. If they were well handled by MR, relative encoders would have a provision, both within the API and the mapping assistant, to handle scaling factors. If you’re ok with 7bit resolution, then it’s fine I guess. Especially since MR includes options for 3 different standards for relative CC values, something the old Generic Remote did not.

[vagglyren]

@thomas_martin @mlib @u-man

For a rookie, hearing one of you saying “this works well” and someone else says “this is garbage” I do not know what to believe

[mlib]

I’m in between “well” and “garbage”.
As you might have guessed from reading previous posts in this thread, scripting with the MR opens up a very large door of possibilities. Unfortunately, once you dig into it, you’ll find some basic functionality of the API is missing and some aspects just doesn’t work very well. You can probably find work-arounds for those shortcomings but it makes the process cumbersome, time consuming and might require 3rd party software to get you where you want to be.
Personally, I was immensely excited about MR when it was first announced and later almost equally disappointed as I was finding all of its bugs and shortcomings.
YMMV

[thomas_martin]

@mlib

Wholeheartedly disagree. If they were well handled by MR, relative encoders would have a provision, both within the API and the mapping assistant, to handle scaling factors. If you’re ok with 7bit resolution, then it’s fine I guess. Especially since MR includes options for 3 different standards for relative CC values, something the old Generic Remote did not.

Well you got me there, I didn’t realise that parameters are stuck to 127 steps using relative mode.
In fact I would have swear it was finer resolution than standard CC.

This is bad indeed…

[u-man]

@thomas_martin

Maybe you’re right but what i said is base on my own experience with the API and I’m not a developer at all. I’m building a full console with thousands of different controls, various sysex feedback, tens of subpages for various areas. and it all works pretty well to me.

I am too not a developer. Nice for you that your stuff works, but it does not work pretty well for me, not at all, to be more precise.

@thomas_martin

Relative encoders are very well handled by MIDI remote. There’s a choice of different relative mode and all parameters can benefit from it.

No, there are not very well handled by MIDI remote. They are handled VERY basic with no scaling options at all. If you want more, you can do it only via API and then as stated by others here, it is very complicated to handle.

@mlib

Wholeheartedly disagree. If they were well handled by MR, relative encoders would have a provision, both within the API and the mapping assistant, to handle scaling factors. If you’re ok with 7bit resolution, then it’s fine I guess. Especially since MR includes options for 3 different standards for relative CC values, something the old Generic Remote did not.

I 100% subscribe that. A TRUE statement, as same as the following:

@mlib

Personally, I was immensely excited about MR when it was first announced and later almost equally disappointed as I was finding all of its bugs and shortcomings.

Still own you a beer

[u-man]

@mlib

Unfortunately, once you dig into it, you’ll find some basic functionality of the API is missing and some aspects just doesn’t work very well. You can probably find work-arounds for those shortcomings but it makes the process cumbersome, time consuming and might require 3rd party software to get you where you want to be.

Not only that, but i also think many “simple” things, need a lot of code to get them working. I experienced that most of the time. In Bome MTP i need less then 10lines of code, that needs like a hundred lines in API. This alone is so silly.

Arguing about the (non)sense of having better scaling options, is like arguing about SD vs UHD and claiming that SD has nearly the same picture quality as UHD or that MP3 is superior to WAV/AIFF. Same logic.

[skijumptoes]

@u-man

Not only that, but i also think many “simple” things, need a lot of code to get them working. I experienced that most of the time. In Bome MTP i need less then 10lines of code, that needs like a hundred lines in API. This alone is so silly.

This is what confuses me really, Ok so they can’t put everything into the on-screen Mapping Assistant because they have to consider UI design and other such methods, and that all takes time across multiple staff.

But why they’re not adding basic functions into the API (such as a value scaling toggle) is beyond me. The method to incorporate scaling into your own scripts feels like a hack which works without intention, than any kind of allowance or consideration by SB.

As you know, you’re basically having to take the native hardware values and manipulate them into triggers and then on to the control itself - which then creates additional issues as you’re no longer binding to a hardware control, but to a pseudo trigger - this in itself totally undermines the binding system which the API is built around.

I thought the idea was to use the API to create a surface that works well within the mapping assistant which is where your every day mapping takes place. To my mind, scaling should be done within the mapping area (i.e. on screen when mapping a control), and not globally within the hardware layer.

In fact, there has to be something within the VST spec that would allow us to read via the API how many value steps that parameter has? i.e. 100 steps = 0.01 per notch on a relative controller.

Surely if we could read it in, then they could very easily just offer that as a ‘fine’ toggle within the mapping assistant?

You could then just have a scale options of 1:1, 1:2 or 1:3… whatever on top of that. So you get 0.01, 0.02, or 0.03 per notch for that parameter.

[mlib]

@skijumptoes

To my mind, scaling should be done within the mapping area (i.e. on screen when mapping a control), and not globally within the hardware layer.

I fully agree.
My workaround for this is to use a scale variable that is used in the OnValueChange callback. I then update this variable for each MR page.
Just another dirty hack.

[u-man]

@skijumptoes

But why they’re not adding basic functions into the API (such as a value scaling toggle) is beyond me. The method to incorporate scaling into your own scripts feels like a hack which works without intention, than any kind of allowance or consideration by SB.

We will sadly not know. I assume they are simply not aware of the benefits and what “good” midi-hardware can do.

The mapping assistant and the midi remote editor, should be the area they should pay the most attention to. If the editor would be more of a construction kit, it would be way more powerful and of importance. And i do not mean to “construct” a midi-remote, i mean the components itself. Add displays, faders add functions, that other people already have constructed. To expand the functionality of the editor by written components that can be add to the editor, so to say. Then all of that, would be another story and i would cherish EVERY new addition to the midi-remote. Currently i can only hope, that someone will write something for my controller. I guess i will need to open a new thread, exactly for this.

[vagglyren]

@u-man

I need to use Bome Midi Translator Pro, to make my Mackie C4 working properly with Cubase. With Bome, i am able to adjust a scaling factor, that is literally so fine that i would need to turn a encoder a few hundred times to make the volume fader travel from bottom to top. This would not be much practical, but it is possible. What i did, is to add the scaling factor to a button. So whenever this button is pressed, i will have that fine resolution for the encoders i want to use. If i press the button again, i return to the (absolute) values and have the 7-bit resolution back again.

You mentioned Bome won’t help me in this case, so what you are mentioning above is something different than from what I want to do? Looks like the same to me but, what am I missing here?

[u-man]

My example there, is not related to midi-remote. I created kind of a hack with Bome to use the Mackie protocol of Cubase with my Mackie C4 controller. The C4 is not MCU compatible and has no faders. To emulate the faders, i used Bome and the (fader) Pitchbend values from MCU, with the relative encoders on the C4. So i had at least the volume parameters with better scaling options. From what i remember, i had better scaling options on the EQs too, by using the flip mode of the Mackie protocol, where the faders can be used on the EQs.

Again, this has nothing to do with the midi-remote. This only works, because the Mackie protocol supports/use Pitchbend-Values for faders.