Marc Assenmacher

I am having this weird problem, that everything inside of a bpatcher opened with pcontol starts bugging after changing the selected track in Ableton. Opening the same content from a patcher does not make any problems.

pcontrol_Test.amxd

pcontrol_Test_bpatcher.maxpat

Any help/articles/information is appreciated!

------------------------------------------------------------------------ 

Add test device to a track in Ableton Live

patcher dial works, bpatcher dial does not work anymore

If yes, is it more likely a bug or is there an explanation and fix for this issue?

------------------------------------------------------------------------ 
Apple M1 Max
maxOS Monterey 12.6.5
Ableton Live 11.3.4
Max 8.5.4 (Full Version)

Hello,
I am having this weird problem, that everything inside of a bpatcher opened with pcontol starts bugging after changing the selected ... 

pcontrol-bpacther-bug-while-changing-selected-track

I found a workaround putting the bpatcher inside of a patcher. Still this doesn't seem right to me.

Although I found a workaround I would like to report this, if someone else can confirm this behaviour.

I only see one dial in the .amxd when I open the window, and none in the device view. It seems to work okay when I switch tracks. But I'm really not clear on what I'm supposed to be observing.

Is this one of these "I want the same UI to be visible and usable in both the device view and a separate window" kinds of things? If so I would never trust those to work in Ableton the way they do in Max.

I'd suspect there is "magic" happening between Ableton/Max where Ableton lets Max devices know when they should be redrawing/updating their UI / able to respond to user interaction (mouse/keyboard). If you have a portion of a device visible in two places at once (bpatcher in the Device View, and opened as a window), then Ableton is probably telling the Device View one it is not visible and shouldn't respond to user events when it's Track isn't selected or visible. And since the window one and Device view [I'm guessing] share the same memory that flag applies to both of them.

(It would be interesting to know how collapsing the device view or stuffing it in a Device Rack or Chain affects this, since changing Track isn't the only way to make a device "hidden" from the view).

In this case I'd guess your workaround works because, since the bpatcher is buried in a patcher and not normally visible in the DeviceView, Ableton/Max is not paying attention to that bpatcher view as something that needs to be drawn on the screen. But in that case why not skip the bpatcher part.

If you do want to have "clone ui" in device view and a window it's pretty easy to do using pattr objects with @bindto. Or if you're comfortable with Javascript to use MaxobjListener to get different objects to share values. The trick with both is to make sure, if you're Automating controls, that you're careful about how the values get "round-tripped" between the views, so that you can still record and playback parameter automation.

I only see one dial in the .amxd when I open the window, and none in the device view.  It seems to work okay when I switch tracks.  But I'm really not clear on what I'm supposed to be observing.

Is this one of these "I want the same UI to be visible and usable in both the device view and a separate window" kinds of things?  If so I would never trust those to work in Ableton the way they do in Max.  


<being speculation>

I'd suspect there is "magic" happening between Ableton/Max where Ableton lets Max devices know when they should be redrawing/updating their UI / able to respond to user interaction (mouse/keyboard).  If you have a portion of a device visible in two places at once (bpatcher in the Device View, and opened as a window), then Ableton is probably telling the Device View one it is not visible and shouldn't respond to user events when it's Track isn't selected or visible.  And since the window one and Device view [I'm guessing] share the same memory that flag applies to both of them.  

In this case I'd guess your workaround works because, since the bpatcher is buried in a patcher and not normally visible in the DeviceView, Ableton/Max is not paying attention to that bpatcher view as something that needs to be drawn on the screen.  But in that case why not skip the bpatcher part.


If you do want to have "clone ui" in device view and a window it's pretty easy to do using pattr objects with @bindto.  Or if you're comfortable with Javascript to use MaxobjListener to get different objects to share values.  The trick with both is to make sure, if you're Automating controls, that you're careful about how the values get "round-tripped" between the views, so that you can still record and playback parameter automation.

Tyler is correct. When all (boxed) views of a bpatcher are closed/hidden, UI objects are not updated anymore. And a bpatcher view in a window is not officially registered as an opened view. The fact that you can still open the bpatcher in a window is a kind of easteregg in Max or C74 forgot to block this.

Interesting. I kind of get it now. So I hope this behaviour will stay the same so my workaround will continue to work.

I don't think pattrstorage will work for me since I am having one device to control hundreds of devices and rack macros all over my Live set and I target them over the current track ID.

I bet javascript could help me out, but I haven't got into coding yet.

pcontrol bpatcher bug while changing selected track