yellotron

Hello. I have recently succeeded in writing and implementing a rather large jitter patcher that uses M4L buttons and sliders for its presentation in a Live set. It works and I can perform with it. The problem is that now my undo history is clogged or damaged in some way. Very quickly after I start using the set, the undo gets stuck on "change live.slider[2]". No matter what actions I take in the set, this is what is listed in the undo menu item. I've never seen this before, and it is giving me practical difficulties.

macbook pro, 2.4 ghz, intel, osx 10.5.8, 4 gig ram, M4L using Max 5.1.8

Hello.  I have recently succeeded in writing and implementing a rather large jitter patcher that uses M4L buttons and sliders for its presentation in a Live set.  It works and I can perform with it.  The problem is that now my undo history is clogged or damaged in some way.  Very quickly after I start using the set, the undo gets stuck on "change live.slider[2]".  No matter what actions I take in the set, this is what is listed in the undo menu item.   I've never seen this before, and it is giving me practical difficulties.  

macbook pro, 2.4 ghz, intel, osx 10.5.8, 4 gig ram,  M4L using Max 5.1.8


undo-history-gets-stuck-with-m4l-jitter-patcher

it sounds like you are writing a massive amount of data to a live.object (like an lfo or similar plugged in to it). for assignments that constantly update or change you need to use live.remote~ instead, as live.object writes to the undo queue.

that is only a guess. without seeing patch cannot say much more.

Thanks. I don't know about live.remote~. I'll investigate. Here's the code incase you have a chance to look at it.

Thanks.  I don't know about live.remote~.  I'll investigate.  Here's the code incase you have a chance to look at it.  

well, it is quite hard to tell as it is quite a big patch and a bit messy. but, some thoughts...

first of all, you do not have any live.object-s in your patch, so it cannot be that as i had mentioned before.

second, you need to look into all your right-to-left ordering and check it all really is as you expect - with cables all over the place it is hard to tell.

if any of those live.buttons are for display only (i.e., just to show you something happening) then you need to set them to "Hidden" in the inspector. at the moment everything is "Automated and Stored" - are you sure you meant that? - they will be added to the undo queue i think.

on that note, if you do need all these live.gui objects to be 'automated and stored', you need to look into the "Defer Automation Output" and "Update Limit (ms)" options in the inspector - these make a massive difference. it is a bit like what 'qmetro' and '@unique 1' are in jitter.

also, i see you are using global send/receives, and i cannot see why. this means that if you have more than one version of this device in a live set all controls will refer to all devices globally - a problem. you need to make all your s/r's names prepended with "---" to make them unique. unless you DO want set-wide global sends etc?

but frankly, i cannot see where, from a brief look at this patch, you would be drastically filling up the undo queue, unless, in your set, you are driving some of you live.sliders, for example, with an lfo of some sort. (if so, you need to look into "live.param").

i see you are using quite a few shader files. of course that would be a huge bottleneck unless you have a high quality GPU. but judging by your patch i am sure you know that. i am not an expert in using opengl stuff within the ableton-live context, but this should not be an issue.

The live buttons are there in order to present something in Live's window that enables me to map midi cc's into the patch to load videos and control faders. I suppose I do not need to see the buttons (is this what you mean by "for display only"?) and so perhaps I could Hide them. I have Defer Automation Output unchecked for these buttons because it's the only way I could get them to work as triggers in Live. Otherwise they seem to act as toggles and this behavior cause them not to work at all. (This issue is so vexing and strange that it makes me think I'm missing something big and obvious.)

I will look into Update Limit; I don't know what it does or means.

I do control sliders in this patch. The faders are triggered via the live.buttons. I hit a footswitch on FCB1010, it triggers a live.button, which sends a bang to one of the two fader systems in the patch. Perhaps this is the source of the undo clog. I will look into live.param. I don't understand it yet.

The live buttons are there in order to present something in Live's window that enables me to map midi cc's into the patch to load videos and control faders.  I suppose I do not need to see the buttons (is this what you mean by "for display only"?) and so perhaps I could Hide them.  I have Defer Automation Output unchecked for these buttons because it's the only way I could get them to work as triggers in Live.  Otherwise they seem to act as toggles and this behavior cause them not to work at all.  (This issue is so vexing and strange that it makes me think I'm missing something big and obvious.)

I will look into Update Limit; I don't know what it does or means.  

I do control sliders in this patch.  The faders are triggered via the live.buttons.  I hit a footswitch on FCB1010, it triggers a live.button, which sends a bang to one of the two fader systems in the patch.  Perhaps this is the source of the undo clog.  I will look into live.param.  I don't understand it yet.


As pid mentioned, something of your patch fills the undo history. For example put a "change" object between the "r mainline" and "line 0 50". So it will trigger the "line 0 50" only when the trigger value changes. Hope that helps.

I know this is an old thread, but I'm having a similar issue (albeit with a much simpler patch). Essentially it seems like the live.slider devices (in the "Master" patch) are absolutely blowing up my undo history (to the extent that I believe it was causing crashes in the 32-bit version of Live). As far as I can tell, Update Limit only applies to automated values so I'm not sure that would help. The "Slave" patch just goes on individual channels and I don't believe it's part of the issue but I thought I'd include it for completeness. Any help would be much appreciated.

I know this is an old thread, but I'm having a similar issue (albeit with a much simpler patch).  Essentially it seems like the live.slider devices (in the "Master" patch) are absolutely blowing up my undo history (to the extent that I believe it was causing crashes in the 32-bit version of Live).  As far as I can tell, Update Limit only applies to automated values so I'm not sure that would help.  The "Slave" patch just goes on individual channels and I don't believe it's part of the issue but I thought I'd include it for completeness.  Any help would be much appreciated.

Undo history gets stuck with M4L jitter patcher