Faderport 8 and 16 users - please help me by testing your controller

airon · 02-24-2020, 04:12 AM

I've run in to a problem with my Faderport 16 unit, and need help to verify that it's just my unit messing this up.

If it is just my unit, your test will run fine and dandy. If it isn't it'll be a firmware problem that Presonus can just fix hopefully. They have been updating their firmware fairly often so that shouldn't be a huge problem.

The Problem (on my end)

If one of your faders is being moved by some volume automation, using one of the other faders to record volume automation results in choppy, crappy data.

For me, the results look like this:

Why do the test

This could narrow it down to either a fault in my Faderport 16 unit or some other aspect of my machine, i.e. it only happens to me. Or it could be a problem for everyone and that points to the firmware messing things up.

MixMonkey ran this test with a Mackie Control Universal, so everything seems to be fine for those units, at least for him .

The Test

Create two tracks or more and enable & arm the volume envelopes on them.

Make a pass on one of the tracks in Latch or Touch mode, and ride the fader up and down a bit. Two or three seconds of data is all you need.

Switch to Read then back to Latch(or touch mode) to clear all latches.

Now use a different fader and push the volume fader up and down, between once and twice per second. That'll show any problems.

Report back in this thread on what you found. If the volume envelope is as smooth as it was on the first volume envelope you recorded, your unit is great.

Please include your general system description and firmware version. It may very well be that my mainboards USB chipset is messing something up(Z170 chipset, i7 6700K on my end).

Thank you for your help.

airon · 03-07-2020, 04:41 AM

One fellow user has reported in so far. He

Are there any other Faderport 8 or 16 users that could run this test ?

Please post screenshots of your volume automation recordings one two tracks.

I am getting this :

Reaper 6

Studio One 4

Ableton Live 10

dougdi · 03-07-2020, 10:04 AM

I have the same behavior here with Reaper 6.04, Faderport 8 firmware 3.21, OS X Sierra. I rarely use the Faderport 8 so I've never encountered this issue. I know I used it successfully with Pro Tools 11 HD in the past. Either way this sucks, how do we determine if it's a Reaper or Presonus fault?

I also have Ableton Live 10, I'll try to run more tests this weekend.

I'm (attempting) to attach 2 pics here.

Doug

dougdi · 03-07-2020, 06:48 PM

I seem to only have the problem when automated tracks are in read mode, trim/read works fine. So that's an easy workaround but definitely a bug. I have yet to try Ableton Live or Pro Tools yet.

airon · 03-08-2020, 02:28 PM

The trim/read volume control is independant of the automatable volume control.

Normally volume automation from control surfaces seem to be recorded at 30 Hz, judging by the MCU control surface plugin. So you wouldn't really notice a change in any data over the short time of a hundred milliseconds or more for a static volume control that never records automation or plays any back.

Thank you for posting the screenshots and your system specs.

Keep those reports coming!

dougdi · 03-09-2020, 10:37 AM

I just tried Ableton and same results as yours above. Huh. I had no idea, as I said I haven't been using it for awhile. If my memory is correct there was an issue with all automation written haven a low resolution with the original firmware of the F8 and that it was fixed. I never saw a problem then with additional automated tracks. So hopefully Presonus can fix this in an update. I guess I should contact them and start a support ticket?

inertia · 03-09-2020, 11:42 PM

I can also confirm this behaviour with the latest firmware and Reaper version.

airon · 03-10-2020, 04:51 AM

I've posted this all over.

Definitely bring this up in a support ticket.

Did you know the Avid S1 appears to have an actual hardware defect that prevents it from recording automation takes longer than 48 seconds.

Why wouldn't the Presonus hardware have problems, and yeah, I do hope they can fix it with a firmware update because I really like this unit and wanted to deep dive with CSI. The faders are really close together, but I don't get it. The Mardi Gras test mode reveals nothing wrong with the faders being able to move all over the place, but reading from them is hard ?

Keep the reports coming. That's three confirmed cases with screenshots so far.

airon · 03-10-2020, 09:16 AM

Quote:

Originally Posted by inertia

I can also confirm this behaviour with the latest firmware and Reaper version.

Intertia, is that a Faderport 8 or Faderport 16 ?

inertia · 03-10-2020, 10:38 AM

It's the 16 channel in MCU mode but I only configured the first midi port so only 8 faders were available.

There is no difference between the 16 and the 8 other than some extended codes for the extra faders and what not. The 8 channel shares the exact same firmware and codes for everything that corresponds between the two.

I am working on a native driver for the two units (I have both of them) but I don't have time to finish it at the moment.

The native mode is quite similar to the MCU mode except a few different mappings and a difference in how the displays work so I don't think the native driver will change this behaviour.

airon · 03-10-2020, 02:34 PM

Thanks.

I hope this is something that firmware can fix. I'll still be using this unit in the coming weeks, but I have an extra Faderport (classic) to do eventual fader runs on overlapping material that moves a fader on the FP16.

I really enjoy using this unit, and I'm making good progress writing CSI zones for it. I can already do more with it than with the native MCU driver Reaper provides. I'm not sure I want to have to get an Avid S1. They're replacing the defective S1 units btw, just sending them to the users on request, who just need to send back the defective unit(Avid's paying for that too). I'm hoping I can keep my Faderport.

Inertia, what do you think causes this problem ?

airon · 03-10-2020, 03:12 PM

The issue is now being sent to the dev team I'm told. We shall see if they can fix it with a firmware update.

inertia · 03-11-2020, 06:52 AM

Quote:

Originally Posted by airon

Thanks.

I hope this is something that firmware can fix. I'll still be using this unit in the coming weeks, but I have an extra Faderport (classic) to do eventual fader runs on overlapping material that moves a fader on the FP16.

I really enjoy using this unit, and I'm making good progress writing CSI zones for it. I can already do more with it than with the native MCU driver Reaper provides. I'm not sure I want to have to get an Avid S1. They're replacing the defective S1 units btw, just sending them to the users on request, who just need to send back the defective unit(Avid's paying for that too). I'm hoping I can keep my Faderport.

Inertia, what do you think causes this problem ?

I am not sure what causes the problem. It could be a duplex bandwidth issue or something.

I'd like to test your files for the CSI...i've had little success getting the Faderport 16 working with it. The displays don't work and the Faderport doesn't reconnect when Reaper loses focus. Do you think you can send them to me?

airon · 03-13-2020, 10:52 AM

Here you go. That's the state it's in right now.

https://stash.reaper.fm/38545/CSI_Fa...e_20200313.ZIP

inertia · 03-13-2020, 11:23 PM

Thanks, will give it a test today!

daslicht · 02-24-2021, 09:54 AM

I have exactly the same issue here with my FaderPort 16 (3.44, 17431) under StudioOne 5 (datareduction 0%)

left: working state, right: broken state

I contacted the Presonus Support they told me that I should send it in for repair.

From another source I heard that they work on the firmware...
What's true ?!

The only workaround, after which anything works as expected, is to powercycle the unit until it works, sometimes it is just one on/of, another day I have to turn it on/off multiple times eg 6 !

daslicht · 02-24-2021, 09:56 AM

Quote:

Originally Posted by airon

The issue is now being sent to the dev team I'm told. We shall see if they can fix it with a firmware update.

Any news on this ? Confirmation that they are aware and work on it ?
If so, the Presonus Ticket Support don't know of this, and someone should brief them.

It would be much better if they would officially admit that there is something wrong,
instead of claiming that units are broken.

daslicht · 02-25-2021, 05:16 AM

2 days ago I ordered a complete new unit to crosscheck if it behaves different.

Today I received the unit, and it behaves exactly the same as my current !

So my unit is not broken !

Conclusion:
* it is either a firmware or unit design bug.
* or the FaderPort 16 is not compatible with our hardware

By the way this is not limited to Windows, it also happens under macOS.

airon · 02-26-2021, 06:14 AM

Yeah, it's likely a firmware or even hardware issue.

This 'feature' which to professionals is a bug/design flaw is the reason I always include a "but" in the recommendation of any Presonus Faderport unit, whether that's 16 or 8(verified too) or perhaps v2. I'm not sure this happens on the single-fader unit. Once you take over from existing automation you should be ok.

So the end result is, the Faderport 16 and 8 are fine if you only do slow fader moves.

But for fast moves or very quick moves as done in dialogue mixing, this thing is rubbish even compared to the MCU predecessor I used 15 years ago, never mind anything with fancy faders like the Procontrol. And only for this particular reason. The rest of the unit is fine. And I've been living ok with the crappy fader output when existing automation makes any fader move.

Buttons are fine. It works really well with CSI. Displays are not so good if you're not looking at them straight down, but still readable if you go closer.

It only matters if it affects you.

Presonus told me they're dealing with it, but that was just as the virus was starting to really impact most of the world. It could have gotten lost in the home office phase we're all still in.

daslicht · 02-26-2021, 07:13 AM

Quote:

Originally Posted by airon

Yeah, it's likely a firmware or even hardware issue.

This 'feature' which to professionals is a bug/design flaw is the reason I always include a "but" in the recommendation of any Presonus Faderport unit, whether that's 16 or 8(verified too) or perhaps v2. I'm not sure this happens on the single-fader unit. .

Never happened on my FaderPort Classic

The FaderPort 16 works as expected here when I turn it off and on again until it works. Sometimes it just one power cycle, the other day it took 6 rounds. But after that it works quite good. Except that the displays sometimes stop displaying anything until I switch the mode from eg Track to Plugin and back.

You opened a tickt at Presonus reporting the issue ?
If more people report it it gets harder to ignore.

You are part of the Facebook presonus faderport group ? There are others reporting similar issues.

airon · 02-26-2021, 08:36 AM

Yeah I opened a ticket and after much back and forth they sent the information to what I assume must be the firmware developers.

That was over 11 months ago. The firmware didn't seem to have any updates a while ago. I'll need to check again, but I'm not optimistic.

daslicht · 02-26-2021, 08:37 AM

do you still have the ticket open ?
Maybe re-open it

airon · 03-01-2021, 02:03 AM

I've posted in the Presonus forum thread again, but I'll reopen a ticket if that doesn't work.

helgoboss · 03-02-2021, 02:16 PM

Same here. Just tested it with ReaLearn.