[ Editor's note:
 [
 [ Further discussion should probably take place on the auxilliary
 [ "MMD-emulation" listserver, which was established for technical
 [ topics like this.  We are publishing it here tonight because
 [ Leonardo presents his case very well for structuring software
 [ to facilitate experimenting.
 [
 [ The familiar term is "Plug-ins", which are optional software modules
 [ which can be changed at will.  Thus you could compare the performance
 [ of Robbie's Ampico emulator Plug-in with one written by Horst Mohr,
 [ and so on.
 [
 [ Similar standards for the hardware would make it easy to substitute
 [ components built by different vendors.
 [
 [ Until investors discover a profit in preserving the music rolls,
 [ the development work will be done by experimenters, like Andy
 [ Taylor is doing.  Hardware and software Plug-ins, which conform
 [ to standard interface specifications, will make his task more fun!
 [
 [ Robbie Rhodes

Hi all,  In his comment to my latest message (970804 MMDigest), Robbie
mentioned to the possibility to establish a standard for translators; if
some standards are to be established, now is the time to do it, since
people that are developing translators are now stating their protocols.

I can give a contribution explaining the way I am developing my system.

I am trying to write a program intended to translate not only piano
rolls, but also other kinds of media, i.e., barrels, discs, books and so
on.  The idea was born when I built a barrel translator for an automatic
organ, last year, and, after few time, needed to translate a barrel from
another instrument, completely different in shape.  Then, I started to
think to a mecha-tronics device that would allow to manage very different
kinds of objects with the smallest possible change in the software and,
possibly, in the hardware stuff.

I developed the idea to build a program structured as a series of
modules, that can be interconnected partly by user choices, and partly by
the program itself, after an automatic check of the resources that are
available.  At present I have a collaboration with John McClelland, who
is developing the hardware part of the roll translator, based upon
optical scanning.  Of course, I do not pretend to complete all of the
modules in few time, since I make this job in my spare time: for example,
the module dedicated to the discs is still to be begun.  I just write
routines having a look to their compatibility with all foreseeable future
connections and extensions.  Other contributions could improve and speed
up the project.

As regards to the software, the system is made with a "core", containing
the high-level routines that, fundamentally, take care to receive the
data from the hardware device, send commands to it, draw the screen,
allowing the user to interact with the system, manage reading and writing
of files, and make the actual translation from the raw data to MIDI.  The
core does not interact with the hardware directly; it does not deal with
the specific features of the external devices, but outputs a series of
standardized commands, such as, for an example, "scan a line", or "read
pulse counter value", and so on.

Hardware devices may have very different modes of performing, but they
should reply to standardized commands by an uniform protocol.  This can
be realized by interfacing sensors either by a card managed by a
microcontroller, that should receive and output the ready-to-use data
that the program is expecting, or by a simpler card, that just converts
the sensors signals to a digital form, and such data could be
standardized by a "low-level" soft driver, that takes care to adjust the
signals coming from the sensors to the standard format (this is the way I
realized the barrel translator).

A soft driver is preferable since it allows to simplify the electronics
stuff, and gives a chance to improve or update the performance of an
external device by simply rewriting a part of it, without opening the
hardware or changing pre-programmed chips.  The driver, of course, should
be structured so as to give a proper response to standard calls, i.e., it
should have a series of entry points for them.

By such a structure, a translating system could be easily improved or
adapted to new and perhaps completely different hardware traps just
providing a minimum driver, that should be furnished by the constructor.
In the end, it is something like computer peripherals working: I can buy
a new, powerful printer or scanner, plug it in my old computer, install
the driver, and enjoy its improved features with my old graphical
program, or I can buy the latest version of a program, and use my old
peripheral with it.

The difference between this scheme and a stand alone translating program
is very small.  A well-done program should already have high-level
routines calling low-level ones; they just should be separated and stored
in different code segments, and calls should be conformed to a standard
protocol.

I have stated a series of standard calls, that should allow to change the
hardware without modifying the main program.  Should someone like this
idea and have interest in improving it, we can discuss.

As regards to Robbie's askings,

1) About the connection of the external device to the computer.  The
external hardware could be connected by a RS232 or RS422 serial port.
Although parallel ports are faster, the serial port is owned by whatever
kind of computer, and allows to use long cables being relatively immune
to electrical noise.  Moreover, most of suitable microcontrollers can
easily manage such a type of communication without slowing down the
performance.

2) About the time base.  The time base could be either internal or
external; in my barrel translator I used an external counter driven by an
optical encoder; in the roll reader I'm developing, the time base is
generated by the program, that directly drives the stepper motor and the
optical line scanner.  By a standard call, the hardware driver should
reply with a list of its features, and the program could react as needed.

3) About the format of the image to be stored.  I think that a real image
of the roll could hardly be stored as is; a complete image of a roll with
a reasonable resolution would require giant files, then it is preferable
to store the raw image in a somehow filtered format.  The easiest could
be to use a compression algorithm; nevertheless, I think that storing of
the image is a waste of disk space; perhaps it is preferable to store
information pertaining to holes as a compact block of "raw events"; the
irregularities of holes edges could be stored as little chunks of image
attached to each event.

It is important to establish a standard as soon as possible, otherwise a
general program will be constrained to provide a plethora of conversion
routines.

Kind regards to all

Leonardo Perretti