Procontrol with ReaControl.py (Dev_OtherDevices) not working

[lazlooose]

Hey, runnng on windows 10 here I have the procontrol working with the old way of using control24d.py and control24osc.py but I tried to do it with ReaControl.py but I can't get it to work the procontrol responds in the sense that the Offline goes away on the Procontrol display but no interaction with Reaper and then the Offline comes back on.

main.log.06_04.23_51.txt
procontrolosc.log.06_04.23_51.txt

[lazlooose]

yeah I've tried a bunch of things and I can't get it past:

020-04-07 23:54:42,302 main INFO device session 1_thread_listener run 333 device session 1_thread_listener Pipe Listener waiting for first data from pid 10676

it seems like it is identifying the desk but not receiving anything after. and this is only with the new ReaControl.py way the control24d.py way still works fine

[lazlooose]

here is an examplke control24d.py log run right after for comparison

control24d.log.07_04.23_59.txt

[lazlooose]

I tried running the newest dev_otherdevices Branch on my mac (old setup 10.6.8) using ReaControl.py only and I couldn't get it to work either. In debug mode the terminal window was capturing the procontrols output but it didn't get passed on to reaper. Briefly I was able to control the procontrol from Reaper, and SCRIB STRIPS WORKED! I had the dbs while changing the fader level and if I updated the track name it would flash on the same screen. After I opened the control surfaces preferences panel it stopped working (changes in Reaper were no longer affecting the pro control). not sure what is going on there.

[lazlooose]

I tried again on Win 10. the procontrol's offline display goes off after running Reacontol.py and stays off until you push any buttons on the procontrol or move faders at which point 2 seconds later the offline display comes back. if you open Reaper and move around faders and souch nothing happens on the Pro Control.

logs:
main.log.10_04.17_49.txt
procontrolosc.log.10_04.17_49.txt

[phunkyg]

Very odd behaviour from the scripts here. No errors but no function either.

I wonder if you have the same issue that MixR had: try swapping the port numbers around in the Reaper Control Surf plugin setup.
I never confirmed whether he'd got them wrong or if I had somehow swapped them in the code.

There is almost no traffic showing in these logs so if you pushed a bunch of controls in reaper and on the desk then neither is getting picked up.

There is a trace mode below debug now that might help (and it being off might somehow be hiding errors) but you have to edit the common. py file and change INFO to TRACE

[lazlooose]

For my Win 10 rig: since I have been messing around with wire shark I took a look on what the difference between the old control24d which still works and the new reacontrol.py which doesnt is. When I push a button on the procontrol, control24d.py responds immediately with a response: (X's where I removed my computers MAC address):

0000 00 a0 7e a0 17 fd XX XX XX XX XX XX 88 5f 00 10 . ~ .ý.oe©ðq._..
0010 00 00 00 00 00 00 00 00 08 6c 00 00 a0 00 .........l.. .

With the new Reacontrol.py, there is no such response from the computer. The pro control resends the message 17 times and then appears to decide the connection is dead and goes offline.

I will also try changing info to trace and see what happens. Thanks!

[lazlooose]

I should add that everything else is the same and the computer still sends what I interpret to be the keep alive packets:

0000 00 a0 7e a0 17 fd XX XX XX XX XX XX 88 5f 00 11 . ~ .ý.oe©ðq._..
0010 00 00 00 00 00 04 00 00 00 00 00 00 00 01 00 ...............

it just doesn't respond to button presses, or faders or anything else.

[lazlooose]

you mean in control24common.py here like this?

DEFAULTS = {
'ip':'0.0.0.0',
'daemon':9124,
'control24osc':9124,
'oscDaw':9125,
'auth':'be_in-control',
'loglevel':logging.TRACE,
'interface':'en0',
'logdir':'./logs',
'logformat':'%(asctime)s\t%(name)s\t%(levelname)s\t' +
'%(threadName)s\t%(funcName)s\t%(lineno)d\t%(message)s',
'timing_scribble_restore':1

I get this when I run Reacontrol.py:

Traceback (most recent call last):
File "ReaControl.py", line 22, in
from control24common import (DEFAULTS, COMMANDS, NetworkHelper, hexl,
File "C:\Users\redarc\Downloads\ReaControl24-DEV_OtherDevices_newest_april_7_\ReaControl24-DEV_OtherDevices\control24common.py", line 41, in
'loglevel':logging.TRACE,
AttributeError: 'module' object has no attribute 'TRACE'

REPLY: Try this: 'loglevel':"TRACE",

[lazlooose]

also, still on Win 10, looking on the local loopback adapter there is no OSC activity at all, not even "hello DAW" with Reacontrol.py whereas there is plenty with control24d.py and control24osc.py using wireshark.

[lazlooose]

hey @phunkyg sorry to bombard you with posts but I feel we are really close to having this working with near full functionality on Mac OS.

I have given up on Win 10 for now and using Mac OS I have communication from Reaper to the Pro Control and from the Pro Control to the Reacontrol.py client (commands received in terminal window) but it is not passed on from there to Reaper. Here are the logs. We are so close!

Also one thing I noticed. the /logs folder ReaControl.py creates can only be opened by sudo (which I don't remember being the case before) is this possibly a permissions issue we are having?

main.log.12_04.20_44.txt
procontrolosc.log.12_04.20_44.txt

REPLY: We have this one down at least: #7

[lazlooose]

in the hopes that this was a problem with my older MacOS I loaded up a raspberry pi with the most recent Raspbian and the new DEv_otherdevices but alas same issue!! procontrol receives reaper instructions but no proC to Reaper communication. Listen window in Reaper receives the Hello DAW messages indicating that the port is right but no commands. Also as before in debug mode the Pi receives commands from the Pro C, but for some reason does not pass them on. I'm at a loss here.

[phunkyg]

Sorry guy, I hadn't assigned myself here in git so wasn't getting notifications.
The lack of TRACE is telling. Could be a failure on my side to commit latest changes.

[phunkyg]

Just from memory and hearing how it is behaving it sounds like a fatal error is happening in the code but we're not getting it out in the log. Seems you can't see it in the terminal either. Last thing I messed with was the logging so it is entirely possible I broke something. I can make some basic tests here with the somewhat rudimentary emulator.

[phunkyg]

OK I have had a tinker - the new 'TRACE' level wasn't working very well. It still isn't perfect but at least it activates now!

Can you get a fresh set of CSV's from a simple test (ONLINE, mute in reaper, mute on desk) and I'll see if I can see any nasties in there?

PS - get the latest from this branch to get the changes. I've left TRACE turned on by default for now.

[lazlooose]

Alright! Thanks @phunkyg ! Trace is working now. Still same behaviour as before between desk and reaper, here is the log from my raspberry pi with the requested sequence: ONLINE, mute in reaper, mute on desk:
procontrolosc.log.14_04.16_48.txt
main.log.14_04.16_47.txt

[phunkyg]

Can you dump your Reaper Csurf OSC settings pls
and copy in the command lines you're using?
As you're split over Raspberry pi and Reaper machine now, you'll need to specify command line switches accordingly.
I can see various 192.168 addresses, can you confirm:

.34 = Pi
.15 = Reaper
.10 = ?

(edit - also realising this would be really good info for the logger to dump out when in debug mode!)

[phunkyg]

PS if you like me are having problems with processes hanging about between tests, I've included a file kill.sh which I'm using to clean up between each run.
You may need to do
chmod +x kill.sh

then execute it with
./kill.sh

it needs to sudo so do that when asked.

[lazlooose]

.34 is pi
.15 is Reaper Win 10
.10 is Reaper Mac

command line for Pi to connect to Win 10 machine:
sudo python ReaControl.py -c 192.168.0.15:9125 -d

screen cap for settings in Reaper:

awesome thanks for the script!

[lazlooose]

one thing I notice as if you change the pattern config in the reaper settings (I did it three times) Reaper stops connecting with the procontrol (the procontrol stops responding to changes in Reaper) but no errors appear in the terminal. if you kill and restart the process on the pi it goes back to responding again

[phunkyg]

OK so in your trace we have these 2:

OSC Listener received Message: ('192.168.0.15', 54646) /button/track/Mute/1 [f] [1.0]
Starting OSC Client connecting to ('192.168.0.10', 9125)

Which is weird, no idea why .15 is getting involved at all.
OSC does allow for multiple clients but ReaControl does not (currently, we might need to overcome this for ProControl fader packs!). I wonder if it is picking up both of your Reaper machines and getting confused?

And yes, in testing, changes to the OSC control files need a full Reaper restart. Also worthy of mention is reloading your project because it 'dumps' everything via OSC. If you restart ReaControl without doing this, your scribbles etc. will be blank until the next message (e.g. track rename)

So, can you try another 'clean' test with the latest code, just the pi and mac, with Reaper and ReaControl definitely OFF on the other machine - just in case.
If the other IP shows up again we can be sure the code is at at fault.

EDIT: just a thought - are both mac and windows physical or is one of them a VM?

[lazlooose]

That is interesting, for a second I thought maybe you had found our problem, but, I checked the more recent logs and they all show the osc_client manager and osc_listener both connecting to 192.168.0.15 (win10 machine I was using Reaper on) I am pretty sure I was also using that OS for that test. There is no way they can be on at the same time since they are on the same computer (with the option to boot into one HD or the other...full disclosure it is not a real mac, but a hack no VMs). I will do another clean test to be sure and post the logs.

[lazlooose]

ok here we go with a fresh git clone of DEV_OtherDevices from phunkyg/ReaControl24.
Running command :
sudo python ReaControl.py -c 192.168.0.15:9125 -d
on pi (192.168.0.34)

1. I opened a blank project in Reaper on win10 computer (192.168.0.15) at this point all the LEDS for automation and pans lit up on the Pro C!
2. Created a new track (fader jumped into position on Pro C at 0db on track 1).
3. Muted that track in Reaper (mute LED turned on for track 1 of the Pro C).
4. Pushed mute on Pro C ( mute light went out on Pro C -- but no response in Reaper track remained muted).
5. Pushed mute once on Reaper (deactivating it since it was still on) and then second time to reactivate it (once again corresponding LED on Pro C turned on).
6. Pushed mute Ch1 on the Pro C one more time (same- Mute LED on Pro C turned off but Reaper track, unaffected, remained muted)
7. Then I Ctrl-C'd out or ReaControl.py on the pi.

main.log.16_04.17_48.txt
procontrolosc.log.16_04.17_48.txt

[lazlooose]

to my limited understanding of how this program works the problem appears to be in the code somewhere as there is communication between Reaper and the procontrolosc.py both ways and all the ports and addresses appear to be correct:
- Reaper can send messages to the procontrol via the osc_listener and also osc_client is able to send test messages to Reaper ( I see the as "hello DAW" in reaper csurf settings listener).

• however messages received from the procontrol never get translated to osc by the osc_client and passed to Reaper. the only thing osc_client is doing according to the logs is connecting to the Reaper computer and sending test messages.

If osc_client was sending the osc commands I see no reason why reaper wouldn't receive them same as it is receiving the test messages and wouldn't they appear in the logs if it was sending them and reaper wasn't receiving them?
in summary from what I can tell it seems like the comands from pro C are getting lost in translation within the code. Hope that is in some way helpful.

[lazlooose]

hey @phunkyg did you have a chance to look at these logs? any idea what is going on here?

[phunkyg]

Hey @lazlooose that is good news as it looks like we have a working config.
I'll take a look in those logs to see if I can suss out wherr we are going wrong.

[phunkyg]

Laptop charging but having a look via phone.
At a guess there are a couple of things going on:

First, you changed the map and altered the ChildByteMatch value, I don't think that edit was a good one, try putting it back for now.

Next I think there is a transposition in the track numbering going on.
I think the MAINUNIT first track is probably 8, not 0
Get yourself a REAPER project and set up 16 empty tracks. Name them and save it for testing purposes.
If I'm right, you might get track 8 muting in reaper when you me track 1 on the main unit.

The trace logs are very long but we can stick with that for a bit as it saves the need to get wireshark out for the most part.

Beyond that we will need to watch what the osc log has for sent osc messages. There is no real way of debugging the reaper osc file only trial and error, but knowing what got sent is half the fight.

[lazlooose]

thanks @phunkyg ! I tried it with 16 channels and got the same result. I also tried it with putting back the map to the previous child byte map and agasin same result as before.

I can use the new map using the old control24d.py and control24osc.py way and it works fine (if I change the map to "MAPPING_TREE_PROC" and modify the import to reference procontrolmap in control24osc.py). The utility buttons appear correctly and all so I don't know if it is the map. honestly using the old method everything works both ways (reaper controls desk and vice versa) also clock, VU, pan and auto leds (if you put the correct addresses in procontrol24osc.py), everything but the scrib strips, so to me it points more to a problem with ReaControl.py or procontrolosc.py rather than a mapping issue, or maybe something in the way they interact has changed.

I have already checked using Wireshark and there are no OSC messages coming from the procontrolosc.py daemon except for the "helloDAW" messages. With control24d/control24osc you can see the messages using the same wireshark settings.

is it possible to run procontrolosc.py as a standalone with control24d.py (similar to the old setup)?

I get this error if I try to run provcontrolosc.py by itself :
using: python procontrolosc.py -d
I get: Exception in thread thread_osc_listener: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 754, in run self.__target(*self.__args, **self.__kwargs) File "procontrolosc.py", line 1374, in _manage_osc_listener self.listen) File "/home/pi/.local/lib/python2.7/site-packages/OSC.py", line 1765, in __init__ UDPServer.__init__(self, server_address, self.RequestHandlerClass) File "/usr/lib/python2.7/SocketServer.py", line 420, in __init__ self.server_bind() File "/usr/lib/python2.7/SocketServer.py", line 434, in server_bind self.socket.bind(self.server_address) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) TypeError: an integer is required

log of error attached:
procontrolosc.log.22_04.01_09.txt

Edit: I tried again but specifying python procontrolosc.py -c 192.168.0.15:9125 -l 192.168.0.34:9124 -s 192.168.0.34:9124 and it is working with control24d! scrib strips an all!

[lazlooose]

here is the log with map as is (childbytematch0x08)
opened a 16 track project
pushed mute on track 1 in reaper.
mute led lights up on channel 1 on pro control
pushed mute on procontrol (led on procontrol goes out)
nothing happens in reaper
pushed mute on reaper (unmuting track)
LEd remains off on Pro Control
muted track again on reaper
same on ProControl led appears.

the select LED also follows the correct tracks as you click on them so doesn't seem to be a problem with the tracks on Pro control being misaligned there is simply no passing of procontrol messages to Reaper.

As a side note if you mute the track in Reaper and the LED is lit on the mute button pushing the mute causes the LED to go out. however for any button where the LED is not lit on the button the LED illuminates while you are pushing the button then turns off again as soon as you let go. Not sure if that is helpfull.
procontrolosc.log.22_04.00_50.txt
main.log.22_04.00_50.txt

[lazlooose]

here is the log after I changed childbytematch back to 0x18
same behaviour.
procontrolosc.log.22_04.00_54.txt
main.log.22_04.00_54.txt

[lazlooose]

UPDATE: !!
If I run sudo python control24d.py then in another ssh window python procontrolosc.py -c 192.168.0.15:9125 -l 192.168.0.34:9124 -s 192.168.0.34:9124 everything is working! scrib strips and all! so I guess using that I can test the map for now.

It would be great to have the ReaControl.py way working too though.

[lazlooose]

using the above method I can confirm that the ChildByteMatch of 0x08 is correct. with value 0x18 buttons do nothing with 0x08 correct osc messages appear in listener.

However moving the Vpots in the DSP/edit assign section cause it to crash:

OSCServer: AttributeError on request from 192.168.0.15:57848: 'NoneType' object has no attribute 'procscribstrip'
OSCServer: AttributeError on request from 192.168.0.15:57848: 'NoneType' object has no attribute 'procscribstrip'
Exception in thread thread_c24_client:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "procontrolosc.py", line 1356, in _manage_c24_client
    self._desk_to_daw(datarecv)
  File "procontrolosc.py", line 1265, in _desk_to_daw
    inst = getattr(track or self.desk, cmd_class.lower())
AttributeError: 'ProCdesk' object has no attribute 'c24vpot'

[lazlooose]

another bug I found is when I get this error in procontrolosc.py the LEDs strop responding, buttons still work but LEDs no:

OSCServer: AttributeError on request from 192.168.0.15:64269: 'NoneType' object has no attribute 'procscribstrip'
OSCServer: AttributeError on request from 192.168.0.15:64269: 'NoneType' object has no attribute 'procscribstrip'

not sure yet what is triggering this.

[phunkyg]

Hmm certainly does look like the Reacontrol version is losing the traffic somehow. Need to dip into those logs...

In the meantime could you find a byte sequence for any other button that isn't on a channel strip? The F keys, transport etc.

Reason being that child byte match defines the bits needes to differentiate these and then we can get that value set right.

[phunkyg]

Right got it. Funny story, receive <> send!
The traffic was quite literally being written to the wrong end of the pipe and was reflecting back to the desk.
Get a fresh one and try again, with a bit of luck you should be going in both directions now.

[phunkyg]

However moving the Vpots in the DSP/edit assign section cause it to crash:

This is just telling us that our 'model' of the desk is incorrect, which we kind-of know.
I could probably put a more informative message there though.

[lazlooose]

In the meantime could you find a byte sequence for any other button that isn't on a channel strip? The F keys, transport etc.

Reason being that child byte match defines the bits needes to differentiate these and then we can get that value set right

did you look in this file I made? it has some of the MP sends for utils etc...

https://github.com/lazlooose/ReaControl24/blob/DEV_OtherDevices/Procontrol%20Map.csv

[phunkyg]

OOh! no I missed that one. That's perfect thanks. I'll give it a run through.

[lazlooose]

cool! I will give the new ReaControl.py a test.

[lazlooose]

YES! @phunkyg you did it!! ReaControl.py is working both ways now! I will close this thread and start a new one for the other elements that neeed tweaking.