|
|
enum |
enum |
This type is sent as header of each MCOP message.
This is sent as start of each normal (twoway) invocation
This is sent as start of each oneway invocation
Body of the mcopServerHello MCOP message
Body of the mcopClientHello MCOP message
The message you get when you connect a MCOP server. The MCOP server can send you some useful information here. Usually, it will send you
GlobalComm=<object reference of a global comm interface> InterfaceRepo=<object reference of an interface repository>
But as this is called "hints" it doesn't necessarily need to happen.
An object reference
The definition of a parameter of a method
hints is reserved for future extensions, such as default, min and maxvalues
enum |
Twoway methods are such where the calling process does a call and is suspended until some result (maybe even a void result) gets back.
Oneway methods are one shot and forget methods: you send the invocation, and continue. Maybe it will be received, maybe executed later. You will never hear the result.
The definition of a method.
hints is reserved for future extensions, such as default, min and maxvalues
enum |
an attribute
flags should contain things like
The definition of an attribute and/or stream
hints is reserved for future extensions, such as default, min and maxvalues
InterfaceDef - interface definition structure
defines what methods/attributes a particular interface supports: these do not contain the methods/attributes of inherited interfaces.
inheritedInterfaces only contains the names of Interfaces that this one inherits in exactly one step. So to see if interface XYZ is inherited from ABC, you need to check the "inheritedInterfaces" of XYZ, and their "inheritedInterfaces" and their "inheritedInterfaces" and so on.
- NB20000320: defaultPorts allows to connect to those port by default if connection is made in the corresponding direction. It cannot be just an attribute flag because of the syntax on a separate line.
hints is reserved for future extensions, such as default, min and maxvalues
One component of a struct
hints is reserved for future extensions, such as default, min and maxvalues
The definition of a struct
hints is reserved for future extensions, such as default, min and maxvalues
One item of an enum value
hints is reserved for future extensions, such as default, min and maxvalues
The definition of an enum
hints is reserved for future extensions, such as default, min and maxvalues
The contents of an idl file
hints is reserved for future extensions, such as default, min and maxvalues
The interface repository
enum |
Internal use: implement distributed asynchronous streams.
The FlowSystemSender object transmits the packets that should be sent over the stream via _allocCustomMessage (Object_base).
Internal use: implement distributed asynchronous streams.
The FlowSystemReceiver object receives and extracts the packets sent by the sender object and injects them in the notification system again.
A flow system.
Flow systems handle the streaming between MCOP objects. As this streaming is network transparent (at least for asynchronous streams) they have this remote interface.
A global communication space used to obtain initial object references
MCOP needs a way to connect to initial (global) object references. This is done by these global communication spaces.
global communication based on the /tmp/mcop-<username> directory
TraderOffer - this contains an offer of an object (which is usually returned as result of a query.
TraderQuery - this is a query against the trader. The idea is simple: you say what you need, and the trader offers you components that do what you want.
Arts::Object is the base object that every interface implicitely inherits
it is also the source for generation of the Object_stub stuff (use mcopidl -e Arts::Object to avoid code generation for this interface)
a simple struct which can hold any other type
enum |
The SynthModule interface is the base for all modules containing streams.
There are two goals achieved by this interface. On one side, there is functionality which users of stream carrying modules want to use (which is: start streaming, stop streaming).
On the other hand, there is functionality which the flow system will use to achieve these goals.
Plays a stream of audio data to the soundcard
Records a stream of audio data from the soundcard
A frequency generator
This kind of object is used to create frequencies. Oscillators are connected at the output of this object
A sine wave
A module which mixes an arbitary number of audio streams
A module which adds two audio streams
Multiplies two audio streams
This plays a wave file
sends data to a bus - busses are dynamic N:M connections - all signals from all uplinks are mixed together, and sent to all downlinks
receives data from a bus - busses are dynamic N:M connections - all signals from all uplinks are mixed together, and sent to all downlinks
Byte stream to audio conversion object
Converts an asynchronous byte stream to a synchronous audio stream
Base interface for all stereo effects
this is a simple clipping stereo volume control
A funny FFT scope
A stack of stereo effects
enum |
Information structure for audio manager clients
an audio manager client
The audio manager interface
This is a virtual output port, which you use to play data. Where exactly this data gets played is managed by the audiomanager.
Creation: there are two ways to initialize a Synth_AMAN_PLAY - one is to set title and autoRestoreID to sensible (non empty) values. The other is to pass an already initialized AudioManagerClient on the constructor.
This is a virtual input port, which you use to record data. Where this data comes from is in turn managed by the audiomanager.
Creation: there are two ways to initialize a Synth_AMAN_RECORD - one is to set title and autoRestoreID to sensible (non empty) values. The other is to pass an already initialized AudioManagerClient on the constructor.
Producer of byte sound
This is used inside the sound server interface
This is a very simple sound server interface
WARNING: This currently inherits a KMedia2 PlayObjectFactory for test purposes, but don't rely on that
enum |
This is an enhanced sound server interface which can be used to query status information or suspend the soundserver right away
A KMedia2 Wave PlayObject
enum |
enum |
KMedia2 time information
This is a time value which contains either milliseconds & seconds, or a custom unit or both. It is a flexible time base.
If a value isn't there, it is set to -1.
private part of the PlayObject API (don't use)
KMedia2 PlayObject - these can be used by Kaiman for instance
use this to create new PlayObjects for media
enum |
enum |
ConnType (maybe obsolete)
ConnType: (connection type) this is wether this value is used
- once (such as a filename of a waveplugin) -> property this implies that the allowed connection is only value
- event based (such as midi events) -> event when events arrive, they are processed, when no events arrive, don't care
- stream based (such as audio streams) -> stream every calculation of the module consumes/creates a sample that means: no data = no calculation possible
WARNING: This is part of the artsbuilder dynamic programming interface as the MCOP port isn't there yet, this stuff may change
PortType (maybe obsolete)
isMultiPort specifies if the port can take multiple incoming connections or not. This is only relevant/allowed for input ports, the output of all output ports may be connected to any amount of receivers.
Ports which can take multiple connections are handled differently internally. (Also, artsbuilder needs to know whether to allow multi- connections or not).
WARNING: This is part of the artsbuilder dynamic programming interface as the MCOP port isn't there yet, this stuff may change
an absolute timestamp
enum |
different status of a midi command
enum |
the following are to be used once status is (mcsParameter|channel):
a midi command
a midi event
a midi port
enum |
enum |
information about a midi client
a midi manager client
Some general notes to the understanding of the midi manager. The midi manager has the task to intelligently assign applications to destinations.
It is important to understand what it actually does to understand the distinction first, which is expressed through the "MidiClientType" of each client.
APPLICATIONS: An application is a user visible application, that produces or records midi data. It is important for the understanding of an application, that an application actually *wants* to be supplied with data, or wants to get its data played. Thus, adding an application to the midi manager is an implicit request: "go and find a place where to put the events to (or get the events from)".
Examples for applications would be games or midi players.
DESTINATIONS: A destination is a system service that plays or supplies midi data. The characteristic here is that a destination is something that is there if you need it.
Examples for destinations might be might be a hardware device or an emulation of a hardware device (such as a virtual sampler).
So the process is as follows: - destinations register themselves at the midi manager, and provide system services in that way
- when the user starts an application (such as a midi player), the midi manager's task is to assign it to a suitable destination
- the user can interact with the process by changing the way applications are assigned to destinations - the midi manager will try to learn what the user wants, and next time do a better job while assigning
To actually record or play some data, you need to register a client first, and after that, you can add Input or Output "MidiPort"s to your client, so that you can actually send or receive events with them.
this interface currently has probably a problem - usually, if you are using such a module, you would expect that you can specify the filename with it - BUT, if you allow this, then any instrument definition file (.arts) and similar might overwrite every file the user can access, which might not be what you want, so I currently save it to a file in /tmp/mcop-<username>/capture.wav (which might be unlucky since the user might not have too much space there)
Generated by: stefan@stefan on Sat Feb 24 19:11:36 2001, using kdoc 2.0a47. |