Calum Vaughan

I've been working on a M4L device for somebody, and they wanted the device to display in windowed mode. This works great, as long as the user decides whether they want the device to be windowed, or not. However, they want the option to choose.

Again, this works fine, but due to the "open" message loading a new instance of the patch, the data does not remain consistent between the devices. For example, if the device is viewed in standard Ableton rack mode, I choose the number 5. I then open the floating version, and this number will not be 5. If I change it, it only effects itself - it does not effect the rack device.

 this is, but surely there must be away around it?

I decided on a workaround - if the "open message is triggered, first it should initialize the value to 0, before triggering an offset message to hide the rack version. At least this way, it resets the data to avoid confusion (and encourage the user to stick to either windowed, or regular). This works great, until I want to return to rack mode. I am struggling to find a way to initialize values in the rack version 

 the clicking of the "close" button in the windowed mode.

I've tried all sorts of solutions to no avail. I was hoping s#0_ would work, but as windowed + regular are different instances of devices, it does not. I haven't tried regular sends and receives, but its not going to work as the device needs to be on many racks + tracks at once.

In an ideal world, this initialization would not be necessary, there would be some sort of "update" message to send to bpatcher or something. I understand this logic doesnt work as we are talking about multiple instances of the same patch, but surely there's gotta be a way?

I've been working on a M4L device for somebody, and they wanted the device to display in windowed mode. This works great, as long as the  user decides whether they want the device to be windowed, or not. However, they want the option to choose. 

Again, this works fine, but due to the "open" message loading a new instance of the patch, the data does not remain consistent between the devices.  For example, if the device is viewed in standard Ableton rack mode, I choose the number 5. I then open the floating version, and this number will not be 5. If I change it, it only effects itself - it does not effect the rack device. 

I understand why this is, but surely there must be away around it? 

I decided on a workaround - if the "open message is triggered, first it should initialize the value to 0, before triggering an offset message to hide the rack version.  At least this way, it resets the data to avoid confusion (and encourage the user to stick to either windowed, or regular). This works great, until I want to return to rack mode. I am struggling to find a way to initialize values in the rack version from the clicking of the "close" button in the windowed mode.

I've tried all sorts of solutions to no avail. I was hoping s#0_ would work,  but as windowed + regular are different instances of devices, it does not. I haven't tried regular sends and receives, but its not going to work as the device needs to be on many racks + tracks at once. 

In an ideal world, this initialization would not be necessary, there would be some sort of "update" message to send to bpatcher or something. I understand this logic doesnt work as we are talking about multiple instances of the same patch, but surely there's gotta be a way? 

Hey everyone,
I've been working on a M4L device for somebody, and they wanted the device to display in windowed mode. This works great, as l

maintaining-consistency-between-windowed-bpatcher-m4l-device-and-rack-bpatcher-device-is-it-possible

For now, I found a somewhat dirty solution, but I think it's what I'm looking for. I'm using scripts to replace the bpatcher, therefore returning to initial values when either 'windowed mode' or 'regular' mode is clicked. This worked but caused a problem where my bpatcher offsets no longer worked. However, after creating scripts that connects the offset cables to bpatcher after the patcher is replaced, it works! Bit strange though, considering that the cables never seem to disconnect when viewed in Standalone, but the M4L version only works if I reconnect them. Anyway, fixed for now.

Maintaining consistency between windowed bpatcher m4l device and rack bpatcher device - is it possible?