Conference napalm::commusic_v1

    Hey!  There's no mention of MIDI in here ...   Well, we'll see about
    THAT ...
    
    Steve

    re: .1
    
    Ya know, that was the first thing that crossed my mind when I read
    this also. No mention of such key "buzzwords" as...
    
              MIDI
              Sequencer
              Synthesis
              Sampling
              MIDI file format
              Sample dump standard
    
    Maybe the inclusion of these items is intuitively obvious to those
    more familiar with this type of engineering than I, but .0 sounds
    like it's not taking advantage of lots of existing technology.
    
    Edd

I agree that the absence of SMF (Standard MIDI File) capability is a deficiency.
However, SMF itself is not complete in terms of full multimedia sequencing, so
it would have to be just one part of the architecture unifying audio and video
(as well as any other synchronized events).

What would seem virtually mandatory, however, is the use of SMPTE as an allowed
coordination mechanism to synchronize audio and video/screen display segments.
I've worked with CDA in the past and seem to recall that the "hooks" for video
sequences were present, but ill-defined; is SMPTE already in the spec, maybe?

Another noticeable omission was the Amiga as a potential delivery platform. One
very viable market for CDA audio/video/voice recognition systems is CIM, and
it seems that cost per seat is *always* a prime consideration in such
high-volume sales. Use of the Amiga as a delivery platform could provide strong
leverage in this market.

Cheers,
	Bob

    According to Jim Gettys and the Multi_Media conference, the 'LoFi'
    DECaudio turbochannel board is a DSP56001, and the attachment options 
    will provide both AES-EBU and line-level RCA inputs and DAC & ADC to 
    allow stereo sampling and playback.
    
    karl

    I asked Tom to post .0 in this conference after having received a copy
    directly in the mail.  I think the folks in this conference bring a
    very different perspective on what should be included in the audio part
    of a compound document system.   I believe that most folks working on
    this at Digital are primarily coming a perspective of storing voice in
    documents.  Secondarily they may be coming from a perspective of
    storing and accessing sounds created by a digital signal processor such
    as in the DECaudio board (LoFi is a real misnomer at this point).
    
    I don't think the MIDI perspective is in the forefront of this work.
    I hope that COMMUSIC folks who have a great deal of experience in this
    area can bring this expertise to the design of CDA audio.  For
    instance, my understanding of the DECaudio board is that there is at
    least some minimal support for MIDI there - not as much as some
    applications need, but enough for many applications that might use
    MIDI.  I hope that CDA Audio can be designed so that at least some
    basic MIDI-related functions are supported.
    
    Please don't assume that MIDI, SMPTE, or anything else is included in
    the spec unless you saw it listed explictly in that note.  If you have
    specific ideas/requirements for storing MIDI or other audio data in
    documents, please send them in by April 19.

Clearly, the existing goals are to provide means for moving around and
editing digital sound samples.  The file formats mentioned are all
sampled audio.  This, clearly, is only half the problem.

The obvious way to compare what they are doing with technology that is
generally understood is to tell them that they are doing the equivalent
of "image processing" on scanned images, and what is missing is the
equivalent of "ascii text", which for sound is a Midi file.

Just as you can convert ascii text to an image by applying a
transformation that includes font definitions, etc., you can convert a
midi file to a digital sound sample by applying a transformation that
includes the characteristics of a specific SGU.  A reasonable
presentation of Midi data on a low end workstation is to send sine
waves of the appropriate frequencies to the feeper in the keyboard (I
know, current keyboards can't do that...Oh well, perhaps you can click
it to the drum track....)

    I question whether to jump up and down re MIDI storage/retrieval.  I do
    agree that wiring AUDIO (that's CD quality, BTW) storage/retrieval into 
    our offerings will be a big win.  Is a DECstation or VAXstation an 
    appropriate tool for MIDI ?  
    
    Can you imagine the cost of Master Tracks Pro running on DEC gear ?  Are we
    going to chase Digidesign and Vision to port ?  Why DO you guys think
    MIDI is an appropriate option, given the dearth of affordable tools ? 
    Do you think disk-full DS5000/200's with DECaudio boards are going to
    set the digital recording world on fire ?  I don't; if I absolutely
    HAVE to have MIDI and digital audio I'll go for a loaded MAC or AMIGA.
    
    comments / rebuttals ? - karl

Re .7:

As regards MIDI/SMPTE or any music-related applications in the context of CDA,
I think the major point is simply to be able to *incorporate* information which
is in any of the industry-standard formats, and to do so in a way which is also
at least compatible with existing standards.

Given that CDA is a *document* architecture, the basic requirement seems to be
that a document be seen as being time-structured as well as space-structured
(i.e., page formatted). Once this aspect is guaranteed to be recognized, the
floor is open for discussion of *what* basis to use for a document's time
structure (enter SMPTE), and for *what* forms of information can be accepted for
defining a document's audio content within one of the supported timeframe
definitions (enter MIDI). The advantages both have are (a) they're already
developed, and (b) tools which use both to generate information exist in
abundance.

A large practical consideration which supports the use of MIDI for CDA audio is
simply storage space. If folks miss the boat and go strictly for digitized
sound, the storage space required for documents will be staggering- or sound
just won't be used! MIDI represents a well-developed way to store at least one
part of the audio content in a fairly compact way.

All that said, your main point is well taken- when all you have is a hammer,
everything does look pretty much like a nail.

Cheers,
	Bob

    I can think of a reason to support MIDI - ACE!  Under this program we
    should begin to see applications supported by Digital and many other
    vendors that will bridge PC users with mini's and such.  Digital has
    made a strong statement about supporting open standards.  MIDI is one
    of the most successful industry standards there is.  To leave it out
    would be, IMHO, a blunder that would send a confused message.  Sure,
    there might not be a big market for MIDI applications in particular.
    But, tell that to someone who is choosing between a DECstation and some
    other station that can hook up to MIDI.  Our own arrogance about his
    particular application (which uses a well-known and widespread industry
    standard) being "too small" a market will really tell him what we think
    about supporting open architectures and industry standards.
    
    Steve

re: mater tracks pro on a vax

I'd think that by using vaxpc or softpc you could use a number of existing
ibm/dos sequencers to great advantage as long as the hardware (MIDI) interface
got straightened out.

I do agree that vax software is a bit pricy though...

dbii

    
    Jeez, and no mention inthe spec about sample dump standard either.
    Seems like as big a deal as MIDI. This shouldn't be that hard to work
    into the CDA architecture...
    
    /pjh

As much I can recall, the CDA Audio spec directly specifies its separation from
the issue of synchronization with other media (e.g. video). Currently, there is
work going on at the research (and A/D) level to include synchronization features
in CDA. This effort is sponsored by OSAG under the EERP (European External
Research Program) program.  

Regards,
/Massimo   

I'm the architect (I hate that word, but that's what they call me) for this
work, so let me try to clarify a couple of points here.

First, this call for requirements received a wide distribution precisely because
we want feedback, so we welcome all the comments here.  As it says at the very
beginning of the memo, we wrote down an initial cut at the requirements
primarily to get people thinking and agreeing or disagreeing.  Requests like
"What would you like to see Digital do with audio?" tend to get greeted with
"Huh?"  We were just trying to avoid that reaction.  We aren't necessarily
wedded to what was written there.

While we welcome all input, business cases with strong supporting arguments
carry the most weight.  We like to do fun things as much as the next person,
but we really can't afford to unless they will make money.  Also, please make
sure that you send your input to Tom Stones so that it gets considered.
Although we try, it is difficult for us to follow all of the different notes
conferences that this notice got posted in.

Our current thoughts are centered around digitally sampled audio with an 
emphasis on voice communications.  Part of the reason for that is that it
is that I believe the market for voice mail, voice annotation of compound
documents, etc is bigger than the market for MIDI and that it fits better
with the things that Digital already knows how to do well.  If someone has
access to MIDI market data, we'd be very interested in receiving it.

If people have documentation on the MIDI standard file format, the sample
dump format, and any other relevent technical standards, I would be 
interested in receiving a copies.

Below are some specific comments on things contained in the other replies:

.3 - Bob Ashford

Synchronization

CDA doesn't currently contain any notion of synchronization.  The ill defined
support for video that you remember was just that, ill defined, and it has
been removed.  There is working going on to define both video and 
synchronization extensions to CDA, but at the current funding levels I think
it is going to take a while to see the light of day.  CDA also does't currently
do animation, real annotation, and a whole host of other things that would
conceivably be useful, but it takes time and energy (and money) to get these
things added.  Anyone who is interested in accellerating this work should step
forward with money and/or manpower and sponsor it.

Even though the CDA audio extensions bring CDA from the spatial domain into the
time domain, there is still no synchronization defined either implicitly or
explicitly.  Currently any synchronization is application specific.  I know
that the CDA Architecture Team realizes that synchronization is critical for
multimedia presentation interchange (among other things) and would like to 
address this hole, but they are strapped for resources.  I know they are trying
to find a way to do it anyway though.

Amiga

The Amiga was omitted from the list of possible delivery platforms more through
oversight than malice.  It doesn't exactly spring to mind when compared to
PCs and Macintosh in the business market.  On the other hand, it does have 
built-in audio hardware which makes it attractive over something like IBM PC
which can't do anything without buying an add-on card.  If anyone has figures
on the Amiga volumes, I'd be interested in seeing them.  Before anyone asks
why the NeXT machines are on the list if we are worried about volumes, let me
say up front that I don't expect NeXT to come anywhere near making "the cut."

.4 - Karl Moeller - DECaudio capabilities

Don't take the DECaudio (n�e LoFi) specs as the sole indication of what we will
be doing.  We are a software group and have hardware independance as one of
the base tenets of our religion.

.6 - Jeff Lomicka - Solving half the problem

If we could solve as much as half of `the problem' (whatever it is), I'd be
delighted.  Because of the necessity of prioritizing work to fit the available
resources, we will probably be solving much less than half to start with.
Clearly if the piece of the problem that we think we can solve isn't big enough
to be useful though, we shouldn't even start.  We need you all to help us
figure out what is most important and what is the minimum required (not 
necessarily that we will only do the minimum, but we can't do LESS).

.9 - Steve Sherman - All standards must be supported

As far as I can tell MIDI is certainly a succesfull standard.  If Digital
decides to be a player in the computer music or software MIDI sequencer market,
it will clearly be critical to support MIDI.  Digital is certainly a strong
supporter of standards, but that doesn't mean that we will implement support
for all standards in all products.  I doubt the fact that the VAX 9000 doesn't
have MIDI support is creating a serious credibility problem for us.

.11 - Paul Harriman - Sample Dump Standard

Where can I get more information on this?


Keep the input coming.  

Tom

Re .13:

Tom- don't hate the word "architect-" for a product like this, you're in the
unique position of defining tomorrow today, as it were. I think we're talking to
the right person.

The point is agreed, in this world of tight resources, money talks and
b*llsh*t walks, as an old salesman friend of mine used to say. It's also almost
impossible to predict what the market requirements for multimedia will be
tomorrow, next week, next month... A good *architecture,* however, is open to
expansion in any direction perceived as even *remotely* likely.

I was with a CMP when CDA came out, and I really had high hopes for it. It has
the potential for being a truly enabling technology, if done right. The first
"failures" I saw in its implementation were with DEC going with so much private
data in its own implementations that vendors got disgusted and ignored it. Now
that multimedia has become the chic area for information presentation, DEC has a
good chance to define a comprehensive format for it.

Like I said, I think a key is to present a document as having a time structure
as well as a spatial structure. Not much needs to be fleshed out, which
(a) allows it to be defined more precisely as needs are more well-defined, and
(b) lessens the front-end work to be done for development. As a prime source of
"prior art" in this area, I'd look to SMPTE; motion pictures are the most
well-developed example of multimedia alive today, and incorporation of audio
with video is a solved problem, I'd say.

I have a copy of the Stand MIDI File format; send me mail at
TLE::ALIVE::ASHFORTH if you'd like me to run you a copy.

Cheers,
	Bob

re: .13

>.9 - Steve Sherman - All standards must be supported
>
>As far as I can tell MIDI is certainly a succesfull standard.  If Digital
>decides to be a player in the computer music or software MIDI sequencer market,
>it will clearly be critical to support MIDI.  Digital is certainly a strong
>supporter of standards, but that doesn't mean that we will implement support
>for all standards in all products.  I doubt the fact that the VAX 9000 doesn't
>have MIDI support is creating a serious credibility problem for us.

Tom,

MIDI is not used just used for entertainment purposes.  And, it is one of the
most successful industry standards in electronic history, not just a successful
standard.  Applications are being written now for use of MIDI in multi-media 
applications.  Cut off MIDI and you will do at least two things:

	1.  You will lock Digital out of segments of the multi-media market.

	2.  You will make a statement that Digital is not really committed
	    to supporting standards as stated in the ACE program, but only in 
	    supporting those standards that Digital feels like supporting.

Decide now that you have no market, and you will fulfill your own prophecy.
But, others in the multi-media business are making commitments to MIDI.

Consider that Digital and the ACE project are committed to moving the
workstation into markets currently dominated by the PC.  I read this today on
Vogon.  If you will not support MIDI, you may well block this effort for
customers considering migrating to a workstation and using the MIDI-dependent
multi-media libraries and tools they have invested in.  It could well become
a feature that causes Digital to lose sales and prestige.  

The fact that the VAX 9000 or any other mainframe does not yet support MIDI is 
entirely relevant - unless that mainframe will be expected to participate in any
multi-media support.  In other words, unless you plan to support MIDI, DON'T
expect to compete in the multi-media market and DO expect to handle some flack
when customers and potential customers use this as evidence of Digital's lack 
of real commitment to successful industry standards.

Steve

Re .15:

Stay cool, Steve, I think the point got across. As Tom Casee pointed out, this
is the kind of input the basenote was looking for. Tom has indeed asked for the
Standard MIDI File spec, which is an indication that CDA-Audio has heeded the
MIDI preaching of previous notes.

Good thing they had the foresight to post a note here, eh?

Cheers,
	Bob

    MIDI - fine.  What SGU architecture ?  For MIDI to work in a
    multi-media config, it has to ultimately make sounds.  What sequencer
    software sends MIDI events to what SGU triggering what sounds (synth?
    which arch? samples?) using what patch-preset-performance multimbral
    multiMIDIchannel approach ?  Or are you saying that once we make the 
    hardware possible, that existing sequencer/librarian software suppliers 
    will rush to fill in the gap ?  
    
    signed, toolkits don't work

Yo Karl- I don't know about you, but I certainly didn't expect anything that
ambitious. Way I see it, if CDA *understands* MIDI file format and can output
MIDI which corresponds to it, according to specified time synchronization, it's
done its part. Choosing SGUs and software to create MIDI files is a totally
separate issue, and not even CDA-related. It sounds like you're reading more
into previous replies than I am...

Cheers,
	Bob

    re: -.1  Yeah.  What he said ...
    
    Steve

    
    
    
    
    
    
    So when can I get my hands on some proto-hardware?  I wanna write MIDI
    applications with a real (VAX) instruction set!
    
    
    
    
    
    

In response to 2606.13....comments on the VAX9000 and midi...

Because a VAX9000 is big, doesn't mean that it has to be boring. 8')
Granted, this may not be a big market, but anything that helps us
sell a VAX9000 IS a big deal.

The attached memo indicates that capabilities, such as midi,
may be a useful application for mainframe class machines.

Note Jim Davis's description of the project mission.

Regards,
Rick

<many forwards deleted>

From:	TLE::KNOBOT::foster "Bruce Foster" 12-MAR-1991 18:36:00.08
To:	tle::benoit, gitdwn::denise, tle::karam, tle::bazelmans, tle::deworken,
	tle::ellenberger, tle::garry, tle::smurphy, tle::clinkenbeard,
	tle::will
CC:	
Subj:	PAWS Project


<many forwards deleted>

     +-+-+-+-+-+-+-+ TM
     |d|i|g|i|t|a|l|      I N T E R O F F I C E    M E M O R A N D U M
     +-+-+-+-+-+-+-+

     TO:     Paws Project Interest LIst    Date:   29-OCT-1990
                                           From:   John A. Morse
                                           DTN:      223-5801
                                           Dept:     Multimedia Eng.
                                           Loc/Ms:   MLO5-2/G1
                                           Enet:     WRKSYS::MORSE

     SUBJ:   Description of DEC/Paws/Media Lab Project
     REF:    PAWS.RNO



     The Paws project is a 3-way joint research  effort  between  DEC,
     Paws  Inc., and the M.I.T.  Media Lab.  Paws is a company founded
     and run by Jim  Davis,  the  creator  of  the  cartoon  character
     Garfield.   Paws  owns  and  manages  the  rights to the Garfield
     character, which is currently licensed  to  over  850  licensees.
     The  Paws  headquarters,  outside  Muncie, Indiana houses over 40
     artists,  musicians,  and  production  people  who  aid  Jim   in
     producing  the  comic  strip,  the  Saturday morning cartoon, and
     currenly a feature-length movie.  Paws was one of the  first  DEC
     customers  to  take delivery on a VAX 9000.  It is in many ways a
     showcase DEC account.

     Paws has signed a 3-year sponsored-research  agreement  with  the
     M.I.T.   Media  Lab.   DEC  has  agreed  to join in this research
     effort and support the work with a team of four engineers.   This
     will  be  a  multi-year effort.  The goals of the research are to
     develop software and  hardware  for  commercial  art,  animation,
     audio  production,  and  product  design.   Some  of the required
     software and hardware exist at the Media Lab in  prototype  form.
     Since Paws does not have technical resources, they are looking to
     DEC to carry out the technical  aspects  of  the  project,  which
     would  involve  porting  software  from  the Media Lab (currently
     running on HP equipment) to DEC's TurboChannel workstations,  and
     integrating  the  software and hardware pieces into a workstation
     that Paws artists can use directly.

     DEC's engineering participation in this project is  being  funded
     by  the Workstations PBU.  It will be managed under my Multimedia
     Engineering group.  I am currently interviewing  for  members  of
     the  team,  and  expect  to  have  the  team  staffed  and  fully
     operational by the end of November.

                                                                Page 2


     There was a kick-off meeting held at Paws Oct 18 & 19,  1990  and
     attended  by  all  three  parties (Paws, Media Lab, and DEC).  At
     that  meeting,  each  participating  organization  was  asked  to
     outline  its  objectives  for  the initial stages of the project.
     The responses were as follows:

          1.  Paws:   Develop  an   understanding   of   the   current
              operations  at  Paws.   This  includes both the creative
              side -- 2-D  and  3-D  artwork,  sound,  animation,  and
              writing;  and  the  operaional  side  --  synergy of the
              entire  operation,  points   of   communication   within
              facility and with licensees around the world, the styles
              of the the work environmen, and  the  philosophy  behind
              the product.  Develop objectives for the project, define
              the skeleton functionality of the end product, establish
              working relationships amonth the entire three teams, and
              identify the first steps.

          2.  DEC:  Identify scope of project in the Paws environment.
              Meet  with  Paws  project  team members.  Understand the
              current  operations   and   speculate   how   multimedia
              technology  may  impact the creative and routine aspects
              of Paw's business.  Discuss potential DEC adaptations of
              current  products  for  use  in  near-term activities at
              Paws.   Identify  future   H/w   and   S/W   development
              activities in support of the Paws project.

          3.  MIT:  Identify scop of project in the Paws  environment.
              Meet  with  Paws  project  team members.  Understand the
              current  operations   and   speculate   how   multimedia
              technology  may  impact the creative and routine aspects
              of Paw's business.  IDentify future  research  focus  in
              support of the Paws project.

     Jim Davis of Paws gave a very succinct description of the project
     mission as he saw it:

          1.  Take every input form there is, or will be...

          2.  Produce output to every device there is, or will be...

     Peter Davis of DEC put forward the idea of developing a framework
     or  workspace  which will support adding tools, media types, etc.
     as required.  In his words:

          The user of the DEC Media Studio is  presented  with  a
          workspace.   In object-oriented programming terms, this
          is an object manager.  It manages  the  display,  input
          events, etc., and calls the appropriate tools (objects)
          to respond.  The tools, such as  airbrush,  pen,  piano
          keyboard, sculpting tool, etc., are object classes that
          have various "methods." In other words, they  know  how
          to  display  themselves  on  the screen, how to archive
          themselves when the workspace is  filed  away,  how  to
          generate  data for particular output devices, etc.  The

                                                                Page 3


          user can define new tools.  For example, the  user  can
          create a 3D model of a coffee mug, wrap a 2D picture of
          Garfield around it, and then call  the  whole  thing  a
          tool.   This  new  tool  can  then be used to create 3D
          scenes of store shelves, etc.

     The next task to be done is to do  a  formal  assessment  of  the
     needs  of  the  artists, production, and business people who will
     use the sytem.  This will be done by  means  of  a  questionaire.
     The  questionaire  will  be  prepared by Tim Bird of Paws.  After
     review and refinement by the  other  partners,  the  questionaire
     will  be  used  to  interview many of the Paws employees, and may
     also be used to interview DEC and Media Lab people  who  work  in
     similar create jobs.  Results of the questionaire are expected to
     be available by the end of November or early in December.

    Concerning MIDI sound --> SGU mapping:
    
    Well, if we restrict ourselves to MIDI sample-dump standard, we _can_
    be assured that a document always plays back with the correct sound.
    
    If not, then we have a similar situation that we have with fonts: some
    patches are close matches and some aren't.  I suggest that a similar
    algorithm as the font-choice algorithm be used with patches; the
    particular patch that corresponds to a given name is the
    hardware-specific patch.  When you install CDA/Audio on a platform, you
    also install the patches that allow the particular hardware to make
    various "defined" sounds (and can buy more sounds later)
    
    -----
    
    Example:
    
    Document specifies patch: 		Piano-Boesendorfer-Big-withReverb
    
    couldn't find it, so look for:	Piano-Boesendorfer-Big-*
    
    couldn't find it, so look for:	Piano-Boesendorfer-*
    
    and if can't find that, look for:	Piano-*
    
    and if can't find that, look for:	Default
    
    -----
    
    Why use patches at all: patches are _much_ more compact than MIDI
    Sample Dump Standard sounds.  
    
    
    I think we'll survive if all we have are MIDI note sequences plus the
    MIDI sample dump standard, but it will be suboptimal in the long term.
    [suggestion: leave the "patch mapping" part of the architecture
    intentionally open for now, and define MIDI sample dump standard as one
    of the _several_ architected ways of mapping note sequence information
    into audio, other architected ways TBS later]
    
    	-Bill                                               

    
    re: sample dump standard
    
    I just got a chance to read this conference again; I'll forward what I
    have for documentation from my sample editor (which uses sds files). 
    sample dumps don't HAVE to be big; that's a function of your sample
    resolution (not unlike GIF), and the length of your sample. The best
    thing would be the ability to use existing tools which edit samples.
    
    /pjh

Just for general info, Tom Morris sent me some mail and I've forwarded the info
on SDS, SMF, and "general" MIDI stuff to him offline; hope this will avoid
duplicate effort.

BTW, I like the analogy between fonts and patches. Both have their "big" forms
(bitmaps, sample dumps) as well as their "schematic" forms (font and patch
"families," as determined by shared characteristics).

Cheers,
	Bob