using the new v2 framework and inheriting from ControlSurface

[markusschloesser]

This thread is a collection of info around the topic:

1. after a week of trying a lot, I finally figured out that once one does class MackieC4(ControlSurface): you cannot have a def song anymore (imho cos song is now an object passed down by the super class)
2. init needs to be

def __init__(self, *a, **k):
    (super(MackieC4, self).__init__)(*a, **k)  

3. once that is done, you can use the component guard like this:

 with self.component_guard():
            self._suggested_input_port = 'MackieC4'
            self._suggested_output_port = 'MackieC4'
            self.__components = []
            self.__encoders = [Encoders(self, i) for i in encoder_range]
            for s in self.__encoders:
                self.__components.append(s)

4. unclear if other modules need to do super as well and if so from what. MackieC4Component from ableton.v2.control_surface.component? current thinking says yes! Because a) Component is for "Base class for all classes encapsulating functions in Live", and b) other scripts do exactly that (Side note "Component" imports "Control" which includes all listener stuff)
5. But currently stuck at `RemoteScriptError: 'int' object has no attribute 'add_children' (which comes from Component)
6. tbc

[BilldarBagdar]

Nice job figuring out that much. Does 5 mean you already tried making that more or less the only change? and you got stuck at that error? What was the full error "trace" around that RemoteScriptError? Believe it or not, I saw a very, very similar error several times last night. While I was trying to figure out how to write self.main_script().overdub correctly. Will I see that error if I try to run the tip of your branch?

Generally, I would guess you are headed in the correct direction for where you want to go. But now that I've said that and looked at a little of the code both some of the examples in the other scripts as well as the C4, and I think I can fairly certainly say, it would probably be easier for you to abandon the existing classes and structure, and build up what functionality you want new "from scratch" (from the library examples). I mean just decide what functionality you want and "how" you want to represent it. I mean as, for example, 4 rows of 8 encoders, or maybe 8 columns of 4 encoders, or maybe a button matrix, both, or all. There are lots of examples of scripts for devices with a group of 8 LED-ring encoders. The C4 has four such groups, and lots of buttons. The two Akai scripts I've looked at most are _Framework based, APC40 and APC40MkII (because I own one of each). so most of what I "know" comes from those scripts. They both inherit from OptimizedControlSurface, not just ControlSurface. I don't know the difference, but otherwise your example looks nearly identical to those two init methods. The giant difference between the C4 and basically any other control surface I've seen though is the LCD screens. Encoders and Buttons come in all shapes and sizes, but sending sysex to those LCDs is likely going to be unique.

(and kind of where I would probably have started, figuring out some way to model the LCD screens with _Framework classes, like maybe NumericalDisplaySegment. If it represents a typical "10 segment display" (8?), then that could represent a single character "position" on an LCD, and the "LCD Screen" in code could be a class with 2 arrays (upper and lower text) of the 55 "text bytes" in each LCD. Do we need to go to the trouble of representing each character as a "NumericalDisplaySegment" when an array of 55 bytes would be just as suitable to the C4 and the sysex message? Depends on what that representation buys us.)

The other concept that I suspect is going to be challenging is the different "modes" in the current script. I suspect part of the reason the "Arsenal" scripts are commercially viable is because Stray figured out how to implement "modes" in a common way across all the "Arsensal" scripts his company produced. So I would think if modes were "easy" to implement more scripts would make more use of them.

One things that kind of stands in the way of my better understanding of Live scripting is... I can "see" where the hand-off between Live and our script happens in the MackieC4 class, and I can follow the "execution path" with my eyes and in my mind down into the script code and I know "where I am" when I get there. But over in the framework classes and scripts, the same cannot be said. I have yet to find a script where I can start at the top (or bottom) and work my way to the other end, down into the guts where the details are. (or up from the guts to the roof) It's like everything is abstracted away so you can't understand the execution path without first understanding the abstraction model. (and there are no documents detailing the abstraction model) I haven't really been burning any cycles studying the examples, so I've been happy to just work on the existing script.

[markusschloesser]

full error log:

RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Beta\Resources\MIDI Remote Scripts\MackieC4\__init__.py", line 10, in create_instance
RemoteScriptError: return MackieC4(c_instance=c_instance)
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Beta\Resources\MIDI Remote Scripts\MackieC4\MackieC4.py", line 137, in __init__
RemoteScriptError: self.__encoders = [Encoders(self, i) for i in encoder_range]
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Beta\Resources\MIDI Remote Scripts\MackieC4\MackieC4.py", line 137, in <listcomp>
RemoteScriptError: self.__encoders = [Encoders(self, i) for i in encoder_range]
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Beta\Resources\MIDI Remote Scripts\MackieC4\Encoders.py", line 21, in __init__
RemoteScriptError: (super(Encoders, self).__init__)(*a, **k)
RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11 Beta\Resources\MIDI Remote Scripts\MackieC4\MackieC4Component.py", line 25, in __init__
RemoteScriptError: (super(MackieC4Component, self).__init__)(*a, **k)
RemoteScriptError:   File "..\..\..\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\ableton\v2\base\dependency.py", line 122, in wrapper
RemoteScriptError:   File "..\..\..\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\ableton\v2\control_surface\component.py", line 64, in __init__
RemoteScriptError: AttributeError
RemoteScriptError: 'int' object has no attribute 'add_children'

[markusschloesser]

Nice job figuring out that much.

Thanks, took me a week and the help of my little brother 😀 And what's especially annoying is, that because of the error mentioning MackieC4.song checking def song was the first thing I checked against other scripts, and a lot had it still in there, but those were ALL scripts going against the OLD framework, while none of the ones going against v2 still had def song

Does 5 mean you already tried making that more or less the only change?

nope, already fixed a couple of other things

and you got stuck at that error?

yep, I also read somewhere in the Ableton forum, that when using the new v2 framework, one has to replace song(). with song. . So I tried that already

What was the full error "trace" around that RemoteScriptError?

see previous post

Believe it or not, I saw a very, very similar error several times last night. While I was trying to figure out how to write self.main_script().overdub correctly.

That's interesting! I believe that once we started using v2 more and more, we see less (boost) errors while using, but more other errors while "compiling". Which is annoying, but probably a good thing in the long run.

Will I see that error if I try to run the tip of your branch?

Probably, but be aware that it's currently very messy 😁

Generally, I would guess you are headed in the correct direction for where you want to go. But now that I've said that and looked at a little of the code both some of the examples in the other scripts as well as the C4, and I think I can fairly certainly say, it would probably be easier for you to abandon the existing classes and structure, and build up what functionality you want new "from scratch" (from the library examples).

Been thinking about that, but not yet ready for this. Still very much a newbie.

I mean just decide what functionality you want and "how" you want to represent it. I mean as, for example, 4 rows of 8 encoders, or maybe 8 columns of 4 encoders, or maybe a button matrix, both, or all. There are lots of examples of scripts for devices with a group of 8 LED-ring encoders. The C4 has four such groups, and lots of buttons. The two Akai scripts I've looked at most are _Framework based, APC40 and APC40MkII (because I own one of each). so most of what I "know" comes from those scripts. They both inherit from OptimizedControlSurface, not just ControlSurface.

OptimizedControlSurface is old _framework.
FYI I am still updating the other repo with docstrings on a daily basis. Also there are quite a few differences even between 11b23 and 11.05b2 w re to code

I don't know the difference, but otherwise your example looks nearly identical to those two init methods. The giant difference between the C4 and basically any other control surface I've seen though is the LCD screens. Encoders and Buttons come in all shapes and sizes, but sending sysex to those LCDs is likely going to be unique.

Other "good" examples of controllers using v2 are AtomSQ, Akai Force MPC and Push/2 of course. I believe all those have displays, albeit color ones. (Some also have touch encoders). SO that's a difference.

(and kind of where I would probably have started, figuring out some way to model the LCD screens with _Framework classes, like maybe NumericalDisplaySegment. If it represents a typical "10 segment display" (8?), then that could represent a single character "position" on an LCD, and the "LCD Screen" in code could be a class with 2 arrays (upper and lower text) of the 55 "text bytes" in each LCD. Do we need to go to the trouble of representing each character as a "NumericalDisplaySegment" when an array of 55 bytes would be just as suitable to the C4 and the sysex message? Depends on what that representation buys us.)

My suggestion would be rather ableton\v2\control_surface\elements\physical_display.py as mentioned in the other thread. In this you have things like def display_string(self): def display_indexes, def set_num_segments(self, num_segments): . BUT: all this ends up in ControlSurface anyway, so I currently don't know what is automatically "there" just by inheriting?

The other concept that I suspect is going to be challenging is the different "modes" in the current script. I suspect part of the reason the "Arsenal" scripts are commercially viable is because Stray figured out how to implement "modes" in a common way across all the "Arsensal" scripts his company produced. So I would think if modes were "easy" to implement more scripts would make more use of them.

Haven't looked at Arsenal scripts, so don't know, but there IS a mode.py in the control surface directory. But I do not understand what it does 😂 very rough guess: you can define your own modes with this

One things that kind of stands in the way of my better understanding of Live scripting is... I can "see" where the hand-off between Live and our script happens in the MackieC4 class, and I can follow the "execution path" with my eyes and in my mind down into the script code and I know "where I am" when I get there. But over in the framework classes and scripts, the same cannot be said. I have yet to find a script where I can start at the top (or bottom) and work my way to the other end, down into the guts where the details are. (or up from the guts to the roof) It's like everything is abstracted away so you can't understand the execution path without first understanding the abstraction model. (and there are no documents detailing the abstraction model) I haven't really been burning any cycles studying the examples, so I've been happy to just work on the existing script.

I understand that, it can be very frustrating. For me on the other hand, it's frustrating anyway, cos of my lacking python skills 😂
So I see using v2 as having more "guidance" a long the way. And reading and comparing all these scripts does of course improve my understanding of both, Python AND the framework. Even though there are not that many v2 scripts.

[markusschloesser]

have a look into https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/main/Akai_Force_MPC/elements.py
I think I figured out where the connection to the physical parts to the script happens. If my idea is correct, than the elements.py basically is our const.py in class form, having 1 base class class Elements(object): and including 4 child (not sure of correct terminology) classes to be able to serve multiple Akai controllers.

https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/main/ATOMSQ/elements.py
does it similarly but also includes a display element (btw a good example of how to use simple_display)

[BilldarBagdar]

Both of these import from ableton.v2 versus _Framework and I haven't had any success using v2 classes with the V2C4 script on the C4Modeling branch. Have you successfully mixed any v2 classes into the MackieC4 script?

I think I've seen the "elements" concept in other _Framework based scripts though. I'm going to rename the C4Model class in the V2C4 script to "C4ModelElements" and borrow some of those techniques (versus just "hard coding" each of the C4's non-encoder ButtonElements, for example).

[BilldarBagdar]

Rather than a new thread. This one seems to be on topic anyway... (My answer doesn't necessarily sound like it, but I'm talking to myself in the future a lot)

BUT: all this ends up in ControlSurface anyway, so I currently don't know what is automatically "there" just by inheriting?

This is one of the things I wanted to write down. All this does end up in ControlSurface anyway, but the only behavior mapped by default is no behavior. Whatever behavior you want your script to invoke, you need to customize the associated "control surface behavior modification" class by using it directly and giving the default behavior "values to work with" (like ButtonElement objects) or by inheriting from it to add customized behavior code.

When researching other Control Surface scripts, I suspect the key to understanding how they do what they do is to carefully review the import statements at the top of the main script class file before trying to read the __init__() method. (It's also helpful to have an image of the hardware layout for reference.) The "local imports" (with the leading '.') are the classes that add any customized behavior code.

For example, in AxiomPro, they don't customize any behavior for these three components.

from _Framework.TransportComponent import TransportComponent
from _Framework.SessionComponent import SessionComponent
from _Framework.PhysicalDisplayElement import PhysicalDisplayElement

If they are doing more than providing appropriate data values, they just connect generic ControlElement objects like ButtonElement.

For the behavior that is the most specific to the Axiom Pro hardware and software, they do customize behavior in these classes (technically I think the files are called "modules" because more than one class per file is allowed. That's what the import syntax says to me, "from (current directory).(module) import (class))

from .TransportViewModeSelector import TransportViewModeSelector
from .SelectButtonModeSelector import SelectButtonModeSelector
from .PageableDeviceComponent import PageableDeviceComponent
from .EncoderMixerModeSelector import EncoderMixerModeSelector
from .MixerOrDeviceModeSelector import MixerOrDeviceModeSelector
from .NotifyingMixerComponent import NotifyingMixerComponent
from .DisplayingMixerComponent import DisplayingMixerComponent
from .PeekableEncoderElement import PeekableEncoderElement
    also imports from _Axiom.Encoders import Encoders

4 "ModeSelector", 2 "Component", and 1 "Element", that's 7 behavior customizers.

The SelectButtonModeSelector class, for example, is used to make 4 "dedicated" hardware buttons control the mappings associated with a group of 8 hardware encoders. In other words... There are four buttons in "mixer mode" that change the function of the 8 encoders between controlling Pan, Send Level A, Send Level B, or Send Level C. I think those same 4 buttons in "device mode" map 8 "device parameters" per "page" of parameters to those same hardware encoders. These is special code for handling devices with more than "4 pages" of parameters (more than 32 parameters). On that note, the PageableDeviceComponent and PeekableEncoderElement are related custom behavior implementations. The "paging" and "peeking" aspects are not default behavior.

In addition to handling "regular devices" normally, PageableDeviceComponent appears to "specifically enhance remote control" of whatever VST instruments or effects were bundled with the Axiom Pro. (maybe?)

[markusschloesser]

btw to bring every info into this issue: #47 (comment) did you see this last year?

[BilldarBagdar]

I think I did see that post back then, but 18 months of river have passed under the bridge since then... good resources.

I'm thinking we can use one or more versions of that kind of "select button mode selector" specialization. But for the C4, the 4 selector buttons would be the 4 Modifier buttons. Then we could, for example, make all 32 encoder buttons implement 5 "behaviors" each (default, shift, option, control, alt) This would be 5 "short press" selections. "long pressing" (holding) modifier buttons could still control "one off" alternative behaviors in various modes.

And we could also implement other kinds of "select button mode selector" specializations for those modifier buttons, for example, each of the 4 modifiers could be linked to a specific row of 8 encoders and each modifier button press could cycle through the same set of alternate behaviors. One row could have the encoder buttons mapped to "jump to previous saved value" (value saved upon "long press" of encoder button?), and another row could have its encoder buttons mapped to "Jump to 0", "Jump to 127", "Jump to 63", whatever.

And, that's probably also how we can easily get more than just 4 modes. Another specialization could map the 4 modifier buttons to the 4 assignment buttons similarly altering their behavior ("long press" Chan Strip button, for example, to go back to "default Chan Strip" mode. Otherwise click Shift, then Chan Strip to get "shift + chan strip" mode; Option, then Chan Strip to get "opt + chan strip", etc.

I don't know that we would actually have a use for all those options. But if a script starts with the idea of such "unknown options" in play, accommodating those same or other options later can be a much easier egg to fry.

[BilldarBagdar]

I do have _MxDCore, don't have the other. And yes, _MxDCore is maxforlive, LOMtypes lists all items nicely

Yes, I too admire that LOM Types dictionary tree.

I think the other one is for / came with my Arsenal scripts. Last time I was on the Arsenal website, their "Push2" script was priced "free with $5 processing fee" (EDIT: because the Push2 script is broken in Live 10 and 11. But my APC40 mk1 and BCR2000 Arsenal scripts still work in Live 10). I rediscovered yesterday, all of that Python code is FOSS free to use. There are 2 such folders _NKFW2 and _Arsenal full of open sourced code. I'm sure we could use any of it we want in scripts in this "open source" repository (with proper attributions, i's dotted; t's crossed) The reason I mention the price is you might be interested in supporting whoever is benefiting from that $5 handling fee who might be the same person responsible for the FOSS code resources in those 2 folders. No pressure. I won't ask if you "donate". I need to figure out the "best" way to upload the FOSS python files in those folders. We don't necessarily need them in a branch here unless we are referencing one or more files like their version of ControlSurfaceBase. After I get a "simple" V2C4 version working well, I'd maybe like to try switching to that _NKFW2 FOSS "sub framework".

[markusschloesser]

https://github.com/aumhaa also has lots of scripts, he also builds scripts as dev for companies

[BilldarBagdar]

There is some cool stuff there too. Looks like that person is doing max4live instruments and/or effects and/or integrated control surface stuff. Have you seen any of that code you think looks promising?

[markusschloesser]

yep, this one https://github.com/aumhaa/aumhaa_commission

[markusschloesser]

btw I did a new branch trying to do my own v2/v3 script and wanted to start easy and "just" do a launchpad style launching clips with vpot push. If you happen to see an easy/simple existing script which does that ( so I can get inspired), I'd be grateful i f you'll let me know! :-)

[BilldarBagdar]

No "dependency injection" stuff (yet?) LOL, I started with Axiom Pro, not ATOMSQ.

The code I pushed up tonight still barely works, but I suspect it barely works from a more solid foundation. The only thing working on the LCD screens is the "clear all" message. The script starts off in "channel strip" mode and the Track Volume feedback is working (but the data is jacked) but the encoder isn't working (Change Track volume with the mouse and LED ring display updates). You can now click the bottom row encoder buttons to Mute, Arm, Activate the selected track and Play, Stop, and Record the transport. I also tried to get the same "device handshake" going that Axiom has, but I don't think the C4 consistently responds to "firmware request" midi messages. It seems like the C4 will only respond to a firmware request once after power up. If the C4 is powered up and Live app cycles, I'm not seeing a C4 SYSEX response and all the "script components" stay disabled until you power cycle the C4. If you happen to click the Marker button, the script tries to load a device and barfs all over the log...

It REALLY seems like I could stand to go to like a 3-day "Control Surface Writers" workshop with Ableton "subject matter experts". I'm betting I could learn in 3 days what I might not get on my own in 3 months...

[markusschloesser]

I also tried to get the same "device handshake" going that Axiom has, but I don't think the C4 consistently responds to "firmware request" midi messages.

Why do you want to do that? IMHO that's only implemented as kind of a half assed copy protection in other scripts.

It REALLY seems like I could stand to go to like a 3-day "Control Surface Writers" workshop with Ableton "subject matter experts". I'm betting I could learn in 3 days what I might not get on my own in 3 months...

I have some contacts at Ableton and an NDA in place with them, will try to get some further documentation. Would you be willing to sign an NDA with them?

[BilldarBagdar]

I was mostly venting frustration. Actual learning isn't easy work, right? Pushing back against the "cloud of unknowing" (Alan Watts) takes real mental effort.

I would certainly want to read such an agreement before signing, but I don't think I have any philosophical reasons for generally not-wanting to be part of any NDAs. I doubt any of my "business plans" would compete in Ableton's arena, but that probably depends on how "big" they define their arena to be.

FYI - I got the firmware handshake working. The problem was my code of course. I kind of like the way the implementation flows now. None of the script components get enabled unless the script is actually communicating with the hardware. So, if you have the script loaded, but the C4 is not powered up, the script will not be using "Live runtime resources" because the script components are disabled.

[markusschloesser]

I would certainly want to read such an agreement before signing, but I don't think I have any philosophical reasons for generally not-wanting to be part of any NDAs. I doubt any of my "business plans" would compete in Ableton's arena, but that probably depends on how "big" they define their arena to be.

of course/ naturally! :-)

FYI - I got the firmware handshake working. The problem was my code of course. I kind of like the way the implementation flows now. None of the script components get enabled unless the script is actually communicating with the hardware. So, if you have the script loaded, but the C4 is not powered up, the script will not be using "Live runtime resources" because the script components are disabled.

ah ok, didn't know that

[BilldarBagdar]

I think I've reached an early "false summit" developing this V2C4 script "from scratch". The script is still more or less broken, but now it seems like the whole car is up on blocks in my driveway with only a few parts or connections missing versus still being at the factory on an assembly line staffed by one barely trained monkey. (that's me :))

I checked in a commit just now that works only a very little bit better than it did before, but now I think all the correct bones are more or less in the correct places. There are basically 3 custom component classes C4ChannelStripComponent, C4DeviceComponent, and C4EncodersComponent that interact with Live and the C4ModeSelector manages the connections between the "control surface element model" objects like Button and Physical Display Elements and the various component objects.

I repurposed the file named C4Controller into the one named C4ControlSurfaceComponent. But I abandoned that approach as soon as I realized that by introducing a customized base ControlSurfaceComponent I was taking on all of the tasks and responsibilities previously handled by each of the default ControlSurfaceComponent subclasses. Or at least I think that's what happened. I didn't do a lot of experimenting while zoomed in on that issue. I ended up making the C4EncodersComponent inherit from C4ChannelStripComponent instead of C4ControlSurfaceComponent, and that's what kind of working now. The encoders are kind of bound to the selected track anyway.

IDK how closely you've been watching the commits progression if at all, but the branch as of this commit might be worth reviewing

[markusschloesser]

had a quick look at this yesterday, but not yet in depth

[BilldarBagdar]

I saw you started a new branch off of the C4Modeling branch, your one commit looks like you've made a good start using v2 imports instead of _Framework.

I banged my head against the wall I hit one or two more times today, but then I went back to the drawing board to update the V2C4 design again.

In a nutshell I think my yesterday's problem was fairly fundamental, the C4EncoderComponent class should not exist. At a high level I think _Framework classes with "component" in the name model LOM stuff and _Framework class with "element" in the name model the midi hardware you want to connect to and control the LOM stuff. I think I probably should have realized remembered that fact before I diverted so far up this dead end route. I was misled by my first reaction to the first error I saw that looked something like self.__parent does not have an attribute named "song().selected_track" and in the Axiom script I was modeling self.__parent points to a ControlSurface object. My first reaction was to look for the "selected_track" attribute which I found on the "ControlSurfaceComponent" tree side. But even there, an attribute named song().selected_track does not exist. I think the correct "attribute path" is song().view.selected_track. (which is maybe a bug that would be fixed if you downloaded and installed an Axiom "controller script" from M-Audio?, but who knows?)

I went back to using "C4Encoders" class object on the "InputElement" side where they now clearly seem to belong. I think I learned a lot being stumped by this impasse so many times. But even after cutting over to the Element side, the issue that is dogging me is "inheriting" from an EncoderElement. None of the examples I've tried to implement have been successfully implemented. Not even the examples in the EncoderElement module itself. I've got an APC40 with encoder rings and it's script works, but that "_Framework code APC40 script" example doesn't work when I copy it to make a "C4Encoder".

The reason I think we need to inherit from an EncoderElement rather than just using it is so we can override this method in InputControlElement base class

    def _mapping_feedback_values(self):

and only return a tuple of the "legal" led ring values for any ring display mode. We also want to be able to update the ring display mode depending on what we connect to.

But the furthest along I seem to be able to get the script is almost all the way through initializing everything, and then...

2022-11-03T19:09:42.937400: info: RemoteScriptError:     
2022-11-03T19:09:42.937400: info: RemoteScriptError: super(V2C4, self).build_midi_map(midi_map_handle)

2022-11-03T19:09:42.937400: info: RemoteScriptError:   File "c:\Jenkins\live\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\_Framework\ControlSurface.py", line 369, in build_midi_map

2022-11-03T19:09:42.937400: info: RemoteScriptError:   File "c:\Jenkins\live\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\_Framework\InputControlElement.py", line 339, in install_connections

2022-11-03T19:09:42.937400: info: RemoteScriptError:   File "c:\Jenkins\live\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\_Framework\ControlSurface.py", line 700, in _install_mapping

2022-11-03T19:09:42.937400: info: RemoteScriptError: AssertionError

I've reached this same dead end three different ways.

`InputControlElement.install_connections() is a method that takes other methods as arguments and then runs them using instance values as inputs. Line 700 in ControlSurface where the assertion actually throws, seems to be around line 600 in my _Framework file, but there is more than one candidate assertion... The other problem is I can't find the code where an APC40 script, for example, implements those callback methods. RingedEncoderElement has an overloaded implementation of install_connections() where the input variable names contain "callback". But I can't find the place where that method is called to see what the callback inputs are, how the methods are implemented.

[BilldarBagdar]

Have fun on vacation, or at least enjoy.

[BilldarBagdar]

I made a C4 "Arsenal Control Surface Script" today.

I went back and (re)downloaded all of my remote scripts to this one "python script development" computer, and then ran "uncompyle6" again on the MIDI Remote Scripts folder. Both the APC40 mk I and the BCR2000 "Arsenal Powered" scripts still work for me in Live 10, but the Arsenal Push2 script stopped working about 2 years ago (around 10.1.20).

Anyway, I only had to write like 3 files to "translate" the Arsenal BCR2000 script into a C4 script. And guess what? Same problem. I mean, the script just loaded up and "works" (exactly like my BCR2000 script is configured to run), except for no incoming encoder CC messages from the C4 and shizzle LED ring feedback going to the C4. I know how to fix the feedback data, but can't find a solution for the lack of incoming CC messages. Argggggg

I'm guessing now maybe the issue is related to "relative signed bit" map mode. But that's a very wild assed guess at this point. Tomorrow I will try to write a "Generic" script with an encoder for the C4, also a "_User" script.

[markusschloesser]

Other wild ideas typed from phone:

1. Have you also always used hex? Maybe try binary for cc value
2. Framework scripts don't know relative signed (and Btw iirc it's not signed, isn't it? The middle value coming from the encoders is at 64, above til 127 is positive, 0-63 is negative. So there's no signed part)
3. We're missing something in the init

[BilldarBagdar]

Three: Agree, very likely. There are apparently only three (not-Mackie) ControlSurface scripts (my local PyCharm finder is finding "In Project") for hardware devices that appear to use physical "relative signed bit" encoders. KeyLab_Essential and Oxygen_Pro both use ableton.v2.control_surface.elements EncoderElement class imports. The third script seems to be for the Tranzport controller and it doesn't use ANY "framework imports".

Two: (my local PyCharm finder is also finding "In Project") Both the "Live underpinnings" of the "generic controller script" and the "_User controller" script appear to be coded to account for "relative signed bit" encoder mode. This .v2.control_surface.elements.encoder` module code makes it a "map mode" clearly (to me) "known to the framework":

def signed_bit_delta(value):
    delta = SIGNED_BIT_DEFAULT_DELTA
    is_increment = value <= 64
    index = value - 1 if is_increment else value - 64
    if in_range(index, 0, len(SIGNED_BIT_VALUE_MAP)):
        delta = SIGNED_BIT_VALUE_MAP[index]
    if is_increment:
        return delta
    return -delta

SIGNED_BIT_DEFAULT_DELTA = 20.0
SIGNED_BIT_VALUE_MAP = (1, 2, 3, 4, 5, 8, 10, 20, 50)

The def signed_bit_delta(value) method specifically says to me "supported map mode". I'm not suggesting all of this signed_bit_delta code is accurate for C4 encoders specifically, or that this code means "our script should work". I am saying the line is_increment = value <= 64 is accurate code for C4 encoders though. "clockwise rotation" values are < 64 and is_increment would be True and likewise False for "counter-clockwise rotation" > 64

Basically, the method will return a "20.0 step delta" for any input parameter value NOT an index into the SIGNED_BIT_VALUE_MAP tuple. The C4 sends 15 "clockwise rotation" values (1, ..., 15), so all of the "clockwise rotation" values above 8 sent by a C4 encoder should become that DEFAULT_DELTA value of 20.0 by default. But we ain't getting jack.

One: Technically all of the numeric constants we write in code get compiled into exactly the same binary representation a computer understands. I use hex notation a lot (specifically in "midi related code") because it's easier for me these days to remember for example the "midi boundary values" as (10, 20, 30, 40, etc) in hex, than as multiples of 16 in decimal (16, 32, 48, 64, etc). The whole MIDI specification is built on a foundation of multiples of 16. But whether numeric constant code is written as 64 in decimal or 0x40 in hex, the value is converted to its binary representation EDIT: 01000000 by the compiler before a computer sees that compiled code. (each "hex digit" exactly represents 4 "binary digits" in physical "bit layout" per byte. Another way to say that is you need 4 bits to count to 16 in binary, 8 bits to count to 256, 16 bits to count to 65,536, etc.) Sometimes, it's easier to think about the F values in hex which are 1111 in binary, so 0F in hex is 00001111 in binary. 0x3F then in binary is (0x30 + 0x0F) 0011 0000 + 0000 1111 {48 + 15 in decimal} so 64 in decimal is 0100 0000 in binary.

I also try to differentiate in written code between "midi data" and "regular data" by using hex notation for "midi data". Even though F0 is 240 (and FF is 255), when the data is going to be a "midi sysex message", for example, I will prefer using the hex notation F0 for the first byte of the message over the decimal representation, just because that seems cleaner to me, more true to the "midi domain". On the other hand, it's still way easier for me to reason mathematically in decimal, and I constantly make mistakes translating back and forth between random hex or decimal values and their equivalent "counter notation" values. (what is 3F - 8? [37 in hex, and 55 in decimal, but thank goodness for "Programmer mode" in Windows Calculator])

[markusschloesser]

1. I understand and know that technically all hex shouldn't be a problem, but I also just remembered that I had a problem with hex before and while scratching my head for hours and decided to just try decimal (sorry, was wrong before, meant decimal), it suddenly magically just worked (9fc3aa4#diff-ce234ad3d47d59d64d8d2acd94ab75f06a046f32b57bc59dc62f0150e8ca4ff7R232 ). Worth a shot?
2. agreed that it should work. Was just confused because of the signed bit. Thought that signed was related to the source, not the destination. But

"clockwise rotation" values are < 64 and is_increment would be True and likewise False for "counter-clockwise rotation" > 64

is the other way around for the C4

4. mmh, might be related to the capabilities part in init?

[BilldarBagdar]

4. Yes, agree again, "might be" anything at this point.

I "might be" about done banging my head into this wall though. I expected my "Arsenal C4" script to fail somehow due to something I didn't understand about the "base classes" like any kind of protection against random people like me coding "new" Arsenal scripts. Even though all I really did was provide C4 specific midi information to the "midi map" class like channel 0 instead of channel 15 and, of course, changing map mode to RSB from absolute, the new "Arsenal_C4_A" script is broken in the same way we've been experiencing using the Framework classes (v1 and v2) in our "simple scripts". All the button elements just work "both midi directions", so the new "Arsenal_C4_A" script does all the "Arsenal magic" in response to button clicks switching out all the various "encoder modes", for example, exactly like the "BCR2000 script" settings I had previously defined and copied over as the C4 script's settings. But the C4 script's Encoders are just as broken as we've been seeing. The feedback side works "normally", the LED rings update with shizzle when the encoder modes change and when you mouse drag connected parameters in Live. But the inbound encoder messages still don't impact (update) those connected parameters. (and, of course, no "feedback" associated with knob turns because no input midi received and processed)

I haven't added a bunch of "investigative logging" to the new script, but I'm not sure I see a point. The new "Arsenal_C4_A" script's main __init__() method is exactly the same code as the BCR2000 script's main __init__() method. I didn't change any of the "Arsenal names" or definitions. The C4 has more buttons and the same number of encoders as the BCR2000, so just providing "C4 midi details" instead of "BCR2000 midi details" where the "Arsenal names" were defined in the "midi map" class is all it took. All of the same extensive _NKFW2 and _Arsenal "base class code" still works normally for my APC40 Arsenal script on this same computer, and the BCR2000 script still works on a different (Live 10) computer.

The only thing different between the two scripts of any substantive merit to me is RSB map mode in the C4 script, and if Arsenal is showing the same problem we've been seeing in our scripting, then I'm no longer sure we're looking at a solvable problem. If (Stray) the Python coding wizard who wrote the "Arsenal framework" didn't solve this issue already, I am a mere Python coding acolyte in comparison. I no longer feel much confidence in my own ability to find any solution-route up this coding-cliff. Maybe an answer seems so hard to find because an answer doesn't exist. Maybe the overhang is too far beyond vertical to get around.

[BilldarBagdar]

Have you ever used a midi data viewing tool like MIDI-OX? If so, have you ever used it to look at the midi data going to and from the C4?

I did way back when I first looked at this script (5 years ago now? longer?), and even earlier when I was learning and using the C4 Commander software to "program" the C4. Some of the comments from 5 years ago in the consts file were copy/pasted out of MIDI-OX. I've said this in other programming contexts before more than once. Sometime you have to go all the way around the world before you end up right next door anyway. It just works out that way, the long, hard way to understanding was the only way the trail didn't die out.

It didn't occur to me "recently" and I didn't really know the code I was working with 5 years ago, but MIDI-OX is telling me today those C4SID_VPOT_CC_ADDRESS_ constants, the original script author's (Lee?) VPOT_PUSH_ constants I copied and renamed, are only CC "feedback addresses". Duh. Facepalm.

The C4 Buttons work "both ways" in our Framework remote scripts because their input "addresses" are those VPOT_PUSH_ constant values. "Encoder Button 32" sends midi note "Eb 4" (63, 0x3F) data values and that's what is configured in Live so the script sees them (and all mapped button values). "Encoder 32" however sends midi CC "note" 31 (0x1F) data values while the "Encoder LED Ring 32" receives midi CC "note" 63 (0x3F) feedback data values. That's why "only the CC feedback side" works. Because our new scripts have Live CC Encoders configured to listen to "3F" and feedback to "3F", but should be configured to listen to "1F" and only feedback to "3F".

I haven't updated a script yet to confirm completely, but this answer fits the bill. After throwing in the towel earlier, I decided to use MusicWonk as a "relative signed bit to absolute encoder value" midi data mapping filter between the C4 and my "Arsenal C4" script to test the latest "it has to be RSB related" theory and I couldn't get a two way connection to work. MusicWonk could send CC 3F data to the LED ring 32, but could not receive CC 3F data from the encoder 32. So I broke out MIDI-OX only to quickly learn the damn encoder 32 is sending CC 1F midi data.

This is likely why at least one of the "Ringed Encoder" specializations I've modeled recently specifically accounts for both an "identifier" and a "ring element identifier".

This could also easily be the reason switching to decimal magically worked to resolve a problem for you before. If the encoder hex value "3F" wasn't working for example, and you changed it to decimal value 31, then the "magic" is you changed it from 63 to 31 and it started working on 31.

[markusschloesser]

holy fuck 😂😂😂💪💪💪
Yes I did look at what was coming from the C4, not via Midi-ox, which I have used a lot, but via the logging. That's why I changed to decimal and "hard-coding" it in the main script, cos C4SID_VPOT_CC_ADDRESS_ didn't work

[BilldarBagdar]

Yes!!! Confirmed. LOL, mapping the correct input CC values really helps scripts work correctly.

Unfortunately, preliminary results indicate either only the feedback works or only the knobs work because by default, the whole framework uses the same CC ID for "control element" feedback as it does for input. Need to figure out how to provide a correctly specialized "feedback map" pointing to the correct LED Ring CC ID to connected device parameters. That task ought to be a comparative cinch though, piece of pie, easy as cake.

I'll make some "simplified" branch commits to tidy things up a bit, and then I think I'll be continuing wherever the "C4 Modeling" branch left off...

[BilldarBagdar]

Are you interested in seeing the "ArtWonk patch" I made for testing the C4? MusicWonk and ArtWonk can open each others' save files, with the caveat that MusicWonk can't open an ArtWonk patch containing any "image processing" stuff because that's the difference between the apps. MusicWonk doesn't have any "image processing" stuff. However MusicWonk still runs in Windows 10 though, so that's probably the app you would need to download and run.

All the patch does is let you test the midi CC input and output to and from an encoder (32 by default). (After you have ArtWonk's MIDI inputs and outputs configured and the patch is loaded) When you turn encoder 32, you see appropriate "CC input data" appear in the patch. When you click buttons in the "ArtWonk widget area", LED ring "feedback" messages get sent to the (encoder 32 by default) LED Ring and you see the ring "light up" appropriately.

[BilldarBagdar]

Writing this out to help me remember what partial() means does. and also, to document the last part.

Internally to the ControlSurface class, the _install_mapping method

def _install_mapping(self, midi_map_handle, control, parameter, feedback_delay, feedback_map):

is called from the build_midi_map method as a partial "function arg", meaning the midi_map_handle parameter is provided (as a pass through parameter) along with the _install_mapping method itself as the input parameter/argument to another method call.

control.install_connections(self._translate_message, partial(self._install_mapping, midi_map_handle), partial(self._install_forwarding, midi_map_handle))

The control.install_connections method is defined in the InputControlElement class and is where the rest of the _install_mapping parameters are provided and the install_mapping method call actually finally happens.

self._is_mapped = install_mapping(self, self._parameter_to_map_to, self._mapping_feedback_delay, self._mapping_feedback_values())

Notice how the midi_map_handle parameter seems to "disappear" once you get inside control.install_connections. Starting from inside install_connections and "working the code logic backward", it can be tough to see easy to miss how the install_mapping method's midi_map_handle parameter is "already provided" (at run time) and thus not explicitly needed for install_connections to call install_mapping like this (at compile time). [Thanks to partial()]

Given all of that and then some... It looks like one way to implement a solution is to override _install_mapping (in each main framework based C4 ControlSurface class) to explicitly handle C4EncoderElement controls deferring everything else to super. For the C4 Encoder LED rings, there's really only one problematic line feedback_rule.cc_no = control.message_identifier(). When the control is a C4EncoderElement instance, the line should be (in effect)

feedback_rule.cc_no = control.message_identifier() + 32

I realize you might not be back from vacation yet, but I just pushed up a commit implementing this solution on the "C4 Modeling" branch. It's still a mostly not working very well Noobie Nuberson kind of script, but you can switch tracks left and right and the volume and pan encoders work correctly. The "Marker" button will even toggle between "device mode" and "channel strip mode" too. I didn't test much of anything, happy enough for today just to see "real encoder action"... You'll be able to check it out whenever you return from vacation.

[BilldarBagdar]

Minimum custom code required for C4 Encoders to work in Framework scripts:

As noted in a previous post, override the main ControlSurface script's _install_mapping method and customize the encoder CC feedback rule

def _install_mapping(self, midi_map_handle, control, parameter, feedback_delay, feedback_map):
    # only most relevant code shown here
    if not isinstance(control, EncoderElement):
        success = super(V2C4, self)._install_mapping(midi_map_handle, control, parameter, feedback_delay, feedback_map)
    else:
        feedback_rule = Live.MidiMap.CCFeedbackRule()
        feedback_rule.cc_no = control.message_identifier() + 32  # or customized code like control.message_feedback_identifier()
        feedback_rule.cc_value_map = feedback_map
        feedback_rule.channel = control.message_channel()
        feedback_rule.delay_in_ms = feedback_delay
        success = Live.MidiMap.map_midi_cc_with_feedback_map(midi_map_handle, parameter, control.message_channel(),
                                                             control.message_identifier(),
                                                             control.message_map_mode(), feedback_rule,
                                                             not control.needs_takeover(),
                                                             control.mapping_sensitivity)

Notice BOTH control.message_identifier() + 32 and control.message_identifier() are used for EncoderElements. After implementing only this override, you should see evidence of a working encoder in your custom C4 script. Knob turns should be reflected in Live wherever assigned and feedback to the LED rings should look ugly but work.

To get feedback data to the LED rings working properly, you'll need to make a custom class that inherits from EncoderElement and add more specialized code.

# constants
class LedMappingType(object):
    """ The various types of parameter mappings that correspond to C4 LED ring modes. """
    __module__ = __name__
    LED_RING_MODE_SINGLE_DOT = 0
    LED_RING_MODE_BOOST_CUT = 1
    LED_RING_MODE_WRAP = 2
    LED_RING_MODE_SPREAD = 3
    LED_RING_MODE_BOOLEAN = 4

# min  max leds in ring illuminated
# multiples of 0x10 mean "all ring LEDS OFF" [0, 16, 32, 48]
encoder_ring_led_mode_cc_min_max_values = {
    LedMappingType.LED_RING_MODE_SINGLE_DOT: (0x01, 0x0B),  # 01 - 0B
    LedMappingType.LED_RING_MODE_BOOST_CUT: (0x11, 0x1B),  # 11 - 1B
    LedMappingType.LED_RING_MODE_WRAP: (0x21, 0x2B),  # 21 - 2B
    LedMappingType.LED_RING_MODE_SPREAD: (0x31, 0x36),  # 31 - 36
    LedMappingType.LED_RING_MODE_BOOLEAN: (0x20, 0x2B)}  # 20 - 2B

encoder_ring_led_mode_mode_select_values = {
    LedMappingType.LED_RING_MODE_SINGLE_DOT: 0x01,
    LedMappingType.LED_RING_MODE_BOOST_CUT: 0x16,
    LedMappingType.LED_RING_MODE_WRAP: 0x26,
    LedMappingType.LED_RING_MODE_SPREAD: 0x33,
    LedMappingType.LED_RING_MODE_BOOLEAN: 0x2B}

def class C4EncoderElement(EncoderElement):
    # again only "relevant" code shown here

    # override __init__() defaults
    def __init__(self, ...):    
        self.set_feedback_delay(-1)  # yes feedback, without delay
        self.set_needs_takeover(False)  # relative map mode does not need takeover

    # add these specialization methods
    def message_feedback_identifier():    
        return control.message_identifier() + 32

    def get_mapping_feedback_values(self, ring_mode=LedMappingTypes.LED_RING_MODE_SINGLE_DOT):    
        if ring_mode in encoder_ring_led_mode_mode_select_values.keys():
            display_mode_min_value = encoder_ring_led_mode_cc_min_max_values[ring_mode][0]
            display_mode_max_value = encoder_ring_led_mode_cc_min_max_values[ring_mode][1]
            feedback_val_range_len = display_mode_max_value - display_mode_min_value + 1
            if ring_mode == LedMappingType.LED_RING_MODE_BOOLEAN:
                halfway = feedback_val_range_len / 2
                bool_values = [display_mode_min_value if x < halfway else display_mode_max_value
                               for x in range(feedback_val_range_len)]
                return tuple(bool_values)
            else:
               return tuple([display_mode_min_value + x for x in range(feedback_val_range_len)])

    # override these protected methods
    def _do_send_value(self, value, channel=None):
        data_byte1 = self.message_feedback_identifier()  # == control.message_identifier() + 32
        data_byte2 = value
        status_byte = self._status_byte(self._original_channel)  # channel 0 
        if self.send_midi((status_byte, data_byte1, data_byte2)):
            # following probably still reports "message_identifier" not "message_feedback_identifier"
            self._last_sent_message = (value, channel)
            if self._report_output:
                is_input = False
                self._report_value(value, is_input)
        return

    def _mapping_feedback_values(self):
        return self.get_mapping_feedback_values()

That should be all the changes necessary for minimal encoder functionality with "single dot" feedback. For more details, see any associated code such as C4EncoderElement and C4EncoderMixin classes in the V2C4 script folder in this repository.

But note that the above is only minimal code. Typically, for example, you would at least want to save a reference to the selected "LED Ring display mode", the generated tuple of mapping feedback values, or both in your custom C4EncoderElement class. The above example code as shared will only ever show "single dot" display mode feedback.

EDIT: added links, fixed typos

[BilldarBagdar]

How To customize the "feel" of the C4 encoders (the correspondence between the speed of a knob turn (the relative values sent as midi CC messages) and the "graphical response" of the connected device parameter in Live's UI). Just update the default "signed bit value map" constant in your inheriting class.

SIGNED_BIT_VALUE_MAP = (1, 2, 3, 4, 5, 8, 10, 20, 50)

Although the above example default can only be found in the decompiled v2.control_suface.elements.encoder_element class file, it also exists in the v1 _Framework somewhere somehow. (and elsewhere like _NKFW2)

The C4 encoders actually send 15 different values (1 - 15), so the last 6 (9 - 15) will not be an index into the SIGNED_BIT_VALUE_MAP and will be assigned the "default delta" value of 20. If you don't want that much of a flat response at the top for example, override the default in your C4 specific class inheriting from EncoderElement with your custom values

# overriding standard to customize encoder "feel"
SIGNED_BIT_VALUE_MAP = (1, 1, 2, 3, 4, 5, 8, 11, 11, 13, 13, 15, 15, 20, 50)

If you just want that flat top value to be different, you only need to override the default delta value in your inheriting class.

SIGNED_BIT_DEFAULT_DELTA = 20.0

[BilldarBagdar]

This post kind of takes a tangent from recent topics in the discussion thread, but I think still "belongs" on topic of using the new v2 framework in new or updated scripts.

Even in the new v2 framework (and later), there seems to be evidence of a difference between an "old way" and a "new way" of implementing custom event handling in control surface scripts. The "old way" would be "directly registering event listener methods with event producing objects" and the "new way" would be "implementing the "Observer Pattern" in custom code to produce the same outcome, to get the same "the event of interest happened now do this" code to run. (specifically note the accepted SO answer links to 3 other "Python ways" that could also be used to implement "Observer" before describing a "first class functions" way with examples, and that most of the comments under the question also contain good info) (Other python specific ways to "python implement observer pattern" are easily searchable)

In the v2 framework, for example, we have the NotifyingControlElement class implementation that InputControlElement inherits from. NotifyingControlElement itself inherits from both EventObject and ControlElement classes. The EventObject class is a concrete CompoundDisconnectable, and the Slot class is a concrete Disconnectable.

All of the docstring comments are worth reading (again?) within the code just mentioned. But these in particular stand out:

# class Slot(Disconnectable):
"""
This class maintains the relationship between a subject and a
listener. As soon as both are non-null, it connects the listener to the given 'event'
of the subject and releases the connection when any of them change.

Note that the connection can already be made manually before the
subject and listener are fed to the slot.
"""

# class EventObject(CompoundDisconnectable):
    #def register_slot(...):
        """
        Creates a new :class:`~Slot` and registers it, so it gets disconnected.
        All arguments are forwarded to the constructor of :class:`~Slot`.
        In case the argument is already a `Slot`, the object gets simply registered.
        """

TLDR, for now. In other words, the "old v2 way" is to "manually" handle appropriately registering and unregistering "listener methods" in custom scripts; and the "new way" is to use annotations (decorators?) like @Subject and @SubjectSlot to "implement the v2 Framework's Observer pattern" in custom scripts (edit: so "appropriate register / unregister handling" happens automatically). ("For now" means I plan to add more details here as I learn more. Like specifically how to decorate custom code to properly implement the v2 Framework's Observer pattern.)

[markusschloesser]

1. is C4modelling the most recent branch?
2. Checked that one out and had to fix the izip_longest problem again
3. after that I now get

2023-01-20T01:23:55.233778: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\__init__.py", line 10, in create_instance
2023-01-20T01:23:55.233961: error: RemoteScriptError: return V2C4(c_instance, *a, **k)
2023-01-20T01:23:55.234017: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\V2C4.py", line 47, in __init__
2023-01-20T01:23:55.234179: error: RemoteScriptError: mixer = C4MixerComponent()
2023-01-20T01:23:55.234233: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\C4MixerComponent.py", line 36, in __init__
2023-01-20T01:23:55.234393: error: RemoteScriptError: MixerComponent.__init__(self, num_tracks=0, num_returns=0, auto_name=True, *a, **k)
2023-01-20T01:23:55.234451: error: RemoteScriptError:   File "..\..\..\output\Live\win_64_static\Release\python-bundle\MIDI Remote Scripts\_Framework\MixerComponent.py", line 66, in __init__
2023-01-20T01:23:55.234721: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\C4MixerComponent.py", line 56, in _create_strip
2023-01-20T01:23:55.234991: error: RemoteScriptError: return C4ChannelStripComponent()
2023-01-20T01:23:55.235060: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\C4ChannelStripComponent.py", line 27, in __init__
2023-01-20T01:23:55.235258: error: RemoteScriptError: self._track_name_label = 'Track Name'.center(LCD_BOTTOM_ROW_OFFSET/2)
2023-01-20T01:23:55.235325: error: RemoteScriptError: TypeError
2023-01-20T01:23:55.235387: error: RemoteScriptError: integer argument expected, got float

never mind 3. fixed that by changing / to // for line 27 and 28 (remembered that 💪😎)
But now 4.

2023-01-20T01:31:05.307342: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\__init__.py", line 10, in create_instance
2023-01-20T01:31:05.307510: error: RemoteScriptError: return V2C4(c_instance, *a, **k)
2023-01-20T01:31:05.307564: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\V2C4.py", line 112, in __init__
2023-01-20T01:31:05.307728: error: RemoteScriptError: self._device_component.device_name_data_source())
2023-01-20T01:31:05.307778: error: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 11.1\Resources\MIDI Remote Scripts\MackieC4SissyTest\C4MixerComponent.py", line 60, in set_displays
2023-01-20T01:31:05.307925: error: RemoteScriptError: assert display_rows.keys()[0] == LCD_ANGLED_ADDRESS
2023-01-20T01:31:05.307974: error: RemoteScriptError: TypeError
2023-01-20T01:31:05.308020: error: RemoteScriptError: 'dict_keys' object is not subscriptable

I thought I quickly check out your work, but it is getting late her, so will have to postpone till tomorrow
UPDATE 2:
fixed error 4, 5 and 6 by outcommenting the 3 asserts, also there was an xrange somewhere which I changed to range and now the script loads! :-)

[BilldarBagdar]

Interesting. I'm not seeing any of those errors in Live 10 / Py 2.

(V2C4) C4 responded, enabling <8> components
(V2C4) <1> Mixer
(V2C4) <2> Master_Channel_Strip
(V2C4) <3> Selected_Channel_Strip
(V2C4) <4> Session_Control
(V2C4) <5> Selected_Scene
(V2C4) <6> V2C4DeviceComponent
(V2C4) <7> V2C4ModeSelector
(C4ModeSelector) mode<0> setting selected strip volume
(C4MixerComponent) setting volume control<Encoder_Control_31> on selected strip<Selected_Channel_Strip>
(C4MixerComponent) setting pan control<Encoder_Control_30> on selected strip<Selected_Channel_Strip>
(V2C4) <8> V2C4Transport
(C4ModeSelector) mode<0> setting selected strip volume
(C4MixerComponent) setting volume control<Encoder_Control_31> on selected strip<Selected_Channel_Strip>
(C4MixerComponent) setting pan control<Encoder_Control_30> on selected strip<Selected_Channel_Strip>

had to fix the izip_longest problem again

Sorry about that. I think I fixed it this time, but let me know if you still see an error.

self._track_name_label = 'Track Name'.center(LCD_BOTTOM_ROW_OFFSET/2) "integer argument expected, got float"

means the center() method expects integer input: 'Track Name'.center(int(LCD_BOTTOM_ROW_OFFSET/2))

assert display_rows.keys()[0] == LCD_ANGLED_ADDRESS "'dict_keys' object is not subscriptable"

Per Stack Overflow: In Python 3 dict.keys() returns an "iterable" that is NOT subscriptable. Likely most easily fixed here by wrapping the iterable in a list and then subscripting: assert list(display_rows.keys())[0] == LCD_ANGLED_ADDRESS

I think all these items are fixed in the C4Modeling branch commit I just pushed to origin... I also pulled down your recent commits to the 2022_dev branch. Unfortunately, my local branch got out of sync with origin so I had to push a couple of "do nothing" commits you'll probably need to pull now too. Let me know if I caused any merge conflicts. I shouldn't have, don't believe I did.

Edit: Since you are looking at the V2C4 code now, about the only dynamic LCD update I got working is the "device name" display in "channel strip" mode. The "device" mode LCDs always initialize with correct values, but no "listener updates" are working yet. When any "parameter value" changes, the LED Rings show correct feedback now, but the LCDs don't also update, yet. That's about where I stopped to take a break. Need to figure out what is still missing or what is now conflicting with implementing the "Observer pattern" API and or using decorators to customize script behavior "the well defined way". I also think it would be a good idea to introduce "Layers" (Assignment Buttons Layer, Modifier Buttons Layer, Encoder Buttons Layer, Encoders Layer, etc. at the base and then combine the Layers (Shift + Encoder Buttons Layer for example) to learn how to define functionality that way. I'm rambling now.)

Edit 2: I didn't push anything because I'm not sure about legal ramifications, but today I successfully updated that Arsenal test branch I worked on before with new changes to get the C4 encoders working properly. So, I now currently have a custom clone of an Arsenal BCR2000 script running on my C4. "Basically" all I did was add the code I mentioned (other thread?) to override Framework methods like, for example, _install_connections() and inherit from the _NKFW2.SpecialEncoderElement class to customize C4 specifics. Next I want to update the "clone" to be a fully C4-customized Arsenal script, if possible. For example, only one row of BCR2000 encoders has "push button encoders" The biggest hurdle I'll have is the BCR2000 has 24 non-encoder buttons and the C4 only has 19 non-encoder buttons, need to figure out how to work around that. Also, BCR2000 doesn't have LCD screens so the C4 screens are unused.

All of that (edit 2) is just to say, I think you can do it too. Any script you want to try adapting to C4 should adapt pretty easily using that earlier guidance.