Sticky: Is this an Issue?

[BilldarBagdar]

When I first launch a session of Live and the C4 script loads, the default channel strip mode display on the C4 is not "fully loaded" with information from the selected Track of the Live session that was launched. I can switch selected Track and switch back after the session loads to see the "fully loaded" display information, but it's not there by default after a session loads (when Live starts - I haven't tested just changing sessions). Do you see the same behavior on startup? Is this an issue?

[markusschloesser]

same here, but don't know if that is a regression or always was like this.
There's still some shit funky for init and destroy, I only fixed unlighting vpots for both init and destroy yesterday.

[BilldarBagdar]

IIRC, the "default display" used to load up everything without needing to switch tracks and back last year when I was working on the script; but it has not ever worked that I remember for this repository version.

Seems to be a valid issue then. But also seems like maybe an easy fix. Maybe we can just call the "track changed" method at the end of __init__ "as if" the track had changed and changed back.

[markusschloesser]

I suspect the multiple hacks like in #45 are competing against each other. I'm currently working on implementing a track_util.py which will use the proper way (cos mute for example can be because of soloing another track AND needs to take group /parent into consideration)

[BilldarBagdar]

Definitely could be. Sometimes you have to fix a whole chain of things from where you first notice the bad behavior and fix something. But sometimes you get lucky and fix something that is the root of other follow-on issues, and they go away too, no matter how you got there with the fix.

This isn't really a high priority "issue" IMHO since such an easy and effective work-around exists (on the device in the script), and especially since you appear to be quite confident issues like this and 45 will have their guts ripped out anyway due to your plans.

So, wait and see.

[markusschloesser]

yep, what makes me especially confident, is the fact that I planned on fixing the destroy function and when I did this for the vpots, it also fixed init for vpots (encoder rings) 😂

[BilldarBagdar]

Interestingly, testing with your "exp" branch just now, after Live loads and the C4 display is "incomplete"... You can change tracks to basically "fix the display" like we've been discussing. However, I found that alternatively you can switch to device mode and back to "Chan Strip" mode, and you also get "the sends" to appear on the "still incomplete" C4 "Chan Strip init track" display. But the devices parts are still jacked-up.

My "default session" when I open Live is on a "selected Track" that has the "Wavetable" Instrument loaded ("Descenting Dreams" preset), so I "know" that device is there. Testing/Playing around just now I added a second device (Looper) to that track. Have you been trying to tell me about this behavior I just witnessed? The "devices" LCD segment over the first device filled in with the more-or-less correct preset name, "Dscntn", but the segment over the (just added) second device stayed blank.

So, I deleted that "second device" in Live (didn't try the second encoder button :)) and switched-track to a next door track with one device loaded (Superior Drummer) which "has always" shown "SprrDr" in the segment over that first encoder, and upon switching back, instead of still showing the correct "Dscntn" preset name like it did when two devices were loaded, it still shows "SprrDr" (like it did when the previous track was loaded?) Now since the other "next door" track to the "selected when the session loads" track actually has no devices loaded when the session loads... If I "change track left" (on the device) "and back" to the Wavetable device track, when I come back, it says "SprrrDr"; and when I "change tracks right and back", when I come back, the display segment over the first encoder is blank again. I can go back and forth all day and the "wrong display" will change depending on the direction I'm "coming from" left or right. That's weird.

Something else I found is that, when I just dragged the "Looper" (default device) in as the second device, the "preset name" display segment was blank, right?, but it occurred to me that I had pulled in a default device and there wouldn't be a "selected preset name", so I tried again by pulling in the "2 bar phrase" preset of the Looper device. And boom, both display segments show more-or-less correct preset names. (and the weird left/right directional thing is gone)

I'm not finding any problems that appear related to your changes, but I saw this in the logs and fixed it.

2021-04-04T15:32:01.999800: info: RemoteScriptError:     
2021-04-04T15:32:01.999800: info: RemoteScriptError: self.__encoder_controller.track_changed(selected_index - 1)

2021-04-04T15:32:01.999800: info: RemoteScriptError:   File "C:\ProgramData\Ableton\Live 10 Suite\Resources\MIDI Remote Scripts\MarkusC4test\EncoderController.py", line 230, in track_changed

2021-04-04T15:32:02.001800: info: RemoteScriptError:     
2021-04-04T15:32:02.001800: info: RemoteScriptError: self.__chosen_plugin = self.selected_track.devices[self.t_d_current[self.t_current]]

2021-04-04T15:32:02.001800: info: RemoteScriptError: IndexError

Now some of the behavior I described above doesn't happen any longer, and this is logged instead

2021-04-04T16:01:28.076800: info: Python: INFO:MarkusC4test.MackieC4:75 - (MackieC4) len(self.selected_track.devices) <= self.t_d_current[self.t_current]
2021-04-04T16:01:28.076800: info: Python: INFO:MarkusC4test.MackieC4:75 - (MackieC4) 1 <= 1

I pushed this update up to origin on "04.02EXP"...

[markusschloesser]

great! I already pulled and merged with mine and also into the newest branch (tracks). Also tested it.

I am hesitant to just push into master or shared-dev, as I don't wanna fuck things up in the branches you manage or use productively. That's why I keep on opening new branches 😇😁 (but also deleting my old ones as a way more experienced guy taught me).
So I don't really know how to go from here. I'm currently having fun and learning quickly and always check/test in Live 11. Also only using stuff that's also available in Live 10 (so no f-get etc).
What's your opinion on this?

[BilldarBagdar]

I would say... Keep going, Keep having fun. Don't let potential compatibility issues slow you down much even. I mean if you come to a point where it seems like f-get or whatever would be the solution, just go for it.

The beauty of git is that it's pretty difficult to make "irreversible decisions". Some messes can be very, very difficult to pull back out of the mud, but to get there you generally need to drive by (ignore) a few warning signs on the way into the mess.

I would say, don't push/pull into master until/unless we both decide some "shared-dev" version is "ready for release" whatever that means to us, and we can "mark the occasion". Otherwise, I would say, at your free discretion, push/pull changes into "shared-dev". I will have my own local copy that might get several commits behind the origin copy. But so what. With that said though, think about much larger OSS projects where one would likely never push up a branch to origin (into public view) that wasn't looking "showroom new" and completely ready for an official "Pull Request". Here, with just the two of us, "experimental branches" that hang around for a week or month or more "at origin" while we work through development together are going to be totally normal. As long as we don't start acting territorial about "our branches", we can (like I did today) freely push up branches and changes to each others' branches because we're working together. So, if you push up your latest work and it works, we can push it straight into shared-dev. But at your discretion, if you think there is a larger "unit of work" this change is part of, then there's no hurry to push the (changes in the) new branch to "shared-dev" yet. All the changes will go with the larger unit of work when it is done.

Maybe if we each make a sort of "personal master" branch, named whatever we want of course, that is our "stuff I'm ready to share at origin" branch, then we would each have 3 shared branches (master, shared-dev, and theotherguy), and any number of local personal branches to work with. I don't know though, that might turn out to be too much structure. As long as "dead, deprecated, or already merged" branches don't start accumulating at origin; we shouldn't have too much trouble identifying branches at origin.

[BilldarBagdar]

Also, if you branched off of "04.02EXP" 5 times already but you haven't pushed anything to origin because of concern for my productivity or whatever, stop being so concerned. :) We haven't seen any formidable 10 versus 11 compatibility issues yet. Like the programmer Michael Jackson would have said, just push it. We'll cross that road when we come to it.

[markusschloesser]

on that matter: when I upgraded from Py2.5 to P3 I changed xrange to range. As range is different in py2.7 (https://stackoverflow.com/questions/44571718/python-3-range-vs-python-2-range), do you see any downsides?

[markusschloesser]

Otherwise, I would say, at your free discretion, push/pull changes into "shared-dev".

Ok, that's what I did right now, 4 new commits merged into shared-dev and pushed to gh/origin (from branch "tracks). Check the new feature and let me now if it's working for you. I will now try to tackle either other track stuff (using track_util) or grouped/chained devices, depending and what I'll manage to do :-)

Maybe if we each make a sort of "personal master" branch, named whatever we want of course, that is our "stuff I'm ready to share at origin" branch, then we would each have 3 shared branches (master, shared-dev, and theotherguy), and any number of local personal branches to work with. I don't know though, that might turn out to be too much structure. As long as "dead, deprecated, or already merged" branches don't start accumulating at origin; we shouldn't have too much trouble identifying branches at origin.

I am quite happy with my current approach, meaning 1. do a new branch 2. do stuff 3. regression testing 4. merge into shared-dev (or maybe master at some point) 5. delete branch