Refactor branch Addressing issues

[lazlooose]

Testing for the new Refactor branch is underway so far there are some addressing issues for faders, scribs panpots and displays.

[lazlooose]

faders work only from Reaper to ProC

Reaper is receiving /track/reafader/1 [f] 0.616211 but expecting TRACK_VOLUME n/track/@/reafader (in the new Reaper.OSC file)

I switched the ReaperOSC file to read TRACK_VOLUME n/track/reafader/@ and you can use that to send to Reaper from ProC but it gives an error when you move the faders in Reaper
Unhandled Error responding to daw_to_desk OSC message Traceback (most recent call last): File "/home/pi/ReaControl24_Refactor/ReaCommon.py", line 1698, in _daw_to_desk track_number = int(addrlist[track_addr_ind+1]) - 1 ValueError: invalid literal for int() with base 10: 'reafader'

possibly the same thing is happening with the scribstrips? which are also not showing anything

[lazlooose]

pans cause an error:
Waiting for the OSC listener to get a client None {'CmdClass': 'reavpot', 'TrackNumber': 0, 'addresses': ['/', 'track', '/', '1', '/', 'reavpot'], 'ChildByteMask': 64, 'TrackByteMask': 31, 'cmdbytes': ['\xb0', '@', 'A', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'], 'address': '/track/1/reavpot', 'ChildByte': 1, 'lkpbytes': [176, 64], 'TrackByte': 1} Looking for mapped cmd_class but not found. The map is incorrect. Track: 0 Class: reavpot multiprocess Client waiting for data: 9 {'CmdClass': 'reavpot', 'TrackNumber': 0, 'addresses': ['/', 'track', '/', '1', '/', 'reavpot'], 'ChildByteMask': 64, 'TrackByteMask': 31, 'cmdbytes': ['\xb0', '@', 'A', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'], 'address': '/track/1/reavpot', 'ChildByte': 1, 'lkpbytes': [176, 64], 'TrackByte': 1} Looking for mapped cmd_class but not found. The map is incorrect. Track: 0 Class: reavpot multiprocess Client waiting for data: 9

[lazlooose]

all displays (VU's, Clock, Automode LEDs, Scribstrips) which were working in the previous version are all not working

[lazlooose]

Scrub Wheel also not working:
Looking for mapped cmd_class but not found. The map is incorrect. Track: 28 Class: reavpot multiprocess Client waiting for data: 9 {'CmdClass': 'reavpot', 'TrackNumber': 28, 'addresses': ['/', 'track', '/', '29', '/', 'reavpot'], 'ChildByteMask': 64, 'TrackByteMask': 31, 'cmdbytes': ['\xb0', '\\', 'A', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'], 'address': '/track/29/reavpot', 'ChildByte': 1, 'lkpbytes': [176, 64], 'TrackByte': 1} No track object exists on this desk with index 28

[lazlooose]

regarding the displays the address for control24 appears to be 0xF0, 0x13, 0x01 whereas for ProC it is 0xF0, 0x13, 0x00 which would explain why the displays are not working. I made this change to my ReaCommon.py and got my Vus, pan LEDs and automode LEDs working but still no scribs or clock. not sure if @phunkyg had tried to implement this address change elsewhere but it got em working

[lazlooose]

I am also getting this error in terminal
MP recv: c:1 s:8 d:f0 13 00 10 20 00 01 f7 OSC Listener received Message: ('192.168.0.15', 57672) /track/1/reavumeter/0 [f] [0.0] OSC message received from an unexpected source address ('192.168.0.15', 57672) OSC Listener received Message: ('192.168.0.15', 57672) /track/1/reavumeter/1 [f] [0.0]

I am not sure why Reaper is sending from that port (57672 -- ...0.15 is my computer running Reaper the ReaControl.py is running on the pi at ...0.34 ) I don't remember seeing this before.

[lazlooose]

I got a bunch of stuff working again except the jog wheel by editing my procontrolosc.py file to mimic the changes made py @phunkyg to control24osc.py in commit https://github.com/phunkyg/ReaControl24/commit/55f0beb7009e025e1027dad7ac70888148887d46 that fixed the fader, auto and pan addressing issue. --edit automode is not working properly: leds respond but auto mode does not change in reaper when pushing automode on the desk. ReaControl.py sends /track/read/reaautomode/2 [s] "1.0" instead of /track/2/reaautomode/read [s] "1.0" which reaper is expecting.

I also edited into ReaCommon.py this was the only way I could get the displays going. I manually editing the addresses which would surely break control24 compatability but I presume there is a way to get procontrolosc.py to change the address from 0xf0, 0x13, 0x01 to 0xf0, 0x13, 0x00 I just don't know how.

If I can figure out how to push from my pi I will push the changes to my fork or I will transfer the files later today and copy them.

[lazlooose]

jog wheel is still being identified as reavpot track 28 instead of reajpot:

Error doing d_c in cmd_class. Track: 28 Class: reavpot
Traceback (most recent call last):
  File "/home/pi/ReaConrtrol24_refactor_06_06_20/ReaCommon.py", line 1666, in _desk_to_daw
    inst.d_c(parsed_cmd)
AttributeError: 'NoneType' object has no attribute 'd_c'
multiprocess Client waiting for data: 9
Packet Received: to:b8 27 eb e2 65 64 from:00 a0 7e a0 17 fd prot:88 5f bytes:19 c_cnt:0 s_cnt:5921 retry:0 cmd:0x0 nc:1 b0 5c 41 27 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
device session 1 RECEIVED 5921
b05c41270000000000000000000000000000000000000000000000000000
device session 1 ACK TO DEVICE: 5921
nc: 1
{'CmdClass': 'reavpot', 'TrackNumber': 28, 'addresses': ['/', 'track', '/', '29', '/', 'reavpot'], 'ChildByteMask': 64, 'TrackByteMask': 31, 'cmdbytes': ['\xb0', '\\', 'A', "'", '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'], 'address': '/track/29/reavpot', 'ChildByte': 1, 'lkpbytes': [176, 64], 'TrackByte': 1}
Sending Packet of 30 bytes: 00 a0 7e a0 17 fd b8 27 eb e2 65 64 88 5f 00 10 00 00 00 00 00 00 00 00 17 21 00 00 a0 00
No track object exists on this desk with index 28
Looking for mapped cmd_class but not found. The map is incorrect. Track: 28 Class: reavpot
Error doing d_c in cmd_class. Track: 28 Class: reavpot

Response: This is OK, it gets parsed as a vpot on channel 28 but the class that is actually instantiated is a jpot so the instructions go to the right code.
There is a bit of weirdness around jpot addresses but this bit is ok.

[phunkyg]

Hey @lazlooose

So after the Control24 session the ProControl stuff needs catching up.
The new base class/specific class patterns means that in the specific class e.g. procontrol.osc ProCDesk class, in the init after super().init() is called (which runs the init from ReaCommon ReaDesk), then specifics can be put in to override or add to the class.

You change will need something like
self.cmdbytes[3] = 0x01

I mentally notes I need to come back to it but I was too tired to pick it up right away.

Most of your issues with addressing might be you haven't picked up the OSC file or I haven't updated it for procontrol.

As for the jog wheel, I need to see which track the Pro Control addresses it as, and adjust accordingly. IIRC I shoved it on 9 i.e. the first after 'real' tracks but that was a guess. I need to refer back to your map.

[phunkyg]

I am not sure why Reaper is sending from that port (57672 -- ...0.15 is my computer running Reaper the ReaControl.py is running on the pi at ...0.34 ) I don't remember seeing this before.

Nothing to worry about here. Your PC uses 'outgoing' ports for all sorts of comms, even going to webpages and such. You hardly ever see them, they are picked by the system.

the 'unexpected source address' happens if comms were lost with Reaper. There is no code to disconnect/reconnect yet. Just restart reaper and if that don't work everything and you'll be back in business.

[lazlooose]

awesome thanks!

Most of your issues with addressing might be you haven't picked up the OSC file or I haven't updated it for procontrol.

I created a pull request https://github.com/phunkyg/ReaControl24/pull/16 for the fixes to get the faders working I did in procontrolosc.py after that change faders and pans work.

As for the jog wheel, I need to see which track the Pro Control addresses it as, and adjust accordingly. IIRC I shoved it on 9 i.e. the first after 'real' tracks but that was a guess. I need to refer back to your map.

the terminal window is identifying it as 28 Error doing d_c in cmd_class. Track: 28 Class: reavpot I will look and see if I can change it.

You change will need something like
self.cmdbytes[3] = 0x01

wicked, I had tried cmdbytes[3]=0x00 but it didn't work. -- the value we want is 0x00 so it should be self.cmdbytes[3]=0x00 no?

[lazlooose]

I tried Adding self.cmdbytes[3] - 0x00 but I have not got it to work same as I couls by changing the addresses in ReaCommon.py

first I tried editing the ProCDesk Class like this:

class ProCdesk(_ReaDesk):
    """Class to represent the desk, state and
    instances to help conversions and behaviour"""
    real_channels = 8
    virtual_channels = 1
    busvus = 1
    deskmodes = {
        'Values': {
            'address': '/track/@/procscribstrip/volume',

        },
        'Group': {
            'toggle': True
        },
        'Names': {
            'address': '/track/@/procscribstrip/name',
            'default': True
        },
        'Info': {
            'address': '/track/@/procscribstrip/pan'
        }
    }

    def __init__(self, parent):
        """ Build a base desk object with the _Readesk class
        then apply the specifics for this device """
        super(ProCdesk, self).__init__(parent)

        self.mapping_tree = procontrolmap.MAPPING_TREE_PROC
        self.reabuttonled = ReaButtonLed(self, None)

        self.modemgr = ModeManager(ProCdesk.deskmodes)
        # Set up specifics for this device
        self.real_channels = ProCdesk.real_channels
        self.virtual_channels = ProCdesk.virtual_channels
        self.busvus = 1
        self.cmdbytes[3] = 0x00 # fix addresses for procontrol displays 0xf0, 0x13, [0x00], ...
        self.instantiate_tracks(ProCTrack)

since I interpreted that as what you were saying but I get an attribute error:

Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/multiprocessing/process.py", line 267, in _bootstrap
    self.run()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "/home/pi/ReaControl24_git/ReaControl24_lazlooose/procontrolosc.py", line 168, in __init__
    self.desk = ProCdesk(self)
  File "/home/pi/ReaControl24_git/ReaControl24_lazlooose/procontrolosc.py", line 112, in __init__
    self.cmdbytes[3] = 0x00 # fix addresses for procontrol displays 0xf0, 0x13, [0x00], ...
AttributeError: 'ProCdesk' object has no attribute 'cmdbytes'

if I put it in the class procscribstrip no error, but no scribs either:

class ProCscribstrip(_ReaScribStrip):
    """Class to hold and convert scribblestrip value representations
    this version specific to the Control24 """

    digits = 8
    defaultaddress = '/track/@/number'
    bank = 0

    def __init__(self, track):
        super(ProCscribstrip, self).__init__(
            track,
            ProCscribstrip.digits,
            ProCscribstrip.bank,
            ProCscribstrip.defaultaddress)
        # TODO = total guess - refer back to ProC scribstrip diferences.
        self.cmdbytes[5] = 0x01
        self.cmdbytes[3] = 0x00

[lazlooose]

regarding the jpot there I checked the map and it is indeed track 28

But there is some kind of attribute error which leads me to believe there is a mistake in the code? it points to line 1666, lol, of Reacommon is the jpot working on the control24?

device session 1 ACK TO DEVICE: 508
nc: 1
{'CmdClass': 'reavpot', 'TrackNumber': 28, 'addresses': ['/', 'track', '/', '29', '/', 'reavpot'], 'ChildByteMask': 64, 'TrackByteMask': 31, 'cmdbytes': ['\xb0', '\\', '?', '\x01', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00', '\x00'], 'address': '/track/29/reavpot', 'ChildByte': 1, 'lkpbytes': [176, 64], 'TrackByte': 1}
Sending Packet of 30 bytes: 00 a0 7e a0 17 fd b8 27 eb e2 65 64 88 5f 00 10 00 00 00 00 00 00 00 00 01 fc 00 00 a0 00
No track object exists on this desk with index 28
Looking for mapped cmd_class but not found. The map is incorrect. Track: 28 Class: reavpot
Error doing d_c in cmd_class. Track: 28 Class: reavpot
Traceback (most recent call last):
  File "/home/pi/ReaControl24_git/ReaControl24_lazlooose/ReaCommon.py", line 1666, in _desk_to_daw
    inst.d_c(parsed_cmd)
AttributeError: 'NoneType' object has no attribute 'd_c'
multiprocess Client waiting for data: 9

[phunkyg]

So I've merged your pull requrest to get those changes in and corrected the cmdbytes bit. You were almost there, but I think it needs to be index 2 as they begin at zero.
Can you give that a go see if it lights up your scribs again? If not it'll only take a bit of comparison work to iron out the guesswork back to the working combination you had previously.

Jpots are added to track 28 for all desks as they are in the _ReaTrack class which is common to both, so in theory should be working on both. We tested on Control24 and they seemed good, are they still a problem on ProC?

I could do with a bit of a round-up on this thread to see what's still outstanding

edit: looking above, did vpot led's, clocks and VU's come back? Do I need to compare back to the working branch for these to see if there's any missing 'specifics'?

[lazlooose]

Something about the most recent merges has completely broken communication for me between ReaControl.py and everything. the desk is recognized ,the logs receive the announcement transimission from the board, but that its it. Reaper can neither receive or send anything. (nothing appearing in the logs. Also Fader movements and button pushes on the ProC do not show up in the logs.

You were almost there, but I think it needs to be index 2 as they begin at zero.

lol, noob mistake! I believe that did it. In order to test I went back to a previous version. the cmdbyte[2] = 0x00 did work there so I think that will work.

presumably we can use a similar thing to access the other row of scrib strips...(he says excitedly!)

Do we need similar classes for the clock, pan leds, Vus and auto LEDs? is it as simple as copying the basic format of what we have tthere and doing the cmdbytes edit?

[phunkyg]

presumably we can use a similar thing to access the other row of scrib strips...(he says excitedly!)

Do we need similar classes for the clock, pan leds, Vus and auto LEDs? is it as simple as copying the basic format of what we have tthere and doing the cmdbytes edit?

Yes exactly, we just need to set the 'bank' byte accordingly but decide how we are going to add them to the desk model.
The choice is to try to send ALL the text from reaper to one class (per track) for scribstrips and have multiple banks/mode mamangers inside. OR we just instantiate multiple scribstrip classes at different OSC addresses and have a selector parameter on the init for it that sets the banks and addresses. I think the latter is most likely.

All the other classes I'm assuming are going to be standard, I don't' recall if we had to tweak them for ProControl? Can you remind me? If so it should be easy enough to do this base class/specific class pattern.

[phunkyg]

OK I've pushed all the cmdbyte[2] changes

[lazlooose]

I can tell that we are making progress since more displays are popping on in my tests but the "can't quit fix" bug makes it hard to test since the desk doesn't really respond to anything in real time and the displays appear randomly.

[lazlooose]

Also, from my notes the Clock has an additional byte that is different from C24:

Clock address for pro control is 0xf0, 0x13, 0x00 (not 01), 0x30, 0x09 (not 19), ....

so presumably that could be fixed via cmdbytes[4] = 0x09?

[phunkyg]

Yep exactly, stick it in see if it flies

[lazlooose]

ok will do, I might need to create a branch without the "quit fix" to keep testing for now though. I think I can go bak to the commit before that and then add the addressing stuff

[lazlooose]

now that the osc communication issue related to the quit fix has been resolved for now I can continue testing.

working:

• scrib strips,
• pot leds,
• auto leds

not working:

• Vus - not sure why cmdbyt[2] = 0x00 in the procontrolosc.py should fix this, problem with the osc name reavumeter?
• Clock - tried fixing it with cmdbyt[4] = 0x09 but no love, again not sure why that isn't working both clocks and vus were working in the previous version if I modified the address in ReaCommon.py
• auto mode - while the LEDs change when you push the auto mode button on the proC no actual change happens in Reaper

that is all I have noticed for now.