Device map per .scs11 file name?

[jameslo]

It looks like SCS saves one and only one device map definition file (.scsd) per .scs11 file name, which means that if you have 2 cue files with the same name, even if they're in different folders, you have to share the device map. This comes up because I've somehow developed the (bad?) habit of naming all the early versions of my cue files "rehearsal", but kept in different folders for each production.

The other habit I've developed is to keep several versions of the cue file for the same show so that I can keep a history of how the show progressed. These files all have different names (because the version is in the name) and should probably all use the same device map definitions (but don't).

So it seems like I should be naming cue files by the production name only, and keep different versions of them in folders that indicate their history. Does that seem right?

Something seems off to me though. Wouldn't it be better if each machine had a set of device map definitions (that could be created and saved independently), and each cue file named the definition file it was using, and which device map within it was currently selected? Then all these naming and folder issues would go away.

[Mike Daniell]

It looks like SCS saves one and only one device map definition file (.scsd) per .scs11 file name, which means that if you have 2 cue files with the same name, even if they're in different folders, you have to share the device map. This comes up because I've somehow developed the (bad?) habit of naming all the early versions of my cue files "rehearsal", but kept in different folders for each production.

The other habit I've developed is to keep several versions of the cue file for the same show so that I can keep a history of how the show progressed. These files all have different names (because the version is in the name) and should probably all use the same device map definitions (but don't).

So it seems like I should be naming cue files by the production name only, and keep different versions of them in folders that indicate their history. Does that seem right?

That's a reasonable solution, but note that if you make changes to your devices across versions then you may not be able to load an old version successfully if it refers to a device that no longer exists in the current device map. An alternative approach is to place a version number at the end of the file name, eg save your cue file with "_V01" at the end of the name for version 1. This way you can keep all the versions in the same folder (preferably your 'production folder') and you will also get a separate device map file for each version.

Something seems off to me though. Wouldn't it be better if each machine had a set of device map definitions (that could be created and saved independently), and each cue file named the definition file it was using, and which device map within it was currently selected? Then all these naming and folder issues would go away.

When I implemented device maps I considered having one device map file per machine but that wasn't workable as different productions may need different outputs, especially for locations like an on-stage radio, etc. So that's why there are just production-specific device maps. Having a "set of device map definitions (that could be created and saved independently)" also has a potential issue. If you decide to modify one of these device maps to change the name of device or to remove a device, what happens if you then open an old cue file that uses the device name you changed or removed?

One feature I am planning is to provide for Production Templates, so when you click on 'New' you will be given the option of starting with a blank production or starting from a template. A template is basically a cue file and associated device map file that provides a starting point for building a new production. You will therefore be able to have different templates for different output requirements, but generally you would only want to keep templates for your common requirements. As the selected template is only used for setting up the new production, you can then add, change or remove devices as required for this production.

Another feature of a Production Template will be that you will be able to include other production properties such as time profiles, run-time settings, default fade time, etc, and also some cues, such as hot-key cues.

Although Production Templates are planned for a future release of SCS, I know of some users who use 'skeleton production files' to achieve the same result. So they just open one of these 'skeleton production files' with all the required production properties and hot-key cues, etc, and then the next thing they do is 'Save As' the new production file, and then start building the new production.

[jameslo]

Having a "set of device map definitions (that could be created and saved independently)" also has a potential issue. If you decide to modify one of these device maps to change the name of device or to remove a device, what happens if you then open an old cue file that uses the device name you changed or removed?

Don't you have that problem currently? Suppose I start developing the show on one machine, and then move the cue file to another. You can't guarantee that any given device exists on the new machine, right? It seems like some discipline is needed regardless.

[Mike Daniell]

Fair point. Hopefully SCS will handle any discrepancies found in a user-friendly manner.