[In 11.4.0] Proposed Device Map changes

[Mike Daniell]

A concern that has been raised with me occasionally is that when you transfer a production to a different computer (eg from home computer to theatre computer) you may need to re-enter certain 'device map' fields, such as cue control parameters. To address this issue I am moving many of the 'device map' fields into the cue file, the intention being to keep only machine-specific data in a 'device map' for that production on each computer.

Here's a sample screenshot of the new Cue Control Devices tab in Production properties:

Cue Control Devices

CueCtrlDevsR.jpg (61.59 KiB) Viewed 1000 times

Previously this tab also displayed the selected Device Map, but that field has been removed from this tab (and also some other tabs) because with this proposed change the Cue Control Devices are set once only for the production and machine, so are independent of any device map selection - although more of that later.

You will also notice that the MIDI In Port has a different background color to the rest of the screen. This background color is common throughout these changes to Production Properties Devices and identifies the only properties that are held on each machine. All other properties are now held in the cue file so are common to all machines on which this production will be run. (I will also wrap that color around the Physical Device and Active fields in the upper part of this tab.)

When you set up your production on your 'design computer' you should set up all your device properties, including the Cue Control device properties. As these will now be saved in the cue file then when you copy this cue file to another computer, the only Cue Control device property you may need to set or change on the target computer will be the MIDI In Port (or similar property for other device types).

Similar changes are being made to the Control Send Devices tab.

The Audio Output Devices tab is also similar but I am proposing to remove all references to 'Device Maps' as shown here:

Audio Devices

AudioDevs2R.jpg (52.06 KiB) Viewed 1000 times

As you can see, this is a 'work in progress'. I plan to remove the 'Device Map' field and the associated save/rename/delete buttons. As per the color convention of the other tabs, the new background color around Audio Driver, Physical Device, etc indicate that these fields will be saved on the current machine (for this production). However, although there will no longer be separate Device Maps, SCS will effectively save a 'device map' per selected Audio Driver. So you set up your preferred physical devices and outputs, etc for DirectSound and have a separate selection of physical devices, outputs, etc for ASIO (using BASS) and ASIO (using SM-S). So you can switch Audio Driver as required and SCS will remember the relevant physical devices, outputs, etc for each selection.

All of the above changes are designed to make it easier to transfer your productions between computers whilst retaining all the functionality you need. I welcome your comments on the above, especially any problems you can identify.

[Buyaicia]

I use "audio output devices" and "send control devices" only.
I understand that if I set outputs A1 to A8 for a cue in the project, when I open the project in an other computer, SCS assigns the physical outputs defined in the device map. This is a good way (something similar is used in Cubase and it works fine)

But, I use sometimes an internal audio device sometimes an external audio device.
If I change the “Audio driver” physical device assignments will it be recovered?
Device maps will be helpful to switch between physical device configurations, may be.
Example:
In the theatre computer with an external device that has a lot of outputs I wish to send A1 (front) to Out 1-2 and A2 (rear) to Out 3-4.
In my laptop with internal audio device only (two output ports), I wish to be able to send A1 and A2 to the same Out.
But if I connect an external device output to the laptop, as soon I change the audio driver (or the device map) the physical outputs should be assigned accordingly.

[Mike Daniell]

In the theatre computer with an external device that has a lot of outputs I wish to send A1 (front) to Out 1-2 and A2 (rear) to Out 3-4.
In my laptop with internal audio device only (two output ports), I wish to be able to send A1 and A2 to the same Out.

The proposed change of removing the 'Device Map' field will handle this situation because on the theatre computer you will specify "send A1 (front) to Out 1-2 and A2 (rear) to Out 3-4" but on your laptop with internal audio device only you will specify "send A1 and A2 to the same Out".

But if I connect an external device output to the laptop, as soon I change the audio driver (or the device map) the physical outputs should be assigned accordingly.

The proposed change would not handle this situation unless you also changed driver - eg DirectSound when using the internal audio device, but ASIO when using the external device. If you want to use, say, DirectSound for both scenarios (internal or external device) then this is an argument for retaining separate Device Maps for Audio Output Devices. That's probably a good enough reason to retain this particular feature.

[dbn]

A concern that has been raised with me occasionally is that when you transfer a production to a different computer (eg from home computer to theatre computer) you may need to re-enter certain 'device map' fields, such as cue control parameters. To address this issue I am moving many of the 'device map' fields into the cue file, the intention being to keep only machine-specific data in a 'device map' for that production on each computer.

From a software architecture perspective, such a "separation of concerns" approach is highly appropriate. I'll preface my comments by admitting that I know next to nothing about the details of the MS Windows device driver architecture. I'm a networking protocols and security guy. Having said that, I think it's fair to say that MOST of the "device drivers" that an application such as SCS will use are in fact APIs to a system service or a layered device driver framework. ASIO breaks that model in that it bypasses the standard Windows device driver layering. However, the traditional notion of device driver is a low level module of software, usually running in kernel space of the operating system, that maps a standard system API onto the unique hardware of a particular model of device. Thus, device drivers have traditionally been device model specific, and provided by the device manufacturer. There are also hardware interface standards, so it's possible that a single device driver may work with many models and brands of hardware. Even so, there are going to be basic differences between bus based devices and external (e.g., USB or FireWire) based devices. And we also have the device driver hierarchy architecture, in which "class drivers" sit atop hardware specific drivers to provide a common API to systems services and applications.

So, what does all that have to do with the question at hand? In a nutshell, if the device driver that's exposed in the Properties Screen of the Cue Editor is a "class driver" it almost certainly won't have a one-to-one mapping with a hardware device. That means a Device Map will still be required to select a specific hardware interface. If some device drivers are bound closely to hardware and some are really system APIs, then it will be difficult to obtain a consistent user experience with selecting devices from the Properties Screen of the Cue Editor. I think the design problem is in identifying which are the truly machine-specific parameters. I think that will vary based on which driver architecture is chosen. That variability will make it harder to achieve a truly consistent user experience. Exception cases tend to drive us nuts.

I often prepare shows on the home or editing computer and then port the cue file to the computer at the theatre. Like others, I have different interfaces on those machines. I have a two channel, bus based interface on the editing computer and two four channel bus based interfaces on the theatre computer. There are also occasions on which I will choose to use a USB based external interface. So the problem that the Device Map was originally intended to solve is still germane.

There is probably no solution that will optimize the user experience for everyone, given the variations in system gear. The best I can suggest is to use the design principle of "least surprise". In other words, make it clear in all cases when selection of a device driver will change the hardware device allocation and when it won't. Any parameters that are clearly device-independent are obvious candidates to be moved out of the Device Map. Sadly, I'm not in a good position to be able to advise as to where the unexpected corner cases may lie. Maybe someone with a solid understanding of the MS Windows Device Driver Framework, and other APIs, such as ASIO, can contribute some better advice.

Thanks for soliciting user input on this issue. You rock!

[jmgordon]

From a quick reading I am not sure how my methods of working will be affected.

I am using SCS in two scenarios - 1. Providing simple musical illustrations for lectures, 2. Creating more complicated multi-output sound schemes for plays. In both cases the show is prepared in my desktop design machine and transferred to a laptop for playback.

1. The cue file is prepared in the desktop using its internal onboard sound chip. It is then transferred to the laptop where playback is checked through the audio (headphone) output using the onboard sound chip. For playback through the lecture PA I make use of its integral optical output (to avoid interference from the PSU). The option to select this as an output is only available in the laptop and requires a changed device map.

2. For shows the cue file is initially plotted using the internal onboard sound chip, with various channels all plotted to the same physical stereo pair. Approaching show time I connect my M-Audio Firewire 410 and replot the channels to their appropriate outputs. The cue file is transferred to the laptop. With the M-Audio connected (my Vaio has FireWire) SCS usually finds the device and the outputs automatically. Sometimes I have to deliberately select them with the device map.

At the moment I always use DirectSound.

I guess I am in the same situation as Buyaicia?