search

markusschloesser / MackieC4_P3

A Mackie C4 Midi Remote Script for Ableton 11
20 stars 2 forks source link

Framework: can we use "Modes" while utilizing (ControlSurface): yes! - and how do other scripts do that #76

Open markusschloesser opened 3 years ago

markusschloesser commented 3 years ago

You asked if the modes can be implemented, so I researched a bit and especially looked at the manual for the Atom SQ (because that's a v2 framework script), and yes, it does have modes very similar to ours, even though they are named differently. If you check https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/82ea7c6af02f982017b33a367c645ab5bae8e41c/ATOMSQ/atomsq.py#L187 you'll see that they are established there (song_mode_button (a mixture of clip and chan strip mode) , instrument_mode_button, editor_mode_button (which the Device mode, so our current Track mode), user_mode_button). And as guessed earlier, it imports AddLayerMode, EnablingMode, ModesComponent from ableton.v2.control_surface.mode.py. (https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/main/ableton/v2/control_surface/mode.py)

So the task would be to do that for our script. I don't know if it can be done without having implemented the stuff that's currently very broken in the component_guard branch (aka using ControlSurface super class), so not sure about the best way to move forward.

BilldarBagdar commented 3 years ago

ok cool, that's a great place to start looking at doing the same in this C4 script. I suspect the concept of "layers" models something like "indexes of depth" to the view a device presents on its display, like maybe "every layer" is always there but the only one displayed is at the correct index. I will look into that for sure. But i also have news I will share over in a Q&A discussion rather than pollute an issue thread.

markusschloesser commented 3 years ago

yep, look at the docstring for layer here https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/f43e734046c2787b790be431ec70dd1848cb01ae/ableton/v2/control_surface/layer.py#L127

markusschloesser commented 3 years ago

CompoundLayer might also come in handy https://github.com/markusschloesser/AbletonRemoteScriptsPY/blob/f43e734046c2787b790be431ec70dd1848cb01ae/ableton/v2/control_surface/layer.py#L77

Why: I am thinking of having a solo button(vpot in row 0) in plugin mode. So once we start using the "ChannelStrip" class for our chan strip (where I would also like a solo button/vpot), we could compound stuff from there into the track/plugin layer/mode. Nice thing about using the ChannelStrip class is, it takes care of things like state of values, number of solos pressed, mute cos of solo somewhere else etc

BilldarBagdar commented 3 years ago

nice detective work. I haven't really been working on "programming" in the evenings after work so I haven't been "checking in", but I have no plans to ghost completely.

BilldarBagdar commented 2 years ago

This stuff really reminds me of the way CSS builds those scripts, "everything" is defined as @Property attributes, and all the CSS application code really does is stitch together Template, Script, and LOM via the "objects" returned by @Property getters and setters. That's no easy feat. The CSS developer was pretty clever with that whole idea and successfully stitching it all together. But it's also an incredibly brittle design because figuratively everything is "just a string", all the connections are made when "compiling/creating" the actual remote script Live loads because labeling (@Property name, for example, ) "strings match". The Python compiler can't really help find coding problems because all it sees are "legal" string values. If you have 14 instances of "some_property_name" and one typo "spme_property_name", that typo can take "forever" to find and fix because the compiler can't tell you where to look. Especially if you don't catch it early, while you are developing. If it goes to "production" and all you get is a bug report, good luck finding it...

One approach to "remodeling" this C4 script, would be to start a new script repository from scratch and build it "the right way" (however we define that) from the ground up. Starting from a "green field" is usually much, much easier than trying to refactor/improve an existing pile of spaghetti code.

Have you located any resources describing how to start a new script for a "new" controller from scratch?

It would be fairly straight forward to create a very simple "one button" Control Surface script in CSS for the C4 and "start this new script" from that point. But I'm pretty sure I don't like that "brittle" architecture for one specific Control Surface script like this. Doing some research in that direction is on my list. (how to "start from scratch" based off of how CSS does it, but different, less brittle, because one custom C4 script doesn't need to support "general script writing" use cases)

BilldarBagdar commented 2 years ago

I started a new branch that creates a new "remote script" (Python package) under the wip folder called V2C4. The v2 script doesn't do anything yet except inherit from ControlSurface and attempt to model the LCD screens, but Live 10 will compile the script so it appears in the "remote script dropdown" and doesn't log any errors. I don't really know what I'm doing necessarily, but I'm hoping to get the script to flash the welcome message on the LCDs if you connect it. That would be "milestone zero".

Are you interested in seeing the early mess I've made?

markusschloesser commented 2 years ago

Quickly replying from my phone:

  1. Very much interested! Wanted to start a v3 script, but didn't have time yet.
  2. _framework, v2 and v3 classes are very similar. So the hanz petrov "introduction to the framework classes" tutorials from 10 years ago are still very helpful (linked in wiki here)
  3. The 10.1 decompiled scripts in my other repo (or from Julien Bayle) are Imho the last ones with docstrings. Those pretty much describe everything
BilldarBagdar commented 2 years ago

I will push the new C4Modeling branch to origin shortly. Even though I suspect the code reflects more ignorance than understanding at this point, at least it compiles. LOL.

  1. It might be very easy to switch from V2 to V3 at such an early stage. Or one could start another V3C4 script/branch.
  2. I have a local copy of my local decompiled scripts that is connected to my remote scripting projects in PyCharm. I don't remember the last time I re-ran the scripts to get updates but it was probably after 10.1.1. I'm on 10.1.43 now. If I write code "correctly", PyCharm can use its "intellisense" to make suggestions as I type further. That's helpful to me, even though "just because it compiles, doesn't mean it will run correctly error free".

I also updated a couple of files in the "original" MackieC4 script. I don't really know how to conduct a "conversation" via code comments. So I "replied" to a couple of question-comments by just changing the code and comments when I ran across them. Reviewing the diff will show what was there before and the updates. I don't think any functionality changed when I changed the code, but haven't tested that because V2C4.

markusschloesser commented 2 years ago

2. I have a local copy of my local decompiled scripts that is connected to my remote scripting projects in PyCharm.

With docstrings? They are essential to understanding what's going on (component registration etc) I can also push my decompiled scripts to the other repo. I have 9 - 11.2

markusschloesser commented 2 years ago

I also updated a couple of files in the "original" MackieC4 script.

Which branch?

BilldarBagdar commented 2 years ago

Yes, I haven't noticed any differences between what I look at locally and what gets linked online. It's possible some of the compiled scripts Live supplies have been updated since I last decompiled. Even the doc strings though can leave a lot of questions unanswered. The code itself can be difficult for me to read from the top down before I understand it from the bottom up.

Same new C4Modeling side branch

BilldarBagdar commented 2 years ago

I'm comparing a picture of the m-audio Axiom Pro keyboard with the code I'm seeing in PyCharm for the first time, I guess... I think I see a road map for the script now, given my stumbling start yesterday...

The Axiom Pro has an LCD screen that looks suspiciously like it is modeled in the code by a PhysicalDisplayElement

encoder_display = PhysicalDisplayElement(80, 8)

in particular looks like "80 characters per 8 lines of text" maybe. I think I see how to use it though, at least at high level.

markusschloesser commented 2 years ago

btw my recommendation would be to look into using the "with_component_guard" things, because in all my trials when trying to use modern framework shit, it always ended up in Live complaining that the components I was using were not "registered". The guard also shields bad things from happening. also those might be helpful: https://github.com/markusschloesser/MackieC4_P3/discussions/73 https://github.com/markusschloesser/MackieC4_P3/issues/58 https://github.com/markusschloesser/MackieC4_P3/discussions/95

BilldarBagdar commented 2 years ago

Weird. I thought I replied here again last night. (But where did it go?)

I pushed another in-progress commit up to origin on the new C4Modeling branch.

I basically had to comment out what I started for the LCDs to get the script to load in Live yesterday, but the stuff I modeled from the AP script doesn't barf in the log, so that's one step forward anyway. (and with self.component_guard():)

markusschloesser commented 2 years ago

I also updated a couple of files in the "original" MackieC4 script. I don't really know how to conduct a "conversation" via code comments. So I "replied" to a couple of question-comments by just changing the code and comments when I ran across them. Reviewing the diff will show what was there before and the updates.

and you don't need to do a conversation in the code comments, those were not intended towards you :-) I do those for me, to better understand problems (and remember later why I did what I did) But thanks anyway!

BilldarBagdar commented 2 years ago

I figured that's part of your commenting style. But when I see the question and I know the answer, it's difficult for me not to answer. We can leave those commits on the C4Modeling branch if the rest of the commits ever merge elsewhere.

BilldarBagdar commented 2 years ago

today's modeling update is... I barely feel like I'm making any progress. I think I'm starting to understand how the Axiom Pro is scripted, it basically toggles between a "mixer mode" and a "device mode", but the learning process is protracted.

What I committed today actually kind of works though. You can move the selected Track left and right.

markusschloesser commented 2 years ago

U want some help with this? Or figure this out on your own?

markusschloesser commented 2 years ago

Btw, don't know if you saw, crossfade assign and crossfade working

BilldarBagdar commented 2 years ago

I'm not sure I knew you put the finishing touches on that project, nice work. I noticed we were both making commits yesterday. I haven't seen two branches getting commits "simultaneously" like that in a while, mostly at work.

U want some help with this? Or figure this out on your own?

I do want to figure things out on my own. I "need to" understand in a sense, and slogging through the mud then trudging up the mountain along many false trails into box canyons and toward precipices is generally how I come to understand things. It's understanding why mistakes don't work then figuring out how to fix the problem that teaches the most powerfully, teaches me things that "stick in my craw" more firmly, longer.

With that said, do you have help to offer? I was going to suggest if you want to start your own new branch for another new script from somewhere on the C4Modeling branch, that would be cool. The current tip with just L/R track movement working might be good, or a few commits earlier before I committed so many new classes in C4Modeling. I'm going to start a new Discussion thread about things I think I've learned. Otherwise, let's talk help over there maybe?

markusschloesser commented 2 years ago

I'm not sure I knew you put the finishing touches on that project, nice work.

Thanks, I have been trying to ping you over in that other ticket (https://github.com/markusschloesser/MackieC4_P3/issues/100), but besides the actual displaying of stuff, I figured it out on my own.

I noticed we were both making commits yesterday. I haven't seen two branches getting commits "simultaneously" like that in a while, mostly at work.

Yep, nice :-)

U want some help with this? Or figure this out on your own?

I do want to figure things out on my own. I "need to" understand in a sense, and slogging through the mud then trudging up the mountain along many false trails into box canyons and toward precipices is generally how I come to understand things. It's understanding why mistakes don't work then figuring out how to fix the problem that teaches the most powerfully, teaches me things that "stick in my craw" more firmly, longer.

I fully understand!

With that said, do you have help to offer? I was going to suggest if you want to start your own new branch for another new script from somewhere on the C4Modeling branch, that would be cool. The current tip with just L/R track movement working might be good, or a few commits earlier before I committed so many new classes in C4Modeling. I'm going to start a new Discussion thread about things I think I've learned. Otherwise, let's talk help over there maybe?

Sure! And I do think I can help, mainly cos been looking at framework scripts for a long time and often. Also I even had a v2 framework branch last year, but it wasn't started from scratch and that's why it didn't work.