phunkyg / ReaControl24

Control24 digital control surface protocol middleware
GNU General Public License v3.0
7 stars 6 forks source link

volume fader touch command missing #5

Closed lazlooose closed 5 years ago

lazlooose commented 5 years ago

I have been using this program with my pro control and despite not all the features working (layout differences with control24) the thing that works well is the faders/mutes /solos and transport section which is great for automation, however I have noticed that when you touch the faders it does not send the touch signal:

TRACK_VOLUME_TOUCH b/track/volume/touch b/track/@/volume/touch

which affects touch automation since if you are not actively moving the fader it will drop the touch, also there is a delay between when you remove your finger from the fader and the end of the "touch",

Is it possible to include this? it seems it is already in the OSC docs. I believe it is just a question of coding it into the mapping and then adding it to the Control24.reaperOSC file.

thanks! LZ

phunkyg commented 5 years ago

This works on the Control24, so potentially the ProControl might use a different byte sequence. control24map.py line 938 Control24 Touch: 0x90, 0x00 (track), 0x09

Can you start a session in debug mode, make a few touches, then attach the log?

lazlooose commented 5 years ago

OK interesting, thanks.

here is a log of just touching the faders 8-1 then 1-8 in debug mode.

In the listen box in reaper csurf prefs touching the fader results in a printing of the value of where the fader is ex: for a fader at 0.00 - touching the fader produces this /track/c24fader/3 [f] 0.000000 /track/c24fader/3 [f] 0.000000

if it is not at 0.0 it produces whatever value it is at twice like above ex: /track/c24fader/3 [f] 0.410156 /track/c24fader/3 [f] 0.410156

control24d.log.07_01.16_56.txt

phunkyg commented 5 years ago

OK so that is weird. These touch commands at /fader/Touch appear to be the same byte sequences as the Control24. Can you do the same experiment with both daemon and client in debug mode. The client seems to not be decoding these correctly.

lazlooose commented 5 years ago

thanks! here it is. basically the same sequence , I started the daemon and client, opened a reaper project, touched the faders 8-1 1-8. then shut it down.

control24d.log.09_01.15_02.txt control24osc.log.09_01.15_02.txt

phunkyg commented 5 years ago

OK got it. control24osc.py line 1231

When the map specifies 'CmdClass' on a mapping, the class is then responsible for all actions. With fader touches (which are effectively buttons on OSC address)

/button/track/touch/@ 

they are specified with command class C24fader, which diverts their actions away from the default for buttons, which is to simply send their buttons to OSC.

I don't see a problem with doing both by default, then both the classes AND reaper could respond to them if required?

I've put this change into both control24osc.py and procontrolosc.py in branch DEV_OtherDevices for you to try out, so clone or download the latest versions to have a go.

lazlooose commented 5 years ago

hey @phunkyg thanks! I had a chance at last to test it out and it was working partially, touching the fader was sending the right command to the listen box but still the touch automation in the reaper project was still acting like before and not responding to the touch at first. So, I added: TRACK_VOLUME_TOUCH b/button/track/Touch/@ to the ProControl.ReaperOSC file and now it working perfect! Thanks man!

phunkyg commented 5 years ago

Great. I've added that entry to the file.