There are two basic items which make the SideBoard work differently than it does "out of the box":

• Network settings - if you have changed the network settings from their default then you can use the GP / SideBoard GUI to change the settings back - there is no "button" or quick reset to do this

• Scripts - From the factory the SideBoard runs a script that defines the main button functions while leaving the programmable buttons undefined, so to revert to the settings "from the factory," irrespective of your network settings, you need to use the Sideboard GUI to load the default script, which can be found (assuming the GUI was installed in the default location) at:

C:Program Files (x86)WheatstoneWheatNetIpGp16pGuibinscriptsexamplessideboard4chdefault.sb4ss (for a 4 fader unit)

C:Program Files (x86)WheatstoneWheatNetIpGp16pGuibinscriptsexamplessideboard8chdefault.sb8ss (for an 8 fader unit)

So, depending upon which of these you've changed, perform the indicated operations via the GUI to achieve factory normal status.

There is no built-in functionality for interrupting the SideBoard headphone feed with a talkback or IFB signal, but one way to do this is by using a script. The SideBoard, once added to Peripheral Devices tab in Navigator, has a destination for the headphone jack audio stream. The destination is on the Blade that's hosting that SideBoard. Its default name is SBrdHdpn. A script that interrupts that headphone destination with a talkback signal would need to route the talkback audio to the headphone destination at the start of talkback and then reroute the audio that had been feeding the headphones back to the headphones at the end of talkback. Depending upon what action needs to be taken to trigger the talkback you could also configure a Control Surface programmable button to make a Momentary Connection to do this same action. Another option would be to use a push button switch wired to a logic input port on a Blade and program that port to make a Momentary Connection while it is held.

What kind of audio files do you have? If they're in VoxPro Wave format which uses a .vpw suffix, then they're compatible with current versions of VoxPro. If that is the case, they're also "RIFF wave" files so you could rename the file extension to .wav and then use any Windows audio app to play them. The one caveat: what you'll hear is the original recording without any of the edits which may have been made to the file using VoxPro.

If they are the older Mac format, which was also used by VoxPro 3 on Win98 and WinXP then you'll have separate mono files for the left and right channels without a standard header. The only way to read these is to use an older app like CoolEdit or Audacity which allows you to import files in "raw" format. This would be a slow and painstaking process to import the separate left and right channels this way but you could then use the apps to export a "mix" to a single stereo wave format file.

VoxPro networking depends on Windows remote access and sharing protocols. If a remote machine is inaccessible through Windows (e.g. File Explorer) then it will also be inaccessible through VoxPro. There are three basic conditions for remote access: the folder must be shared to the network; all users must have full read/write permission; and the folder must be accessible without requiring login credentials (i.e. no username, no password).  

Pages 12-17 of the VoxPro Admin Guide, which you can access through VoxPro's Help menu, describes VoxPro Network Configuration and Diagnostics, followed by File Sharing and Remote Access.

This networking troubleshooting guide will also help you. 

You may connect up to four controllers to the same PC. Since they'll all be active at all times, your crew will need to work out a way to coordinate actions and not step all over each other.

Copy all of the user accounts and their audio files first. On your old PC, copy the Users_Local.inf file, in C:UsersPublicVoxPro, into a folder in the same location on the new PC. This is the file VP uses to know who your users are and where their accounts live. It's a text file that you can view using NotePad to make sure the information is correct. Change anything that isn't. Save the file, then start VoxPro.

Is the remote hardwired to the control panel's DB9 connector, or does the play command come over the WNIP network from a Blade logic interface? If you are using the control panel logic, please note that an option for disabling remote control was added in VP6. To reach that setting go to: Settings > Disable Remote Controller... Make sure the remote logic you want to use is not checked here, disabling it. Note that these settings can be different for each VoxPro user.

This document covers al l aspects of the VoxPro controller operation and has a test application you can download and use to test the connection.

We do see this from time-to-time, but fortunately it's a relatively easy fix. There's an optical sensor, under the wheel, which has gotten jolted out of alignment (dropping the controller is a good way of causing that) and that's most likely why the scrubbing is not working right. 

Carefully remove the controller's top cover (note that it's a tight fit) to expose the underside of the jog wheel. You'll see a thin disk with slits around the edge, and a small sensor on a thin metal bracket. This sensor must squarely straddle the wheel so it receives light thru the slits. Use your pinky to gently nudge it back into place. You can keep the controller plugged in during this operation so you can spin the wheel to verify proper operation before reassembling the controller.

Contact: JL Cooper in El Segundo, CA. They are the OEM and handle all repairs and parts. Note that they only work on controllers which are less than seven years old. If you have an older controller, replacement parts are available so you can service it yourself. Button switches and encoder parts are relatively easy to replace, but if your unit can't connect to the PC and the cabling is not the issue, then it may be time to replace the controller.

There's a JL Cooper RMA Form (controlpanel_rma_instructions.pdf) that you can fill out and email them to get an RA # so you can send in a controller for service. If you'd rather do the work yourself, there's a field replaceable parts list (voxpro_control_panel_parts.pdf). You order parts using a JL Cooper parts order form (parts_order_form_voxpro.pdf). 

VoxPro maintains a configuration folder in C:UsersPublicVoxPro with a file named Users_Local.inf if you've created VoxPro user accounts and are not just using the generic Admin and Guest accounts. The Users_Local file is a text-only file which can be viewed using WordPad or Notepad. The file lists the full paths to the users' various account folders.

By default, VoxPro accounts are saved in C:UsersPublicVoxProVP_Depot so probably the easiest approach is to copy this entire folder into the same folder location on the new computer. When User accounts are used, the Users_Local.inf file tells VoxPro where the various user accounts are actually located so you can edit that file to add, remove, rename, or move user account folders.  

For more details about all of this, here's a link to get the Managing VoxPro User Accounts white paper

The VP7 Admin Guide is another good source for this type of information. You'll find a link to it under Help in VoxPro.

Most antivirus programs have a way to whitelist applications. You may need to do that with the HASP driver installer (haspdinst.exe) and all executables in the VoxPro installation folder. CDM 2.04.16 is the control panel driver installer. VPVC.exe is a utility used for converting audio files from VoxPro3.X to VoxPro4 and later. FTD2XX.DLL is the module VoxPro uses to talk to the control panel. DSETUP.DLL is a Microsoft DLL used to query DirectX audio functions. Since we've not heard from other VP4 users that anything out of the ordinary was required to get it to run on Win10, other than installing the newer HASP driver, it does not appear you will typically have to go to extremes with whitelisting the VP apps.

In Windows 10 and above, if there is no microphone plugged into an input on some sound cards (especially the sound card built into the motherboard), it doesn't appear in the Windows Sound Control Panel. 

If there is no available record input in the Windows sound control panel, then VoxPro can't finish its setup process to open and throws the error.

Professional and prosumer cards generally won't do this, but "Sound Blaster" style cards will. Plug in a microphone, wait for a record input to appear in the Windows Sound Control Panel, and then VoxPro can open.

Also, make sure that Microphone Privacy is turned on in Windows 10 and 11 and that Windows has been set to "Allow desktop apps to use your microphone." See this Windows Support article for more information.  

That error indicates that the audio capture device assigned in VoxPro is not working properly. This may mean that the driver for the audio card on that PC was not loaded or is not compatible with Windows, if it did an update. Is this a Windows 10/11 PC? If so, it could also mean that Windows changed the “mic access” setting on VoxPro so it’s now not allowing VP to create a record buffer. 

If you have “<Default Windows Capture Device>” selected in VoxPro (look at Settings > Audio Devices and Format… window, see attached Default Windows Capture Device screenshot) then you could select a different input source in the Sounds Control Panel, or change the selected source in the Audio Devices window, then try recording. If you don’t get an error using the alternate source then it’s most likely a driver issue for the audio input that was selected.

If you still get a record buffer error even when using a mic or line input on the PC, and it’s a WIN 10 PC, then most likely it’s a “Mic Privacy” settings issue. Go to the Mic Privacy Control Panel

Click in the Windows search bar and type Microphone Privacy and pick Microphone Privacy Settings.

Look first up top for the master switch that says Microphone Access and make sure that is set to On.

Then scroll down to where it says "Let Desktop Apps use your microphone and make sure that's On. You will see VoxPro in the list of desktop apps below. 

If you're using an audio driver for streaming audio to a WNIP system, also check your sample rate settings on each record and play channel since a Windows update can change those to 48k, and most radio users' systems use 44k.

Another change that occurred with Windows 10: If nothing’s plugged into an AUDIO INPUT then that audio input device does not exist, so check that you have something plugged into the selected audio input, otherwise that input will not be available as an audio input device. See if, with an active audio signal connected to the selected audio input, VP can then do a recording.

The “object reference” error indicates that some Windows function (a counter, file size, etc.) exceeded a maximum limit. It was nice that Windows displayed a polite message rather than simply crashing VoxPro! The theoretical maximum length of a Windows wave file is around 4 hours, so recording a lengthy file, even if it was two hours long, should not have caused any issues but it just as easily could indicate the hard disk become full as well.

For your information, here’s the process that occurs when you start a new VoxPro recording: 

1. A 512KB file is created to hold the RIFF wave file headers and our proprietary header information, which stores editing data including a history of all edits done to that file, so most of that file is empty when you start a recording. 

2. A relatively small buffer is setup in RAM to hold incoming audio so it can then be transferred to the disk in chunks of data.  

3. As the RAM record buffer fills up, the audio gets transferred to the record file on the hard drive, being continuously appended to the end of the record file so that the record file continues to grow in size dynamically until stop is pressed.

VoxPro has supported Axia GPIOs since VP5. If the Livewire driver is installed then you should see an Axia GPIO configuration command in the Administrator's Settings menu. Contact Axia support if you need assistance setting up their logic.

On the existing VP PC, you’ll find a file in C:UsersPublicVoxPro called Users_Local.inf. This is a text file that’s opened using Notepad or Wordpad. It contains a list of the full paths to every user’s account. By default, the accounts are saved in C:UsersPublicVoxProVP_Depot but they can be saved anywhere, including on a secondary drive or network drive. So, for the simplest case: copy all the audio files to the new PC putting them into the same folder locations, and then copy the Users_Local.inf file as is. If you want to make any changes to your user list (delete users, add users, move them, rename them, etc.) then make the appropriate changes to the Users_Local.inf file. As to file locations, the first thing VoxPro does when it starts is to read the Users_Local.inf file, which tells it which user accounts exist and where they live.

See this document for more information

VoxPro does not offer a software license. Let’s start by getting the latest Keylok driver:

Go to https://www.keylok.com/support/install-utility-download and download Install.exe

Follow the instructions in the setup; it will prompt you when to install the dongle.

In the Dongle Type section check KEYLOK 2 (USB w/Driver). In the Installation Type section select Standalone.

After installing the driver, the driver will validate. 

In Windows 11, Windows Memory Integrity can prevent the Keylok driver from loading. If this happens, even with the latest Keylok driver installed, the USB key will have a caution sign in device manager and Windows will throw a pop-up saying a security setting prevented a driver from loading. To fix go to Windows Security, then go to Core Isolation, and turn Memory Integrity off. Reboot. The driver will load. 

That's why we use UDP broadcast. The VoxPro machines don't need to know about each other. They just need to be on the same LAN. The same mechanism is used to exchange user lists. When VoxPro is started it sends out a broadcast message containing the UNC paths to user accounts which it "owns" (i.e., were created on that machine). Other VoxPros on the LAN receive that message and respond with their own user lists. Thus the folder C:UsersPublicVoxPro is populated with files in the form of Users_<remoteMachine>.inf as each VP on the network sends out its list and receives others in return. A good test of the network is to delete all of these files EXCEPT Users_Local.inf, then restart VoxPro. As the user list from each VP on the LAN is received and written to the folder, you have confirmed two-way communication with that machine. It doesn't necessarily guarantee that you have write permission into those folders, but that's another issue...

For our users only Delilah is doing this. I'm going to hazard a guess that if Windows allows you to access the mapped drive without, for example, prompting you for credentials, then VoxPro will also have no problem accessing it. Be aware that VoxPro looks in this file: C:UsersPublicVoxProUsers_Local.inf for the location of user account folders. These may be mapped drives or network locations with valid UNC paths. Note that we recommend keeping the Admin and Guest accounts on the local C: drive so that they're available when the network or external drive is nto available. There's a diagnostic tool in Settings/VoxProNetwork that displays network paths to accounts. It also warns you if no valid path exists. Note: You must be logged in as Admin to access that menu item.

All in all running VoxPro over a VPN is not too tricky. The main thing is to enable NetBIOS at both ends (Firewall rule for 33333). Setup as usual just map the network drive via IP address then add the user from the mapped drive.

The folder containing each VoxPro user account must be shared to the network, and it must set for user access permissions. This allows other users on the network to read and write ("full control" in Windows parlance) to that folder without having to supply user credentials (e.g., name and password) in order to access that location.

Win10 has made it relatively easy to share and access the VoxPro folder at C:UsersPublic, which is why this is the default location of the VoxPro configuration folder (C:UsersPublicVoxPro) and the user accounts (C:UsersPublicVoxProVP_Depot<user name>). It's usually sufficient to share just the C:UsersPublic folder, since that will automatically share everything under it.

To enable networking in VoxPro you must log into the Admin account on each machine that you want to join the network. View Settings > VoxProNetwork and verify it's enabled on each PC. You can also enable/disable connections to individual VoxPro workstations on the network from this dialog box. It also contains a very useful diagnostic tool that shows if your shared accounts actually have a valid UNC path.

Keep in mind: Admin and Guest accounts on each VoxPro machine are NEVER shared. Only "normal user" accounts other than the default Admin and Guest, can be shared to other VoxPro machines.

One thing to note about folder updating: the first requirement is that all VoxPro versions must be the same. More specifically, if one is VP4 and the other are VP5/6/7 dynamic updates won't happen. The second requirement is that the UDP broadcast messages on port 33333 are allowed across the LAN/VPN. Normally, all UDP broadcast messages are enabled by default among devices connected to a given switch or router--but not beyond that, so I suspect that on a VPN you might need to enable that port.

When sharing is working, you'll see user config files from remote machines that are saved in C:UsersPublicVoxPro. There is a file named Users_Local.inf which has a list of users on the local PC. The other files named Users_<remote server>.inf have been broadcast from the other VP PCs on your network. All of these .inf files are simple text files. The local accounts should all have a local path with drive letter, but the remote accounts will all be in UNC format.

You will see networked accounts in the VoxPro login window. Admin, Guest, and local user accounts are at the top of the user list, followed by the users from remote PCs. 

The VoxPro Admin Guide, which is accessible in the VoxPro Help menu, contains a chapter on networking and remote access, starting on page 9. That's probably the best place to start. One other note: we've discovered problems with sharing the root of any drive, so don't do that as it results in an invalid UNC path for all accounts on that drive. We're working on a solution for that issue.

This was resolved in VoxPro v7.1.0.60. The current release is v7.1.0.66. Contact us in support to get the latest version.

You can keep all your audio files from VP4 and they will be completely recognized by VP7. It's just a matter of putting them in the right spot. The VoxPro configuration folder is C:UsersPublicVoxPro. In that folder there's a file labelled Users_Local.inf. It's a text file which you can view in WordPad or Notepad. You'll see a list of the full paths to the VoxPro user account folders. The default location the user folders is C:UsersPublicVoxProVP_Depot<username> but the accounts can be saved anywhere, and the Users_Local.inf file will list where each user's files are located. The .vpd files (there will be one in every folder) are the file editing database files. You can delete the ones created by VP4 as they will be ignored on the new machine (the database format changed after VP4). You may simply copy the audio files to the appropriate places on the new machine since the audio file format is the same between VP4 and VP7. 

You can set things up exactly the same way on the new PC if you like, or you can change things as required by editing the Users_Local.inf file to reflect your changes. You can also add/remove/rename user accounts in this same manner. When you're ready, save Users_Local and restart VoxPro.

The Managing VoxPro User Accounts PDF file goes over all the gory details of the VoxPro file system.

VP4 will run on Win 10 although it doesn't perform as well as VP7. Anyone can try out VP7 for 21 days using any VP security key (dongle) before purchasing it. Audio files are the same between all versions of VP. VoxPro audio files use a .vpw (VoxPro Wave) extension. The same folder hierarchy is used on VP7 as was used with VP4, VP5, and VP6: C:UsersPublicVoxProVP_Depot<users><folders>

You must map the drive by logging in as the local administrator of that VoxPro PC. When connecting from a PC that’s on a domain, to a PC that’s not on that domain, but are on the same subnet, you need to use a local user account which has administrator rights to that PC. It’s kind of confusing. The mapped drive will save the credentials and will always have a constant connection to that PC.

The user configuration file is located on each VoxPro PC in the C:UsersPublicVoxProUsers_Local.inf file. Open the file in Wordpad or Notepad since it's a simple list of the full paths to the various user accounts. Accounts may be saved anywhere, on any drive, and on any device on your LAN (UNC paths are allowed). You may add users, delete users, move users, or rename users simply by editing this file and restarting VoxPro. You're responsible for ensuring that the folder locations specified in the file actually exist since VP does not correct your mistakes! The generic Admin and Guest accounts must be locally on the C: drive of that VP PC so that you always have a way to log in if the usual account location becomes inaccessible (e.g. loss of hard drive, loss of network, etc.).

VoxPro remembers where that window was last positioned for that user, so they msot likely moved it off to one side and thus it is now appearing out of the main monitor. This can happen if a new monitor is used or if there were two monitors on that PC but only one now. So it's opening, but just not on the main screen. To get it back we can edit their user file so that it uses the default location which is on top of the VoxPro main window. 

View the files in that user's folder in C:/Users/Public/VoxPro/VP_Depot/<Username>. Inside that folder is the file: ~Settings.xml. Open it using Notepad (rather than an XML editor). Note that if VoxPro was upgraded you could also have a Settings.inf file leftover from VP4 so you can delete that file since VP7 ignores it.

Locate the section that pertain to the Search window which uses this tag: <SearchWin>. In's near the top fo the file. Here's an example:

  <SearchWin>

    <Position Xpos="1680" Ypos="289" />

    <Size Width="817" Height="540" />

    <ResultList Col0="300" Col1="90" Col2="175" Col3="175" Col4="100" Col5="100" />

  </SearchWin>

Delete all of that information from <SearchWin> to </SearchWin> and then save the file. When the user logs into VP7, and selects File > Search, the search window will appear in its default location on top of the main VP7 window.

Earlier versions of VoxPro did not have any buffer size adjustment whereas VoxPro 7 does. However, the issue is often the audio interface settings in the Windows Sound Control Panel.

Go to the search bar and type control panel, then click to open the Windows Control Pannel.

Go to Sound.

Go to your sound card and double-click it on the Playback tab.

Go to the Advanced tab. Uncheck "Allow apps to take exclusive control of this device."

This often will clear up the lag.

VoxPro uses UDP broadcast messages so the VoxPro machines don't need to know about each other. They just need to be on the same LAN. The same mechanism is used to exchange user lists. When VoxPro starts it sends out a broadcast message containing the UNC paths to user accounts which it "owns" (i.e., which were created on that machine). Other VoxPro PCs on that LAN receive that message and respond with their own user lists. Thus the folder C:UsersPublicVoxPro is populated with files in the form of Users_<remoteMachine>.inf as each VP on the network sends out its list and receives others in return. A good test of the network is to delete all of these files EXCEPT Users_Local.inf, then restart VoxPro. As the user list from each VP on the LAN is received and written to the folder, you have confirmed two-way communication with that machine. (Which doesn't necessarily guaranteed that you have write permission into those folders, but that's another issue.)

All VoxPro configuration files are in the C:UsersPublicVoxPro folder. The Users_Local.inf file has the list of users whose accounts were created on the local machine. It's a simple text file containing the full path to every user's account. By default these paths point to the C:UsersPublicVoxProVP_Depot folder but it doesn't have to. You may add, delete, or move users by editing this file in Notepad and restarting VoxPro. Any entry in the form: Users_<remote machine>.inf, are the user accounts which reside on other PCs. If you open one of these files you'll see the paths are in UNC format because this is how VoxPro accesses files on those remote machines. 

In any case, you can deleting the remote user .inf files but DO NOT DELETE the Users_Local.inf file, then restart VoxPro. When VoxPro restarts, it resolves the paths in Users_Local.inf to UNC paths if they are shared, and then broadcasts that list on the local network. If there are other machines on that network running VoxPro, then they will receive that list, write it out to a file called Users_<your machine name>.inf, and then return their own user lists to you, thus creating all those Users_<machine>.inf files. This is therefore an excellent method to find out which machines you are connected to. If you've been making network changes then you'll want to do this for each VoxPro machine.

To obtain a replacement dongle you must provide VoxPro proof-of-purchase for the version VoxPro license you're requesting us to replace. For a broken key we need the serial number from your license key, which is etched onto the metal USB plug. WS# 071415 is the part number for a replacement USB license key. The cost is $75.00 plus shipping.

The default administrator password in X-Point is Admin

In a Wheatstone TDM system, anything with an IP address needs to have a unique address on a common subnet. The default TDM subnet is 192.168.1.0, but you don’t have to stay with that subnet. If you do change to use another subnet, you’ll need to change the IP addressing of all your Wheatstone equipment since everything must now use an address within the new subnet. Here’s an overview of the main TDM components:   

• Tier 1— This can either be a Bridge rack with one or two CPU cards, or it may be one or two WheatNet hubs, so Tier 1 will always have either 1 or 2 IP addresses with the Tier 1 addresses set by that device’s
_NET.TXT file (for Bridge and WheatNet CPU config files, the filename is XP_NET.TXT). This file is saved on the device. In very early systems a DOS configuration program was used instead of a text file. If Tier 1 has two CPUs or two hubs, then there will be a primary and a backup address. Both must be changed to the new subnet. The network settings files are accessed via FTP to the device in question and are editable using Windows Notepad. Instructions for changing these addresses are included in the Bridge and WheatNet manuals. 

• Other Tiers—Other Tiers will have CPU addresses only if they have CPU cards in them. Any of these cards can have their IP addresses changed by the FTP process using the information found in the Bridge and
WheatNet manuals. 

• Control Surfaces—Control surfaces will have one or two CPUs each. They will also have device_NET.TXT files. The E-6 Surface CPU file will be named E6_NET.TXT. The procedure for editing these to change the IP
address is like that used on the Bridge / WheatNet CPUs, and is covered in the Bridge and WheatNet manuals, and in the specific surface manual. 

• XPoint—The XPoint program needs to know the IP addresses of the Bridge/WheatNet CPU primary addresses, and the Surface primary addresses as well. The Bridge manual explains how to change the addresses that XPoint is looking to find CPUs and Surfaces at. Additionally, the PC running XPoint must also have an address on the common TDM system subnet.  

• XY Controllers—The utility program WSNetServer is used to change XY controller IP addresses  

1. Take XPoint offline and save the configurations with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from the standby WheatNet, then power it off.

3. Delete the file that stores the devices from the Master WheatNet, then reboot.

4. After rebooting the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed and send it. This will likely reset all the cards in the system.

5. The standby WheatNet will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we'll need to power off the other WheatNet unit, then power it on, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

It all depends on which one is set as the master when we start since either top or bottom unit could be the master.At that point in the instructions, there is one unit powered on and one unit powered off, so "power off the other" refers to the one that is powered on. Assuming the the top unit (Wheatnet A) is master when we start the process, then "the other" is the top unit (Wheatnet A). If the bottom unit (Wheatnet B) is master when we start the process, then "the other" is the bottom unit (Wheatnet B).

Assuming the top unit (Wheatnet A) is master when we start the process...

1. With XPoint offline, save the configuration with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from Wheatnet B, then power it off.

3. Delete the file that stores the devices from the Wheatnet A, then reboot.

4. After reboot, the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed, and send it to Wheanet A. This will likely reset all of the cards in the system.

5. Wheatnet B will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we will need to power off Wheatnet A, then power on Wheatnet B, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

Assuming the bottom unit (Wheatnet B) is master when we start the process...

1. With XPoint offline, save the configuration with the CPU cards removed and update network files on both WheatNet units.

2. Delete the file that stores the devices from Wheatnet A, then power it off.

3. Delete the file that stores the devices from the Wheatnet B, then reboot.

4. After reboot, the software will start up with no cards in the configuration. Once we are online with XPoint, we will open the saved configuration with the CPU cards removed, and send it to Wheanet B. This will likely reset all of the cards in the system.

5. Wheatnet A will also start up with no cards in the configuration, so the two will have no way to detect each other. For this reason, we will need to power off Wheatnet B, then power on Wheatnet A, open and send the configuration to it as well. After that, we will be able to resume normal operations with both units powered on.

The Tier 1 cage normally has two HC-2001 Host CPU cards in it: slot 22 will have the Primary Host CPU and slot 20 will have the Secondary Host CPU. Under normal operations the Primary card in slot 22 is in charge, which means LED3 is lit to indicate it's the Main CPU. The other CPU card will have LED2 lit to indicate it is now the backup CPU.

When something happens to cause a CPU failover, the Primary and Secondary CPUs may swap their Main/Backup roles. Thus, a lit LED2 on either card is not necessarily an indication the card is failing. From your description it sounds like your concern is in seeing LED2 lit on the Primary card in slot 22, which simply indicates there has been a failover and now the Secondary CPU card is serving as the Main and the Primary CPU is the Backup. Considering only the LED status, that is all we can determine without further information.

Have there been other issues that lead you to suspect problems with the Primary card? If so, what kind of issues? How often do they occur? In this condition you can force a failover to switch back to having the Primary serve as Main by pressing the failover switch on the CPU that's currently serving as Main. The failover switch on an HC-2001 card is the switch just below the card's handle. 

You could force this resetting by powering down the Tier 1 rack, waiting 30 seconds or so, and then power it back up. It should power up with the slot 22 card set as Main (LED3 lit) and the slot 20 card set as Backup (LED2 lit).

Note: The Main card uses an FTP process to communicate configuration changes--including the current crosspoints, to the Backup. If this process is not working properly, the two CPUs will have different configurations and a failover can cause changes to the active crosspoints and their associated audio and logic. For this reason it's always advisable to perform a system backup prior to doing any system rebooting or forced failover by using XPoint's File > Save... to save the current configuration.

The system architecture was initially designed to function without the need for a network or a PC except during configuration. At the time of development in the late 90s and early 2000s we didn't want our product reliability to depend on a network or a PC in any way. Thus the system is fully functional even without a network, with the following exceptions:   

1. Wheatstone PC software can't communicate with the system without a network. 

2. Optional hardware controllers and automation interfaces won't work without a network. 

3. A frame or Surface with an optional backup CPU will not have up-to-date settings in its backup CPU without a network. The backup CPU needs to be constantly updated over Ethernet so that it can take over, where the primary CPU left off, if the situation ever arises.  

If both are 64-bit PCs, you copy the contents of the Wheatstone directory in the Program Files (x86) folder from the old PC to that same folder on the new PC. If the old PC is a 32-bit but the new one is 64-bit,
then the Wheatstone folder you need to copy will be under the Program Files folder.   

Once you copy the files to the new PC, the XPoint settings file, XP.INI, will need to be edited to set the path to the default config file, which is usually defined in the second line from the top. It must specify
the correct path which is: C:Program FilesWheatstoneXPointcfgdefault -- on a 32-bit PC  

C:Program Files (x86)WheatstoneXPointcfgdefault -- on a 64-bit PC.    

If the config file is saved in the default location, the path will either be Program Files or Program Files (x86) and will only need to be edited when going to a 64-bit PC from a 32-bit PC. 

The XP.INI file also has a similar path issue with the HowTo.txt file (it’s in the Program Files or Program Files (x86) path). When that's not defined properly, every time XPoint is started it complains there's a file it can't find.

The short answer is yes. The X-point app can be run on WinXP, Win7, or Win 10 PCs. As to transferring your config files, you’ll first need to determine whether the previous PC is a 32-bit or 64-bit OS since that
determines where the files are stored. I assume your new PC is 64-bit. If your current X-point PC is 32-bit--and it was installed using the default settings, then the folder you’ll need to copy is in this path: C:Program FilesWheatstoneXPoint. If your current X-point PC is 64-bit--and it was installed using the default settings, then the folder you'll need to copy is in this path: C:Program Files (x86)WheatstoneXPoint. 

The key to transferring an X-point installation from one PC to another is to copy all the files from the original installation and paste them into the appropriate location on the new PC. In the case of transferring
from one PC to another using 32-bit, the procedure is simple: copy the entire Wheatstone folder from the original PC to the new PC, landing it in the same location that it was in on the old PC. 

But, when transferring files from a 32-bit PC to a 64-bit PC, the procedure is a bit more complicated. The WheatstoneXPoint folder should be copied from the old PC location of: C:Program FilesWheatstone but it needs to be pasted into the new PC using this path: C:Program Files (x86)WheatstoneXPoint.    

If you moved from a 32-bit PC to a 64-bit PC, you have some additional things to do: 

1. In the WheatstoneXpoint folder, set the executable file (XP.exe) to Run as administrator. 

 a. Right-click on the icon for XP.exe 

 b. Select Properties from the popup context menu 

 c. Select the Compatibility tab. 

 d. Check mark the box that tells the program to Run as administrator. 

 e. Click OK 

2. Edit the XP.ini file section [Config Dir] path settingsto read as follows: (see Note 1 below) 

 a. ConfigDir=C:Program Files (x86)WheatstoneXPointcfgdefault (see Note 2 below) 

 b. HowToFile=C:Program Files (x86)WheatstoneXPointHowTo.txt   

Note 1: In most cases, Win7 and up allow you to open and edit the XP.ini file from its normal location, but then won't allow you to save it. So, before you start editing the file, drag it, or create a copy and paste
it, to your desktop. Once you've edited and saved the file you can then drag it back to its proper location. If you copied it make sure the original file gets overwritten.   

Note 2: The default configuration X-point uses is typically the one shown. However, the user can specify using a different location but DO NOT change the file location specified in the XP.ini file beyond the insertion
of “ (x86)” – without the quotes – after “Program Files” unless you have a good reason to do that and an understanding of why it must be done.   

In the case of transferring from a 64-bit to a 32-bit PC, why? If you must do this, the procedure is basically the same with a couple of exceptions – you will be moving from Program Files (x86) to Program Files,
and thus will be removing “ (x86)” from the paths. You will most likely want to create a shortcut on your desktop to easily start the program. 

If you follow these instructions carefully you should end up with a working version of XPoint that has proper read and write access to the configuration files.   

There are a few possible gotchas to watch out for: Depending upon how the PC has been setup, file extensions may not be visible. In this case you'd see two files named XP, rather than an XP.exe and an XP.ini. The
larger of these files should be tagged as an Application – that will be XP.exe. The smaller one will be XP.ini and tagged as a Settings file. 

The current (old PC) may be set up to have the configuration files in a different location than default, possibly even on a network drive – i.e., on another PC than the one X-point runs on. This should still be possible to do on the new PC, but may involve a committee decision on whether to do it or not. The new PC must have a unique static IP address on the same subnet as the Wheatstone equipment.  

I suspect you're running into a tier-to-tier bandwidth limitation. The AT links between tiers have a limited bandwidth that allows only a certain number of "channels" originating in Tier X to pass audio to Tier Y (where X and Y are actual tier numbers in your system). If there is no path for the audio between the tiers, then XPoint will not make the crosspoint.   

A quick way to verify this is the case is to pick a crosspoint that you cannot currently make, determine what the source tier is and what the destination tier is for that crosspoint, and look for existing
crosspoints between the two tiers in the same direction. For example, if the crosspoint not being allowed has a source in tier 3 and a destination in tier 4, you would be looking for other crosspoints with their sources in tier 3 and destinations in tier 4, not from tier 4 back to tier 3.    

Disconnect one of the current crosspoints you find and see if you can then make the one that was being refused. If you can, that's a sure sign you're encountering a tier-to-tier bandwidth limitation between those two tiers in that direction. One caveat: if the crosspoint you're trying to make is a stereo connection and the one you disconnect is a mono (or 5.1 vs stereo) that may not free up adequate bandwidth and the new crosspoint may still be disallowed, so in doing this test make sure the channel width (mono, stereo, 5.1) of the crosspoint you remove is at least as wide as the one you want to replace it with.   

It may be possible to increase the available bandwidth between a given pair of tiers, but would require someone from the factory to be able to remote in and make the adjustments, or, in lieu of that, you would need to send us your current configuration and specify the tier pairs that require increased bandwidth so we can, if possible, update the configuration to meet your new bandwidth needs.  

These are wired to LIO ports and require no special software. The GPC-IP user manual has some information, including schematics, on that panel, beginning on page 1-7. Here's a link to download that manual. 

Generally, you’ll need to wire the panel to LIO ports then use the XPoint software to configure the LIO functions. The functions are configured on the LIO tabs of the microphone audio signal definitions. Information about wiring the LIO ports begins on page 2-66 of the Gibraltar Network manual and information about configuring the LIO ports begins on page 4-23.

 If that CD player does not supply +5 volts then you will need an external +5V supply since the logic outputs on TDM cards are “dry-contact” which means each logic port only provides a closure between its two pins (labelled as plus and minus). For example, when output logic port 1 is activated on an LIO-2001 card, you get a dry-contact closure between pin 12 (Out +) and pin 25 (Out -) on the lower DB-25 connector.    

If you’re using logic port 1 for Start and port 2 for Stop you would need to wire the CD player remote and a +5 volt supply in this manner:   

1. Connect the 5 VDC supply’s plus wire, through a pull-up resistor R1 to LIO card pin 12 and thru pull-up resistor R2 to LIO card pin 11.   

2. Connect LIO card pin 12 to CD player START connection (TIP) and LIO card pin 11 to CD player STOP connection (SLEEVE).   

3. Connect the 5 VDC supply’s minus wire to LIO card pins 25 and 24 and to the CD player AUDIO COMMON.   

The R1 and R2 pull-up resistors should be around 1K (unless NuMark tells you differently) since the Wheatstone logic ports can sink up to
120mA.  

Whenever a CPU failover occurs, both CPUs will indicate "failed over" in the log, but one will indicate that it's online while the other will indicate it's offline. Rebooting is the only way to clear those error messages. You shouldn't be concerned about the rare instances of a CPU failover since the system is designed to do that under certain conditions. However, I would not expect loss of audio from the failover action,
but it's not unheard of. Keep XPoint running for a while and periodically check for error messages in the logs which could indicate a CPU or system issue. If you do see errors, let us know and we can help you analyze the log entries. 

Since the two controllers are listed in WSNetServer, they must be Ethernet-connected controllers. For future information, the controller configuration dialog in XPoint that you were looking at only applies to controllers connected to the Bridge via RS-485.

If both controllers are visible in WSNetServer as soon as you open the program that indicates they were probably visible as part of a saved configuration. Open WSNetServer and select Scan > Network... from the menu. This opens a Network Scan Results dialog box that will show what devices WSNetServer can actually see. If you can't see them after the scan then there is most likely a network issue that you'll have to take care of.

You use the Add Signal Wizard in XPoint to add the 2nd Mono Source to the system. You'll need to select the proper Tier/Rack Card and Wire #, in this case 2, to add the signal to the matrix. Once there it should be available to the console faders although you may need to edit the Visibilities to add that signal to one or more faders' visibility lists.

 For us to help you, follow these instructions:   

1. On your XPoint PC, create a folder on the desktop and name it by your call letters and date like WXYZ 10222019.   

2. If you already have logs, copy them into that folder. If not, acquire the logs and save them in that folder.   

3. In XPoint, select the menu item: Diagnostics > View System Health Status to show the System Health window. In that window, a single left-click on the dark grey bar near the top with the column headings to expand the health diagram. Look down the left side of the diagram for any + (plus) signs that indicate rows which are not fully expanded; click on any + sign to insure you end up with all of the health diagnostic rows. Get screen shots of the system health, doing as many shots as necessary so that you are showing us the complete diagram. Put the screen shot files in the desktop folder mentioned above.   

4. Get a screen shot of the lower left corner of the main XPoint window, showing the left end of the status bar with the colored box (green, yellow, or red) and any text to the immediate right of the colored box.
Put that screen shot file in the desktop folder.   

5. In Windows Explorer, navigate to the Wheatstone directory on the PC. On a 32-bit PC this would be C:Program FilesWheatstone. On a 64-bit PC it is C:Program Files (x86)Wheatstone. Copy that entire folder to that desktop folder.   

6. Make any notes about the issues you’re experiencing and include them as a text file in the folder.   

7. Right click on the desktop folder and select Send to > Compressed (zipped) folder from the context menu to create a single file, WXYZ
10222019.zip.  

8. Send an email to [email protected] with the zip file. If the file is too big to attach, ask us for a Box link and we'll send you a web link you can upload the files on.  

For us to gain remote access to your system, have TeamViewer installed on the XPoint PC and insure that there are two network connections to that PC so that we can remote into that PC while it’s connected to the WheatNet system.  

When anything changes in the system, including crosspoint connections, the primary CPU should be updating the backup CPU with the changes over the Ethernet network so that when the backup CPU takes over, it should be up-to-date with all the current connections. However, if there's a problem which prevents those updates from taking place, that can lead to crosspoints not being made. Here is how you can see if that’s what’s happening:   

1. Connect to XPoint, while the primary CPU is running, and save its configuration. (File -> Save, OK) 

2. Fail over to the backup CPU. This can be forced by pressing the button below the card handle on the primary CPU. 

3. If there’s no audio on the outputs, connect to XPoint and open the configuration you previously saved and send it. (File -> Open, OK... File -> Send Cfg To Switch). If the audio is restored then need to figure out why the secondary CPU isn’t being updated. Check the network settings files on both CPUs to verify they are identical—with the exception of their names. To check the settings, you can use any FTP client like Filezilla, to login into the CPU.. Log in with the Username: knockknock and the password: whosthere   

If sending the saved configuration to the backup CPU doesn't return the audio, then there’s another problem that will need to be investigated.   

Download and view the file XP_NET.TXT and verify that the files on the two CPUs are identical, again with the exception of the CPU names. If there’s not a problem with the network files, then there may be a problem with the network itself. We’ve seen network switches misbehave when the IP addresses are changed. This can cause problems because when there’s a CPU failover, the two CPUs swap IP addresses, so if one CPU is not communicating properly you could end up with both having the same IP address.  

At one point, early in the development of the TDM series of products, Wheatstone was considering making a manifold program to allow port sharing, but one was never developed. For that reason, it becomes necessary, when running TDM utilities simultaneously, to use multiple PCs. I'm not aware of any manifold products available from others, so I can't speak to the use of any such programs.   

There are essentially two ports of interest used by XPoint and utilities, and you cannot run two programs that are using a common port on the same PC at the same time.   

Port 2898 (TCP, I believe) is used by WSTimeSet and WSNetServer, so those two programs cannot run simultaneously on a single PC. Please note that you also cannot run two simultaneous instances of any of these utilities on the same PC.   

The other port of concern is the system Broadcast Port. It is configurable, but everything in a system using broadcast communications must use the same broadcast port. By default, this is set to 55555. The following programs use the broadcast port, and so none in this group can run simultaneously on a single PC: XPoint, but only in Guest Mode (a mode which was eventually dropped as the product line developed), WSNetServer, Event Scheduler, and pc_xyc. Again you cannot run two simultaneous instances of any of these utilities on the same PC.   

The only other network restriction I'm aware of in the TDM product line, other than an automation simulator which would only be used by automation vendors during the development process, is that you cannot run two or more instances of XPoint in normal mode in the system, even on separate PCs.   

Early in the development of the TDM products we considered making a manifold program to allow port sharing, but one was never developed. Thus, when running TDM utilities simultaneously, you must use multiple PCs. I'm not aware of any manifold products available from others, so I can't speak to the use of any such programs.   

There are essentially two ports used by XPoint and utilities and you cannot run two programs that are using a common port on the same PC at the same time. Port 2898 (TCP, I believe) is used by WSTimeSet and WSNetServer, so those two programs cannot run simultaneously on a single PC. Also note that you cannot run two simultaneous instances of any of these utilities on the same PC.   

The second port is the system Broadcast Port. It's configurable, but everything in a system using broadcast communications uses the same broadcast port. By default, this is set to port 55555. The following
programs use the broadcast port and so only one in this group can be run at a time on a single PC: XPoint, but only in Guest Mode (a mode which was eventually dropped as the product line developed), WSNetServer, Event Scheduler, and PC_XYC.   

The only other network restriction I'm aware of in the TDM product line, other than an automation simulator which would only be used by automation vendors during the development process, is that you cannot run two or more instances of XPoint in normal mode in the system, even on separate PCs.  

Most scripts require a host blade in order to do meaningful work. For example, something as simple as making a route needs a host blade to act as the router. The script sends a command to the host blade to make the crosspoint. The script itself can’t do this. To set a host blade, click on the Device Map tab and enter any valid Wheatnet Blade IP address in the “Host Blade” field. If you haven’t done a complete System Scan, now would be a good time. Do this from the WheatNet-IP System menu item. Then you will be able to select your host blade by clicking on the blade picker (three dots) next to the Host Blade field.

Visit Wheatstone's Scripting & Logic Forums 

Sometimes you need to have something start upon the execution of the script and run until the script stops. For example, maybe you want to monitor an LIO or the state of a connection so that you can do something if, for example, Comrex 4 is connected to your LXE consoles fader #18. You can do this by using a StartupHook. This is found on the Script Wizard tab under “Custom Action Hooks.” All you need to do on this tab is enter the name of a subroutine which you will create later. This subroutine will run when the script starts and you can set up your monitors or other actions you need to perform upon startup in the subroutine. Let’s assume you put “my_startup” as the name of your subroutine in the StartupHook. 

Syntax for setting up a subroutine (which you will do on the Script Editor tab) is found in the online help. It might look something like this:

subroutine: my_startup
{
    variable: ii
    //Turn all 16 GP buttons on
    for (ii=0 to 16)
    {
       btn_led (ii,1)
    }
}

Visit Wheatstone's Scripting & Logic Forums  

There is no scripting manual. Screenbuider and our other devices which contain a script engine include an extensive online help file which covers all the commands and instructions needed to build a useful script. Syntax is described in detail, and in many cases a working example is provided.

If you have difficulties even with the online help, please check our our online Scripting & Logic Forums. You’ll need to set up an account and wait for Wheatstone Tech Support to verify and enable your account. The account is free and you can ask questions and share your own knowledge to help other Wheatstone scripters. You can also email Wheatstone Tech Support. 

Short answer is a qualified yes. Let’s say you have a computer in your station’s front lobby that you want to run a script on with station logos, cool-looking meters and a Now Playing display. You’ll need a license for Screenbuilder to run the script engine on that computer. The script engine is what runs and displays the output of the script.

Suppose you want to build this script on the computer in your office. You can do this by installing Screenbuilder on your office computer, and you can build and modify the script to your heart’s content without a license. But to test it, you’ll need to have a license on your development machine, or deploy it to the production system and see if it works.

Visit Wheatstone's Scripting & Logic Forums  

You can also change the IP address using Telnet. Download the PuTTY utility and use it to connect to your console.

You'll be prompted for a username (knockknock) and a password (whosthere) to connect to the Surface. Type "help ip" and press enter to list the proper syntax for the IP command which is used to display or edit the device network settings. For example, to change the IP to 10.0.4.204 you would type the below command, followed by enter:

ip 10.0.4.204 255.255.255.0 10.0.4.1

This entry sets the IP address, the subnet mask, and the Gateway. All three entries are required; you cannot skip the Gateway. As with blades, the Gateway should be set to your subnet address ending in .1

After you hit enter, it will display the text that it received. If everything is correct, reboot. if not, repeat the process. Make absolutely certain that you have a valid IP, subnet, and gateway before rebooting!

The order that your switches are powered up in should not matter, but we do recommend powering up the switches first and waiting (patiently...) until all of the switches completely boot up--which can take several minutes-- before you begin powering up your Blades. The main issue with powering up the Blades, before the switches are ready, is that each Blade comes up and operates as if it were a standalone device since it wouldn't be communicating with any other device. This means that once the switches boot up completely, the Blades will need to "talk amongst themselves" to sort out how to merge all of those "stand-alone" systems together again. Needless to say, it's a lot easier process for Blades to form one system as each one "wakes up" in a network as opposed to "thinking" it's a stand-alone device.

In Navigator, look at which subnet your Blades are on. If they are all on the 192.168.87.0 subnet (which is our default) then you should configure the new Blade for a unique IP address on that subnet. If there are Blades on both subnets, then you'll have to find out the logic behind using two subnets to see where the new Blade would best fit.

When we design a network, which we know is going to have a lot of devices, if we need more than 254 IP addresses, we'll setup the system with a subnet mask of 255.255.254.0. The reason/logic for doing this is to expand the total number of IP addresses available in that system. The standard Class C subnet mask (255.255.255.0) means you can address a maximum of 254 devices, but a subnet mask of 255.255.254.0 increases the system to be able to address 512 devices. We then typically assign all Blades and Surfaces to the .87 subnet and put the guest panels and other accessory devices onto the .86 subnet. 

In such a case, when adding a new device on this type system, the subnet mask would need to be 255.255.254.0 to make that device visible to the entire network, and vice-versa. If you used the default subnet mask (255.255.255.0) then that device would only see, and be seen, by the devices assigned to the same third octet number: either only those devices using .86 or only those devices using .87 in their IP address.

Open a Command window (Windows key + X and select Command Prompt). At the prompt enter: 

netsh interface ipv4 show joins

If you see 238.38.38.38 and 238.38.38.39 listed, along with 234.0.0.1 and other addresses, then that NIC is most likely connected to a WNIP network. The .38 address is used to send Announce, Logger, and LIO traffic. The .39 address is used to send metering data. If the PC has an audio driver running, then you’ll also see 239.192.0.0 which is used by the metronome packets for audio synchronization.

Let’s say you have a Control Room with an LXE console and a Talk Studio with four microphones and four talent stations. You want the board-op to be able to talk to the co-hosts and guests in the Studio. You also want the board-op to be able to talk to any guests that are remoting in through a codec such as Comrex Access.

First the board-op’s mic needs to be cross-connected to the TkBk destination for the surface being used in the Control Room. This sets it up to be the designated Talkback source for this LXE.

There are two basic types of Talkback on most of our console systems. One is operated by the TB buttons on each of the fader modules. These TB buttons interrupt the bus-minus outputs for each fader. The Bus Minus signals show up as sources in Navigator and are usually labeled BM01, BM02, BM03 etc. The base mix for the Bus Minus signals is chosen on the VDIP page in the GUI program for the surface you are using. 

If you are feeding Comrex1 with BM11 (because the Comrex is on Fader 11 of the console) then the guest on the other end of the codec will hear everything in the Bus Minus base mix EXCEPT his own audio (which would be delayed if you allow it to be fed back to him) and, when the TB button is pressed on Channel 11 he will hear the board-op’s mic audio instead of the normal mix as long as the button is pressed.

The second type of Talkback involves the TB button on the Studio Module for the surface. This TB button will interrupt the feed to the Studio Monitors. Assuming the guests in the Talk Studio are listening to the default Studio Monitor output (usually fed to the speakers and the headphones for the talent stations) they will hear the board-op when he or she presses the TB button.

You can use any microphone (or any other source, for that matter) as the Talkback source for your studio. Normally this will be the board-op's microphone. To set up Talkback using this mic source, you will need to crosspoint that source (let's say it's Mic 1) to the surface's Talkback destination. This might be called something like "LXE TkBk" for an LXE surface, or "DMXTkBk? for a DMX. 

Once you make this crosspoint, Mic 1 will be the source for all Talkback operations originating from the surface.

Let’s say you have a Control Room with an LXE console and a Talk Studio with four microphones and four talent stations. One talent station is for the Co-Host, and the others are for guests. You want the board-op to be able to talk to the co-host individually and to the co-host and guests in the Studio as a group.

First the board-op’s mic needs to be cross-connected to the TkBk destination for the surface being used in the Control Room. This sets it up to be the designated Talkback source for this LXE.

The normal Studio Module TB button will talk to all the individuals in the Studio if they are listening to the usual Studio Monitor feed. But you'll need to set up something different to talk privately to the Co-Host. To do this, you can use one of the Softkeys (or 'Spare buttons") on your console. Choose the button you wish to use, then find it on the LIO Info page for the console's mix engine blade. You should see Blade LIOs, then Software LIOs, Functional LIOs and finally, Surface Spares. Expand the Surface Spares and you will see each of the spare buttons available on that console. You may see more than you actually have; these additional ones should be ignored.

If you look at the row for your selected Spare Button, you will see that this button can do one of several things. It can

• Fire a Salvo
• Initiate a Momentary Connection
• Take a Processor Preset
• Control a Clip Payer (in some software and hardware versions)

To talk to the Co-Host individually, you should set the button up to do a Momentary Connection. Choose the board-op microphone as the source, and the Co-Hosts headphone (TS4HDPN or TS22HDPN for example) as the destination. As long as the soft key/spare button is held down, the normal headphone feed for that Talent Station will be replaced with the microphone audio.

It depends upon the console model whether there is a DIP switch to allow you to do this. If you have a model which is hard-wired to the PGM 1 bus then you can't change that. If your PC doesn't have an audio input jack, you'd need a stereo audio to USB adapter, which are available for under $50.00USD (https://www.dak.com/product/line-usb-audio-adapter/). Using one of these adapters would allow you to connect the PGM 2 output to your PC. You'll also need an adapter cable to get from the RJ45 jack on the console. A RJ-45 to TRS adapter can be purchased from most broadcast supply companies.

You must use Windows 10, release 1803 or later for the USB audio to work properly since you could not change the USB input from 1-channel to 2-channels. Also, it has to be done on the full Sounds panel (open Control Panel on the PC and choose Sound), not the Windows 10 audio panel which you get when you open the sound device. The Sounds panel allows change without reverting to prior configuration, while the Windows 10 audio panel options always reverts to its default values.

Many Wheatstone/Audioarts users connect their consoles to Apple products. There was an issue in OS Sierra where the driver used by the USB chipset in our products wasn't in the OS. Here are some USB troubleshooting tips for Macs:

1. Verify the USB cable is securely plugged into the USB port at each end of the cable. 

Unplug the console cable from the Mac's USB port, wait about ten seconds, then securely plug it back in.

2. If following #1 makes no difference, unplug all other devices plugged into the USB ports, then plug in the USB cable from the console or M4IP-USB Blade to see if the Mac then detects the device. Sometimes other devices will have a conflict and don't "play nice" with the console/M4IP-USB connection. If you find this to be the case, you may need to manual connect the other devices after plugging in the console, or there may be a driver update or other information available from the other device manufacturer.

3. Was USB working from the console and then just stopped working?  

If it used to work, what changed prior to norticing it no longer is working? A new device added by chance? A new program installed? Could try reverting the computer to the way it was before the device stopped working. If it works again, there's an incompatibility with the console/M4IP-USB and whatever new device or program was added.

4. Check the System Profiler 

Open System Profiler from the Utilities folder in the Applications folder. From the Contents column on the left, under the Hardware header, select USB; the panel to the right will show all the USB devices that the computer recognizes. It may not identify them correctly by name, but it should have the right number of devices listed.

If the console/M4IP-USB device shows up in System Profiler--even if it doesn't work, then it's usually a software issue. Your best solution is to try updating the drivers, creating a new user, or reinstalling the system software.

If the console/M4IP-USB device doesn't appear in System Profiler, the issue is more likely to be hardware either the device or the USB port isn't working properly. In this event, continue on to the next item on this list. With each of the following items, go back and check the System Profiler window (press Command+R to refresh the list) to see if the device appears.

5. USB port lacks power 

If you have the device plugged into a USB hub or into your keyboard, plug it directly into one of the USB ports on the computer. If it works there, the issue is with the device to which it had been previously connected. The device may need more power than the port provides.

6. Not all USB ports in the computer are working 

Check the device in all the USB ports on the computer. Also test each port using a good, working USB device. Sometimes one port on the computer will stop functioning, but others will still work. If this is the case, the computer may need to be serviced.

7. Check if the device is properly mounted:

a. Open Hard Disk > Applications > Utilities > Disk Utility.

b. Highlight the name of your device, if it shows Mount on top, click Mount so that it changes to Unmount.