I find it a bit worrying that the MIDI feedback issue isn’t even really acknowledged as a problem by Steinberg. The only real response I ever saw here was to just ‘turn off hardware feedback’, which of course makes no sense in terms of solving the actual problem.
A clear “Yes, that is a big problem and we’re working on it” shouldn’t be too much to ask.
And break their code of silence, we can live in hope come on Steiny you know we love you but we want our controllers to work so pretty please with a little icing on top ,please can you give us a hint to which century ( joke )we can expect this
But yeah as above mentioned… do we just keep this discussion alive to try to get some attention?
I also feel like we are lacking an acknowledgement that this is a big problem (or even a problem to begin with).
Yeah, it´s pleasant to look at VSTLive forum, where devs are daily in contact with costumers and solving problems, giving info and asking workflow improvements for the software. I wonder, if these products are from different companies.
GEnerally speaking Steinberg should definitely work hard to make programming via a programming language unnecessary and instead deliver a full blown editor to design midi remotes.
Of course the scripting laguage should stay… for those who are willing to spend much time in technical things. Sciptprogramming Remote Controller’s Interaction with cubase appears to be a hobby or profession of its own, that heavily interferes with the time spent for making music - especially for those of us who are working through the day and maybe also have a family to care for. The remaining time is for music, and should not be eaten up by programming.
I think the scope of the whole project fell just a little short of the mark.
It wasn’t an irrational plan though! Have a surface editor for the average user, and then have an API for manufacturers so that they can provide Steinberg with scripts for their toys if they want.
My view (and I could be very mistaken of course) is that the “average” user apparently wants to do a lot more with the Remote than what was initially predicted and planned, and manufacturers, well… I don’t know if there’s much eagerness to make the effort. It’s probably a situation of Steinberg telling controller brand X “Hey, we’ve got customers, if you provide a script they could become your customers too!” and X says: “Nah, I’ve already got enough customers, but if you support my ControllerX, they could become your customers too!”…
So, until this “you first” situation settles and as the MIDI Remote is being expanded upon to fit our needs, we “average” users try our hand at scripting. I don’t have a doubt that a hairdresser might be able to write a mean fugue, or that a tiler might be able to accurately recite the apparent magnitude of many stars, but I suspect that a programmer would do a better job at scripting than a musician.
The MIDI remote is just that editor. I think some people underestimate the complexity of things. e.g. When one turns a rotary encoder on a MIDI control surface, the response from Cubase depends on the focus that a control or window has. The idea to have Focus Quick Controls and Track Controls was trying to make this more obvious and at the same time, the interfacing more intuitive and predictable.
Now we have MIDI remote, but Cubase will never be able to guess what the user is trying to accomplish. So for some interaction, it just may be better to use mouse and (QWERTY) keyboard .
And I repeat myself when promoting the iPad Cubase remote control, (Works great)
I hope you are not saying that it would be impossible to implement a decent and (almost) complete midi remote editor that does not require script programming.
If someone thinks that this is the case, he/she is absolutely missing the available options and technology. Of course it is not trivial - but it could be done.
(I must add: I have a degree in computer science and been into programming on most complex matters - my point is: In my hobby, which is MUSIC - I dont want to be forced into programming, since my time is limited. The idea of the script language is a great addition/extension for a relative minority and should of course be available. To not fully exploit the potential of a non-script editor simply is a programmer’s idea of how things should be solved and not a musician’s).
Let me add an analogy: Instead of giving you an motorized drill I would offer you the tools you need to build a motorized drill. … this would be great concerning flexibility, but an absolutely not sufficient idea for those who just need a working drill.
The trouble with the MR is that the surface editor method of creating a decent mapping isn’t up to scratch, and the API is primarily aimed at manufacturers, but won’t see the support required as it’s constantly subject to changes.
Look at the Novation factory mappings as an example, already broken in the recent update. Yet Steinberg want us to contact manufacturers to get their hardware compliant?
It’s pointless asking manufacturers at this point in my opinion. And therein lays the biggest issue, this should have been a public beta, not a paid for feature.
But to sing it’s praises, It does accomplish many tasks very well.
You are absolutely that Cubase itself is a huge complex program that has to keep track of a lot, and just implementing a brand new feature can be a huge ordeal.
However that’s not exactly the problem at hand here.
Part of all the frustrations above stem from the MIDI Remote Editor being really nice to use, and it solves many nice things that we couldn’t achieve with the Generic Remote (albeit also removes certain important mappings that we could do before).
However, it is fundamentally broken in a few ways that Steinberg had solved perfectly in said Generic Remote.
I believe that it is down to them not having either time nor resources (same thing really, isn’t it?) to test the new MIDI Remote Editor properly. Testing multiple controllers controlling the same things, as well as controllers with motorized faders, encoders should be a no brainer, as they are very common.
Also testing to ensure that expected values are sent and interpreted correctly should’ve been tested in a more automatic fashion, as it’d be very easy to detect that it produces incorrect values (truncated, as opposed to rounded).
All of this worked perfectly with the generic remote, and what we have been frustrated about for a year by now is these fundamentally broken parts of it, which means that the only way to actually use it is to code our own scripts.
Some comment above points out that musicians can probably hack away at it and make it work, but a programmer would always do a better job (I’m not so sure).
This is kinda true, but many of us are programmers and music is our hobby, so we have a lot of really knowledgable people here who could make things work.
This is going on a year now, and still no real acknowledgement from Steinberg that this is a problem, and no indication on it being worked on, so for all we know it might just never happen.
We need to know what is going on with this.
It does everything with buttons i need , haven’t even bothered with other stuff just avoid disappointment .But im glad to see you have come over to the darkside and we finally agree on the MR behaviour . Buttons , can’t fault it but the other half on my controllers , not a chance
It would be nice if I could find a place where other users have put up their instrument maps. I have A Yamaha MODX, ES7, Yamaha E473 ,Roland Jv1080, Korg 05R/W. Boss RC505 mk2 Boss BR808, Behringer XAir x18. I am sure someone would have built maps for some of these instruments? Why is Steinberg so bad at putting up resource sites that can not be found. Anyone know where I can find these things?