markusschloesser
commented
3 years ago Hey there :-) Glad to see you here!
If I have some devices on a track in track view, the view shows the first 8 devices on that track and a bunch of "sends" where you can adjust the send level. One of the features I really like with the script is the way you can click the "vpot button" of the device in track view and jump to device view of that device where you have 24 encoders automatically mapped to control the first 24 automation parameters of that device. A feature of device view is supposed to be that you can "page through" all of the automation parameters any device exposes, 24 at a time. (up to 128 which is the max size in the script's database (parameter list max sizes); although Live I think also has a 128 parameter limit of some kind, some devices expose hundreds more controllable parameters) But in my experience that "paging" (using the '>>' and '<<' labeled pots in the top row) only works when you are in device view for the first device on a track. (if you got to device view by that vpot button jump only?). If you click the second or later device on a Track, it takes you to device view and you have the first 24 parameters mapped to the pots, but you don't have the '<<' or '>>' pots for paging to any "higher" parameters. I will often have a "midi transpose" or "midi velocity" plugin in front of an instrument plugin, so this bug really impacts my "C4 workflow" in Live - I often would like to get to the second page of parameters on the C4 but can't because no '>>'.
I just checked and you're correct, it does not populate for more than the first page for the second, third device (or it doesn't show the bank switching). I did not know this and nor is this fixed in my version of the script.
Currently, my PyCharm setup is still exactly how I left it last May, and I don't have Live 11 yet. But I do have a Python 3 version of Live 10 (10.1.28 - last v10 version), so I think I just need to get my local repository and IDE setup upgraded to Python 3 and catch up with your work. BTW - I don't normally work in Python, but I wanted some experience in a new language like Python and was motivated by this C4 scripting opportunity. But I'm still very green, a rookie, in Python-land. Some of the programming concepts are just opposite or not-a-concern compared with languages I'm more familiar with. For example, I don't really understand how class inheritance works, why you would use inheritance in Python, when "private" data or methods aren't really a thing. I'm much more used to working in languages where there is a distinct line (without using "reflection") between "private" and "publicly" exposed data and methods. So, the fact that these script classes are in a bit of an inheritance hierarchy doesn't completely make sense to me. Something else I have trouble wrapping my head around is the "methods are first class objects" thing in Python that makes "method calls" expensive (in terms of processor overhead cycles) compared to other languages. Separating distinct logical operations into well named methods is a primary way I keep track of things in code. Normally I would prefer calling a well named method that executes a single boolean operation than executing that same boolean operation directly, but in Python, not only is it "expensive" to call a method that just does one operation like that, you can't make that method "private" so it is only callable from inside the class where it appears. Perhaps a person with more Python experience than either of us will start contributing and can teach us both a thing or two along the way.
I can only recommend Live 11, lots of cool things were added. Having said that, I am still running it thru tests to determine if everything is ok. Wrt Python 3: Live 11 b24 was the first Py3 version, so I don't think that you're running Live 10 with it :-) wrt rookie: at least you know development and GitHub 😂 For me those two are new as well. But yeah, I am currently in the middle of teaching myself coding/python for the first time ever, right now at "modules". So inheritance and how to instantiate properly and call stuff from somewhere is where I'm struggling with. At the same time, I read the code that's out there and try to understand what's going on and copy ways of doing things. And the whole boost thing, so calling c++ is a whole other level.
One thing I recommend for starters though is to make a "deprecated" branch of this repository where a python 2 version of the script is hosted. If anyone has an older Python 2 version of Live and a C4, that version might be exactly what they would want to work on or use. In other words, the repo would have essentially 2 "master branches", a P2 master and a P3 master. But the P2 master might not ever see any updates because all contributors contribute to the P3 side. But who knows, many updates or bug fixes might apply to both P2 and P3 anyway. If you really want to go "historical preservation", you could also make a "deprecated branch" that consists of just what was originally decompiled from Leigh's script (what you shared with me), and then another dead end branch with just what I contributed last year. "Code development history" is a big part of why source code repositories are popular. IMHO, the "best way" to have done it would have been to have had a source code repository going all along, and you could have just started this public repo from that "existing" repo including all the history. Since it doesn't look like you did that, we have what we have. It's not a show-stopping issue, it just means we would need to be careful when "inserting history" in "deprecated branches". If that sounds like too much, I'll see what I can do from my end about setting up something for the historical aspects, perhaps in parallel. Regardless, good job on everything you have accomplished so far. I don't know how many Live and C4 users are out there who also want to customize and improve this C4 script, but there are at least 2 of us...
From my understanding one can use the SAME script for both py2 and py3. Mainly with the help of "future imports", so with that we wouldn't need 2 branches. But the other thing is how to address LOM changes or different versions thereof. My current goal is to just bring everything up to speed for py3 and Live 11. However I still have the old stuff on my PC and could do different branches (1. decompiled versions I sent you, 2. decompiled versions I did later which were "better" decompiled, 3 the code you sent me, PLUS all the different Mackie Control scripts versions). But for that I need to understand branching better and how to manage that with pycharm. I am still struggling with more basic stuff I looked a lot and am really good at searching but could only find very little about (more complex) remote scripts less alone remote scripts and the C4. What I DID find was this https://intellij-support.jetbrains.com/hc/en-us/community/posts/360006921160-virtual-environment-for-developing-Ableton-Live-Midi-Remote-scripts-in-PyCharm?page=1#community_comment_360002795740
BilldarBagdar
SOMETIMES devices are now shown in channel strip mode and can be clicked :-)
right now unfortunately only for exactly 1 track in my template and I can't find out why, but making progress.
Also clicking a vpot button for where there is no device still leads to an index out of range error.
Can you find out why it's only working for 1 track?
Hi Markus,
I am the theoretically anonymous person you mentioned in the readMe. I use GitHub at work, but it's a closed hosted version. This is my first adventure into public GitHub land. I couldn't find a place here for us to talk like a forum or whatever. So I opened this issue.
The title of this issue is actually something I would like to fix in the script, so it's a real issue too. If I have some devices on a track in track view, the view shows the first 8 devices on that track and a bunch of "sends" where you can adjust the send level. One of the features I really like with the script is the way you can click the "vpot button" of the device in track view and jump to device view of that device where you have 24 encoders automatically mapped to control the first 24 automation parameters of that device.
A feature of device view is supposed to be that you can "page through" all of the automation parameters any device exposes, 24 at a time. (up to 128 which is the max size in the script's database (parameter list max sizes); although Live I think also has a 128 parameter limit of some kind, some devices expose hundreds more controllable parameters) But in my experience that "paging" (using the '>>' and '<<' labeled pots in the top row) only works when you are in device view for the first device on a track. (if you got to device view by that vpot button jump only?). If you click the second or later device on a Track, it takes you to device view and you have the first 24 parameters mapped to the pots, but you don't have the '<<' or '>>' pots for paging to any "higher" parameters. I will often have a "midi transpose" or "midi velocity" plugin in front of an instrument plugin, so this bug really impacts my "C4 workflow" in Live - I often would like to get to the second page of parameters on the C4 but can't because no '>>'.
Currently, my PyCharm setup is still exactly how I left it last May, and I don't have Live 11 yet. But I do have a Python 3 version of Live 10 (10.1.28 - last v10 version), so I think I just need to get my local repository and IDE setup upgraded to Python 3 and catch up with your work. BTW - I don't normally work in Python, but I wanted some experience in a new language like Python and was motivated by this C4 scripting opportunity. But I'm still very green, a rookie, in Python-land. Some of the programming concepts are just opposite or not-a-concern compared with languages I'm more familiar with. For example, I don't really understand how class inheritance works, why you would use inheritance in Python, when "private" data or methods aren't really a thing. I'm much more used to working in languages where there is a distinct line (without using "reflection") between "private" and "publicly" exposed data and methods. So, the fact that these script classes are in a bit of an inheritance hierarchy doesn't completely make sense to me. Something else I have trouble wrapping my head around is the "methods are first class objects" thing in Python that makes "method calls" expensive (in terms of processor overhead cycles) compared to other languages. Separating distinct logical operations into well named methods is a primary way I keep track of things in code. Normally I would prefer calling a well named method that executes a single boolean operation than executing that same boolean operation directly, but in Python, not only is it "expensive" to call a method that just does one operation like that, you can't make that method "private" so it is only callable from inside the class where it appears. Perhaps a person with more Python experience than either of us will start contributing and can teach us both a thing or two along the way.
One thing I recommend for starters though is to make a "deprecated" branch of this repository where a python 2 version of the script is hosted. If anyone has an older Python 2 version of Live and a C4, that version might be exactly what they would want to work on or use. In other words, the repo would have essentially 2 "master branches", a P2 master and a P3 master. But the P2 master might not ever see any updates because all contributors contribute to the P3 side. But who knows, many updates or bug fixes might apply to both P2 and P3 anyway. If you really want to go "historical preservation", you could also make a "deprecated branch" that consists of just what was originally decompiled from Leigh's script (what you shared with me), and then another dead end branch with just what I contributed last year. "Code development history" is a big part of why source code repositories are popular. IMHO, the "best way" to have done it would have been to have had a source code repository going all along, and you could have just started this public repo from that "existing" repo including all the history. Since it doesn't look like you did that, we have what we have. It's not a show-stopping issue, it just means we would need to be careful when "inserting history" in "deprecated branches". If that sounds like too much, I'll see what I can do from my end about setting up something for the historical aspects, perhaps in parallel. Regardless, good job on everything you have accomplished so far. I don't know how many Live and C4 users are out there who also want to customize and improve this C4 script, but there are at least 2 of us...