How to tell which SCOPE (PCI or XITE) is currently running?

[odlumb]

Please forgive me if this question has been asked and answered.

I have SCOPE v5.1 installed on my system for both my old Creamware boards (PCI) and XITE-1. They run exclusively, that is, never both at once.

I have a program I'm developing which need to determine (programmatically) which SCOPE version is currently running, if either. Is there a key in the Windows 7 (64 bit) registry which can be queried to yield this specific information? Something with maybe a value of "PCI", "XITE-1" or "None"?

I can theoretically create what I'm looking for by modifying the .inf files of the respective drivers, but that won't set the key's value back to "None", or "0", or "" when SCOPE exits, which I need. I'm hoping the folks at Sonic Core have already provided this info somewhere in the registry...

Thanks in advance!

[w_ellis]

I only use Xite-1, so I can't check, but the Window names for the two applications may be different, which would allow you to use the FindWindow Win32 function (http://msdn.microsoft.com/en-gb/library ... s.85).aspx)

From a previous discussion I had on this topic, the names may be:
"SCOPE Fusion Platform" - Xite-1 Scope 5
"Sonic Core Scope" - PCI Scope 5

The code would just be something like:

Code: Select all

#include <Windows.h>

HWND hsWindow = FindWindow(nullptr, "SCOPE Fusion Platform");

if (hsWindow)
{
    // Do Xite-1 stuff
}

[odlumb]

I haven't actually tried your example (yet), but according to spy++ in Visual Studio, the windows names are exactly the same. I'll give it a shot anyway. Thanks!

[dante]

Cubase or host apps can tell which Scopes are running if they are loaded with asio modules.


I run PCI and XITE simultaneously normally, so in cubase can toggle between them. However, if one of them is not running, cubase will pop up an error if I try to select the one that's not running.

So, I would imagine the only way to do it would be the same way, ie to attempt asio comms via the respective PCI and XITE hardware drivers. Cubase knows which is which.

[odlumb]

Yeah, Cubase does a great job generally dealing with ASIO drivers. I needed to know which scope was running in a third party application I wrote myself, it's a complex control program which routes audio signal not only in my studio but throughout the entire house. Sort of the way SCOPE routes signals INSIDE my DAW, this program is routing signals OUTSIDE the computer using a Signex MIDI controlled audio patchbay.

Here is the code I'm using, it work just fine, the one caveat is that it requires elevated permissions. This can be achieved in Visual Studio using the Project->Properties->Configuration Properties->Linker->Manifest File->UAC Execution Level.

This code assumes only one (or neither) of SCOPE XITE-1 or SCOPE PCI is running, and it determines which one by parsing the install directory path of the running application. This is .NET C++, adjust to your own requirements:

Code: Select all

private: enum ScopeStatus whichScopeIsRunning(System::Void)
	{
	array<Process^>	^scopeProcesses;
	String			^fullPath;
	ScopeStatus		status;

	status = SCOPE_NONE;

        //requires elevated privileges
	scopeProcesses = Process::GetProcessesByName ("Scope",".");

	if (scopeProcesses->Length != 0) //a least one instance is running
		{
		if (String::Compare(scopeProcesses[0]->MainWindowTitle,gcnew String("SONIC CORE SCOPE 5")) == 0) //double check by window title
			{
			//get the installation directory
			fullPath = scopeProcesses[0]->Modules[0]->FileName;
			//does it contain "XITE"?
			status = (fullPath->Contains(gcnew String("XITE")) ? SCOPE_XITE1 : SCOPE_PCI);
			}
		}

	return(status);
	}

[dante]

Yeah that would work on my system because the install directories are called Scope XITE and Scope PCI respectively.

Is the signex thing like copperlan but you don't need a host PC to run it ?

[wouterz]

That Signex patchbay is just what I was looking for

http://www.signex.com/arc32.html

[odlumb]

I love the Signex audio patchbay. But when I bought mine years ago there was a serious caveat - no software! The company provided me with a technical specification, from which I was able to write my own drivers to control the unit (via MIDI). I am always happy to share this work with anyone who wants it. Perhaps by now the company has some software to offer, but I doubt it. My impression was that the company had essentially failed as a business, and the owners had a huge inventory on-hand they wanted to sell. They weren't of the mind to invest MORE money to pay a programmer to develop software. So my work is free to anyone. It's written in .NET C++ for PC.

[dante]

"The Smartpatch is a programmable automated routing controller that allows connections between sources and destinations (outputs and inputs) to be made electronically rather than with patch cords."

Sounds like Scope ! Except you don't need a PC.

Well done re the C++ development.

[odlumb]

Well, you do need a PC (or some CPU device) to operate/program the patchbay. It's controlled by MIDI, true, but it not a simple matter of sending some CC/value to the device. Rather it's packets of info (not unlike TC-IP networking) which are COMPRESSED/DECOMPRESSED by a proprietary algorithm, except MIDI is the transport layer, so the packets are directed to some MIDI send/receive sub-system instead of an Ethernet controller. In my application I had to write the MIDI transport layer as well, but that's not too difficult, lots of examples are available as blueprints.

But it was worth it. The patchbay is now the heart if a very sophisticated audio routing system which saves me a lot of time and relieves me of having to REMEMBER all the details of wiring and connections. I just encoded all that info into the control program, and select the configuration I want with a single click of the mouse There's an ethernet controlled powerstrip in the system as well, so only equipment that is actually being used in the selected configuration is turned on. Hi tech, I love it

[Bud Weiser]

I love the Signex audio patchbay. But when I bought mine years ago there was a serious caveat - no software!

Well, normally no software necessary, isn´t it ?

I understand you program the machine on the frontpanel and store "scenes" in 128 patches which you recall by sending MIDI Prg-Ch. numbers.
That´s what is "MIDI control" for ´em.

Does that work or not (without using your custom software) ?

I also understand you wanted more,- maybe remotely controlling the patchbay from a computer without touching the unit´s frontpanel at all, which is a different story but wasn´t the intention of the manufacturer.
That´s why you´ll never find any software for the machine.

Doesn´t mean your custom application isn´t useful.
I think it might be welcome if it works, but here, I want to find out if it doesn´t work w/ MIDI (Prg.-Changes) at all in the sense of a unfinished product or not.

Bud

[odlumb]

Absolutely, one can store configurations and recall them from the front panel only. I never use it that way, but it was certainly something the designers had in mind. But they also had in mind remote control by a computer. In fact they had an engineer write a control program that did exactly that (my understanding is that it was for Macintosh OS only), but something happened (dispute over copyright?) that prevented them from offering it. I can't remember the details of the story I got from the company, but the end result was that the specification one needed to write such an application was available, but the application itself was not. So I wrote my own.

But yes, no software necessary if you intend to use it from the front panel.

[Bud Weiser]

Absolutely, one can store configurations and recall them from the front panel only.
...
But yes, no software necessary if you intend to use it from the front panel.

Hi!

Thx for reply.

I hoped for reading:
"Yes, it works switching patches (programmed by using frontpanel before) by sending MIDI program change numbers."

Does it ?
If not, it´s senseless for me.
In a DAW environment it makes sense controlling it by a program running on a computer, but it should also work standalone and being controlled by a keyboard or MIDI controller for simple patch recalls.

I´d wish it could store input levels too, like the AKAI MB76 I´m using up to now but is 7-In / 6-Out only and is MIDI switchable.

Bud

[odlumb]

Verbatim from the "manual":

"MIDI program changes may be used to select patch numbers either sent from a MIDI keyboard, voice number or sequencer etc. This facility may be enabled or disabled by the third channel key on the bottom row. When it is enabled the PC LED is illuminated (channel 3). This means that when a patch is loaded the patch number is transmitted in the same way the voice program number is transmitted from a keyboard."

You now know as much about it as I do. Sorry, I've NEVER even touched the front panel (except for the power switch)

[Bud Weiser]

Verbatim from the "manual":

"MIDI program changes may be used to select patch numbers either sent from a MIDI keyboard, voice number or sequencer etc. This facility may be enabled or disabled by the third channel key on the bottom row. When it is enabled the PC LED is illuminated (channel 3). This means that when a patch is loaded the patch number is transmitted in the same way the voice program number is transmitted from a keyboard."

You now know as much about it as I do. Sorry, I've NEVER even touched the front panel (except for the power switch)

Can be 2 things:

The unit receives MIDI Prg.-Change No. and switches the related patch,- then ...

a) transmits the, to it´s patch location related, program number over MIDI Out ... or
b) echoes the received MIDI Prg.-Change No. over MIDI Out ...

I hope they don´t mean MIDI Thru functionality the way as quoted above

Anyway, according to the manual, it seems it does what I hoped it will do when not using any additional software.

thx again

Bud