Maintaining future Live 10 compatibility of C4 script #116
Replies: 11 comments 14 replies
-
Hi,
Indeed! 🤐😉
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)
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.
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). |
Beta Was this translation helpful? Give feedback.
-
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
No :-) When the MKS80 came out, I was 7 😇
Thank you! I had lots of help on the cycling forum.
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.
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.
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. |
Beta Was this translation helpful? Give feedback.
-
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.) |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
https://www.logicuser.de/forum/viewtopic.php?t=74513&sid=8d5c6e29d229ab57b427d94e259d8911&start=15 |
Beta Was this translation helpful? Give feedback.
-
I did not know that! Might come in handy for usability shenanigans 😉 |
Beta Was this translation helpful? Give feedback.
-
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.
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? |
Beta Was this translation helpful? Give feedback.
-
posted an updated project zip at C74 forums... |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 thereceive_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 thereceive_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 thereceive_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 toreceive_midi
each time.Beta Was this translation helpful? Give feedback.
All reactions