GENERIC REMOTE: Should Remain Because

It serves strong purpose for use in general shortcuts management.
What I mean is this;

I use GR to manage the shortcuts from an ergonomic keypad which is based on muscle memory. Other than initial training (which I just stick a print up until I have learnt it), the new remote editor, whilst excellent, does not fulfil this role without a lot of verbosity. I trialled around and its just unmanageable compared to the simple xml format of the GR

This is in progress…but try and get remote editor to do it…its just not the right tool. Generic Remote should remain because it fills a needed and useful niche in the Steinberg production instrument.

It should also have the new features like select combination etc available too

See PDF for high res so it makes sense
Razer Shortcuts.pdf (646.0 KB)

1 Like

It’ll probably be around for a while, but I know I, for one, will not miss it when it’s gone.

TBH…using it manually is rubbish for sure…but
Plug it into a spreadsheet that lets you manage your system and then just save the xml…light years ahead of whats on the market; but its not easy so I guess not many have gone that far…who would???
Yeah people that should be doing more important things like making music hehe

1 Like

You could write some small app or something that translates the spreadsheet into JS. Added benefit would be that you could potentially change stuff (e.g. colors) automatically via Cubase. But yeah, if GRs work for you, there might be little reason to change it- other than Steinberg dropping support for it.

There are no null objects for the editor otherwise it wouldn’t be an issue :frowning:
An info panel with null objects might help but at the end of the day…you dont need to see muscle memory stuff…and thats the point of production becoming an instrument in its own right ie without being bogged down with analytical stuff vs creative

I’m not sure what you mean by “null object”… do you mean you don’t want to see the buttons?

It seems that there needs to be a visible control for each assignable control, a bit like GR has a controller in the top list and a target object in the lower.
For a GR like equivalent, there doesnt need to be objects per controller but rather just an invisible list object prob a bit like the 2 GR tables

Yeah, got it. This threw me off at first as well, but since the Remote Editor seems to handle hundreds of Objects totally fine, I just gave in and ignored that. I also now see a benefit in it… I’m grouping the controls just a little bit. so I know where I am when I need to change / add mappings. I’ve attached a picture of my touch controller and the resembling MIDI Remote Device. The MIDI Remote is not pretty, but it doesn’t need to be. If Steinberg just adds an option to hide certain Remote Mappings from the MIDI Remote Panel, I’ll be happy forever.


2 Likes

Wow thats a lot of work. I have the same touch screen I think. I mentioned re touch screen after using it for a while…its just too fatiguing to use it that way compared to a keypad…now I just use the touchscreen for the mixer as a secondary device
All of the logical controller sheet in my earlier post comes from just one device and you rest comfortably in ergonomic position.
(all midi controlled via programmatic xml/mtp files from 1 spreadsheet ie they are in concert)

So the legend is egB2 = Button 2 on the keypad.
Ctrl (15), Shift (11) and Alt (06) are on the left hand lower corner and enter(15), tab(10)

It really is fast…and I have studied the best I could find to use the cream of what is out there
It takes a bit to learn but so does playing something well…will post a demo and see what sort of feedback I guess…its a journey thats for sure

1 Like

Nice stuff. Is this the Tartarus?
I just got used to the touch controls over the years, and I have to say, mapping it in the new MIDI Remote System is just a breeze compared to the GRs.Since the software is custom written, I could’ve written something which spits out the XML-File to load into the GRs, but I never did. It always seemed annoying to me that I would have to export a file and re-import it into Cubase when I just want to add a button.
But I see where your problem lies I think. I just think that GRs are gonna go sooner than many might like, so getting a comfy solution in place with the new system is probably still a good idea I suppose. That’s why I instantly migrated the whole touchscreen from the GRs to the MRS. And it was really easy to do, which is a relief.

I understand.
Yep the tartarus, but I program for OEM Chinese mfgs and do midi remote for Ableton…I migrated the gesturing system and its hard to imagine, but its seriously lightning in comparison to using the touch (which I also tried OSC etc but its all just too clumsy/Raven or to large to traverse comfortably for basic commands. )
The important things is not about GR etc its about being able to have overview and detail in map form so the development of the logic is good. Ive been careful to keep it fluid until its well formed but its close now. I dont find the button press in Google Sheets and reimport is much of an issue…but we are all different. I couldn’t imagine using GR manually for this stuff
It actually works in tandem with MCU
Well hopefully they have some sort of solution :slight_smile:

Maybe they’ll give us the possibility of importing XMLs directly into the MIDI Remote Editor in the future. And maybe they’ll give us null-objects. They did put a lot of thought into it- looking at the API reference- so I’m sure there’s going to be rapid development in this area. I think they know that some people preferred the GRs for special use cases, and I think it would be smart of them to integrate some of that functionality and methodology into the new MR System. I do have faith in Steinberg here, though :smiley:

1 Like

Yep…I have been here since v1.0 :slight_smile:
(But I also use Live for the last 12 years too…different beasts)

1 Like

Generic remote should remain since there are still some commands that cannot be done on the new midi remote (open plugins windows, for example)

2 Likes

Hey @nicholasbinder , what did you actually use for the touch program?
If they just allowed touch for the remote objects would be brilliant (just some simple panel obj…I wouldn’t really go back to touch now I think)

BTW I think the diff is too… I planned all of the mappings etc before I started and grouped them logically in overview…so I while there is tweaking etc; Its structured vs ad hoc…which spreadsheets are good for esp with filtering. There is no way I would have started doing it manually…I already have no hair :slight_smile:

1 Like

It’s custom written. We actually recently made a video about it… but be warned, it’s 1.5 hours long :rofl:

1 Like

Cool
I left mac quite a number of years ago…actually I tried and went back to PC as its just a tool for me…
but either way for the touchscreen guys…great.
I definitely couldn’t go back to the real estate or ergo of touch unfortunately…and after 40 years of knobs and faders; despite trying my best, its the disconnect from the visual that I find the most powerful ie being aurally focused especially with eq etc
Cant unravel your accent?? Deutsche?

2 Likes

Actually there is a way to do that in JS, and it is likely the spreadsheet could be simplified. It would take some work, but writing a JS generator to go from the spreadsheet to an MR script wouldn’t be impossible. The issue is with getting from the non midi controller to the JS script, and the other issue is with the performance of the JS script. I really wish it had been in Lua, because the performance is pretty bad.

Yep…just a null object that doesnt show in the editor, even just an embedded version of the GR would sort it for those that DONT need the gui (still love info panel though)

Agreed. For those using OSC or Lemur or any touchscreen stuff, Generic Remote is essential!

I use it ALOT especially when it comes to triggering Cubase and Nuendo commands and opening plugins for processing on the fly.