I’ve noticed that important “item properties” of e.g. buttons and faders are not editable. However, I think being able to change the CC # or note # or channel would be very useful, especially for those users with controllers where those values can also be changed (which includes software based control surfaces).
@Jochen_Trappe Do you think this would be a reasonable (and easy ) feature to be added in a maintenance update? Highly appreciate your thoughts on this.
(One “solution” is to remove each item, re-add it, but this involves then also re-adding the mapping, which is a lot of work. I do have managed to change note values through the Cubase-generated json file of the controller surface, however, this involves changing two files, one being the controller surface, the other being the corresponding Cubase-generated mapping json. It seems to also involve unloading and reloading the controller surface )
We made that way for a reason: Persistence.
If we encourage you as a user to make those “breaking changes” to your surface, your saved mappings get lost easily. The Surface Editor offers a fast workflow. So removing the controls you want to change and creating them new should be done very quick.
Thanks @Jochen_Trappe for taking the time to answer and for your feedback on this, very much appreciated. I understand that Steinberg would want to keep the Remote editor as easy to use (and hard to break) as possible, which makes sense of course.
What I don’t understand is how changing an item’s properties (e.g. CC # or Note # or MIDI channel) would break the mapping (or “lose a saved mapping” as you described)? As I understand, Cubase could (behind the scenes) also change the corresponding mapping data structure simultaneously to keep in sync with the control surface definition, no? (Just as I need to do manually with the two json files right now [1]).
With the current MIDI Remote, when e.g. changing the MIDI channel that my hardware (or software) surface is using, that would mean to re-create the entire MIDI Remote surface from scratch, no?
@Jochen_Trappe Or am I missing a quick way to change e.g. the MIDI channel of all items without re-creating them? (which forces to also re-create all mappings, right?)
What do other MIDI Remote users think?
Thanks again and all the best
[1] For those curious: (1) one json is the control surface definition as stored in ~/Documents/Steinberg/Cubase/MIDI Remote/Driver Scripts/Local/vendorname/surfacename/surfacename.json, (2) the other json is the mapping stored in ~/Documents/Steinberg/Cubase/MIDI Remote/User Settings/vendorname_surfacename_SOMEHASH_globalmappings
We are dealing with “concurrent persistence sources”. There is some user mapping saved in your project (“Project Scope” mappings), then there is the “Global Scope” mappings in a different file. And there is the script file. Three different files with data that has to match. It’s a non-trivial problem
I’m tweaking a Remote layout for the Yamaha MODX and realised the CC #s conflict with some internal CC # used by the MODX.
I can set new CCs in the MODX , the layout and functionality are done on the Cubase side, so I suddenly need to redo everything from scratch? @Jochen_Trappe , this doesn’t make a lot of sense, especially when developing for complex controllers.
Thanks @Jochen_Trappe for your additional technical details, much appreciated as a technical user I understand, that’s one (or even more) file(s) to keep in sync.
@Jochen_Trappe Another technical question though, if I may! Why do the mapping files need to contain (duplicate) information about an item’s CC #, note # or MIDI channel? Why duplicate this information both in the control surface file and mapping file (then making it harder to keep in sync). Wouldn’t it suffice to have item properties only in the control surface file, then “connect” these items with an internal ID to the mapping file, which only specifies mappings, but wouldn’t duplicate an item’s MIDI properties? (so to speak separate concerns).
Doesn’t work, that’s why it’s so non-trivial. We don’t know if someone duplicates a file, then the object IDs would be wrong. CC#, note# and channel# are used as semantic object identifiers. Like a primary key in a database. I understand that it is not ideal from a user perspective but other solutions would be much more problematic. So, like always, it is a compromise between correct data integrity and usability.
Thanks @Jochen_Trappe again for sharing some more technical internals, it’s at least good to know that a feature which would be quite desirable from a user perspective might not be as easy to implement as expected .
) feature to be added in a maintenance update? Highly appreciate your thoughts on this.
)
.