- This topic has 36 replies, 3 voices, and was last updated 3 years, 9 months ago by
.
-
Posts
-
Over the last few months I’ve again and again tried to get Ctrlr working in Cubase, but to no avail. If I’m doing something dumb then feel free to tell me!
I’m using the MKS-80 panel as a relatively ‘simple’ example (though I don’t understand why it has to be set to ‘0’ to control MIDI Channel 1, but let’s leave that…)
In standalone I can get Ctrlr working just fine. I assign the input and output MIDI ports, so that my controller keyboard can play the MKS-80 and the panel’s controls work as they should. This all works fine. No problems here.
Then I use Ctrlr as a plug-in inside Cubase 9.5…
No matter what I do to create the input and output MIDI ports I get a ‘cannot open’ error. I’m guessing this is because the ports are assigned to Cubase, so Ctrlr isn’t allowed access to them. Fair enough.
So I try to set Ctrlr to simply pass host input to host output. This is allowed (no errors), and my controller keyboard is passed through such that I can play the synth, but I can’t get anything to come from the Panel’s controls. I can move all the controls, but they generate absolutely no MIDI data to the synth.
I have one Cubase Instrument Track set as Ctrlr with my controller keyboard set as input, and a second MIDI Track set to take the output from the Ctrlr track as input and my MKS-80 as output. I can play the synth, but none of the panel’s controls do anything.
Needless to say that I’ve played with every option I can find, all to no avail. I’ve run both 5.4.11 and 5.5.2 (I managed to suss the broken display parameters myself with a bit of trial and error), but neither works.
The only documentation I can find here relates to standalone, but I have that side of things working – and it goes into detail about creating my own panels, which I won’t be doing.
If I’m doing something wrong I really don’t know what it is! Please heeeeeeelp!!!!!!
An Eagle for an Emperor, A Kestrel for a Knave.
This is Windows 10, BTW.
An Eagle for an Emperor, A Kestrel for a Knave.
Well, I’ve partly answered my own question. It seems the block on using a port is caused by my having the port assigned in Cubase’s ‘MIDI Devices’ panel. Anything allocated in there is rendered unavailable to Ctrlr.
This said, it doesn’t explain why the ticked option to ‘Output to plugin host’ doesn’t seem to work – at least under Cubase. Surely this option should render all the port selecting unnecessary?
I’m none too happy about breaking my Cubase ‘MIDI Devices’ settings, so it’s looking like it’s a dead end for me.
It’s a pity, because I’m waiting on a ‘Vecovened’ V4 MKS-70 and I though Ctrlr was going to be my white knight of editing for it.
Again, I’m happy to take advice…
An Eagle for an Emperor, A Kestrel for a Knave.
Could it be because the panel is coded to use a particular midi channel? I had a similar experience with another panel, the Kiwi-3P, and spent a while trying to figure out the same thing before remembering I had read on the posts related to that panel about the midi channel being set to use Midi channel 1 only, and since I had previously set up my Kiwi Technics modded JX-3P on channel 3 it wasnt working no matter what I did.
Check the code of the panel you are using to see if it is set on a specific channel, or email the developer of the panel to see if he can help.
Good luck and let us know what the reason was if you do find out 🙂
On Windows you can’t share the same port with different apps if your MIDI interface drivers aren’t multi client. Your options are:
Change the MIDI interface to one with multi client capabilities.
Use virtual midi ports.
Disable in Cubase the MIDI port used with Ctrlr.Thanks for your thoughts, guys.
It’s not a MIDI Channel problem – I can make the panel work in standalone, and it also works if I use a MIDI port not referenced in MIDI Device Manager.
It’s not a Windows port sharing problem. I definitely CAN share ports inside Cubase. I am only using one ‘app’ – Cubase. It’s just that Ctrlr (as a plug-in – I’m not running it separately) cannot access any port that is referenced in Cubase’s MIDI Device Manager. If I remove the reference then Ctrlr accesses the port just fine. Removing the port in Cubase isn’t an option anyway – I then wouldn’t be able to play the instrument in Cubase.
If I use a port that *isn’t* defined in MIDI Device Manager, then Ctrlr works perfectly – and that port can be in use multiple times. So it’s definitely not a Windows sharing thing – just a specific conflict between MIDI Device Manager and Ctrlr.
I could remove the MIDI Device Manager reference, but then I lose my ability to access hardware instruments by name. I’m not very happy with this prospect. That’s why I would prefer to use the ‘output to host’ option from Ctrlr – which doesn’t work at all. But I’m narrowing it down…
When using the Ctrlr ‘output to host’ option – it looks like Cubase is intercepting the data generated by the Ctrlr panel. For one example, when I move the VCF Frequency control in the MKS-80 Ctrlr panel, one of the Quick Control knobs in the Cubase Instrument window also moves. This suggests that Ctrlr is generating the data, and Cubase is aware of it, but that data is not being allowed to escape from the instrument.
An Eagle for an Emperor, A Kestrel for a Knave.
Yes, it is a Windows sharing thing. You are answering your question.
It’s just that Ctrlr cannot access any port that is referenced in Cubase’s MIDI Device Manager. If I remove the reference then Ctrlr accesses the port just fine.
Ctrlr needs it’s own ports, so you have two apps trying to access the same port, Cubase and Ctrlr. If the ports were multi client, you could use the same port with Cubase and Ctrlr.
I can’t help you with Cubase, but have you tried to use “input from plugin host” and “output to plugin host” and not selecting any midi in/out device?
To my knowledge when you talk about the plugin version of Ctrlr it does not matter if you have a multiclient capable midi interface. The DAW and the Ctrlr plugin won’t ever be able to use both the same port. That’s why the options “Output to plugin host” and “Input from host” are there. Unfortunately in Cubase “Output to host” does not work. The only DAW I know that this works somewhat as expected is Reaper.
With my SuperJX v4.x panel the plugin version of Ctrlr won’t give you any advantages compared to the standalone version. Well, except parameter automation. Ctrlr standalone works well in parallel with any DAW as long as you have a multiclient midi interface. Btw. on Mac all interfaces are multiclient. So I would recommend you to try out Ctrlr standalone.
Yes, it is a Windows sharing thing. You are answering your question.
It’s just that Ctrlr cannot access any port that is referenced in Cubase’s MIDI Device Manager. If I remove the reference then Ctrlr accesses the port just fine.
Ctrlr needs it’s own ports, so you have two apps trying to access the same port, Cubase and Ctrlr. If the ports were multi client, you could use the same port with Cubase and Ctrlr.
I can’t help you with Cubase, but have you tried to use “input from plugin host” and “output to plugin host” and not selecting any midi in/out device?
I’m *am* trying to use ‘input from host’ and ‘output to host’, but no data is coming out of Ctrlr in that mode.
It honestly isn’t a Windows sharing thing – I’ve proved that. I definitely *can* use ports more than once. That really isn’t the problem. I can prove this with any port that is not referenced in MIDI Device Manager. Cubase can access the same port as Ctrlr this way and everything works fine. It’s just that I can’t name my instruments without using MDM – I have to remember the ports and with 24 MIDI ports that’s a bit galling.
I’m using Ctrlr as a plug-in, not as a separate app.
An Eagle for an Emperor, A Kestrel for a Knave.
To my knowledge when you talk about the plugin version of Ctrlr it does not matter if you have a multiclient capable midi interface. The DAW and the Ctrlr plugin won’t ever be able to use both the same port.
Yes they can – I’ve proved that. It works. It’s just that I can’t use MDM to name the ports. Again, this is using the Ctrlr plug-in – not as a separate ‘app’.
It’s simply that ‘output to host’ seems not to be able to get data out to Cubase.
An Eagle for an Emperor, A Kestrel for a Knave.
To my knowledge when you talk about the plugin version of Ctrlr it does not matter if you have a multiclient capable midi interface. The DAW and the Ctrlr plugin won’t ever be able to use both the same port.
As I have no multi client midi interface I can’t test it by myself, but this contradicts this post:
Windows XP/ Ableton 8.1
Midiman midisport 2X2: supports multiclient (selecting the midi out in ableton preferences as in the plugin)
RME Fireface midi: does not support multiclient. (selecting the CTRLR midi out will cause an error openDevice hardware failed if it is also selcted in ableton midi preferences))
It’s not a Windows port sharing problem. I definitely CAN share ports inside Cubase. I am only using one ‘app’ – Cubase. It’s just that Ctrlr (as a plug-in – I’m not running it separately) cannot access any port that is referenced in Cubase’s MIDI Device Manager. If I remove the reference then Ctrlr accesses the port just fine. Removing the port in Cubase isn’t an option anyway – I then wouldn’t be able to play the instrument in Cubase.
If I’m not mistaken, you’re sharing ports INSIDE the same app (Cubase). Of course this is possible without multi client drivers. But Ctrlr, even as a plugin, has to manage his own ports, independent of the host, so consider it as another app, just as when you use Ctrlr as a stand alone app.
Can you use Cubase and Ctrlr standalone at the same time using the same ports?It seems like we have very different experiences – strange, I will check that again when I find the time…
Cubase is special as you cannot disable or enable ports. If you don’t use a port in any tracks the port will be disabled automatically.I am using a MOTU Midiexpress 128. This one has definitely multi-client drivers as Ctrlr standalone and MIDIOx and any tested DAW does work in parallel. But within Cubase I cannot select the same port in Ctrlr if it is already used by Cubase. The same thing with Reaper and with Ableton Live 9. Also the same thing on my virtual Mac and Ableton Live 9.
in Reaper the Ctrlr plugin does work almost perfect: NO selection of any ports needed! In other words, you leave the Ctrlr midi input and output device selection BLANK. Just enable input from host and output to host and set the thru setting to host to host.
in Reaper the Ctrlr plugin does work almost perfect: NO selection of any ports needed! In other words, you leave the Ctrlr midi input and output device selection BLANK. Just enable input from host and output to host and set the thru setting to host to host.
Great info. I really do appreciate the help from you all here!
Yes, that’s definitely the option I feel I need to use, but it simply doesn’t work. I’m happy that Ctrlr is outputting the data from the panel, but Cubase is somehow intercepting it and preventing it reaching outside the Instrument. I think the problem really is Cubase, but I’m jiggered if I can figure out a way round it – I’ve tried resetting Cubase Remote Control settings for the Instrument (which are responding to Ctrlr’s data), but to no avail.
I had a feeling someone would tell me it works in Reaper! Lol! Unfortunately, although I do use Reaper for field recordings, I do all my studio and mix work in Cubase.
FWIW I also use a trio of MOTU MIDI Express 128s.
An Eagle for an Emperor, A Kestrel for a Knave.
fyi I made some other experiments in Cubase:
Input from Host does work, no problems there. Output to Host: make a second track selecting the Ctrlr ouput as input . Unfortunately Cubase will only pass program and control changes to this new track – NO sysex! Therefore this is no option either. The only way in Cubase is to set the port on Midi output of the Ctrlr plugin. Cubase can access the synth through the Ctrlr plugin by selecting thru option “host to output”. This works nicely on my setup. Of course you will have to dedicate a port for the synth (no daisy chaining). But daisy chanining using Midi Thru is no option anyway when using bidirectional panels.
Edit: I forgot – you have to select “input from host to comparator”. “Input from host” does not work resp. is useless.
fyi I made some other experiments in Cubase:
Input from Host does work, no problems there. Output to Host: make a second track selecting the Ctrlr ouput as input . Unfortunately Cubase will only pass program and control changes to this new track – NO sysex! Therefore this is no option either. The only way in Cubase is to set the port on Midi output of the Ctrlr plugin. Cubase can access the synth through the Ctrlr plugin by selecting thru option “host to output”. This works nicely on my setup. Of course you will have to dedicate a port for the synth (no daisy chaining). But daisy chanining using Midi Thru is no option anyway when using bidirectional panels.
Edit: I forgot – you have to select “input from host to comparator”. “Input from host” does not work resp. is useless.
Much appreciated.
Yep, that all works, as I’d already discovered (except I don’t need to use ‘host to comparator’ – ‘host to output’ works fine for me). Just like you, I can see that the output (presumably sysex) from Ctrlr is somehow intercepted by Cubase and blocked when using ‘output to plugin host’. This is the sticking point.
I can get it working by setting the port in Ctrlr directly – no problem with that, but it will not work if I have the port used anywhere else in Cubase, or if I simply name the port in MIDI Device Manager. This just isn’t tenable for me. Ctrlr is effectively wanting exclusive use of the port and that isn’t realistic. If I temporarily remove the port references in Cubase to get Ctrlr working, then Cubase can’t make use of the port that Ctrlr has snatched from it. Sigh…
It looks like I will have to abandon this and see if I can come up with some other method for controlling my V4 MKS-70. Maybe there’s an iPad app I can use.
An Eagle for an Emperor, A Kestrel for a Knave.
Bingo! Sudden realisation!!!
V4 MKS-70 has, I *think*, all MIDI Controller number allocations for editing – not sysex. With that in mind I tried the simple host in/host out option with the V4 panel, just to test (I’m hoping the new synth will be here in a couple of weeks) and… it works! Well, at least I can see that the controller data is making it to the MIDI port.
The panel I’ve been testing with (MKS-80, because I have a couple of those) is generating sysex, and it was this that was being blocked by Cubase.
Phew! Looks like I have a solution. Many, many thanks to all here who have given their help. I do appreciate it. Hopefully I can come back to this thread and report that all is fine once the synth lands with me – it actually did land once, but the PWM mod was futzed, but that’s another story…
An Eagle for an Emperor, A Kestrel for a Knave.
yes the MKS-70 uses NRPN MIDI-CC’s for most parameter (tone parameters) but it needs sysex for the patch parameters and also the librarian is using nothing but sysex. So you will miss a lot of functionality when you go the no-sysex way.
Why is it not acceptable for you to dedicate a MIDI port for Ctrlr and the MKS-70?
I only work with single Tones to a Patch, because I hate the Tone sharing system. The way I do it is that Tone 07 lives in Patch A7 and is never referenced outside of it; Tone 26 lives in Patch D2, etc. This is the way I’ve always used my MKS-70s – it keeps me sane! If I have to make Patch edits then I can use the front panel – by far the most complex editing is to a Tone.
I also don’t think that I need the librarian – I will save Tones and Patches to the MKS-70’s own storage system (I have the M-1024C 16-bank cartridge). Occasionally I will back up to a sysex file, but I don’t need a librarian to do that for me.
I don’t want to dedicate a port to Ctrlr, because when I don’t want to use Ctrlr (and the vast majority of the time I won’t) then I’ll have to remember that my V4 MKS-70 is on MIDI Express box 2, Port 6 – at the moment I can assign that relationship in MIDI Device Manager and choose ‘MKS-70 B’ by name in Cubase’s output selection list – that’s why MDM exists, after all. Plus, once Ctrlr has hold of the port I can’t access it from any other Cubase Tracks, and I may have alternative/additional Tracks needing to play the same instrument.
In summary I *think* (there’s probably something I haven’t considered, I bet!) I will be fine. All I need now is for my V4 to arrive ready to go.
I may raise this sysex filtering by Cubase with Steinberg – a fairly pointless task, given their history of responses, but nothing to lose…
An Eagle for an Emperor, A Kestrel for a Knave.
I only work with single Tones to a Patch, because I hate the Tone sharing system. The way I do it is that Tone 07 lives in Patch A7 and is never referenced outside of it; Tone 26 lives in Patch D2, etc. This is the way I’ve always used my MKS-70s – it keeps me sane! If I have to make Patch edits then I can use the front panel – by far the most complex editing is to a Tone.
I also don’t think that I need the librarian – I will save Tones and Patches to the MKS-70’s own storage system (I have the M-1024C 16-bank cartridge). Occasionally I will back up to a sysex file, but I don’t need a librarian to do that for me.
I don’t want to dedicate a port to Ctrlr, because when I don’t want to use Ctrlr (and the vast majority of the time I won’t) then I’ll have to remember that my V4 MKS-70 is on MIDI Express box 2, Port 6 – at the moment I can assign that relationship in MIDI Device Manager and choose ‘MKS-70 B’ by name in Cubase’s output selection list – that’s why MDM exists, after all. Plus, once Ctrlr has hold of the port I can’t access it from any other Cubase Tracks, and I may have alternative/additional Tracks needing to play the same instrument.
In summary I *think* (there’s probably something I haven’t considered, I bet!) I will be fine. All I need now is for my V4 to arrive ready to go.
I may raise this sysex filtering by Cubase with Steinberg – a fairly pointless task, given their history of responses, but nothing to lose…
An Eagle for an Emperor, A Kestrel for a Knave.
I only work with single Tones to a Patch, because I hate the Tone sharing system. The way I do it is that Tone 07 lives in Patch A7 and is never referenced outside of it; Tone 26 lives in Patch D2, etc. This is the way I’ve always used my MKS-70s – it keeps me sane! If I have to make Patch edits then I can use the front panel – by far the most complex editing is to a Tone.
I also don’t think that I need the librarian – I will save Tones and Patches to the MKS-70’s own storage system (I have the M-1024C 16-bank cartridge). Occasionally I will back up to a sysex file, but I don’t need a librarian to do that for me.
I don’t want to dedicate a port to Ctrlr, because when I don’t want to use Ctrlr (and the vast majority of the time I won’t) then I’ll have to remember that my V4 MKS-70 is on MIDI Express box 2, Port 6 – at the moment I can assign that relationship in MIDI Device Manager and choose ‘MKS-70 B’ by name in Cubase’s output selection list – that’s why MDM exists, after all. Plus, once Ctrlr has hold of the port I can’t access it from any other Cubase Tracks, and I may have alternative/additional Tracks needing to play the same instrument.
In summary I *think* (there’s probably something I haven’t considered, I bet!) I will be fine. All I need now is for my V4 to arrive ready to go.
I may raise this sysex filtering by Cubase with Steinberg – a fairly pointless task, given their history of responses, but nothing to lose…
An Eagle for an Emperor, A Kestrel for a Knave.
- The forum ‘Using Ctrlr’ is closed to new topics and replies.