Maintaining future Live 10 compatibility of C4 script

[BilldarBagdar]

Hi Markus,

I got a Push 3 over the summer which prompted me to upgrade my music studio "legacy" machines to Windows 10 and Live 11 (about time right?). I'm just now getting around to updating my remote scripting setup on the C4 connected machine. I was able to load the most recent Master branch code directly into my Live 11 MRS folder and run the latest C4 script in Live 11.3.13. Nice work.

But of course, Live 10 can't compile those code files because of a few "Python 3 only" code snippets. Because I still want to use Live 10 on occasion, and because I was curious, I created and pushed a fresh "master_Live10" branch (Commit:
1940c3e [1940c3e]) that restores Live 10 compatibility for the "most recent master branch code" (Commit: 7781719 [7781719]).

We should talk about maintaining (or not) such compatibility going forward from here. I'm not sure I want to keep refactoring "py3 only" code into code compatible with both py2 and py3. (and Live 11). I did it this time because I wanted to satisfy my curiosity and because I could. But if you and chatGPT keep committing py3 only code, I'll probably throw in the towel on maintenance for Live 10 versus chasing that tiger.

Edit:
I think the only change I made of any substance this time was to the note_handling_dict definition in the receive_midi method in the MackieC4 class. Functionally, I think the change produces comparable results.

The way the note_handling_dict was defined and initialized using the ** dictionary unpacking operator initialized a dictionary mapping of "note number" keys to "handler function reference" values (for every C4 midi note number 32 + 19 buttons) meaning 51 keys initialized in the keyset every time that block of code is entered. The way I refactored the dictionary mapping of "note number" keys to "handler function reference" values, there will only ever be at most 2 keys in the mapping keyset, the "Lock Surface" note key, and the other key if it exists will correspond to whatever other (non modifier) midi note was passed into the receive_midi method.

I would "argue" that if a "note handling method dictionary mapping" is going to be defined for all 51 buttons, then that dictionary object should be defined once elsewhere (perhaps in the MackieC4 class init method?) and then referenced many times in the receive_midi method. As a local variable within the receive_midi method, the mapping only ever needs to know how to dispatch one note at a time to the correct handler method (one button press at a time). The one (non-modifier button) note in the midi message input parameter passed in to receive_midi each time.

[markusschloesser]

Hi,
Great to hear from you again! :-)

prompted me to upgrade my music studio "legacy" machines to Windows 10 and Live 11 (about time right?)

Indeed! 🤐😉

I was able to load the most recent Master branch code directly into my Live 11 MRS folder and run the latest C4 script in Live 11.3.13. Nice work.

Thanks! Been running smoothly here as well, just the occasional change needed when Ableton decides to change things (which I wasn't supposed to use anyway)

Because I still want to use Live 10 on occasion, and because I was curious, I created and pushed a fresh "master_Live10" branch (Commit:
1940c3e [1940c3e]) that restores Live 10 compatibility for the "most recent master branch code" (Commit: 7781719 [7781719]).

I looked last week and couldn't find anything, but now I just found your code. BTW I had uploaded a couple of "official" releases and one of those was the last Live10 version.

Edit: I think the only change I made of any substance this time was to the note_handling_dict definition in the receive_midi method in the MackieC4 class. Functionally, I think the change produces comparable results.

The way the note_handling_dict was defined and initialized using the ** dictionary unpacking operator initialized a dictionary mapping of "note number" keys to "handler function reference" values (for every C4 midi note number 32 + 19 buttons) meaning 51 keys initialized in the keyset every time that block of code is entered. The way I refactored the dictionary mapping of "note number" keys to "handler function reference" values, there will only ever be at most 2 keys in the mapping keyset, the "Lock Surface" note key, and the other key if it exists will correspond to whatever other (non modifier) midi note was passed into the receive_midi method.

I would "argue" that if a "note handling method dictionary mapping" is going to be defined for all 51 buttons, then that dictionary object should be defined once elsewhere (perhaps in the MackieC4 class init method?) and then referenced many times in the receive_midi method. As a local variable within the receive_midi method, the mapping only ever needs to know how to dispatch one note at a time to the correct handler method (one button press at a time). The one (non-modifier button) note in the midi message input parameter passed in to receive_midi each time.

I didn't get notified that you updated your post and will need to take a longer look at this. Currently I am deep into m4l for 2 of my synths, check out my other repos (MKS80 and MKS70)

WRT to future backwards compatibility: I don't think it's worth it. The current script version runs fine and I even ran out of ideas to do (or in 2 cases Live doesn't work the way it's supposed to work).

[BilldarBagdar]

Yes, great to hear from you too Markus.

I saw the tag marking the last Live 10 version in the code tree view, but I didn't notice that corresponded with an official release too. It's fine I'm sure, I mean I don't think there would be any functional differences because of my updates. Whatever changes you made since that last Live 10 release would be different now, but I think most of those changes were specific to Live 11, or refactored "cleanup" anyway. If anyone else ever drops in looking for "current" Live 10 version support, they have that master_live10 branch to start from. It doesn't sound like you have any "big plans" for the C4 script going forward either anyway, just maintenance as needed.

Have you had those MKS synths since they were in production back in the day?

I still have a Yamaha Sy22 I bought new in 1989. Those m4l devices in your repos look pretty cool, inspiring even. I had not even considered trying something similar for my Yamaha Mu100r, particularly the VH100 and VL100 expansion cards which are only addressable by SYSEX. When I last had it set up, I had been using the old Yamaha DAW app XGWorks to "program" voices in the Mu100r and Live to "perform" voices on it. I remember dreaming of being able to use "native Live" programming features for voices on the Mu100r but not really getting very far into programming in the Max (m4l) style. I was programming and using the Mackie C4 Commander software at that time to remotely control some of the Mu100r "performance control" features. I wonder if anyone else has already done a m4l device for the Mu100r? Need to check around.

After your experience with the MKS m4l "instrument" devices, what do you think about making some kind of m4l "midi" device that addresses the C4 hardware? I mean maybe something like a 1 to 32 step midi step-sequencer device (mapped to the 32 C4 encoders/buttons). Obviously?, one could only use the existing C4 script or some future m4l C4 device alone in any given Live session, not both at the same time (unless one connected more than a single C4?). But I have a lot of creative fun with the hardware midi sequencer on my Akai Max49 keyboard controller and I think I see a pretty clear path from that functionality to a "clone" m4l midi sequencer device using the C4 hardware. Now that you are a seasoned veteran of m4l device programming, does such a C4 "midi device" sound like a reasonably small project?

Edit: Did you know "C4 Commander" app comes with a bunch of pre-defined instrument files for "old" Roland hardware? (Including MKS-7 and MKS-80)

[markusschloesser]

I saw the tag marking the last Live 10 version in the code tree view, but I didn't notice that corresponded with an official release too. It's fine I'm sure, I mean I don't think there would be any functional differences because of my updates. Whatever changes you made since that last Live 10 release would be different now, but I think most of those changes were specific to Live 11, or refactored "cleanup" anyway. If anyone else ever drops in looking for "current" Live 10 version support, they have that master_live10 branch to start from. It doesn't sound like you have any "big plans" for the C4 script going forward either anyway, just maintenance as needed.

I still have some plans, especially zoom and scroll in device and midi/audio editor view would be really helpful, unfortunately both do not work (confirmed by Ableton), even though they should according to the LOM

Have you had those MKS synths since they were in production back in the day?

No :-) When the MKS80 came out, I was 7 😇
Bought it 3 years ago, the MKS70 with v4 vecoven mod half a year ago. Nearly done with patch parsing for the MKS70

I still have a Yamaha Sy22 I bought new in 1989. Those m4l devices in your repos look pretty cool, inspiring even.

Thank you! I had lots of help on the cycling forum.

I had not even considered trying something similar for my Yamaha Mu100r, particularly the VH100 and VL100 expansion cards which are only addressable by SYSEX. When I last had it set up, I had been using the old Yamaha DAW app XGWorks to "program" voices in the Mu100r and Live to "perform" voices on it. I remember dreaming of being able to use "native Live" programming features for voices on the Mu100r but not really getting very far into programming in the Max (m4l) style. I was programming and using the Mackie C4 Commander software at that time to remotely control some of the Mu100r "performance control" features. I wonder if anyone else has already done a m4l device for the Mu100r? Need to check around.

A quick search didn't show any results. But it's not THAT hard to do. Also chatgpt can do read screenshots and picture which really helps when doing max stuff, plus the js code (for max) it produces is working fine as well.

After your experience with the MKS m4l "instrument" devices, what do you think about making some kind of m4l "midi" device that addresses the C4 hardware? I mean maybe something like a 1 to 32 step midi step-sequencer device (mapped to the 32 C4 encoders/buttons). Obviously?, one could only use the existing C4 script or some future m4l C4 device alone in any given Live session, not both at the same time (unless one connected more than a single C4?). But I have a lot of creative fun with the hardware midi sequencer on my Akai Max49 keyboard controller and I think I see a pretty clear path from that functionality to a "clone" m4l midi sequencer device using the C4 hardware. Now that you are a seasoned veteran of m4l device programming, does such a C4 "midi device" sound like a reasonably small project?

I am sooooo far from "seasoned", but thank you :-) For a sequencer I would do it with a v2/v3 remote script. Or you could just use an existing m4l sequencer with plenty exposed params and use the C4 in the way it is currently functioning. For example I use "ARP Control" a lot and all device params are fun to work with on the C4.

Edit: Did you know "C4 Commander" app comes with a bunch of pre-defined instrument files for "old" Roland hardware? (Including MKS-7 and MKS-80)

I do, even tracked down one for the FS1R, but they are unidirectional and not automatable, that's why I now mainly do m4l devices. Also for recall.

[BilldarBagdar]

but they are unidirectional and not automatable, that's why I now mainly do m4l devices. Also for recall.

Yes, I agree. The C4 Commander app doesn't work smoothly in the Live ecosystem. Which is why I was thinking about trying to reproduce it as an m4l device. But I never got very far on that path, and now I'm not really sure what "killer" functionality all that work would add over building m4l devices dedicated to each piece of hardware versus having C4 Commander integrated. Someone with dozens of vintage synths might prefer C4 Commander style versatility over dedicated devices for each of their old synths. I imagine the data in those "instrument definition" XML files could be useful, especially if you didn't have access to a synth's "programming manual".

The main feature I think C4 Commander might add is the versatility to have custom controller layouts for every song, accessible in real time by one click in C4 Commander. You could also, for example, define a "C4 Layout" page where each row of encoders controls the filter parameters of 4 different synths.

I subscribed to your YouTube channel yesterday and watched/listened to your videos. You might have noticed your view numbers "jumped". I enjoyed what I heard. Fairly cinematic. I didn't really feel like I was listening to "dance tracks", I wanted to see the associated "movie" too.

For a sequencer I would do it with a v2/v3 remote script. ... For example I use "ARP Control" a lot and all device params are fun to work with on the C4.

I'll have to check out a few sequencer devices and see how they function with the existing C4 script, But I was kind of imagining integrating the C4 script with whatever C4 based "sequencer device" gets built. So the script acts "normally" until the "C4 sequencer" device is selected (in "device" mode), and then the script automatically changes to "sequence device" mode for controlling that specific device in possibly non-script-standard ways.

Have you seen the "Stepic" sequencer device? I told myself I wasn't going to purchase any more VST instruments or effects until long after I start using more of the VSTs I already own. (or I start actually making money in music...) "Stepic" might become an exception. I think I "need it" LOL.

[markusschloesser]

Thanks for subscribing and the nice words! I do appreciate it 🤩
I got a double album coming out on a label, the release date for the first one is on the 28th of December. Very exiting for me 😊😊

[BilldarBagdar]

Hi Markus,

I didn't start a new topic, but I am sort of changing subjects in this one.

My C4 LCD screens went dark over the last week. All the other device functionality still seems to be working normally, just dark screens.

Fortunately, I found a video on YT documenting how to replace the "back light strip" part in the C4's LCD sub-assemblies. I ordered replacement parts (from Germany, "backlights4you.com") and hopefully I can get the LCDs working again once those parts arrive. In the meantime, all the buttons and encoders still work normally just no LCD display, only LEDs.

I forged ahead with making a C4 max4live MIDI effect device, but all it does is feed data back to itself for display. (The main reason it took so long to figure out my LCD screens experienced a hardware issue is because I was working on the SYSEX feedback messages to send to them. Then, my first troubleshooting efforts were directed at my Max patching, not the hardware. I didn't notice any dimming on any screens before they were all just "dead" dark, indistinguishable from "screen saver" dark. I thought they were in "screen saver" mode and would light back up once I sent a correctly formatted SYSEX message. But, alas...)

You are correct about using a controller script based approach for a C4 based "MIDI effect" like a MIDI sequencer. A m4l MIDI effect can NOT "naturally" communicate with any other MIDI port except its "midiin inlet and outlet" which always comes from / goes to the device chain of the Track it's on. I would need to resort to some "hacky" solution like creating m4l "send and receive" modules to side-chain different MIDI information from another Live Track and use that side-chain info to modulate my main m4l C4 "effect", AND I would need to hack that side chain into and out of the "sequencer" device. So "feedback" could go to the C4 midi port (through the normal midiout outlet) and "music" could go through the side-chain midi out to a synth or whatever device. That kind of hack seems possible, but also probably a LOT of work. The main issue is differentiating MIDI Note messages between C4 "button presses" and "musical Notes" (also an issue for CC messages on the same MIDI port and channel, but less commonly).

For now, my little device is basically just a m4l "how to send midi input back out to the C4 for display" demo. Are you interested in checking out the patching details? (A LOT of my development time was spent scratching my head simply trying to understand how to "patch" things together "properly" in Max. The Max documentation is pretty thorough, but also seemingly very shallow without many "real world patching" examples. I was glad to have the C4 side of the equation already in my bag while struggling through those Max learning-curve adventures.)

[markusschloesser]

My C4 LCD screens went dark over the last week. All the other device functionality still seems to be working normally, just dark screens.

ALL of them? And suddenly? Then it is not the backlights, but a transformer on the psu board. I have the same issue with a emergency replacement C4 I bought this year for backup purposes. There's a German thread on a forum somewhere on how to fix it, but I haven't got around to learning it
(Quickly typed from phone)

[BilldarBagdar]

Yes, and yes-if, with suddenly defined as all failing completely within an hour (or whatever the default C4 "screen timeout" time is) of each other at the end of a 10k(?) hour expected service lifetime, and I wasn't present to witness any dimming.

So, yes, the actual problem might not be the backlights, especially if any "surge" accompanied a recent power outage. But I didn't find that German language thread about the power board transformer, and I don't really know how to independently troubleshoot the hardware myself. The "backlight video" looks like a hammer to me and my problem like a nail with a big fat head. Lol. (and the back lights will eventually fail even if they are not the specific problem today)

Does that PSU board transformer forum thread have a lot of pictures? I imagine you probably have that link bookmarked, but not on your phone. Please share when you get a chance.

[markusschloesser]

https://www.logicuser.de/forum/viewtopic.php?t=74513&sid=8d5c6e29d229ab57b427d94e259d8911&start=15

[BilldarBagdar]

The OP on that thread (spocintosh) seems to be the "thread expert" and responded to:

[The LCD screen is] dead again for me, so it's not the "usual" dimming but simply dead. It's probably the small transformer that powers the lighting.

with

Yes, the transformer is a so-called inverter, they tend to smoke sometimes, but it could still be the lighting.
I'd be happy if you also contributed a picture.

But I didn't see any other "backlight" related posts from "janzoulou" or anyone with or without a related picture. Did I miss anything in translation?

[markusschloesser]

the last one was on page 3 where a guy with a c4 had the same problem as you have (sudden 4 display death) and fixes it with a replacement psu board (There's currently one for sale in Canada which is supposed to be for the C4, but it is NOT! The C4 has 4 display power output connectors (cos 4 displays, duh), the board on reverb has only 1..
But you're correct, the "fix" mentioned is "replace the inverter" and because of that I want to measure first what's actually defective.

Attached you'll find the service manual. Don't know good you are with electronics? As mentioned earlier, I have a couple of yt videos lined up on how to measure and fix shit, but haven't gotten round to actually watching them 😇🙄😂

MCU PRO Power Supply 0020142-XX {Scheme}.pdf

Oh and the new backlight (hammer/nail), will not solve the problem, as it doesn't fix the power supply.

[BilldarBagdar]

awesome, thanks for the info. I'd sure like to get ahold of an original C4 detailed service manual too.

I've replaced a few caps over the years and I successfully followed instructions to modify my Amiga 500 back in the day, but I wouldn't exactly say I'm "good" with electronics repairs. I have a buddy with an oscilloscope who builds/repairs guitar amps and it was always my plan to troubleshoot the problem a little before just replacing the backlight strips, like ensuring the old ones are getting current before desoldering and replacing them.

Lol, I know right, the only thing driving home that nail would accomplish is resetting the "back light strips have XXX hours of service lifetime remaining" clock. If the inverter smoked, new backlight strips won't get power either.

Did you know that if you send a Note ON message to a C4 button LED with velocity 1, (144 4 1) for example, the button will blink?

[markusschloesser]

Did you know that if you send a Note ON message to a C4 button LED with velocity 1, (144 4 1) for example, the button will blink?

I did not know that! Might come in handy for usability shenanigans 😉

[BilldarBagdar]

I also just learned the secret to encoder button LEDs today. Did you know they "respond" due to CC feedback rather than Note feedback?

Any CC value > 64 will turn on the led, and any CC less than 65 will turn it off. Additionally, the encoder ring LED feedback types are also mapped to their "previously known" constant values + 64. So, given the "led ring" feedback value you want an encoder ring to display, add 64 if you also want the "encoder button led" to be ON at the same time.

encoder_ring_led_mode_cc_values = {
    VPOT_DISPLAY_SINGLE_DOT: (0x01, 0x0B),  # 01 - 0B for "button led" OFF and + 0x40 (0x41, ox4B) for "button led" ON
    VPOT_DISPLAY_BOOST_CUT: (0x11, 0x1B),   # 11 - 1B OFF and 51 - 5B ON
    VPOT_DISPLAY_WRAP: (0x21, 0x2B),        # 21 - 2B OFF and 61 - 6B ON
    VPOT_DISPLAY_SPREAD: (0x31, 0x36),      # 31 - 36 OFF and 71 - 76 ON
    VPOT_DISPLAY_BOOLEAN: (0x20, 0x2B)}  # boolean type is wrap type that goes all the way dark

[BilldarBagdar]

Hi Markus,

I think I finally squashed all the bugs in my first-try "C4 Feedback" Max project. The "max device" doesn't really do anything except feed (incoming midi) back (outgoing midi) to the C4 led and lcd displays. The one piece of "business" functionality implemented so far is the Split button controls the (led and lcd) display of 4 "pages" of virtual encoder data.

all Split leds OFF == encoder page0 (1)  
Split led 1 ON == encoder page1 (2)       
Split led 2 ON == encoder page2 (3)      
Split led 3 ON == encoder page3 (4)     

I had to connect directly to the C4 midi port in Max in order to "manually" handle Note ON and Note OFF messages to/from the C4. Generally in Live (and m4l), you can't send an "orphan" Note OFF message anywhere, and any two Note ON messages (for the same pitch) are always separated by an (automatically generated as needed) Note OFF message. Those conditions make musical sense for Note messages, but ruin "C4 control" messaging inside Live.

Are you interested in checking out the project? IDK if you have a full Max 8 license or just the M4L sub-license, but AFAIK, the only difference between licenses is whether or not you can open Max "stand alone" or if you need to let Live "open Max" for you. Once you can see a Max window in Live (m4l), you can load "any" Max patch.

The midi in and out of the project should be the "actual" C4 midi port (using short name a) for your system, and that same port should be disabled in Live (and disconnect the C4 remote script) if Live is running.

The only current issue I'm aware of in the project is you can't press and release the Split button too fast or the displays don't all update properly (due to SYSEX bottlenecking I think). When I "hold press" maybe 500 ms before releasing Split, all the updates work normally. But "releasing too quickly" can cause display sync issues.

You are correct the "best way" to integrate the C4 with Live and Max is via remote scripting, but I don't really know how to connect a remote script with m4l devices. (I know it's possible. Check out this video for the Akai Fire beginning about 2 minutes into the video)

I'm thinking we might be able to leverage the "user mode" of our existing script somehow and connect to some form of my "C4 feedback" Max device. But I need to know more about how that "Fire script" and the "m4l Fire device" reference each other. What do you think?

[markusschloesser]

I think I finally squashed all the bugs in my first-try "C4 Feedback" Max project. The "max device" doesn't really do anything except feed (incoming midi) back (outgoing midi) to the C4 led and lcd displays. The one piece of "business" functionality implemented so far is the Split button controls the (led and lcd) display of 4 "pages" of virtual encoder data.

nice work! :-)

Are you interested in checking out the project?

I am!

IDK if you have a full Max 8 license or just the M4L sub-license, but AFAIK, the only difference between licenses is whether or not you can open Max "stand alone" or if you need to let Live "open Max" for you. Once you can see a Max window in Live (m4l), you can load "any" Max patch.

I don't have the full license, but indeed do not need it afaik.

The midi in and out of the project should be the "actual" C4 midi port (using short name a) for your system, and that same port should be disabled in Live (and disconnect the C4 remote script) if Live is running.

You can work around that by using the big/paid version of LoopBE and then some clever routing with either "Soundigy Midi Patchbay" or MidiTools from https://mountainutilities.eu/miditools. Basically use 2 separate virtual midi connections from LoopBe and then patch those to the actual C4 device (if you have a midi interface that is multi-client capable e.g. RME or iConnectivity, if not then more trickery is needed)

You are correct the "best way" to integrate the C4 with Live and Max is via remote scripting, but I don't really know how to connect a remote script with m4l devices. (I know it's possible. Check out this video for the Akai Fire beginning about 2 minutes into the video)

I am still not completely sure what to gain when utilizing m4l instead of pure remote script in Device mode.
For example this is a fantastic Arpeggiator device called "Arp Control" and when switching to Device mode on the C4, I have access to all the params I want. I can also reorder the parameters easily in m4l with the '#" column when you go to "View" > "Parameters" (in Max)
https://photos.app.goo.gl/8uoyuX3ZUGtL8NoF9

I'm thinking we might be able to leverage the "user mode" of our existing script somehow and connect to some form of my "C4 feedback" Max device. But I need to know more about how that "Fire script" and the "m4l Fire device" reference each other. What do you think?

I will need to take a deeper look into this, but not sure, if I'll have the time till the end of January (longer hospital visit coming up)

[BilldarBagdar]

I am still not completely sure what to gain when utilizing m4l instead of pure remote script in Device mode.

Neither am I, but that's part of the fun of discovery and learning. The "Stray411" channel on YT has several 5 year or older videos talking about some interesting "new" features in Live 10 and 11. I don't really know where I've been this whole time that these old videos are new to me in late 2023 on the verge of Live 12's release. Late to the party as usual for me.

I'm pretty sure our C4 script is not compatible with "grabbing and releasing" controls from control surface scripts as shown in the video because it's built on the old legacy Live 8 patterns. But I suspect we can therefore maybe create parallel "user mode" controls that would be compatible. Still though, all that really grants is the ability to build custom m4l devices that directly interact with "script" controls versus just exposing device parameters to "script control" as you described.

You can work around that by...

That's exactly how I've been developing, except I use "loopMIDI" for the "virtual connections" and have "Midi-Ox" between the "physical" C4 port and Max (or Live) so I can monitor the midi data flow. I guess I was just using awkward shorthand to describe how the Max patch needs to be connected to the C4 "directly" in Max versus "through" Live. I found a "Max external" I could probably use to work around that m4l restriction on "direct" midi connections inside m4l devices but I haven't tried using it.

I also found a relatively new GitHub repo, updated here that seems like it might be a great way to jump start our work toward escaping the legacy scripting framework we inherited. Have you heard of these repositories already? (I found both projects via associated YT videos) I still have a desire to update the Arsenal C4 script I started just because there is so much functionality packed into those "encoder modes", but I'm not sure how much work would be involved in updating all of that Python 2 "Arsenal framework" code, or if indeed it's even possible. There is some reason the author stopped further development and basically abandoned the "Arsenal" product line.

I'm sorry to hear you have a relatively long hospital stay scheduled soon. I don't think being in a hospital is ever routine unless you work there maybe, but hopefully your stay will be as routine, unsurprising, and successful as you and your doctor have planned and desire. Good tidings.

C4_deviceTests.zip I just zipped up my local project folder in Windows, I didn't do anything special in Max to prepare the project for sharing. Hopefully you can open the project even though I'm on the latest Max release (8.5.3) and you are on whatever version is bundled with Live 11.3. (Somebody has already released a video about an m4l feature only available (currently) in (beta) Live 12's bundled Max version, the video assumes Live 11's bundled version will eventually catch up someday)

[BilldarBagdar]

I don't know how I didn't find this issue earlier, but you might see "dict doesn't understand int" error messages in the max console when you click the Split button (in the project shared above). I found the problem today only after I refactored the name symbol of a dict object from "encoders" to "encodersBtnOff".

The problem is located a few patcher layers down the "page change" side where the "new page" data to be displayed on the C4 lcd screens gets collected (in the "get row values" embedded patcher). There is a t b i Trigger object causing the errors right above the ("encoders" still for you) dict "get" call that should be configured t b l. (trigger passes list not int)

I don't know how that error wasn't more apparent until I refactored the name of the associated dict today. I "formally" reloaded and tested the project patch version I uploaded twice before upload. Thus, I don't know if you'll see that problem on your end unless you save some change in that embedded patcher.

I'm now starting to work on doubling the number of "virtual encoders" in the project to keep track of both an "led OFF" value and an "led ON" value for each encoder (on every page). The first step was renaming the original "encoders" dict to "encodersBtnOff". Next I will add and (try to) integrate an "encodersBtnOn" dict. (Off and On states of the associated encoder button led entry in the "ledState" dict).

I've been getting inspired by max and m4l related videos about integrating graphics with sound design using jitter and gen objects and I think I should be able to leverage this C4 "controller patch" to get direct "hardware control" of the "video tutorial" patches I build. I'm pretty sure 128 (virtual) encoders might be overkill already, 256 will double the overkill. But what the heck, might as well see what happens. "More is better" :)

[BilldarBagdar]

Today I found another anomaly of patch behavior but this might be a C4 hardware issue... I mean when the problem randomly appears, Midi-Ox shows me my patch sent 4 sysex messages that haven't "yet" displayed on the C4 lcds. It's like the messages get stuck in a C4 input buffer or something until the next sysex message breaks the logjam. The problem only hangs around for one "page change" but sysex messages randomly don't get displayed more or less continuously, once or twice per dozen page changes, and I don't understand why.

All you need to do to cause the problem to appear is repeatedly press and release the Split button (slowly). The encoder data pages will cycle correctly a few times for both CC (led) and SYSEX (lcd) feedback, but eventually for some page change, the lcd screens won't update with the leds that do update correctly, yet Midi-Ox shows 4 correct SYSEX already passed through after those CC messages, and the C4 doesn't "yet" show those updates on the lcds. (You can fairly easily "read" the beginning of the (Midi-Ox for me) sysex hex data to tell if the "first encoder name" on the top line is a one, two, or three digit (ascii) number surrounded by "hex 20" blank space values. Page 0 is the only page with "single digit encoder numbers", and page 3 is the only page with "triple digit encoder numbers")

Once the problem appears, there seem to be two ways to make it go away temporarily. The weird way is to turn an encoder which should only update the lcd over the row of the turning encoder, but instead seems to flush a buffer somewhere (after Midi-Ox) so that all "5" sysex messages (4 delayed + 1) get displayed on the lcd screens. The other way to make the issue go away temporarily is to just keep slowly pressing the Split button. The leds and lcds will sync back up again (temporarily) with the next press (or release, you'll see the pattern)

I know you are busy, but whenever you happen to check out the patch can you tell me if you see the same kind of weird "delayed" lcd updates when the patch connects to your C4? Any ideas?

I found I can influence the frequency of triggering the problem by manipulating the "threshold time" (right inlet) of the "thresh" object. A setting of "1." makes the problem appear much more frequently than a setting of "2." But strangely, the Midi-Ox monitor shows the same details with every "lcd update failure", that the lcd sysex messages passed through Midi-Ox yet didn't display on the C4.

[BilldarBagdar]

Looks like I can resolve the issue by deliberately introducing a delay to the sysex data feed.

By delaying each byte of the outgoing sysex message by 2 samples it introduces about 5 ms of latency per lcd sysex message, and that seems to be enough time for the C4 to now consistently display all 4 lcd screen updates every time an "encoder page" changes.

Have you ever encountered a problem like this where code was apparently spewing too much data too fast for the C4 to handle properly?

It only takes 63 bytes of sysex to update a single lcd line, top or bottom, maybe those can "stream" faster. But 4 * 119 (=476) bytes to write all 8 lines across all 4 screens seems to be right on the border of too much data for the C4 "all at once".

[BilldarBagdar]

posted an updated project zip at C74 forums...

[BilldarBagdar]

Hi Markus, I hope all is well. Happy 2025.

I started and pushed a new branch called Live12UserMode to integrate the C4 Sequencer Max patch above with this script as "User" mode functionality instead of the lightshow demo. I'll post again when I've made some actual progress. For now, I just implemented a fresh PyCharm development project setup locally and updated associated utility scripts. The utils make setting up and using fresh "new" PyCharm projects for this repo almost as easy as creating new branches in Git. Check out the changes maybe?

I'm thinking that going into "User mode" will be a simple "Marker" button click just like any other mode change the script does. But I think to get out of the sequencer (which normally uses the "Marker" button for something else), I'll need to implement press-and-hold plus another button click semantics like "(press and hold) Marker + (press) Lock" to exit "User mode" and go back to previous script mode. The sequencer "control" feedback midi messages will "enter and leave" this script on the same midi port connection the script uses, and the RTC midi messages to the sequencer and "pitch info" midi messages from the sequencer will still travel to/from Live over a separate (loopback) midi port connection.

[BilldarBagdar]

Hi again Markus,

I just pushed an update to the "Live12UserMode" branch here which coincides with the "remoteScript" branch I also just pushed to my "Max Sequencer" project repository. I doubt everything works correctly yet, there's always bugs, right? But the changes seem robust enough to share with another developer like you.

I plan to do much more comprehensive documentation, but in a nutshell... You need 3 "midi loopback" connections, two out of Live, one in to Live. The first out of Live is the "remote script output" and the other is for "midi sync" RTC out of Live. The input is "sequencer notes" in to Live. The other end of all three loopback connections is the Max patch (C4 Midi in, RTC in, sequencer out). Finally, the C4out DIN midi should connect to Live's C4 "remote script input" port, and the Max patch C4 Midi out should connect to the C4in DIN. The remote script processes midi messages from the C4 first, then in USER mode forwards them to the Max patch for processing and feedback, or when not in User mode generates feedback for the C4 that the Max patch just forwards to the C4 display.

C4o-->--iLIVEo-->--iMAXo-->--iC4     // midi control port path (remote script and patch)
LIVEo-->--iMAX                       // midi RTC  port (external Midi Sync from Live to Max)
MAXo-->--iLIVE                       // midi notes port (sequencer output from Max to Live)

Open a default Live set and let the C4 remote script load completely. You won't see normal remote script feedback display on the C4 because Max isn't connected yet, but the script input is connected, you can "track select left or right" for example and see the selected Track move in Live. Now browse into the Sequencer project, can you open the Project file "C4DeviceProject.maxproj"?, Either way when the remote script is NOT in User mode, open the patch named "openSequencerBypassing.maxpat" in the /patchers folder. (If already in User mode open the patch named "openSequencerProcessing.maxpat")

If you have your midi ports already configured (by customizing and saving your selections in your copy of setupProjectMidiPorts.maxpat), or as soon as you select the correct ports in the patch for your studio, you should start to see normal "remote script" feedback appear on the C4 after any button press or encoder turn. (or update in Live like "track changed")

The original three assignment modes Channel Strip, Devices, and Function should still operate exactly the same as before this User mode update. If you are not using the Max Sequencer patch, the only differences in remote script functionality should be around User mode. The text displayed in User mode, the button click semantics "(press and hold) Marker + (press) Lock" to exit "User mode", and "force unlocking" the controller after exiting User mode (this force might not be needed though). If you are using the Max Sequencer patch, it takes over the entire device. The only way out is "(press and hold) Marker + (press) Lock".

The only thing to watch out for is don't be in User mode when Live loads a new set, for example. The new remote script session won't start in User mode anyway, and all the "SPAM midi" messages that fly while the set loads can confuse the patch if it's not bypassing.

The readme over in the Sequencer repository goes into much more detail about sequencer operations. But basically, when none of the nine "control button" LEDs are ON, the sequencer is operating on the first of five "decks" where each deck consists of 4 "pages" of 32 sequencer steps (2 bars of 16th notes) and the split button controls which page is currently linked to the sequencer. It's easier to see than to explain. Press all of the encoder buttons on one row then give each one a random twist. Now press Split. Page 0 went away, Page 1 is on display. Press Split again Page 0 is back on display. Rinse and repeat pages 2 and 3. Each of the 4 Assignment buttons allows another "deck" of 4 "split pages" of sequencer steps. Now try the Slot Up/Down and Track Left/Right buttons, see how that one active encoder row (of data) "moves around"? Start Live transport with at least one midi instrument listening to the sequencer notes and mess around. Have fun.

I've been testing the latest iteration of code changes but I keep getting distracted by how much fun I'm having playing the sequencer. Rhythmically timing your Split and Slot Down button presses makes for some surprisingly interactive musicality... I hope you can find some time to check it out sometime. I would enjoy using the remote script more if the LCD backlights in my C4 were working, but I do like using the script too, having all those device parameters at your fingertips...

[BilldarBagdar]

I added 2.0 updates to the readme file over at my "sequencer repo" with a little more detailed information. The main thing I figured out is you CAN open .maxproj "project" files with only a Max4Live license which is very important because "Max Projects" establish a "project relative" search path, and "relative path finding" in Max is quite difficult otherwise. I tried. If you just double click the "openSequencerBypassing.maxpat" file for example, you'll see a bunch of javascript "can't find object" errors in the Max console and the patch won't work. But if you open the Project file first, C4DeviceProject.maxproj; then you can open "openSequencerBypassing.maxpat" from the "Project Menu" without seeing any javascript errors as it loads.

[BilldarBagdar]

I am still not completely sure what to gain when utilizing m4l instead of pure remote script in Device mode.

You should see the gain now, once you try the updates. The only other sequencer I've used that is so "playable" is the hardware sequencer built into my Akai Max 49. For example, the "Split" and "Slot Down" button behaviors associated with "paging swaps" and "Rotating" the sequence-data doesn't exist in any other sequencers of which I'm aware.