| Title: | * * Computer Music, MIDI, and Related Topics * * |
| Notice: | Conference has been write-locked. Use new version. |
| Moderator: | DYPSS1::SCHAFER |
| Created: | Thu Feb 20 1986 |
| Last Modified: | Mon Aug 29 1994 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2852 |
| Total number of notes: | 33157 |
Starting the software piece of a home project, a Z80 based microP
doing MIDI mergeing, filtering and conversions I have some specific
questions to those MIDI-gurus out here;
Is it ever possible, from proper designed hw/sw, to get MIDI bytes like
MIDIclock and active sensing, in between 2/3 bytes strings like note on,
Control Change and others??
Normally you would expect a note on message to be uninterupted and
delaying the clock like: 9n cc vv F8 .... and not like this:
9n F8 cc vv.
What about when you are sending Sys exe messages, could they be
interupted by anything like note off or clocks or are the different
messages prioritized??
Second: Is the "running status" consept used widly in todays gear??
I find this project very interesting, imagine doing 3 in to 1 out merge
with different filtering and conversion for each input and not loosing
your timing :-)
Torbjorn
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2424.1 | 4GL::DICKSON | Mon Aug 27 1990 13:25 | 7 | ||
Both regular messages (like note-on) and SYSEX messages can and are
interrupted by Clock messages.
"Running status" is indeed used.
You can't predict what people are going to do. The only way to be sure
you have it right is implement the full MIDI spec exactly as published.
| |||||
| 2424.2 | Z80? what fraction of the speed of light? | LEDDEV::ROSS | shiver me timbres.... | Mon Aug 27 1990 19:18 | 27 |
Agree...But unfortunately, the SPEC does not help you understand
the implimentation details necessary for 'problem situations'. You
only hope you can envision them all.
Even with 0 time CPU and UART delay, just 'wrapping' a midi byte will
RESULT in ~600 usec delay from source to reciever ( uart byte assemble
is one byte time...then CPU/UART access...then get the byte to UART,
then its one more byte time till it's OUT the serial line...
Um, start expecting lots of delay.
Like 2 sources sending sysex, or continuous controller info. Dont worry
about CLOCKS! They're SLOW!!!!!!!!!! Sure note ons with running status,
and then some clocks, and then pitch bend, and aftertouch, and then
a sysex dump (nothing in the spec to dissalow this) and finally the
note offs.....
So start figuring how big your buffer needs to be to handle same...
Merging......stuck notes on.......two of the buggaboos of the
MIDI architecture. cest la muse.
Good luck.
ron
| |||||
| 2424.3 | You think 8Mhz Z80 is old stuff ?? | STKAI2::HALL | Thu Aug 30 1990 14:54 | 24 | |
For sure, you must be looking into the timing aspect as well.
Maybe my original question about real time meassages occurances wasn't
clear enough. LAst night I hooked up my ROLAND E20 to my microP, made a
small program, (assembler code) to send all MIDIbytes at the input port
through a FIFO buffer, converted into ASCII and then to my terminal
(ATARI ST running VT52 emulator at 9600 baud). The E20 sends all the
accomp. music out on MIDI including clocks. Turning the tempo to 240
BPM and starting a SAMBA rythm (with plenty of 16th notes accomp.)
seeing the MIDIstream in HEX on the screen, I never noticed that any F8
clock bytes appeared inside the note on/note off messages. I.e the
(9n xx vv) three bytes always were bounded together and never looked
like 9n xx F8 vv.
--
Maybe the E20 has good software but is this good behaviour specified in
the MIDI specs?? Are the specs this detailed??
Torbjorn
P.s I also noted that the E20 sends release velocity, not mentioned
anywhere in the documnetation. That's pretty good for a home type of
keyboard. :-) D.s
| |||||