perlman@wanginst.UUCP (Gary Perlman) (07/15/85)
I am requesting this information for a friend at Cornell. She has a Roland MPU 401 and an IBM [PCA]T and is planning to do some research on music perception. She needs some assembly language routines, or even some Pascal routines, for doing basic stuff to control a synth (Roland Juno 106, although I don't think that matters). Her experience with assmebly language is limited to an undergraduate course in IBM 370 ASM. Any help: pointers to public domain software (even a few simple routines) pointers to humane documentation on MIDI pointers to for-profit software packages would be appreciated. Please send responses to me. -- Gary Perlman Wang Institute Tyngsboro, MA 01879 (617) 649-9731 UUCP: decvax!wanginst!perlman CSNET: perlman@wanginst
andy@sdcarl.UUCP (Andrew Voelkel) (07/20/85)
This is a repost with some more verbosity. Sorry for the somewhat unreadable
form (it's troff -ms)
This is for public domain midi software for the ibm pc and the Roland
MPU-401
.sp 1i
Dear Person,
.sp .25i
.PP
Sorry to be impersonal. I'm getting a good deal of response so I'm having
to write a general cover letter. Fortunately I'm not getting swamped enough
to do things like not give out my phone number (it's 714-621-4308). I'm
writing this in the hopes of getting things off to a good start. I'd appreciate
it if you folks could each write me a little bit letting me know where you
are at in the following ways:
.PP
What is your hardware configuration? P.C or clone? 4.77 or 8Mhz? How much
memory do you have? Particularly, do you know if your interrupt number 2 and
i/o port addresses 330-337 are free? If you have a standard p.c. without
special stuff (serial, parallel and hard disk are not special) you should.
Are you running a standard color card, hercules graphics, or other display
card? If finding out these answers presents a problem, don't sweat it.
.PP
What synthesis or sampling hardware do you own or plan to own? This info
will help insure that two different patch editors don't get written for the
same machine.
.PP
Are you just a potential end user or are you willing to get involved in
writing code for your area of special interest? My general thought is that
I'd like to get this stuff out to code writing types first, so that any
major boo-boos I might have made will be found quick and by someone that
might be able to at least help towards pointing out the source of the problem.
I'd hate to hang up some musical project because of a unknown bug, but I
can let out the current stuff now. Waiting a while longer will result in
more complete programs is all.
.PP
For you programmers, do you code in C? This would certainly help. If
so, what compiler(s) do you use? What problems have you had with them?
More on this later.
.PP
Specifically, what are your musical goals regarding midi and PCs?
Sexy multitracking packages? Algorithmic composition? Improvisatory realtime
applications? This info will help me in trying to make sure that if x
person is working on something specific, y person will know about it
and not unnecessarily duplicate it.
.sp .25i
MY OVERALL GOALS AND CONCERNS:
.sp .25i
.PP
It has astounded me, being involved in hardware and software development for a couple years, how much longer it takes to write code for
a given hardware configuration than to put together the hardware. This,
I think, is why a hardware hacker such as myself decides to purchase
hardware that is arguably becoming obsolete (the pc). The moral of this
story is to realize the incredible value of device independent software.
This is of utmost importance to me. I'd like to make sure that any code
I write will run on another machine without much modification. Since
the mpu401 can be interfaced to any parallel bus, it doesn't present much
problem in this respect. And the most pervasive programming standard
these days is C and the UNIX-like file interface functions it supports.
.PP
This leaves two potentially sticky areas for making sure that a
public domain midi software base doesn't dissappear with the ibm pc.
One is the temptation to write code in assembler. I know it runs faster,
but my opinion is that it is not a particularly wise move. I've written
my interrupt driver in assembler but nothing else.
.PP
The other sticky area is graphics. How many packages will run on the
ibm color card but not on the Hercules graphics, or vice versa? And what
about the EGA card or the graphics interface on an Atari ST? This is
an area I'm not sure how to approach. Should I use a complete package
like GEM which has a good chance of being supported on many machines, or
just define a set of primitives for lines, circles, etc. which can be
rewritten for another graphics card. If anyone has had a bit of
of experience in this area, I'd really appreciate some feedback. So
far, I've just shied away from using any graphics (though I'm not really
to that point anyway).
.sp .25i
WHAT I HAVE SO FAR:
.sp .25i
The basic overdub program. It is inclusive of record and play, and uses
the interrupt driver and dynamic memory allocation schemes I have running.
Parameters to the program (tempo, input and output files, etc) are
specified on the command line a la UNIX.
.PP
The interrupt driver, which is written in assembler. It is designed to
handle four mpu401s (or less), and works simply. It determines what the
reason for the mpu401 is, then takes appropriate action. For record and
play, it calls queing routines that read or write from a global queue.
The state of this queue is easy to obtain from C, so record and play
can take place fairly transparently. For more obscure functions, the
interrupt driver will call a C routine written by the user, which will
take the necessary actions.
.PP
An alphanumeric midi dissassembler. This gives human readable output of
a midi file, and provides elapsed time, etc. This program was ported
from a UNIX program written by D. Gareth Loy.
.PP
A merging program. It simply merges two files (in mpu format) together
into one.
.PP
A midi channel mapping program. Takes an input files and maps information
on specified midi channels to other midi channels.
.PP
A general purpose parsing routine. Takes mpu format input and unpacks
it into a form that is easy to modify in various ways. The accompanying
unparser can be used to convert other score formats into mpu streams.
I plan to use this shortly to write a form program, which will take
recorded passages and expand them into forms. This will be groundwork
for realtime versions of the same.
.sp .25i
PLANS FOR FUTURE
.sp .25i
My long term goals involve realtime transforms of live midi performers and some
score control. I plan on taking two approaches towards that goal. One
is to develop the above mentioned parsing routine to work in realtime
and experiment with it, first doing simple things like keyboard splits.
I also plan to implement a programming environment called Player (also
developed by Gareth Loy) on the pc. It is a simulated multiprocessing
environment in which many parallel processes can run together, and is
designed for a realtime music environment.
.sp .25i
C COMPILER ISSUES
.sp .25i
Much of my initial hassles involved getting C to talk to assembler,
using assembler calls C, C calls assembler, and sharing global memory.
Although the problems were obvious once I found them, it would have
helped to have had a better explanation of this. I've found no major
bugs but have run into a couple annoyances.
.PP
The first one is that it has trouble reading binary input from
stdin. When is bumps into an end of file character it aborts. This
is pretty annoying but I've worked around it so far. The other annoyance
is the lack of an isatty() function. I'd also like it to be able to
produce Microsoft format assembler.
.PP
I see no major problems using another C compiler. If you have another
one, you might send me a copy of the assembly language calling convention.
I'd also like some feedback on other compilers. I have Desmet, CiC86,
and Lattice 2.0. Desmet only supports small model so I don't want to
get too involved with it. I have messed around a little with cic86 but
my initial impression was negative. I have no Lattice manual so I
haven't done anything with it. The grapevine indicates that Microsoft
C 3.0 is the ticket. Anyone have it? It has isatty() and expands
command line wildcard before calling programs, as well as producing
great code, I hear. Any comments?
.sp .25i
ANYONE HAVE A SHELL?
.sp .25i
The stuff I've written so far either works from the command line or
is a raw function. This works fine under unix because the shell gives
you so much flexibility. While eventually I'd like to get a nice editor-
like user interface going, right now I'd rather concentrate on the building blocks. Does anyone out there know of a unix-like shell that remembers
recent commands and can reexecute them, with slight modifications? Just
this would make things very usable very soon. Or does anyone have experience
using the DOS EXEC call so I could write my own?
.PP
I could also use help finding a good public domain make program. Can
anyone help?
.sp .25i
TO GET WHAT I'VE GOT
.sp .25i
I'm happy to send out what I've got right now. As I mentioned above,
if you are just a user, I'd recommend waiting a couple weeks to get
something more complete. Anyway, send a stamped, self-adressed mailer
with two floppies to:
.sp .25i
Andy Voelkel
910 Pomona ct.
Claremont, Ca. 91711
714-621-4308
.sp .25i
FURTHER NOTES
.sp .25i
There is some interest at Byte Magazine in a possible future article concerning what develops. So at some point anyone wishing to contribute some words
about something they might have develop may have a chance to write some
(if they want). I hope there's a lot to write about.
I'll be writing a follow up letter to you all after I get back some
response to this one. I think it would be good for everyone to know what everyone
else is up to. If this bothers anyone, let me know.
--
Andrew Voelkel
{ucbvax,ihnp4,akgua,hplabs,sdcsvax}!sdcarl!andy