System Configuration - Scopes | MUSE
In this video, you’ll be introduced to scopes on an AMX MUSE controller and how they help organize devices and scripts across multiple spaces. We’ll walk through creating scopes, structuring them in a hierarchy, and referencing devices using intuitive dot notation. You’ll also learn when it makes sense to use scopes versus keeping everything in the Global scope. By the end, you’ll understand how to maintain a clean, scalable system design for larger and more complex deployments.
What You’ll Learn:
• What scopes are and why they matter in MUSE
• Creating and organizing scopes in a hierarchy
• Referencing devices using dot notation
• Structuring systems for better readability and scalability
• When to use scopes vs. the Global scope
• Best practices for managing larger MUSE deployments
Hello, and welcome to this video on Scopes in your MUSE controller. The scopes page is where scopes and devices are created on the controller. Scopes are a way to organize scripts and devices in your controller, usually based on rooms.
Scopes help logically organize devices and scripts into groups, but adding extra scopes may not be necessary in every installation. Many installations will only utilize the Global scope. However, since MUSE controllers can be used to control multiple spaces, it’s important to keep everything well organized when necessary.
To create a new scope, click the plus button next to the name of the scope you would like to create it under. For this example, we will create a scope under Global. Click the Add Scope button in the Add Item to Global popup box. Type in the Name of the scope you would like to create, in this case we are going to use NewYork. A friendly description for the scope can also be added. Press the Accept button at the bottom right. You should now see the NewYork scope listed under Global.
Scopes are broken out in a layered tree structure with the Global scope as the ‘root’. When referencing devices or scripts in a scope, we use a dot notation to access those devices programmatically. Any device or script that is located in the same scope as your program can be referenced by the base name of the device alone. Devices that are located outside of the scope are referenced by the format scope.sub-scope.device.
For example, if we were referencing a touch panel named dvTP that is located in a scope named NewYork and a sub-scope named Saratoga, the full name of the device would be NewYork.Saratoga.dvTP. When the device is created in that scope, you can look at your controller in VSCode and see the full name of the device listed in the Devices section of the controller.
Something to note is that there isn’t actually a scope named Global. Any device or script located in the Global scope does not have a Global prefix to it. Devices in the Global scope are simply referenced by their base name.
The last thing to mention about scopes is how they work with Automator. Since only one project of Automator is able to run on the controller at a time, the Automator project is always loaded to the Global scope. This cannot be changed. However, this does not affect communication; devices can still be accessed in other scopes.