Camd Library - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:21:37Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:21, 26 January 2025
Line 31:		Line 31:

	MidiNodes are created by		MidiNodes are created by
	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	ICamd->CreateMidiA(struct TagItem *TagsList)		ICamd->CreateMidiA(struct TagItem *TagsList)
	</syntaxhighlight>		</syntaxhighlight>
	or by		or by
	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	ICamd->CreateMidi(Tag tag1,...).		ICamd->CreateMidi(Tag tag1,...).
	</syntaxhighlight>		</syntaxhighlight>
Line 109:		Line 109:
	To connect our MidiNode to a cluster,		To connect our MidiNode to a cluster,

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct MidiLink ICamd->AddMidiLinkA(struct MidiNode myNode, int32 type, struct TagItem *TagsList);		struct MidiLink ICamd->AddMidiLinkA(struct MidiNode myNode, int32 type, struct TagItem *TagsList);
	</syntaxhighlight>		</syntaxhighlight>
Line 115:		Line 115:
	or		or

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct MidiLink ICamd->AddMidiLink(struct MidiNode myNode, int32 type, Tag tag1, ...);		struct MidiLink ICamd->AddMidiLink(struct MidiNode myNode, int32 type, Tag tag1, ...);
	</syntaxhighlight>		</syntaxhighlight>
Line 166:		Line 166:

	From camd.h:		From camd.h:
	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	typedef union		typedef union
	{		{
Line 189:		Line 189:
	Each incoming MIDI event is both timestamped and marked with the linkage number (settable by the application) from the link that it came in on. Some people have questioned whether a task can respond fast enough to incoming MIDI data to meet professional standards of timing accuracy. Our experimentation has determined that a high-priority task (say, 30 or so), can meet these requirements, even when the disk drive is running.		Each incoming MIDI event is both timestamped and marked with the linkage number (settable by the application) from the link that it came in on. Some people have questioned whether a task can respond fast enough to incoming MIDI data to meet professional standards of timing accuracy. Our experimentation has determined that a high-priority task (say, 30 or so), can meet these requirements, even when the disk drive is running.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	uint32 SignalMask = (1UL << CamdSigBit) \| Other_bits_we_care_about;		uint32 SignalMask = (1UL << CamdSigBit) \| Other_bits_we_care_about;
	uint32 Signals = IExec->Wait(SignalMask);		uint32 Signals = IExec->Wait(SignalMask);
Line 209:		Line 209:
	Sending MIDI data is very simple, mainly a matter of filling out a MidiMsg structure and calling PutMidi(). Note that if the receive buffer is full, then the function will fail, rather than waiting for the receive buffer to empty.		Sending MIDI data is very simple, mainly a matter of filling out a MidiMsg structure and calling PutMidi(). Note that if the receive buffer is full, then the function will fail, rather than waiting for the receive buffer to empty.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	MidiMsg mm;		MidiMsg mm;
	mm.mm_Status = MS_NoteOn \| (chan-1); // for MIDI channel 1 to 16		mm.mm_Status = MS_NoteOn \| (chan-1); // for MIDI channel 1 to 16
Line 277:		Line 277:
	More details on all functions are in the autodoc at SDK:Local/documentation/autodoc/camd.doc.		More details on all functions are in the autodoc at SDK:Local/documentation/autodoc/camd.doc.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct MidiLink ICamd->AddMidiLink(struct MidiNode , int32 type);		struct MidiLink ICamd->AddMidiLink(struct MidiNode , int32 type);
	void ICamd->CloseMidiDevice(); /Not supported in AmigaOS 4.x/		void ICamd->CloseMidiDevice(); /Not supported in AmigaOS 4.x/
Line 327:		Line 327:
	Following is a complete example of "MidiThru". This is a virtual "patch cord" to connect MIDI clusters. The in and out cluster names are provided from the command line.		Following is a complete example of "MidiThru". This is a virtual "patch cord" to connect MIDI clusters. The in and out cluster names are provided from the command line.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	/*		/*
	** MidiThru.c		** MidiThru.c

Steven Solie: /* Creating a MidiNode */

2013-07-03T21:05:12Z

Creating a MidiNode

← Older revision		Revision as of 21:05, 3 July 2013
Line 25:		Line 25:

	Each MIDI application must create a MidiNode. This structure is used as a central dispatch point for incoming and outgoing messages, and holds all of the application-specific information, including:		Each MIDI application must create a MidiNode. This structure is used as a central dispatch point for incoming and outgoing messages, and holds all of the application-specific information, including:
	-- location and size of input buffers.		* location and size of input buffers.
	-- the name of the application		* the name of the application
	-- the icon to be used for the application in the patch editor.		* the icon to be used for the application in the patch editor.
	-- the address of the task to signal when messages are received, and the signal bit to use.		* the address of the task to signal when messages are received, and the signal bit to use.

	MidiNodes are created by ~~ICamd->CreateMidiA(struct TagItem *TagsList), or by ICamd->CreateMidi(Tag tag1,...).~~		MidiNodes are created by
			<syntaxhighlight>
			ICamd->CreateMidiA(struct TagItem *TagsList)
			</syntaxhighlight>
			or by
			<syntaxhighlight>
			ICamd->CreateMidi(Tag tag1,...).
			</syntaxhighlight>

	For both forms of CreateMidi, tags may include:		For both forms of CreateMidi, tags may include:

Steven Solie: /* The MIDI System */

2013-07-03T21:03:22Z

The MIDI System

← Older revision		Revision as of 21:03, 3 July 2013
Line 20:		Line 20:
	==The MIDI System==		==The MIDI System==

		⚫	The MIDI distribution system is based on the idea of "linkages" (called MidiLinks) between applications. Each application or hardware driver can establish linkages to other applications or hardware drivers. Multiple links can be established to a single source, so that more than one application can see the MIDI stream coming out of a hardware port or application output. Similarly, more than one application can send a MIDI stream to a single hardware port or application input. The ability to have one application send data to another allows "pipelining" of the MIDI stream, for example connecting an interactive composing program to a sequencer and running both concurrently. Note that there is no requirement that the data sent actually be valid musical data -- it is possible for a pair of applications to set up a private linkage, and communicate anything they want, as long as it follows the syntactic rules of MIDI. However, it is suggested that such linkages be hidden from the user using a special bit which makes a linkage private.
	The MIDI distribution system is based on the idea of "linkages" (called MidiLinks) between applications. Each application or hardware
⚫	driver can establish linkages to other applications or hardware drivers. Multiple links can be established to a single source, so that more than one application can see the MIDI stream coming out of a hardware port or application output. Similarly, more than one application can send a MIDI stream to a single hardware port or application input. The ability to have one application send data to another allows "pipelining" of the MIDI stream, for example connecting an interactive composing program to a sequencer and running both concurrently. Note that there is no requirement that the data sent actually be valid musical data -- it is possible for a pair of applications to set up a private linkage, and communicate anything they want, as long as it follows the syntactic rules of MIDI. However, it is suggested that such linkages be hidden from the user using a special bit which makes a linkage private.

	==Creating a MidiNode==		==Creating a MidiNode==

Steven Solie: /* Goals */

2013-07-03T21:02:33Z

Goals

← Older revision		Revision as of 21:02, 3 July 2013
Line 4:		Line 4:

	==Goals==		==Goals==

	The goals of CAMD are:		The goals of CAMD are:
			# To encourage development of music software and synchronized multimedia applications by providing a working driver to the public.

	1. To ~~encourage development of~~ music ~~software~~ and ~~synchronized~~ multimedia applications by ~~providing~~ a ~~working~~ ~~driver~~ to ~~the~~ ~~public~~.		# To enable music and multimedia applications to operate concurrently and exchange MIDI data in real-time.
		⚫	# To improve on existing "freeware" drivers by enhancing performance, by providing hooks for getting raw input, and by simplifying the interface as much as possible.

	2. To enable music and multimedia applications to operate concurrently and exchange MIDI data in real-time.

⚫	3. To improve on existing "freeware" drivers by enhancing performance, by providing hooks for getting raw input, and by simplifying the interface as much as possible.

	==Operating System Requirements==		==Operating System Requirements==

Steven Solie: /* Establishing Links */

2013-07-03T20:55:49Z

Establishing Links

← Older revision		Revision as of 20:55, 3 July 2013
Line 98:		Line 98:
	One of the advantages of the cluster model is that applications can be started up in any order and still work. The following are suggestions as to how applications should handle linkages:		One of the advantages of the cluster model is that applications can be started up in any order and still work. The following are suggestions as to how applications should handle linkages:

	1. An application should allow the user to see a list of existing clusters (which CAMD can provide), or allow the user to type in a new cluster name. (camdtools has ReAction based "clist.c" to help with this)		# An application should allow the user to see a list of existing clusters (which CAMD can provide), or allow the user to type in a new cluster name. (camdtools has ReAction based "clist.c" to help with this)
		⚫	# The application should save the current linkages either in the applications "settings", or embedded in the document or performance file (perhaps using an IFF chunk). When the application is restarted (or that performance loaded or whatever) the application should then automatically establish the links specified.

⚫	2. The application should save the current linkages either in the applications "settings", or embedded in the document or performance file (perhaps using an IFF chunk). When the application is restarted (or that performance loaded or whatever) the application should then automatically establish the links specified.

	If every application does this, then it will be easy for the user to set up the same configuration of linkages as they did last time, even if they launch their applications in a different order. Even if the applications are invoked via a script, the network of applications can come into existence automatically.		If every application does this, then it will be easy for the user to set up the same configuration of linkages as they did last time, even if they launch their applications in a different order. Even if the applications are invoked via a script, the network of applications can come into existence automatically.

Steven Solie at 21:47, 21 March 2013

2013-03-21T21:47:34Z

Show changes

Steven Solie: /* MIDI Timestamps */

2013-03-21T21:41:14Z

MIDI Timestamps

← Older revision		Revision as of 21:41, 21 March 2013
Line 294:		Line 294:

	==MIDI Timestamps==		==MIDI Timestamps==
	Each incoming MIDI message may be timestamped, however, you must
	supply a source of timing information (the recommended method is to use
	RealTime.library, however many other timestamp sources are possible).
	You can tell CAMD to use a particular timing source. The MidiNode
	contains a pointer (of type LONG *), which may be pointed to the source of
	timestamps. Whenever a MidiMsg is received, the longword that is pointed
	to by this pointer is used as the current time, and copied into the
	MidiMsg. Normally, what you would want to do is point this pointer at a
	longword that was contually being updated. Note that in this fashion, your
	application can have timestamps in any format it wants, since CAMD never
	looks at the timestamp field once it is set.
	One important point is that the timestamp is set at the time the
	message is placed into the receiver's buffer. It would have been nice to
	timestamp the messages at the interrupt time of the first MIDI status
	byte, however this would have made the cluster model of distribution
	impossible. Application which desire ultimate accuracy should probably
	adjust the timestamp to compensate for the length of the MidiMsg.

			Each incoming MIDI message may be timestamped, however, you must supply a source of timing information (the recommended method is to use [[RealTime_Library\|RealTime Library]], however many other timestamp sources are possible). You can tell CAMD to use a particular timing source. The MidiNode contains a pointer (of type LONG *), which may be pointed to the source of timestamps. Whenever a MidiMsg is received, the longword that is pointed to by this pointer is used as the current time, and copied into the MidiMsg. Normally, what you would want to do is point this pointer at a longword that was continually being updated. Note that in this fashion, your application can have timestamps in any format it wants, since CAMD never looks at the timestamp field once it is set. One important point is that the timestamp is set at the time the message is placed into the receiver's buffer. It would have been nice to timestamp the messages at the interrupt time of the first MIDI status byte, however this would have made the cluster model of distribution impossible. Application which desire ultimate accuracy should probably adjust the timestamp to compensate for the length of the MidiMsg.
⚫	CAMD ignores timestamps internally.If you don't require them, feel free

	to ignore timestamp initialization completely.
		⚫	CAMD ignores timestamps internally.If you don't require them, feel free to ignore timestamp initialization completely.

	==Interfacing to Hardware==		==Interfacing to Hardware==

Steven Solie: /* Example code */

2012-08-15T19:02:52Z

Example code

← Older revision		Revision as of 19:02, 15 August 2012
Line 388:		Line 388:

	==Example code==		==Example code==

	Following is a complete example of "MidiThru".
	This is a virtual "patch cord" to connect MIDI clusters.		Following is a complete example of "MidiThru". This is a virtual "patch cord" to connect MIDI clusters. The in and out cluster names are provided from the command line.

	The in and out cluster names are provided from the command line.
			<syntaxhighlight>
	<pre>
	/*		/*
	** MidiThru.c		** MidiThru.c
	** AmigaOS 4.x version
	** Creates a link between named clusters		** Creates a link between named clusters
	** 3/24/2012 Lyle Hazelwood		** 3/24/2012 Lyle Hazelwood
Line 417:		Line 416:
	int main(int argc, char **argv)		int main(int argc, char **argv)
	{		{
	MidiMsg mmsg;		MidiMsg mmsg;
	uint32 signal;		uint32 signal;
	BOOL alive = TRUE;		BOOL alive = TRUE;
Line 440:		Line 439:

	// We create our MidiNode here, requesting buffers as desired		// We create our MidiNode here, requesting buffers as desired
	ournode = ICamd->CreateMidi( MIDI_MsgQueue,2048L,		ournode = ICamd->CreateMidi(MIDI_MsgQueue, 2048L,
	MIDI_SysExSize,10000L,		MIDI_SysExSize, 10000L,
	MIDI_RecvSignal,midisig,		MIDI_RecvSignal, midisig,
	TAG_END);		TAG_END);
	if(NULL == ournode) bailout("Can't Create MidiNode");		if(NULL == ournode) bailout("Can't Create MidiNode");

	// This is our input stream of MIDI messages		// This is our input stream of MIDI messages
	fromLink = ICamd->AddMidiLink(ournode, MLTYPE_Receiver,		fromLink = ICamd->AddMidiLink(ournode, MLTYPE_Receiver,
	MLINK_Location,argv[1],		MLINK_Location,argv[1],
	TAG_END);		TAG_END);
	if(NULL == fromLink) bailout("Can't Add Input Link");		if(NULL == fromLink) bailout("Can't Add Input Link");

	// and our output stream		// and our output stream
	toLink = ICamd->AddMidiLink(ournode, MLTYPE_Sender,		toLink = ICamd->AddMidiLink(ournode, MLTYPE_Sender,
	MLINK_Location, argv[2],		MLINK_Location, argv[2],
	TAG_END);		TAG_END);
	if(NULL == toLink) bailout("Can't Add Output Link");		if(NULL == toLink) bailout("Can't Add Output Link");

Line 471:		Line 470:

	while(ICamd->GetMidi(ournode, &mmsg))		while(ICamd->GetMidi(ournode, &mmsg))
	{ // Every message we get...		{ // Every message we get...
	ICamd->PutMidi(toLink, mmsg.mm_Msg); // we send back out.		ICamd->PutMidi(toLink, mmsg.mm_Msg); // we send back out.
	}		}
	}		}
Line 498:		Line 497:
	if(reason) exit(-1);		if(reason) exit(-1);
	}		}
			</syntaxhighlight>
	</pre>

	==Further Resources==		==Further Resources==

Steven Solie: /* Function List */

2012-08-15T18:58:32Z

Function List

← Older revision		Revision as of 18:58, 15 August 2012
Line 335:		Line 335:
	SDK:Local/documentation/autodoc/camd.doc.		SDK:Local/documentation/autodoc/camd.doc.

			<syntaxhighlight>
	<pre>
	struct MidiLink ICamd->AddMidiLink(struct MidiNode , int32 type);		struct MidiLink ICamd->AddMidiLink(struct MidiNode , int32 type);
	void ICamd->CloseMidiDevice(); /Not supported in AmigaOS 4.x/		void ICamd->CloseMidiDevice(); /Not supported in AmigaOS 4.x/
Line 371:		Line 371:
	void ICamd->UnlockCAMD(APTR);		void ICamd->UnlockCAMD(APTR);
	BOOL ICamd->WaitMidi(struct MidiNode , MidiMsg );		BOOL ICamd->WaitMidi(struct MidiNode , MidiMsg );
			</syntaxhighlight>
	</pre>

	// Note: OpenMidiDevice and CloseMidiDevice are not supported.		{{Note\|text=OpenMidiDevice and CloseMidiDevice are not supported. Camd simply opens all devices found in DEVS:Midi}}
	// Camd simply opens all devices found in DEVS:Midi

	==Credits==		==Credits==

Steven Solie: /* Filters */

2012-08-15T18:57:15Z

Filters

@@ Line 265: / Line 265: @@
 ==Filters==
--- controller change single byte
+# program change
--- mode change messages
+# controller change LSB
--- system exclusive messages
+# mode change messages
 In addition, there is a special filtering system for SysEx messages