[AZ, Watercourse, BobF] PreSonus Faderport

[BobF]

You might find clues here -- > http://forum.cockos.com/showthread.php?t=170036

Source link is at the bottom of the first post

[azslow3]

Thank you for testing!
Please try one more time with preset attached. No other tests, just check either it works or not.

Thank you for the link! Reaper does it the same way as Ardour. Reaper does that without "handshake" at all, just with "Switch to native". Ardour check that FaderPort exists with "Is someone there?" (yes, just with generic question). It looks like Sonar original preset tries to do something else with specific SysExes , Reaper nor Ardour do not use them. FP does not reply on these SysExes (from your tests), so it is unclear for what they are good.

My mistake in the last preset was a typo... I forgot to convert "64" from HEX to DEC, so it has to be "100" inside my interface. Unlike humans, digital devices do not forgive such mistakes 

PS Looking at the Reaper and Ardour sources... programming AZ Controller is simpler 

[BobF]

I'll check it out right away.

From the user perspective (me), the configuration of the FaderPort XT controller in Reaper is VERY simple.  In part that's due to Reaper exposing every possible thing to use for custom actions.

The ONLY thing the Reaper version won't do is move properly back/forth with the [Output] button

[BobF]

SUCCESS!

I deleted/reimported the new preset prior to shutting down, leaving my old preset selected in Az_Ctrl

Upon startup, the FP went to [Write] lit as always.  I started SONAR and opened Az_Ctrl and selected the new preset BEFORE loading a project.  The status was pending

As soon as I opened a project, the FaderPort went active matching the current track and the Az_Ctrl status went to Done.

[azslow3]

SUCCESS!

Great! I will update build-in preset for other.

Upon startup, the FP went to [Write] lit as always.  I started SONAR and opened Az_Ctrl and selected the new preset BEFORE loading a project.  The status was pending

That is a bit unexpected... Recent versions of AZCtrl was thought to work without project loaded. Thank you for that observation.

From the user perspective (me), the configuration of the FaderPort XT controller in Reaper is VERY simple.  In part that's due to Reaper exposing every possible thing to use for custom actions.

That is from END user perspective, in assumption "someone else" has written a plug-in for particular controller, the plug-in you have mentioned in your previous post. The situation with Sonar is different. At the moment, there is a single person which tries to create such plug-ins, me. And I do not have devices for which I do that. As with CW API, Reaper API is "traditional" one: even with C++ experience, the code should be programmed, then compiled, then loaded for tests. Not only I will be unable to proceed with such approach without device in the near, one single "cycle" with such development schema takes a lot of time. "Quick planing", f.e. add one more "shift" key, rearrange strip types, test something remotely with TeamViewer is only possible within interactive environment.

I completely agree that exposed by Sonar operations are far from complete. They have stopped updating "Commands" long time ago, also commands available under particular views are "forgotten" (they expose only "Global" bindings). Quick and dirty "hack" to make VS-700 work with ProChannel is a joke. And there are too many bugs in what is already there. But nothing prevents improving that part of Sonar

[azslow3]

I have updated last attachment (cleaned Init Test and changed one action...). I do not think the change is significant.

I have also changed generator code inside AZController.

Thanks for improving the preset!

[BobF]

Thanks again, Alexey.  I'll download again to make sure I'm in sync.

[BobF]

Alexey -

This latest version has been thru many reboot/cold starts now and continues to perform error free.

[bbergen]

Was using Faderport tonight in Sonar (with AZController) and just noticed that pan is not working and the stop button doesn't work. The only way to stop playback is to hit the play button.
Using 0.5r3.
I tried recreating the preset but the same.
Any ideas?

[azslow3]

Was using Faderport tonight in Sonar (with AZController) and just noticed that pan is not working and the stop button doesn't work. The only way to stop playback is to hit the play button.
Using 0.5r3.
I tried recreating the preset but the same.
Any ideas?

That is very strange. Please install the latest test version from the Downloads, 0.5r4, just to be sure we you the same. Regenerate the preset, switch to the Overview tab. Watching the "Last MIDI event":
1. press Play, you should see "Ch:1 KP:6 ...". Now press Stop. You should see "Ch:1 KP:5". If you see that, look at "Lost control actions" lower. There should be 3, the middles one "Command Stop"
3. turn the encoder. You should see "Ch:1 PB ...".

If you do not see these messages, for some reason Faderport is not sending them or Sonar blocks them. In Sonar preferences/MIDI/Playback and recording check that "Pitch Wheel" is checked. But for the "Stop" button the reason is hard to imagine...

If you see these messages but Sonar is not reacting on commands from AZ Controller, I will write another instructions to test.

I am sorry it does not work. But if the device is ok, we will make it work again.

[bbergen]

Play shows a command in the overview tab, stop shows nothing, pan to the right shows nothing, pan to the left does.

[azslow3]

That is not good... Encoder working in one direction only can be an indication of broken hardware, the same for the button. The encoder in both direction should send the same MIDI message, just with different value. The button can theoretically be blocked by some software, each button sends different message.

But before any conclusions, please check with the original plug-in or even better with another DAW if you have some.
If controls are not working anywhere, you can try to upgrade the firmware, Presonus has instructions.

Excuse me for pessimistic replay, I wish the problem is in my code so I can fix it. But only fader touch message is not shown in the Last MIDI event by design. All other should be reported even if not assigned. While I can not exclude some bug which prevent incoming message from be shown/processed, I have never observed that so far.

Reaper script for the Faderport has a workaround for "half broken" encoder, I guess that problem is not unusual. But in such case it is flipping, I mean when you turn it right it periodically report it was turned left. Your observation is different.

[bbergen]

Ok, time for some contact cleaner.
Kept pressing hard on the stop button and now it works correctly.
Time for some maintenance!
Thanks!

BTW, Presonus has changed their site and removed the installer for Faderport.
The only way to get the dll is on this page:
http://support.presonus.com/hc/en-us/articles/210040173

The page is not easy to find either.

[azslow3]

Good that you could bring the button back. Usual Russian way to fix any equipment: hit it hard 

Cleaning encoders on my StudioMix is still in my plans (all 16 of them plus the jogger are "left oriented", I mean they send turned left on almost all movements). Back in time, I remember how "fixing" the opto-pairs in mouse was required every half an year: just by moving them close to each other. I do not know how encoders are constructed internally, but I guess the same way. So can be dirt or loose of sensitivity/emission.

[bbergen]

Good that you could bring the button back. Usual Russian way to fix any equipment: hit it hard 

Funny that you should say that, 15 years ago I had a business with my Dad and brother where we rebuilt close tolerance machinery.
He had a hammer that we called "The Russian Hammer", it was a 10lb sledge with a metal handle.