Hi Mark,
Do you know of a solution to get the LivePad (LiveOSC) agent to work with Live11?
Because, Ableton Live 11(not Beta) has moved the code base for MIDI remote scripts from Python 2 to Python 3.
Due to the change in Python 3 syntax, custom/third party MIDI remote scripts that were created to work with Python 2x / Ableton 9 or 10 will not work in 11.
If you have any insights on this I would appreciate your advice.
sorry, no Ive not used it for a while⊠in fact I cannot even remember how to use it 
from a quick look, my guess is its in two partsâŠ
a) LivePad agent within EigenD
this sends osc to âliveoscâ
this part should still work
b) LiveOsc remote script
from : http://livecontrol.q3f.org/ableton-liveapi/liveosc/ ?
this is I guess the part that is now failing?
that looks pretty old, but looks like someone forked it to get it working with Live 10.
i guess someone will at some point (hopefully) get it working on Live 11?
unfortunately, I really donât know much about how the liveosc remote scripts works, so it would not be an easy thing for me to fix.
a bit of background, I think livecontrol was created for Lemur, so was originally by lline ?
but they donât seem to doing much these days
interestingly though there forum has a user asking about this too
https://forum.liine.net/viewtopic.php?f=25&t=6166
Thank you for your kind signposts and answersđ
I donât know if anyone will be able to find a solution in the future, but I will continue to monitor the thread on the URL site you gave me for a while.
ableton Live 12 MIDI Remote Script for LivePad(LiveOSC) agent
Hi everyone,
Iâve updated LiveOSC â the Ableton Live MIDI Remote Script required for EigenDâs LivePad agent â to work with Python 3 and Ableton Live 12 (tested on 12.1.5 and 12.4b8/b9).
As some of you may remember, this was the missing piece that prevented LivePad from working ever since Live moved to Python 3. The original LiveOSC was written for Python 2 and simply stopped loading in Live 11 and later.
Whatâs fixed:
Tested with:
Installation:
~/Music/Ableton/User Library/Remote Scripts/The MIDI Remote Script for Ableton Live 12 (for Eigenharp alpha) is designed to interact with EigenDâs LivePad agent. This script enables interaction between LivePad and Ableton Live via MIDI signals, allowing users to operate more flexibly in music production and performance.
Key features of LiveOSC include the display of clip playback statuses and LED synchronization, and it is compatible with Python 3. It can be used with Ableton Live 12, facilitating smooth music production while utilizing the latest features.
Download:
LiveOSC_Live12.zip (18.3 KB)
A note on how this was made:
This MIDI Remote Scriptâs migration project to Python 3 was developed through vibe coding based on my own trial and error and intuition, without any coding knowledge or expertise. It was made possible through interactions with Claude (Anthropicâs AI). This project exists thanks to that collaboration.
If you find a bug, I canât fix it directly â but please report it here with as much detail as possible (what you did, what happened, which version of Live and EigenD youâre on). Iâll feed the report into Claude and work through a fix the same way this was built. Bug reports are genuinely welcome.
Hope this gets some of you back to playing with LivePad again!
My System information:
OS: Mac OSX 26.3 64 bit: yes
CPU: Apple M1 Max, Cores: 10, Speed: 2400 MHz
Memory: 65536 MB
EigenD Version: 3.0.0-beta-2
Ableton Live Version: 12.4 beta9
cool stuff !
I saw your bug report for the talker agent.
I did quite a bit of testing and I cannot reproduce it.
youâll find details of tests I did etc in the issue report.
tl;dr;
I think for some reason, the live pad agent was not present when you tried to edit the talker - so its NOT a talker issue, more likely live pad agent was missing.
(Iâll wait for your feedback, before closing this as non-reproducible)
assuming the live pad agent was supposed to be present, then the issue likely lies there.
BUT Iâd need to see the eigend logs for that, and also some reproducible scenario around thatâŠ
so that would be a best as a new bug issue, once we have details surround this.
Im wondering if there could have been some failed âcommsâ (not so likely with osc) , or perhaps this version of LiveOSC is sending back something unexpected, and the LivePad agent is not handling this well. again, eigend log might give some hints here.
Thank you, Mark, for conducting numerous reproducibility tests and sharing your insight that this issue is not related to the Talker.
I will also investigate whether the problem of not being able to write a Belcanto script when adding Action to the Talker is related to connections with LivePad or other agents.
as stated on issue, I dont think its anything to do with talker.
bare in mind, talker is working with much more complicated setups, and we know these work⊠so as long as its adding / saving the action (which it is , I tested), then Id say they are a âred herringâ, its something else.
id be surprised, if its anything other than âlive pad 1â did not exist at that time (or had stopped responding).
and, given you have implemented a new live script,
it seems likely(?) this could have caused some change in the protocol being sent/handled, and creating a use-case not being handled in the existing livepad agent (as it didnt occur before)
fortunately, livepad was one of the first agents I ever wrote, and its actually very simple⊠based on cfilter (used by many other agents), so I took a look at the implementation - it does seem to âprotectâ itself from certain âbad messagesâ.
However, I canât guarantee all cases are handled - it was, after all, tested against. a particular LiveOSC script.
you can see the message encoding and decoding in this file:
so this would be a good place to start to determine if the protocol you are sending, matches what was expected/ used before.
it wont catch everything, i.e. there may be certain message ordering that is important, that wont seen at a âmessage levelâ, but its still a good place to start.
As Iâm not a programmer, I had Claude (Anthropicâs AI) analyze both the workbench log and live_osc.cpp. Here are the findings:
Analysis 1: Talker/Action save failure â root cause identified
The error current value not a key in finfo appears consistently every time a write is attempted to <talker73>#4 (the Belcanto script field of the Action key). This occurs repeatedly throughout the log, not just once.
Key observations:
The Action key itself is created successfully. The log confirms backend create instance <talker73>#3.9 1 â so key creation is not the problem.
The error occurs before any LivePad interaction. The first occurrence of current value not a key in finfo appears at line 12813, well before any Action key editing is attempted. LivePad wires are established at lines 825â839. This confirms LivePad and LiveOSC are not involved.
The finfo cache does not register the Action keyâs property. After the Action key is created (nf changes from 8 to 9), Workbenchâs internal finfo does not include the new keyâs property entry. Every subsequent write attempt is silently rejected.
This appears to be a Workbench Beta-2 bug where finfo is not updated correctly after a new key is dynamically added to an agent. The issue is isolated to the Workbench/backend layer and is unrelated to Talker, LivePad, or LiveOSC.
Analysis 2: live_osc.cpp protocol compatibility check
The OSC messages sent by the updated LiveOSC script match the format expected by live_osc.cpp in all handlers. Specifically, /live/track/info is sent as iiiif (INT32 Ă 4 + FLOAT), which aligns with what live_track_info_handler_t expects.
The /live/refresh message added to LiveOSC has no corresponding receiver in live_osc.cpp, but this is intentional â it is used only as an internal trigger on the LiveOSC (Python) side and does not need to reach EigenD.
One additional finding: in live_track_info_handler_t::messageHandler, the length argument is declared as float and the type check correctly requires LO_FLOAT, but the value is read using ->i (INT32 accessor) instead of ->f (FLOAT accessor):
float length = args[4]->i; // should be args[4]->f
This appears to be a pre-existing typo in the original code. It means length is currently being misread on the EigenD side, though it may not cause visible issues depending on how length is used downstream. Flagging it in case itâs useful.
Iâve pushed an updated version of the LiveOSC script with the following improvements:
Bug fixes:
KeyError crash in _purge_dead_clip_listeners() caused by using del on a dictionary key that had already been removed. Changed to pop(key, None) to safely handle missing keys.Boost.Python.ArgumentError in rem_clip_listeners() when accessing already-invalidated clip objects (introduced in Live 12.4b9). All listener removal calls are now wrapped in try/except.try/except protection to rem_device_listeners() for consistency and forward compatibility.schedule_message() calls which are not supported in Live 12.4b9, replacing them with direct method calls.Listener management overhaul:
add_cliplistener() and add_slotlistener() now always remove any existing listener before re-registering, preventing duplicate callbacks that caused conflicting OSC messages on play/stop.add_clip_listeners() now performs a full remove-then-rebuild on every call, ensuring that track index changes (e.g. after adding a new track) are always reflected correctly in OSC output.Track and scene handling:
getslots() to use song().tracks instead of visible_tracks, which could miss newly added tracks due to update timing.scenes_change listener so that adding or removing scenes also triggers a full listener rebuild.Code cleanup:
Download:
LiveOSC_Live12_2026-2-28.zip (17.8 KB)
this is incorrect, simply because this âerrorâ occurs even when the behaviour actually works⊠i.e in my tests, i got this âerrorâ, and yet the action was created successfully,
Id need to check the code, but its likely the code is throwing an error, whilst checking that the key is not already present (since its a new key), rather than checking for this âcleanlyâ (so kind of a âfalse postiveâ)
unfortunately, whilst AI has looked at the code, its then jumped to a conclusion, without taking into account the fact that this code CAN work, it does not fail every time. e.g. does not explain why it works for me 
ok, float length = args[4]->i; // should be args[4]->f this is indeed a typo, should be ->f
however, since I only ever check for length as being 0 or not, and even if that was incorrect - it would only ever mean the state was shown as incorrectly recording.
so it would be a functional error.
void processClip(int track,bool armed, int clip, state_t state, float length)
{
// pic::logmsg() << "track_info_handler_t::processClip track: " << track << "clip:" << clip << "state:" << state << "length" << length;
if(length>=1.0)
{
piw::tsd_fastcall(__updateModel,wire_,new model_update(wire_->root_->view(), wire_->root_->client_, track,clip,live_model::clip_t::CLIP_RECORDING));
}
else
{
piw::tsd_fastcall(__updateModel,wire_,new model_update(wire_->root_->view(), wire_->root_->client_, track,clip,stateToModel(state)) );
}
}
but yeah, this would not cause any issue with the action on the talker.
which is what I said previouslyâŠ
again, AI needs to be coerced into digging into problems
this is a general problem Ive seen with vibe / ai codingâŠ
AI is great at some tasks, but it has a nasty habit of âfinding a smoking gunâ, and then creating a hypothesis then coming up with a âreasonableâ suggestion as to why this is the caseâŠ
as you can see above, in both cases, it finds a simple âthingâ to latch onto, but doesnât really dig deeply into if this actually would cause the issue you described.
its pretty shallow in its âreasoningâ.
unfortunately, the only way you can stop it doing this is looking into what its telling you - look down to the ânext levelâ, find its wrong, tell it ⊠and hope it will find a new hypothesis taking the new info into account.
sometimes, after a few attempts itâll finally get it right,
but, if you are unlucky, itâll eventually circle around back to its first hypothesis, even though youâve already explained its incorrect 
anyway, back to problem at hand, when I get time, Iâll have to see if I can find a way to reproduce the issue - as without a solid reproduction, we are just into guessing why its not working (for you)
Mark â thank you for your accurate observation. I can ask Claude to explain things, but since I donât have real coding experience Iâm likely to fall into the spiral you described and fail to spot AI errors. What this exchange has made clear to me is that you have always been â and will continue to be â one of the worldâs leading programmers, deserving of respect beyond AI for your knowledge, experience, and skill. Thank you sincerely for the wonderful work you always do to support and grow the Eigenharp community!
you are way too kind 
re-reading my reply, I realised this may have come across a bit too negatively, that was not my intention, ( I was rather trying to be informative)âŠ
Id, definitely, not want to put you off, this is all cool stuffâŠ
I should, reaffirm (as Ive said previously), Im not against AI coding.
it can be a great toolâŠ
I love the fact that it lets non-programmers âgive it a goâ, removing that barrier is very cool - what you have done here, is very cool !
But as Ive mentioned before, whilst the benefits of AI are undeniable, and its quick and easy accessibility is fantastic.
there are issues, flaws and limitations, and I like to try to understand these, especially as AI is being used so widespread in so many various flaws.
personally, Ive found my understanding of its limitations within the coding realm, has meant Im little better it using it in fields Ive zero or little experience in. Its made me question its results more, find other sources to try to verify.
this way, Ive found AI can be an interesting learning tool, as Im sure you found too⊠whilst you used Claude to get help, you will have also learnt a lot about coding, and in a fun / useful way - and that is very cool!
Thank you for looking out for me. Iâm fine! 
Iâve long wanted to teach myself programming, but there are so many different languages and they interact in complex ways to make apps and services work, so as a beginner I found it hard to understand and didnât know what to focus on learning.
Claude isnât perfect yet, but when I ask about those complex interactions it explains them one by one, so as a first step it was very helpful in guiding me. However, as you pointed out, the chatâs memory feature gets less accurate over time, and if Iâm not careful I can drift far off course, so thatâs something to watch out for.
Porting the Live 12-compatible MIDI Remote Script for Livepad Agent has been my long-cherished goal over the past four to five years, so while itâs not perfect Iâm satisfied to have accomplished it.
Through this experience Iâd also like to try developing a new agent for EigenD. When I do, Iâll appreciate your advice again.
oops, this turned into a bit of a rambling postâŠ
but perhaps useful, when you come to think about âwhat nextâ
I do tend to get (over) excited about, whats possibleâŠ
but, for now, please, bask in the enjoyment and satisfaction of your successes with LiveOSC
yeah, programming is a very large field, with so many languages all have their own purposes and pros/cons.
python is a good start, as whilst its started out as a scripting language, its full featured now. so you can start simple, but move to more complex concepts.
the main thing is getting something working,
especially when you are starting out, its better to do lots of smaller working projects than some âdreamâ that you never finish
so congrats on that !
go for it, Iâll be interested to hear how you get onâŠ
there is a pretty good video from EigenLabs on youtube, about how to create agents to get started (based aroud cfilter)
note: its likely youâll need to watch previous videos in the series to get some âbackgroundâ
I will say, unfortunately, EigenD is not very ânewâ programmer friendly,
it uses a lot of different tech (mix of python, c++, generated code, its own db language), also its build system , and frankly, a lot of its code its rather convoluted.
That said, if you look at the dev video, above, it gives you a good starting point / template. plg_synth has a number of agents that were built cfilter
(cfilter is a simplified agent framework, has limitations but hides a lot of confusing bit used by underlying agent framework)
But its all possible, I built my first agent without any help for EigenLabs or other developers (or AI ;)) and it wasnât that bad.
Itâll be interesting to see how Claude (or similar) cope, as they donât know anything about EigenD, and there is no written documentation for it to learn from - but perhaps if you point it at the plg_synth agents as a starting point, it might get the general idea.
(or perhaps the dev tutorial video had some simpler for it to use as a starting point)
as a complete aside, Ive been wondering about making agent development more accessibleâŠ
in recent years, on other platforms (SSP / MetaMorph) , Ive been playing with RNBO to allow end-users to create âmodulesâ e.g. using rnbo to create vcv modules
I did consider doing something like this for EigenD, but before 3.0, I frankly thought EigenD was a bit of a dead end - hard to support, very niche etc.
rather, the better approach was to separate out the hardware layer, and then use more conventional tools on top (hence MEC, EigenLite, MetaMorph etc)
But now EigenD is on a firmer footing, I have wondered again, perhaps making agent creation simple, could open some really interesting possibilities.
as âconvolutedâ as EigenD is at times, it does have some unique features e.g. its keygroup mapping is very flexible/complex, and has a lot of important use-cases.
so perhapsâŠ
that said, for now, I will say if you want âexperimentalâ I think my MetaMorph project alongside vcv might be more âaccessibleâ for your own development with AI
AI is very knowledgeable about VCV as its well documented, so building new modules is very easy !
I also kind of revised my thinking of MetaMorph,
Originally (pre 3.0) I saw it perhaps as a replacement to EigenD, and it struggled at that, as building huge complex setup like those we have in EigenD (e.g. factory setup) was daunting, to say the least.
but now, rather I see, MetaMorph as for building unique setups that serve particular purpose, a bit more experimental a bit more unique - as that is what I find modular does well atâŠ
e.g. you dont buy eurorack or use vcv to build a conventional polyphonic subtractive synth - its more about building something âuniqueâ