PreSonus FaderPort 2 (2018) midi remote script

The issues I have with midi remote devices are a little bit random. Sometimes happens, sometimes not. I do not understand why the controller is disabled each time I close a project and enabled when I open another one. I think a device driver should depend on the studio and not the project, like the sound driver.

2 Likes

If I import the tracks and audio from corrupt project to a new project then Faderport functions correctly, therefore in my Neanderthal mind it is not the tracks or audio but the actual project that has gone awry.

2 Likes

That’s fine, I just needed a confirmation where to look, which you gave me. Thanks!!

2 Likes

I have one specific project where it neither helps disabling and re-enabling the interface nor restarting Cubase, I never get the Faderport to connect properly. Maybe that project can provide some clues to what is happening here? I have removed all tracks and all audio from the pool, so it must be something in the project settings. Maybe some of you can take a look and see if the same is happening on your systems? Dropbox

2 Likes

After downloading and starting it, Cubase told me, that a one plugin was not installed and your midi ports were not find, but it was no problem, to ignore that. After that, Cubase asked me for a project folder, then everything seems to be also ok. Then I added three audio tracks and I had normal access to those tracks with the FaderPort, so it seems, that your project makes no problems here with the FaderPort.

Maybe you try to

  1. delete all files here, but NOT the newest
    \documents\Steinberg\Cubase\MIDI Remote\User Settings
    (make a backup before, as this could delete your Custom Mode settings of the FaderPort)
    and then
  2. delete all program preferences of Cubase per pressing together Ctrl-Alt-Shift (= Strg-Alt-Shift) left on the keyboard when starting up Cubase to delete all Cubase preferences.

OR BETTER

  1. delete all files here
    \documents\Steinberg\Cubase\MIDI Remote\User Settings
    and then
  2. delete all program preferences of Cubase per pressing together Ctrl-Alt-Shift (= Strg-Alt-Shift) left on the keyboard when starting up Cubase to delete all Cubase preferences.
    and then
  3. set all your Custom Mode settings of the FaderPort again NEW with Cubase 14

However, there is still a chance that the upcoming updates of Cubase 13 and Cubase 14 will fix the problem.
If this all not work, I think, the project-file is corrupt or the problem is related to the fact that Steinberg has changed the format of the project files.

1 Like

I didn’t want to lose my preferences, so I waited for 14.0.10. The project still wouldn’t connect properly with the Faderport, but when I tried in 13.0.41 I got it to connect and after saving it in 13.0.41 and reopening it in 14.0.10, it works. So there is still something strange going on here.

1 Like

Hi, LluĂ­s,
I have opened a new thread for this…

2 Likes

I have found that if I quit/reopen cubase instead of closing/opening the project, the Faderport always works fine. This delays some tens of seconds the project swapping but is good for me.

2 Likes

Hi CKB,
would you recommend switching from Cubase 13.0.41 to the new Cubase 13.0.51 update ?
And would you generally recommend Cubase 14 ?

I have just encountered something similar to what you report.

I’m yet to understand what causes the issue, but it seems related to my opening of non-Cubase-14 sessions in Cubase 14. It first appeared when demoing some sessions for family members during a recent holiday.

If a prior-version session is loaded there is a chance that the script will somehow go into a wonky state where some of the top section buttons still function, but the vast majority of everything else shows there is nothing mapped.

Like you, disabling and re-enabling does nothing to resolve the issue. If I find myself in this state, so far the only 100% success rate at fixing it has been to factory resent my FP2 and reload the current firmware. After doing this, sessions that had previously not resulted in this wonkiness will return to normal, but any session that does exhibit the wonkiness will re-wonk the script.

In my case, once the wonkiness starts, any session I open will continue to misbehave without the factory reset.

What I’ve taken to doing is rebuilding my session templates in pure v14, and importing the previous session’s tracks into my template.

Sometimes it just Wonk do what we want

Yahoo Mail: Search, organise, conquer

Yes, because as far as I can see, Cubase 13.0.51 now with MIDI Remote together with the FaderPort doesn’t seem to have the bugs that Cubase 13.0.50 had.

I did that (the update). I think the new features in Cubase 14 are brilliant. :innocent:

But evaluating the MIDI Remote problems of migrating old projects to Cubase 14 is too time-consuming for me.
Steinberg has changed the project structure, which can mean various unknown side effects. Some things of this kind may be solved in 14.0.10, others not until 14.0.20 or even later. That’s why I always delete as many settings as possible after an update and then always re-enter everything so that I know better what the problem is NOT. Of course, everyone has to decide that for themselves.

1 Like

Nuendo 13.0.51 still not working for me.
All projects forget the midi controller each time I open it.
I rolled back to 13.0.41 :rage: again
I will not buy Nuendo 14. I will wait and see.
I have no confidence in Steinberg at the moment.

I have the connection for the FP script in my session template. Do you not?

I don’t own unfortunately this midi controller, however, I do have a suggestion if you don’t mind:

How about @LluisV and @SouthFresh share your current midi port names by a screenshot of Studio→Studio Setup→MIDI Port Setup?

From what I understand, the MIDI Remote API has become more strict when it comes to port recognition. I don’t know if it’s intended or just a miss, but it is what it is for the moment.

I’m asking you this info, because if we all can see the port names, I’m optimistic that we could come up with a solution, kindly asking @CKB to perhaps insert another detection unit in this great script.

3 Likes

As requested: Studo → Studio Setup → MIDI Port Setup:

For extra credit:

3 Likes

Your setup looks perfectly fine to me, it’s exactly the one the script is set to detect! So, if you don’t load a template, and you simply create a new blank project, doesn’t this midi controller get activated?

3 Likes

Mine seems to load fine in a completely empty session. All settings show exactly as they did regardless of my template usage!

3 Likes

Don’t think this is any help but…
Cubase project which Faderport likes in Cubase 13 but not in 14.
I attempted and failed to import the tracks from the 13 project into a 14 template. All arrived corrupt.
Opened the project in 13 (all good with FP) now ran backup project. Opened backup version (all good with FP) closed 13 opened 14 FP now likes the project in the backup 13 version. Saved that (so becoming a 14 version) and all is well with FP.
What have I learned ? Not sure !!!

2 Likes

Hi m.c.,
thanks for your help. :innocent:

At the moment, the script looks like this:

// create objects that represent the midi ports of the hardware
var midiInput = deviceDriver.mPorts.makeMidiInput()
var midiOutput = deviceDriver.mPorts.makeMidiOutput()
deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('PreSonus FP2').expectOutputNameEquals('PreSonus FP2')

Very often I only work with the FaderPort and my audio interface, which also has MIDI. Then it looks like this for me:

I have NEVER had a MIDI port problem since MIDI Remote was introduced, so unfortunately I can’t reproduce the errors. I work with Windows 10. Maybe there are only problems on the MAC?

I just checked the thread Midi Remote Randomly Disconnects again.

Steinberg said they have tried to solve this, but unfortunately there are still cases where it doesn’t work. It seems to be a very difficult problem to localize. The only solution I can see is for Steinberg to test a real system configuration that has turned out not to work here 1:1 in their office, i.e. to have the error themselves in order to be able to find it. The strategy of only being able to find the error with “theory” sometimes just doesn’t work.

2 Likes