first 6 vpots in row one need proper clean-up / update in ChanStrip mode

[markusschloesser]

the first 6 vpot rings in row 0 stay where they were in user mode (lit up). Will try to fix this (when switching assignment mode, do a proper clean-up). UPDATE: this bug ONLY happens in ChanStrip mode

_Originally posted by @markusschloesser in https://github.com/markusschloesser/MackieC4_P3/issues/98#issuecomment-1286210878_

[BilldarBagdar]

I was thinking about encoders and buttons and feedback this morning when I remembered how verbose our OG script is over midi. Since I hooked up midi ox between Live and my C4 the other day and switched back to the fully operational OG script to "play music" yesterday, I see the MIDI logging stream in midi ox constantly rolling. It looks like 3 or 4 C4 buttons are sent a 0 value (in Channel strip mode) every time the screen updates and 4 sysex messages are sent every 3 seconds or so. The constant scroll was so distracting to me, I had to minimize midi ox to get the window out of sight while I only wanted to think about playing music.

The reason I mention the above here is because I think I just realized in relation to the above why this "user mode LED animation trash" issue exists. It's because "channel strip" mode doesn't have anything mapped to the first 6 encoders and the other (not "user") modes must cleanup after themselves better upon exit than "user" mode somehow. If "channel strip" mode was already doing any cleanup of those first 6 LED values when it gets activated, I don't think this problem would exist.

Is this information only news to me?

I haven't tried to verify my thought by actually repairing the problem because I'm working in a different branch right now and I don't want to get distracted over on that OG wip branch. We should probably retire that old school script as soon as we get an acceptably working "framework based" script going.

That chattiness over MIDI is "resource intensive" and bad manners. I now think it is responsible for certain "midi data traffic jams" in my studio that result in occasional audible (not musical sounding) glitches. I understand for example, it takes a "constant midi data stream" to implement the "song time" display in "function" mode. But the "new" framework only sends (LED and LCD feedback) updates over MIDI when "events happen" (when "something changes") instead of 10 times per second (every time the "screen update timer" event pops) regardless of any actual "events happening".

[markusschloesser]

I've already tried repairing, but failed. Probably because I searched in Chan strip mode, so your comment is helpful! 😊 Btw I'm back from vacation and currently trying to implement racks/grouped devices in legacy script (let's call it that 🙂). I also added "Framework" as prefix to the gh issues that are relevant to working with frameworks

[BilldarBagdar]

Yes, legacy.

[markusschloesser]

That chattiness over MIDI is "resource intensive" and bad manners. I now think it is responsible for certain "midi data traffic jams" in my studio that result in occasional audible (not musical sounding) glitches. I understand for example, it takes a "constant midi data stream" to implement the "song time" display in "function" mode. But the "new" framework only sends (LED and LCD feedback) updates over MIDI when "events happen" (when "something changes") instead of 10 times per second (every time the "screen update timer" event pops) regardless of any actual "events happening".

While I tend to agree that the chattiness is bad manners (and already had doubts about this last year), I haven't run into any problems (but I have dedicated Midi ports for all my devices, so no wonder that there's no interference). I also probably made it worse in the last couple of months by moving more displaying code into on_update_display to make sure that the LCD and vpot lights are up to date. And also it was easy for me to implement 😇. Lots of that could probably also be achieved by using listeners, especially the on/off stuff, but I wasn't able to do that (the Electra One scripts makes use of plenty of listeners, if I stay on legacy, I might change stuff towards those, but that's a big if).

FYI:

1. I merged the branch 2022_dev into master yesterday. It has been running flawlessly here for a couple of weeks.
2. Also updated the manual (https://github.com/markusschloesser/MackieC4_P3/wiki/Manual--Using-the-Mackie-C4-with-Ableton) with all the new features (text only for now, needs new picture as well)
3. Also tidied up GH issues.

[BilldarBagdar]

Before that Midi Ox log scroll reminded me of the legacy C4 script's chattiness, I had attributed the occasional "midi burps" in my studio to Link running and synchronizing 3 copies of Live with 9 connected midi controllers distributed around. The indigestion seems to often be associated with stopping playback. What made me "accuse" the chattiness is the fact that I don't remember any recent midi burps. However, I haven't been doing many "music sessions" this fall/winter, so I don't really know. The chattiness can't be helping though.

I noticed you had been "housekeeping" around the repository, but I haven't looked at any changes yet. Will do.

I'm going to make a summary post elsewhere detailing the minimum specific updates that I think need to be made to create a C4EncoderElement class and C4 "control surface script" class that work with the framework so "anyone" can adapt an existing script or start a new script from scratch to work with the C4. I'm pretty sure now the latest V2C4 script will be "easy" to update to using .v2.control_surface.xyz imports. But I'm not sure how much longer I will be motivated to work on V2C4 itself. I started writing the V2C4 script as a "simple" learner project that ended up taking me "around the world in 80 days". I just wanted to learn enough to go off and work on a different "control surface idea", and now I'm feeling the itch to scratch on that other idea for a while.

[markusschloesser]

fixed with https://github.com/markusschloesser/MackieC4_P3/commit/4323808804f9e7e451b5d5839610bcc6766b0827