New Conventions and Functions in Scope XTC /DP

There are some conventions and new functions that you should know so that your device will work flawlessly together with others.

Surfaces

There are a number of changes concerning the surface. First of all a surface now consists of a SurfaceInterface and at least one panel. The panel can be seen as the visible part of the surface while the SurfaceInterface is the a controlling node. The class from which the panel is derived was changed from 'ChildView' to 'Surfaces@BasicSurface' (you might want to have a look at the 'Module Attributes' window). If you have multiple panels for your device then the main panel must have a SurfaceInterface, the others can have one. Both - the SurfaceInterface and its panels - have a graphical representation in the circuit.

The SurfaceInterface controls whether the device is visible in the 'Device Bar' (Pulsar/Scope) as well as what is visible in the host software (XTC mode). (Right mouse button and choose 'Show in devicebar'/'Don't show in devicebar'.) Before the surface always had to be situated in the first layer of the device. Now the surface can be situated somewhere inside the device as long as it is connected to the SurfaceInterface (which has to be on the first layer).
In XTC mode the host software is always displaying the surface which is connected to the first found SurfaceInterface of this device - e.g. the SurfaceInterface that has the highest position in the device's hierarchy in the Project Explorer. (In the picture the highest SurfaceInterface in the hierarchy is marked with red arrows. You can see another SurfaceInterface directly under the marked one which is the one for the preset list.)


Also the 'Minimized View' functionality will no longer be supported. Instead there is the 'close group' which consists of the 'keep on top' and the 'close' button. In XTC mode the close group is replaced by the xtc button. This button gives the user access to the XTC settings and the performance meter for his setup.



We would like to encourage you to optimize your devices. Be aware that the new 'Protect and optimize' operation (Project Explorer -> RMB on node -> Protect and optimize) will delete all old surfaces (of the type ChildView). This is due to the fact that old surfaces have their ViewID set to 'Circuit' and all circuit elements will be deleted. So you should convert your device first (like it is explained in the following chapters) and apply this operation afterwards.
For building new devices it is important to note that this function will delete the surfaces of all the simple library modules except those from 'Empty Synth', 'Empty Effect' and the 'DefaultPanel'.
You should also set the 'Draw ClipChildren' and the 'Select ClipChildren' flags should as often as possible. Also 'ViewTree Group' should not be checked.

Pad names for insert effects


With the InsertRack and the MultiFX (in XTC) we provide some interesting tools. Especially in XTC mode it is interesting because the streaming of signals between the effects inside one MultiFX is handled by the card. This means the host is only communicating with the MultiFX. This reduces PCI overload and latency.
We would like to emphasize that for working with these devices you should name the Pads of your effects exactly as follows:

Stereo effects: 'InL', 'InR', 'OutL' and 'OutR

Mono effects: 'In' and 'Out

May we draw the difference between naming Pads of modules and those of devices at this point.
When dealing with modules, bipolar Pads are named in minuscules (lower case letters), unipolar Pads begin with a majuscule (capital letter). For devices all Pad names begin with capital letters.

Pads and Variables

In the past it sometimes became hard to manage and overview the Pad list for some modules because there were too many Pads. Normally you would not need so many Pads but they were there. In the new version a difference is drawn between a Pad and a Variable. A button was added to the Pad list window to toggle between Pad list and Variable list.

A Pad could be considered as a connection point of the module. A Pad is a variable that can be connected to other Pads. Variables cannot be connected to other variables or Pads. They can only be edited in the Variable list. You can transform each variable to a Pad (from the context menu of a variable) or transform a Pad to a variable by deleting it from the Pad list. A Pad demands more resources than a variable.

With the new concept it gets much easier to manage the Pads of a module and to make connections between different modules.

  © 2000, 2001 CreamWare GmbH. All features and specifications are subject to change without notice.
Product names are trademarks of their respective holders.