I would really like to see an overhaul of the Device Panel editor, that is being used within the MIDI Devices. The current one is clunky to use. I envision the creation of a device panel could be made much more user friendly.
YES!.. this is basically the intent of the feature request. Thanks for getting involved in the thread
This is where things won’t go your way. Not every external synthesizer sends MIDI messages for every parameter they have. Especially those sound modules, you mention the Oberheim Matrix 1000. Most of them are designed to rather receive MIDI than to send it themselves.
Agree!.. I actually just referenced the Matrix 1000 as an example of why you’d require the ability to manually edit outgoing messages from the Device Panel / MR interface. The thing is though, that for many many synths it’s a simple “twist knob, it appears”; and for the others you’d enter in manually, sure, but it only takes one cuibase user to develop that “more complex” setup and then it could be made available to all users in a freindly community approach. Wouldn’t matter if it was just sharing bewteen direct messages; or perhaps steinberg would consider an official list / link / download system (but that could get messy for them).
The MIDI standard has no concept for a two way communication.
I’m not sure that I follow you here? But I might be missing something about what “bi-directional” means for the actual current midi protocol. What I’m referring to is allowing the GUI to send data back to the device by moving the GUI itself (as in click drag). In terms of fundamental midi capabilities, this is possible, as it’s currently implemented in editing / librarian software and the various VSTi style interfaces available (e.g. soundtower). In the proposed feature request, I don’t see how this would be a limiting factor (it can both send and recieve)… they might need to code in some “if mesage is recieved, don’t send that message back” to avoid double sending midi messages, but that’s fairly straight forward (I’ve done a lot of that style coding in BOME midi translator for example).
Yes, there will be some quirky devices that need some more nerdy attention. And I absolutely expect bulk dump scenarios to be one of those, but when you think about it - this is a program dump… they’re never simple!.. For the Feature Request basics, this isn’t a roadbkock at all though (for THIS specific example… they’ll be some synths that might be in the too hard basket). Why? Because the Matrix parameters are CC programmable… it’d work perfectly for the Matrix, and it’s a good example of why this system would work well.
The Matrix 100 has no need to send controler data… it has no controllers! So this dump is the way it sends out it’s patch data, but it’s not meaningful for “control” of the device from the proposed MR style device panel.
And then Cubase would need to know how to read this bulk dump
Well, not really… cubase doesn’t need to do anything. It just needs to have a system that allows it’s users to do the hard yards in programming what to do when complex sysex is recieved. In this case, it would be allowing users to manually enter complex sysex commands into the recieve tab; and configure what happens when they’re recieved (in the matrix example; it’s patch memory). Every librian for Matrix 1000 currently does this; it’s just sysex code… painful, but far from rocket science. I’d say recieving patch data in bulk is not a major concern or interest for me personally, but it’s probably important in the long run, so it’s good point to raise though and get my head around how the system would need to be…
That means every single external synth needs to get its individual support through Cubase.
I think you might be missing the key point here though - this would be a USER generated world… cubase deson’t need to support anything other than the MR style interface and it’s capabilities… they already do that for MR, and all I see is some additional functionality added to that system. Each device panel generated needs no formal cubase support… zero. They’d just be made by users like you and me, in the same way the current Midi Remote interfaces are made. Some people might hold onto the panels they make; others like me would be happy to share them to world…
That’s why no DAW has done it so far
Well, how about this… if you do think it would be an awesome addition, even if you think it’s not possible, why don’t you give me a vote on this feature request and we’ll see what happens!!
Sorry, I’m referring to the actual GUI here. Apologies if the terminology was confusing for midi protocol references.
What I mean is that the actual GUI in e.g. Midi Remote cannot be used to modify parameters… e.g. I can’t click a fader in the MR panel I create, and move that fader to send messages to my devices. The midi remote panel doesn’t SEND data (and is not able to be modified directly). It ony recieves data. When I say “bi-directional”, I mean I want a MR style system for use as device panels where the PANEL interface is to be able to send data as well as recieve it.
I try to ask in a different way: I bought my last hardware synth in the previous century. Can you give me an example of a hardware synth that transmits the same parameters that it can receive data for? I just need to know the name, I will look up its MIDI implementation myself.
Can you give me an example of a hardware synth that transmits the same parameters that it can receive data for?
In my experience, it’s the vast majority to be honest, since the early days too. That’s how the implementation charts work a lot of the time… the data list is typically the send and recieve message. It’s common beyond synths too - most midi units I work with including control surfaces and digital mixers do the exact same approach (the midi message is the send and recieve message… they’re identical).
Some quick examples are:
EARLY DAYS: Juno 106… all midi functions send and recieve the exact same midi sysex message (with a variable for the value)
Novation - all of the their synths as far as I know send and recieve all midi data with idenitcal messages.
DSI - all messages, all synths I know of…
Waldorf Pulse - all midi parameters…
Waldorf MicroQ - almost all values, but not quite… the VERY complex arpegiator / sequencer midi messages are a good example of why a complete remote control system would need some more complex sysex abilities, as this needs some very tricky sysex to be sent, and is only sent during patch send as far as I’m aware… Putting this here as good example of why a complete system may need deeper programmability in a new device panel MR interface.
And the near impossible?!.. Roland R8… to develop a panel that could e.g. program a rhythm on the R8 is possble, but allllmost impossible. I think it’d be beyond the scope of this idea… particularly as the midi implementation is NOT documented and would take some truly painful reverse engineering with a midi monitor searching for changes in midi sysex messages to determine what change on the unit made what change in the message. It would be possible; but soooo painful. I started this once and gave up lol…
I think a key thing to note is that this system would therefore work for the vast majority… it may not work for every single unit at all, or in full though… and that would need to be accepted by the user base along the lines of “ah man, bad luck the R8 is just too complicated to get a proper panel working on”. A small number of units that may not easily work shouldn’t be a reason to consider the system a fail though…
@m.c Hi again… actually, sorry to be a pain but could you help me understand current scripting options a little deeper…
This is for a much deeper example of how these panels could work… I’m not suggesting users would have to do this if they didn’t want to… But something like this is how I imagine you’d need to IMPORT a patch from a hardware synth into a panel GUI (so the panel shows the correct parameter positions when you change a patch on a synth)
e.g.
For more complex sysex, say a patch dump from a synth into cubase, some units send a huge string of variables, but not as parameter changes, just within the sysex dump string… To use this to “update” the panel, users would need to undestand each variable and assign it to their panels knobs.
SO: Could I write a script that nominates variables, and then sends the actual value to a knob in the GUI…
e.g. just say I recieve the following sysex, where variables are in bold:
90 50 3F
80 50 00
Could I get a script to see “90 50 XX”, and then take the actual value “XX” and send it to a GUI knob; and then see “80 50 YY” and take value YY and send it to a different knob…
If Cubase would send CC1 ModWheel to the device it would be able to receive and react to it but it would not be able to send it back to Cubase. So there is no chance for a bi-directional communication in regards to this parameter.
Same applies Aftertouch, Breath Control, Main Volume, and the Sustain Pedal. Also a Program Change could not be reported back by the device.
So even if Cubase had the feature you request it would work with the Waldorf Pulse only partially.
In my experience most synths show this behaviour: maybe some things will work but some other things won’t.
In my opinion it would be better for Steinberg to focus on getting this kind of stuff right with MIDI 2.0 and to update the Device Panel maker to become more user friendly.
Bi-directional communication with MIDI 1.0 devices does not work often enough to justify the programming requirements.
This from the Juno 106 manual, where, as you said, most parameters are send via SysEx. SysEx was later on avoided for performance related MIDI messages and replaced by CC messages as it takes too much time to transmit.
E.g.
The Juno requires 7 bytes to send or receive a volume message.
Since MIDI can transmit 3125 bytes per second that are 2.25 ms. But we need bi-directional communication, so 2 * 2.25 ms = 4.5ms.
Everytime you touch the volume fader the midi port will be busy for 4.5 ms. Imagine sending several changes plus notes at the same time. The timing would be all over the place.
I think youre being constructive in debating rhe possibility / functionality. I think thats good / healthy. You miiight be being a little nit picky in those examples though, and perhaps search8ng for reasons why it wouldn’t work rather than thinking of the things it could achieve… again, that’s productive though, and good to have it all discussed.
Lets look at the Pulse example though… the pulse is a rackmount synth with no keyboard (aftertouch / notes), modwheel, breath controller, etc. It physically can’t send that data! Thats why theyre not there to send… Volume - well it doesnt send on the standard volume cc, but it does on another at a patch level… CC… something… 50 something… cant remember as im on my phone away from studio.
To be clear on the pulse example: it sends and recieves EVERY programmable message… its a great example of why this system would be incredible, as the hardware interface is “ok” but not great, and a GUI would make it next level for programming and automating.
The juno is the same deal… as you note: simple and sends data for all programmable parameters. Note that 7 bit sysex isnt that different to standard CC. Most CC commonly used is 7bit too… CC was just an initiative to streamline standard controls across multiple devices and manufacturers.
Id suggest that instead of spending time looking at individual synths and what can and cant work, id just look at any of the large product library midi librarians… safe to say that works been done, and any software librarian / efitor for a product shows the capabilities of what a built in device panel MR should be able to achieve. But within cubase you can add automation and Pligin Delay Compensation to that capability and have an incredible outcome.
Definitely not trying to shoot you down though - keep the discussion coming i say!!
Take a look at midiquest… that list gives a feel for units they support… just kerp in mind thats a list that THEY have developed, not a list of the inits that could be implemented… it also may explain some limitations that a particular unit may have (some units dont send/recieve everything, so theyre only partially able to be controlled remotely… modern example is a meeblip anode).
Older soundiver was VERY good… you might be able to find a list somewhere, but its long since gone for modern computing sadly.
Ok, I took a look. I think @mlib was right when he mentioned that Device Panels already do what you want in regards to remote controlling a synth from within Cubase.
Their creation is cumbersome but the general fuctionality is already there.
Here is an example for what such a panel can be made to look like:
What you are looking for is not turning MIDI Remote into a MIDI library software but actually updating the Device Panel and Patch maker into the 21st century.
And if it could spy on incoming MIDI from such a device in order to update its own display, that would be most certainly welcome, too.
Personally, I would be happy with that.
For example, I don’t need a special GUI that looks like the synth.
Just a flexible editor where you can assign and automate midi CCs.
Sysex for dump etc.
All these things more user friendly and without having to think about a certain order.
I know it all works somehow, but it’s very cumbersome and time-consuming.
I mean, it’s all there, but it just requires better organisation.
I wasn’t implying anything. I think a mechanism for receiving, storing and sending SysEx dumps would be helpful. It’s something I remember missing from the days Cubase was MIDI only.
Just chiming in here to say that I would love a major update to Device Panels. I, too, like the OP, was of the belief that the new Midi Remote feature was the start of controlling hardware. I have a lot of hardware connected to Cubase, some of the newer things have vst editors but a lot don’t.
Device Panels in their current state are sort of working but lack that two way communication. Not to mention they look super outdated and are not user friendly to make.
CTRL seemed like it was going to be a nice solution but it’s pretty dead now.
That said, it’s probably wishful thinking that Device Panels will ever get an update. Probably a better chance they remove this feature (please don’t). I’d like to be optimistic but I just don’t know if there is a big enough demand. I’d love to be wrong though.
Also, a little off topic but I pray they implement the new Modulators to be able to control hardware.
There are some very good ones out there. The best one in my mind is the Access Virus. TI. This is an amazing VST that acutally outputs the audio of the Virus out of the VST output channels so you don’t have to use inputs in your interface, regardless of what sample rate your project is using. This is the greatest VST I have ever seen and the current incarnation has to be 15 years old now. The VSTs from Modal are awesome as well (For example the Cobalt 8M) but those don’t bring in the Audio.
For Windows users (I know Mac can do aggregate devices) it would be extremely helpful if we could use a USB audio input or other interface as an input for our MIDI device panel similar to what Access does with the TI VST.
Using a real world example: I generally run my system at 96k and use a MOTU 1248 connected over thunderbolt as my main interface. If I want to bang out something on a Roland TR-8 it only has a few analog outs. It does have a USB out capability that works fine but is stuck in 48k. It would be really nice to be able to setup an external device for the TR8 where it uses the USB audio from the TR8 where each channel is presented at the same time. I know it wouldn’t be “sample accurate” but neither would recording 11 channels over analog individually be “sample accurate”.
The functionality of some of the VSTs out there that integrate with hardware could be accomplished with Cubase alone if they would allow multiple audio interfaces on Windows.
So yes, the device panels need a serious upgrade, but there is more that could be done here than just that.
