yes …AS IN STUIO ONE!!! Please
1 Like
folder Components
Please make it backwards compatible!
So Mathias, can you tell us please, will this new API include the long promised but always ignored updates to the Eucon adapter? Six years of waiting and constant disappointment and frustration in updates for the many avid control surface users, who still can’t use mix views and hidden channels features despite years of investment and time in Steinberg software. It’s is a huge issue in large projects not mention mute/solo in vca groups and folders and other irritating bugs.
To those who sketch out how the “thing” should work: Steinberg has said they are working on a MIDI remote API - something that allows controller manufacturers to deeply integrate… unfortunately they did NOT talk about a clever way of defining a controller oneself… I am really really worried - will it be about delegating responsibility to controller providers merely?
I dont believe in an improvement in the area of self-defining a controller - because they do not speak about a new clever remote controller editor/Generic Remote Editor (that could, by the way, also replace the device panel editor, which is anyways not acceptable as it is).
Well MIDI 2.0 solves im pretty sure what you’re talking about
The whole point of the API is that they can allow third parties to support Hardware without Steinberg needing to hard code it, or to apply for the MIDI SDK and sign NDA etc.
This means that the user community will be able to define controller setups too. So yes, delegating is a huge improvement, it shouldn’t be seen as a negative, or them shunning responsibility. Very much a positive step.
I imagine:- For most users running basic controllers (i.e. such as 8 rotary/8 faders etc) it will just be a standard mapping that you can go in to an .xml file and enter your MIDI CC values for each control. Once that is done, the mapping from hardware to software instances will happen within the DAW itself.
This means that the user community will be able to define controller setups too. So yes, delegating is a huge improvement, it shouldn’t be seen as a negative, or them shunning responsibility. Very much a positive step.
There is a misconception about what an API provides. “Application Programming Interface” is a type of interfacing that is for programmers and not for users. As a consequence: Yes, it is fine that steinberg will provide a mature API. But: if this is all it will not be sufficient. What USERS need in addition is a well designed Remote Controller Editor (manipulating XML is not a USER thing, for sure not. Maybe a workaround for some, but nothing more than that). Steinberg can provide such a well designed RCE by means of the API of course. But so far I do not read a committment from Steinberg to provide such a thing. The API alone is not enough.
Your claim “this means that the USER COMMUNITY WILL BE ABLE…” is something that I want to read confirmed by Steinberg. The API alone will for sure NOT provide this automatically.
Cheers, Ernst
1 Like
if they make the API public, what is the problem? For instance, everyone has access to VST SDK.
The problem is that we need a USER Functionality to define Remote Controllers.
Users are not programmers. Will you provide a generic remote controller editor based on the API (of course this is possible - but not for normal users; you need to be a software developer of some kind to deliver that).
Ernst
1 Like
This is public API, for users too - hence it’s existence. I’m not linking to any leaked beta documentation but it clearly gives information on how to create your own hardware setups and where the files and documentation exist.
What USERS need in addition is a well designed Remote Controller Editor
All the API does is set the communication between software and hardware. When it comes to mapping those controls to track parameters, and plugins - that’s all done within Cubase via a new interface - that’s the main part the user will be focusing on and will be more akin to the Remote Control Editor which you are describing. You won’t need any programming to create mappings within the DAW, i think that’s confusing you?
There only needs to exist a few basic vanilla templates to select, and from that most users won’t need to do anything other than change their MIDI hardware to correspond with the MIDI CC ‘vanilla’ values. As i see it, the API will be purely for connecting and communication of hardware, not the mapping of plugins.
It’s just as Studio One operates, and it’s a very good, flexible, system to employ if they go a similar route. And why it’s great is that as new features get added, they can be added to the API as a command, and ALL controllers can be updated to get access to it.
If this is the case, skijumtones - if it is designed as you say - it will be more than an API - which is great. I hope that you are right!!!
cant find anything called houston…anyone know which component handles control surfaces?thank
thats a lot of work, duplicated by every user. unless you have some vintage synth / controller there should be a MIDI map available for anything made in the last 10-15 years.
- Go to Devices
- Add New Device
- CU "Add YourDevice MegaSyth 2000 ? "
- Click yes or customize settings
- YES. Done.
This kind of really smells of MIDI 2.0 as mapping / device descriptor is part of the spec 
S
2 Likes
It’s in program files / cubase (10.X) / components / your surface plugin.dll
Think of it this way: what’s more realistic? 1) Asking Steinberg to create MIDI Device maps for every piece of hardware released in the last 10 to 15 years and ship them with the update, or 2) providing users the flexibility to quikcly MIDI Learn their own MIDI devices like Studio One then maybe share those with other users?
Obviously it’s #2.
1 Like
George Bernard Shaw : “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
#1.
as for users having to do it, consider the ridiculous amount of duplicated and wasted effort of thousands of people who all own some given piece of popular not but not even vintage hardware. thats irresponsible and disrespectful of people’s time. see Details about MIDI 2.0, MIDI-CI, Profiles and Property Exchange (Updated June, 2023) - where it has to happen from the vendor end anyway
no this should be up to the hardware companies. many have files already. you just have to use this thing called google to search for name of your device + midi device file or midi map or cubase device file and you’ll find what you need most likely.
as a #3, Steinberg should add to CuB an online device file interchange so that users could share files, and rate their quality so that poorly done files get eventually either fixed or removed. I know there are some people who have the patience to map out a vintage device, label it all correctly, but most don’t. At least if some one goes thru the effort of mapping a device, they can save other people from duplicating the effort.
S
1 Like
checked those folders cant see anything saying houston or any other control surface or midi …is it under a different name?
sorry Waxxy - houston not supported in C11 - official
OSC support would help. Already in use in many other DAWs and hardware. Together with the Generic remote it would be an unbeatable combination if attention would be given to some things, a lot of it is already there:
1.The generic remote would be much more usable if every switch function would react to cc or note value (0 is off, 127 is on) instead of togge on and of on the same note/cc…(so you would finaly be able to create a button that realy shows you what is going on in cubase. Now you have to check every action you did, did it work? In what state are we now? My neck hurts If I think about all the times I looked up from my controller to do this…))That’s not a big job to program, most of it is already there.
2. A way to adres plugins directly like in studio one, and a way to adress channels by name or ID. (NOT by order from left to right…)
3. A way to show detailed parameter values and namefields. Without it any controller is useless, you will still have to look at the screen to see what’s going on.
4. Ad OSC and propper 14bit midi (nrpn).
The generic remote isnt that bad at al. You can even get NRPN midi to work if you dive into it.
What’s missing is a good manual of all the functions. What’s missing is a good tool to show parameter values next to a fader or knob.
Steinberg never finished the GR…If you look at the past it’s not hopefull at al, but lets give steinberg one more chance, maybe, maybe this time…Time will tell…I’v been waiting forever to be able to use my daw the same way I used to handle analog gear. Came a long way building my own controllers, that will probably only work in older versions of cubase in some time if things go bad…(I would not be surprised when steinberg would just ditch the GR for something new, remember what they did with the vst presets…).