cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/26/17:52:20

From: jdevlin AT WPI DOT EDU (joseph devlin)
Newsgroups: comp.os.msdos.djgpp
Subject: MIDI/Interrupts/Timing?
Date: 23 Jan 1997 22:32:32 GMT
Organization: Worcester Polytechnic Institute
Lines: 72
Message-ID: <5c8ou0$8ln$1@bigboote.WPI.EDU>
NNTP-Posting-Host: bigwpi.wpi.edu
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp



	hello!

	im trying to write some midi software, using djgpp on a 386/40
	machine with 4mb of ram. I have an MPU-401 midi interface, and
	thanks to allegro, i have some simple code for putting it into
	uart mode and writing data to whatever port it is located at.

	the thing is, since this is midi software, timing is a huge issue.
	I wish for my program to send out midi clocks so that it will
	be synchronized with external midi devices, acting as the master
	clock.

	in case you dont understand, that means that for every quarter
	note, 24 midi clock bytes must be sent. at least this was my
	understanding.

	so, the rate at which midi clock bytes are sent is dependent
	upon the tempo at which playback occurs.

	here is what i have been experimenting with:

	i create a timer, whihc occurs 102 times every second. every tick
	of this timer, a midi clock byte is sent out of the mpu port.
	every sixth tick of this clock, a flag is set. if all goes well,
	this should represent the highest possible  tempo at which the
	software will run, or 255. 

	the flag is a message to a polling loop in the main function,
	which sits around waiting for the flag to occur. This represents
	the minimum resolution over which a user will have control, that
	is, sixteenth notes; if 24 ticks represents a quarter note, then
	six ticks represents a sixteenth note.

	every sixth tick, a function called workload is called. it was
	supposed to be a test of what sort of limits the system would
	have at various tempos. what it does is loops a certain number
	of times <this number is entered at run-time>, and during each
	iteration, it also sends out a midi clock.

	once the loop has finished, a message stating that it had finished
	and which sixteenth note had just been completed is printed.
	it then goes back to wait on the flag.

	the idea is that, if the workload function is able to complete
	the given number of sends for each tick, and print out finished
	results consecutively without skipping a segment, then it is
	able to handle that many transmissions at that tempo.

	anyhow, i have found that the performance is horrible. i assume it
	is because i am lacking the requisite skills or concept to
	build a device of such complexity, or maybe just because
	my computer is pretty poor. I tend to doubt this, though, because
	i have used windows midi software at such high speeds without
	problems.

	what im trying to figure out is if there is a way to tighten
	all of these timing issues. is there a way to avoid using
	a timer interrupt, or to avoid calling the handler at such 
	a high rate? is there a way to speed up port communications?
	is there a way to synchronize two timers, one at the very high
	rate of 102 ticks per second, and another at the considerably
	lower rate of 17 ticks per second, such that the slower is
	called every sixth tick of the faster? is there a way to do
	away with the faster timer alltgether <although i tend to
	doubt it>..

	anyhow, thanks for listening.

	joseph devlin

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019