live.button bangs on device load - how to stop it?

joshg567's icon
Max Patch
Copy patch and select New From Clipboard in Max.

When I load the device copied below or open it in the editor, the live.button connected to p togSetTimeSigD gets banged and changes the live set time sig denominator. I only want the button to bang when I touch it, of course. I haven't used live.thisdevice to force any bangs at device load and don't understand why it's happening. A cursory search didn't lead to any good resources on debugging M4L device loading. Setting Initial enable with initial as 0 in the inspector doesn't fix it.

Evan's icon

You could put a gate after the button, and open it after 100 ms or some other time delay using a live.thisdevice into a [delay 100] -> [t 1] -> [gate]

But there might be a way to just not send out bangs on device load. Not at my M4L machine at the moment, but the above should be a dirty fix.

joshg567's icon

Your suggestion unfortunately cripples the patch for some reason I can't fathom. Moot point, though:

What's weirder is that I get the time sig denominator toggle even when the live.button itself is no longer connected to p togSetTimeSigD. So, the live.button banging at device load is NOT the cause of this behavior. I'm lost for an explanation, wish I could find something good to read on this topic.

joshg567's icon

For now I'm just using live.thisdevice to bang the toggle back after a [delay 100]. I can see the live set time sig change to 8 and back to 4 when I load it now.

Irritating and hacky, but I guess it will keep me from having to remember to hit that button every time I load a set with that device in it or every time I add the device to a set. Unfortunately it still flips the toggle when I close the editor, but I don't need to do that often.

joshg567's icon
Max Patch
Copy patch and select New From Clipboard in Max.

Here's the full context:

joshg567's icon

Follow up: I can avoid this behavior by passing arguments to live.path via messagebox, rather than specifying the arguments in the live.path object itself. The latter will cause automatic bangs downstream anytime the device is loaded. Peculiar.

Jay Walker's icon

Hello! Has anyone figured out a good solution for not having live.buttons trigger every time you load ableton or max? If buttons are triggered behind the scenes like this, imo it's buggy behavior.

Davidson Audio & Multimedia's icon

Should be able to just remove scripting name and turn off initial enable check box in the inspector. Save the patch and open, counter shows zero.

Max Patch
Copy patch and select New From Clipboard in Max.

Jay Walker's icon

Hey Davidson thank you for the tip! I ran into kind of a major max4live meltdown which is currently unresolved and I thought it had to do with not assigning script names. Is there any danger in that approach?

Davidson Audio & Multimedia's icon

Hi Jay, scripting names are typically used to reference an object. So for example the object [pvar], say you are sending from pvar to an object with a script name hello the object would have to have the scripting name "hello" and pvar object would be [pvar hello]. Or alternatively if you use pattrstorage and autopattr for your preset system any objects that have a scripting name would be added to pattrstorage. On load up or preset change any object with a scripting name would send out the saved value.

So if you gave a scripting name to a button on load or preset change that button would trigger. I typically never give scripting names to buttons. Usually I just use scripting names for pvar receive objects and gui controls I want saved in the pattrstorage object. So in the patch Josh posted above probably the reason the live buttons trigger is because of parameter settings or that the live buttons have a scripting name linked to pattrstorage.

The button shouldn't trigger if no pattrstorage is present however it is the reason I think that is happening is because of the scripting name. Script messages to this patcher and JS also use scripting names to reference objects.

This post may explain a little more about scripting names and live gui controls. https://cycling74.com/forums/new-live-objects-and-scripting-name

Hope this helps Jay.

Jay Walker's icon

Thanks this is perfectly clear and awesome info. Totally solves my problem, thanks a ton!!

Davidson Audio & Multimedia's icon

Great to hear Jay glad I could help out a bit.

Jay Walker's icon

I tested the counter example and that worked just fine, but for some reason, behavior is inconsistent. I've deleted the scripting name and unchecked initial enable. However I'm getting a bang when opening and closing m4l devices if opened from live (similar to Josh's problem of getting bang on closing the editor). I found that live.text bangs every time too, regardless of initial enable. However, normal live.buttons bang too, and I can't replicate it! Maybe I have too many buttons? I may contact support (don't know if live or cycling74), but if someone has any ideas on what's going on, please let me know! Here's a demo of the live.text bang.. The JS in the patch (just in case it's not included:

outlets = 1;

function test(bang){
    post('this function has been triggered');
    var output = number;
    outlet(0,bang);
    }

Max Patch
Copy patch and select New From Clipboard in Max.

Davidson Audio & Multimedia's icon

I don't have Live to test but Max7 the patch opens without triggering the counter. Try this Jay it is a loadbang varname trick might work.

Max Patch
Copy patch and select New From Clipboard in Max.

outlets = 1;

function test(bang){
    post('this function has been triggered');
    var output = number;
    outlet(0,bang);
    }

Jay Walker's icon

Hey Davidson, I just wanted to follow-up with you on what I found and thank you for helping me! I wrote support and sent in an enhancement request. I was trying to push a button with a single trigger message (as opposed to two, like a mouse up/mouse down). I set the bang behavior to "Both" so that any time the button is triggered with a single message, it reacts. Unfortunately, even though I achieved this functionality, buttons still toggle between "on" and "off". The behavior I wanted was consistent bangs on single trigger messages like midi or keystrokes, but if the button happened to be "blue"/"enabled" on closing or opening the device, it would bang. I didn't notice this until I looked at the device itself and saw blue and gray buttons even though I expected the behavior "Both" to be consistent on that end as well.

It might be possible to move away from buttons and listen for midi messages directly in javascript, although there's a limitation of ableton with CC messages and channel information being sent to max. Kind of a small problem but those mysterious bangs made the device a bit unpredictable. Hope you're having a great week and thank you again!

Davidson Audio & Multimedia's icon

Glad you are making progress I have had similar issues like this but seem to find a work around eventually. Ultimately depending on your motivation you can code a custom external object for mac and pc that performs the function you need. If you can't code it yourself there are some freelance coders that could make them for a fee. I am trying to get everything setup to make externals on mac and pc it is a bit of a chore. I think once setup it may be easier to produce these simple type externals.