Using with ProControl ( 8fader)

[lazlooose]

I have been successful with the pro control for Faders, mutes Solo, rec rdy, channel select, automation select, Jog Wheel, pans and transport are all working. but the VUs , scribble strips and clock are blank and pushing certain buttons causes the program to crash

the terminal window for control24d.py shows MP Listener waiting for connection at ('192.168.0.10', 9123) Control24 Broadcast detected from: 00 a0 7e a0 17 fd MP Listener Received connection from ('192.168.0.10', 50087) Waiting for DESK ACK 0 Waiting for DESK ACK 0 Waiting for DESK ACK 0 and then a long series of the same messages including Waiting for DESK ACK 1 Waiting for DESK ACK 2 Waiting for DESK ACK 3 Waiting for DESK ACK 4

log attached here:

control24d.log.12_03.00_30.csv.zip

I am not getting a log from control24OSC at the moment so here is the text from the terminal:

this session was working then I pushed a button in the channel matrix and the program crashed.

OSCServer: AttributeError on request from 192.168.0.10:64844: 'C24track' object has no attribute 'c24scribstrip' OSCServer: AttributeError on request from 192.168.0.10:64844: 'C24track' object has no attribute 'c24scribstrip' C24client unhandled osc address: /scroll/CursorLeft [f] [0.0] C24client unhandled osc address: /scroll/CursorRight [f] [0.0] C24client unhandled osc address: /scroll/CursorUp [f] [0.0] C24client unhandled osc address: /scroll/CursorDown [f] [0.0] C24client unhandled osc address: /zoom/CursorLeft [f] [0.0] C24client unhandled osc address: /zoom/CursorRight [f] [0.0] C24client unhandled osc address: /zoom/CursorUp [f] [0.0] C24client unhandled osc address: /scroll/CursorLeft [f] [0.0] C24client unhandled osc address: /scroll/CursorRight [f] [0.0] C24client unhandled osc address: /scroll/CursorUp [f] [0.0] C24client unhandled osc address: /scroll/CursorDown [f] [0.0] C24client unhandled osc address: /zoom/CursorLeft [f] [0.0] C24client unhandled osc address: /zoom/CursorRight [f] [0.0] C24client unhandled osc address: /zoom/CursorUp [f] [0.0] OSCServer: AttributeError on request from 192.168.0.10:64844: 'C24track' object has no attribute 'c24scribstrip' C24 client Uncaught exception Traceback (most recent call last): File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1320, in _manage_c24_client self._desk_to_daw(datarecv) File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1220, in _desk_to_daw parsed_cmd = C24oscsession.parsecmd(cmd) File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1154, in parsecmd 'Level %d byte not found in MAPPING_TREE: %02x' % (level, this_byte)) LookupError: Level 3 byte not found in MAPPING_TREE: 1a Exception in thread thread_c24_client: Traceback (most recent call last): File "/usr/local/Cellar/python@2/2.7.14_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in bootstrap_inner self.run() File "/usr/local/Cellar/python@2/2.7.14_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run self.target(*self.args, **self.kwargs) File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1320, in _manage_c24_client self._desk_to_daw(datarecv) File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1220, in _desk_to_daw parsed_cmd = C24oscsession.parsecmd(cmd) File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1154, in parsecmd 'Level %d byte not found in MAPPING_TREE: %02x' % (level, this_byte)) LookupError: Level 3 byte not found in MAPPING_TREE: 1a

^Cdaemon shutting down as SIGINT received. C24oscsession closing C24oscsession closed OSC Listener error Traceback (most recent call last): File "/Users/reddrzazccron/Library/Application Support/REAPER/Scripts/ReaControl24-Release copy/control24osc.py", line 1344, in _manage_osc_listener self.osc_listener.serve_forever() File "/usr/local/lib/python2.7/site-packages/OSC.py", line 1816, in serve_forever self.handle_request() # this times-out when no data arrives. File "/usr/local/Cellar/python@2/2.7.14_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 271, in handle_request fd_sets = _eintr_retry(select.select, [self], [], [], timeout) File "/usr/local/Cellar/python@2/2.7.14_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 150, in _eintr_retry return func(*args) error: (9, 'Bad file descriptor')

[phasewalker18]

It appears that there are 2 main issues: there is a scribble strip being addressed on a track that doesn't have one. The Control24 has one for tracks 0-23, and 2 more on virtual tracks somewhere between 24 and 31. This means the same sequence is used for something else on the ProcControl or a scribble elsewhere is being addressed.

The main issue with the matrix buttons has a couple of interesting points:

The 3rd byte 0x1A is not in the map, which can be remedied if we can work out what it is supposed to do. When the map is incomplete an error occurs rather than a warning. The program could even look to output new map elements when they are encountered.

Overall, support for having desks other than a Control24 is required.

@lazlooose - if you could try the following and report back findings:

modify the 'logs' subdirectory so it is writeable by all users (chmod +w logs) Add the debug flag to the command lines (-d or --debug) This should provide both log files as output and a lot of detail that will help identify the sequences.

[Disruptormon]

Map for ProControl different. Need map made for device and code to handle other map. C24client unhandled osc address: /scroll/CursorLeft [f] [0.0] - seen on Control24 - ignore. 'C24track' object has no attribute 'c24scribstrip' - this is sane - PC has diff. number of display.

[phasewalker18]

@Disruptormon yes, hoping once @lazlooose posts debug logs, code can use device announcement to determine which map to use, and then I will make a branch for ProControl compat. Matrix control very different to anything on Control24, and banking will need to be changed to 8 wide, but with allowance for banks of 32 on matrix control. Scribble strips also seem very different. This can all be routed easily enough, then new ProControl classes made for different operation of controls.

[lazlooose]

here are some debugs. I had a little trouble finding them since the logs directory changed on me cause I was running the python command from my home folder instead of inside the reacontrol folder ...

for these ones it connected to a reaper session. then I used some of the faders, the jog wheel, pressed some mutes and solos and then pressed the matrix button (17 or 18 I believe) which crashed it. I have experimented and found that half of the matrix buttons and most of the EQ section buttons are mapped as channels 9-24 rec select , mute, solo, etc...if you look at the reaper listener in the osc csurf preferences. the other half (17 -32) seem to be unmapped and crash the control24OSC.py script. also the assign/mute pre/post buttons for channel 1-8 appear to be unmapped and also crash the script. I think all of the transport and edit section buttons are mapped correctly but I will continue to experiment.

thanks so much for looking at this! control24d.log.12_03.16_20.csv.zip control24osc.log.12_03.16_21.csv.zip

[phunkyg]

Great work @lazlooose ! I'm sure @phasewalker18 will take a look. I just wanted to say I have been working in the DEV_Compatibility branch, and I have made a change that makes unmapped sequences a non-fatal error. This should at least mean you can continue your session after pressing one of these. If you want to grab that branch and try again, please feed back if the crashing behaviour stops.

[Disruptormon]

Hello Phunkyg. TY for code help. I try this today and feedback.

[phunkyg]

@lazlooose apologies, that code didn't catch the desk announcement very well. Can you download the latest and try again please? You should hopefully see the device name appear as it connects.

[lazlooose]

hey I tried the ones in dev_compatability. @phunkyg the fix for the unmapped buttons worked, the program no longer crashes!

I think it caught the device name MAINUNIT v1.37 but i'm not sure if that is what you were looking for.

here are the debug logs:

control24d.log.13_03.22_57.csv.zip control24osc.log.13_03.22_58.csv.zip

thanks again!

[lazlooose]

Also I looked into the control 24 and I notice one of the main differences for the scribble strips is that the control 24 has four characters whereas the pro control has 7 characters. the control 24 also seems to have one per track whereas the pro control has two per track , one for track name and one for the encoders: usually pan value, but, also used for assigning sends and inputs etc.... and then another nine in the DSP Edit/Assign section (all 7 character displays) hope that helps. it would be awesome to have the clock VUs and track names working.

[phunkyg]

@lazloose that's perfect. Looks like the Pro Control announces as a main unit, then I suppose the expansion modules announce separately. This should be enough to divert you into a different map, then it might be possible to write classes to deal with the different layout and capabilities - and thanks for the extra info on that. I'll chat to @phasewalker18 about it, as I'm still very new to the code and I'm not sure how this would be done yet.

[phasewalker18]

@phunkyg the issue you will have here is that there is currently no message sent along the MP connection when the desk announce is received. I had been thinking about a 'command channel' style MP comms where it would be possible to send such control commands. Another way of thinking it is the broadcast packet itself might contain a control command byte which means the whole thing could be sent then handled by the OSC client by the existing mapping method (CmdClass). I don't know, you have looked more closely at this in your recent edits and @lazlooose log files. This would answer a current TODO in the code line where announcement would be useful for initializing anything stateful. IIRC this is around the Navigation class at the moment because this was the first stateful LED lamp on begin. After that then it would be possible to direct the instantiation of the desk object to another class or parameterize the current one with different channel count and classes for the announced unit. Later on maybe, consider multiple devices might announce and many session require instantiation if the pro control multiple unit configuration is used. Currently this isn't supported but could be possible and that is why the session object is a class so there could in theory be many of these.

I know this all very complicated so you can come to chat again if that helps and I will point at things and talk again.

[lazlooose]

thanks @phasewalker18 and @phunkyg ! let me know what else I can do to help!

[phunkyg]

Not much news, but work in on-going here. I have been reviewing and refactoring the code with @phasewalker18 to get it ready for the adjustments he suggests above. We've also been tidying up and making things a little more pythonic.

[lazlooose]

thanks for the update. I really appreciate the work you guys are doing

[phasewalker18]

Thanks @phunkyg , that was a very productive session we had on refactoring the code ready for these changes. I wish I had known these things earlier on about python. The code is much cleaner and more elegant now. I hope you will take that version forward and see it tested and completed.