Conference napalm::commusic_v1

    
    We need a MIDI toolkit first...to ensure portability.
    
    Maybe we can start gathering input for a standard API...
    maybe a mouse driven builder will do too.
    
    Check out MAX from Opcode for some ideaS.
    
    Kris..

    
    
    What would the toolkit do?  Maybe provide the OS-independent interface
    to the MIDI hardware?  I'll call Opcode for MAX literature.  Anyone
    that's interested can contact me for copies.
    

	I would certainly welcome the opportunity to upgrade from a VAXmate to 
a VAXstation for my MIDI games. I can run SoftPC for DOS programs but don't see 
how I could actually talk to any hardware. So for starters how would you go 
about getting a MIDI interface for a VAXstation, this surely is the initial 
stumbling block before you consider whether this project is worthwhile.

Nigel

    I've been thinking recently about a unix, X windows, and midi machine
    for home use. The decision I came to was a (used) Sun workstation for
    the unix and X part. For the midi part, I'll be using my atari-ST to
    talk midi to the synths and to talk normal rs-232 to the Sun. One could
    use one of the midi<-->serial black boxes just as well.
    
    My intention was to write simple librarians for my synths at first.
    Next would come control panel programs. Finally would come some kind of
    patch editor programs. I'm afraid real-time sequencing type programs
    are beyond the scope of my ambitions.
    
    I've already written librarian programs for the Yamaha TX-7, 
    the Kawai K1, and the yamaha dx-100. These run on the atari ST and are
    available on line somewhere. I decided not to invest any more effort
    into the ST windowing system (I've forgotten it all anyway), and to
    concentrate future efforts in X windows. 
    
    For librarians, one could write a decent librarian using only the unix
    file system. At least you could verify what is in a bunch of data files
    and you could re-arrange the sounds within those files. It would allow
    you to see if your user interface works anyway.
    
    
    This should be an interesting project!!
    Jim

    re: .3
    
    Nigel, the hardware interface has to be isolated from the upper levels
    of the application, so that we can obtain platform independence.  This
    means that we'll probably need a variety of device driver type modules
    that support the various hardware options on each platform.
    
    For the VAXstation, the KEE MIDIator (the RS-232 to MIDI translator)
    looks like a viable option.  But if something better comes along, we
    need to be able to support it easily.  For some reason, serial I/O on
    the VS3100s I use seems to impact performance significantly...
    
    I don't think there's much doubt about the value of this kind of
    project, not only to ourselves, but to the company.  If Digital's own
    hackers chose to work on other platforms due to any reason but cost,
    what does that say to the world?
    

Personal (RISC) DECstations have some amount of capability...if only we could
do 16-bit audio (I heard some group was working on it).

VAX and Alpha will have multimedia and audio with the arrival of a TurboChannel
bus on VAX and Alpha.

The proposed Midi Tooolkit will help isolate OS and other low level dependencies
so users can develop applications without worrying about what platform they are
working on.

The toolkit will be object-oriented to make sub-tools building and other
development relatively easy.

What is needed now, is a specification requirements study and document.

You may start by looking at products already out in the market, what they
do, and what they don't, and what you think users would love to have.

Kris..

I think there is a need to build a 'faster' midi-interface...maybe DEC
can help extend the MIDI Standard by building a TurboChannel-to-RSXXX
interface...or something along those line....no?

MIDI's biggest challenge has been its sluggishness..when compared to other
protocols.  Transfering huge files over Midi is an exercise in patience ;-)

Kris..

    Well, my group here in Littleton is the group which brings you all
    those neat FDDI adapters (TurboChannel, XMI, FBUS, EISA, ISA, SBus,
    Qbus, NuBus, etc...) If we can design adapters for a 100mb/s link, I
    think we can handle 31.25k baud. 
    
    I'll suggest adding it to the LRP.....NOT!
    
    dp

    
    
>   What is needed now, is a specification requirements study and document.
    
    Even though we're talking midnight engineering here, I think we should
    do the whole product development schmeer...just as long as the
    paperwork doesn't become the product.
    
    Kris, do you have a study we could use as a template for this thing?
    

    XOR is a universal librarian (I guess... I don't _use_ any of these
    things, I just read about 'em here and in EM!). Maybe XOR would be a
    good model for capabilities, design, and/or interface?

    
    
    Well, so far, the universality we've been discussing relates to
    portability between Xwindows-capable platforms.  We haven't begun to
    talk about individual applications' capabilities or operator
    interfaces.  Given that a sequencer is a pretty universal type of tool
    in the first place, what do you think XOR offers for us to consider?
    
    Maybe I am making an assumption here.  My thoughts are that a sequencer is
    the logical first component of a MIDI suite for Motif.  Maybe you're
    thinking a universal librarian is more appropriate.  Well, there's
    plenty of room for participants here...  In fact, it might help to have
    a librarian proponent here to help hone the requirements for the MIDI
    API that Kris mentioned.
    

    XOR is a universal librarian / patch editor. As such, it must contain a
    series of widget-analogues which can be configured for a given SGU. XOR
    might suggest a UI and an approach to "configurability".
    
    I don't really understand your question. You hadn't mentioned
    "sequencer" in your replies until -1. I guess I was supposed to infer
    that you were talking about a sequencer, and apparently I was supposed
    to infer that your sequencer had the features of a librarian and patch
    editor built in. Am I inferring correctly?
    
    The larger point is that we should be adapting existing MIDI tools to
    X/Motif, rather than reinvent functionality and the UI. It might be
    best to start with the "best" (lots of luck :^) GUI-based sequencer,
    and mimic the minimal useful functionality. With time, we can add our
    favorite stuff from other sequencers... or put it out there on the
    USENET and lets others do the enhancements!
    
    - Hoyt

    I'd also suggest backing off on re-engineering the MIDI spec.  While
    it's true that 31.2Kbaud doesn't look like much, there are other
    approaches readily available.. there's a MIDI fiber LAN out there,
    forget the name, plus a device like MOTU's MIDI Time Piece allows
    multiplexed incoming RS422 hispeed serial traffic to get demuxed out to
    'real' 31K MIDI lines.  
    
    There's enough work just to get to some simple sequencing.
    
    karl

    
    I agree that we have bitten off a large chunk of stuff to do.  I also
    agree that borrowing features from existing packages is a good
    approach.  In fact, if one of the existing MIDI software packages was
    available for porting, I'd abandon this whole start-from-scratch
    effort.
    
    Rather than one big application that does everything, I thought it
    would be easier to create separate programs.  So, my inclination would
    be to build a sequencer first, which would in turn force development of
    the MIDI API for whatever platform I happened to be working on.  Of
    course, once the API is defined, others could use it to create their
    own MIDI apps...
    
    If someone else wanted to go out and design a new MIDI interface (for
    fiber, SCSI, whatever) the API should be able to embrace the new
    hardware and present the same abilities to the applications.
    

Maybe someone should contact a company like Opcode or MOTU and propose
a collaboration.  We bring the hardware, base understanding of OSF Motif based
development not to mention U*ix, they bring the application base...

This might even be fundable within the company at an appropriate level with
a key partner...

	- Jim

    Dr. T's (XOR, etc. -- they publish a LOT of stuff invented outside
    the company) is located in Needham, MA. They might very well be willing
    to collaborate on a product, e.g. we do the front-end and the back-end
    and they hand us the middle. It wouldn't be public domain, however. If
    we want to put this stuff on the USENET, then a possibility would be
    that Dr. T's (or equilvalent) gives us a _subset_ of the middle stuff
    -- the functionality is limited, and the USENET version is a teaser. If
    a user wants more functionality, they write a check to Dr. T's.
    
    We cannot make money on this, as I recall, given Digital policies. Do
    we have objections to Dr. T's making some, in return for giving us all
    that proven code? Such a strategy would vastly increase the likelihood of
    actually _accomplishing_ something.
    
    And once it's out there on the net, then the USENET community can add
    functionality instead of buying Dr. T's stuff.

    "We" don't need to make money.  Under NMS it should be possible for
    somebody to work with, say, Dr. T under and agreement that allows
    Digital to make money.  Why not develop a version of Dr. T that runs
    under Motif on a DECstations that Dr. T can market?  A cut can go to
    Digital and Digital can get more exposure.  Surely this type of deal
    can be worked out.  If nobody else has a CC manager that will listen, I
    certainly do.  And, I've been doing some Motif encapsulation and have a
    workstation set up to do VMS Motif development.  I will be doing some
    porting to U*ix soon.  So, I could probably assist in such an effort.
    It becomes a question of putting in some midnight hours, and I do that
    all the time.
    
    Steve

    
    I want the functionality, and I don't care how we get it.  Starting
    from scratch on a public domain effort is just about my last choice,
    but if there's no other way...
    
    On the other hand, if someone (like, maybe you, Steve?) can get
    official backing for an effort in this direction, I will be more than
    happy to use your stuff when it's done.  In fact, I'll even volunteer
    to be a beta test site.
    

Withthe advent of 3500 VAXstation VLC and $4000 Personal DECstations
(albeit the configrations may not be the optimal, I don't know the
details of exactly what one gets at these prices), targetting these machines
for MIDI makes more sense because the machines are starting to be affordable
for "the masses".  I mean, if it costs me that much for a high
powered mac, NeXT or 486, I'd take the VAx anyday...


Also, I'd rather see efforts turned to Opcode or MOTU than Dr. Ts.
Just personal opinion.

Chad

    Do those prices for the VLC include the system licence, etc?
    
    Can you buy a word processor for it for under $400?

    
    I checked with DIGIDESIGN....they have a developers kit...but
    for a price. (better than street prices)...Actually, Digital
    has some kind of relationship with Digidesign (Nina Price of
    the Palo Alto Multimedia Group is DEC's contact).
    
    I prefer the idea of hacking from scratch myself.  I know this
    is more difficult....but...has anybody thought of getting people
    like Richard Stallman (Free Software Foundation) and his propeller-
    head associates at media labs like the ones at MIT, Brown, Princeton,
    Standford..etc invloved?  
    
    I believe the entertainment world is a logical next major victim in 
    the open systems revolution..... MIDI manufacturers are getting away
    with murder...maybe...more powerful/open system in the public domain 
    will instill some new wave of competition and price cuts...no?
    
    Kris..

    
    I forgot to state again that...a redesign or major enhancement
    to the MIDI spec is one sure way to start a new exciting era
    in this business.
    
    This has been done in other industries with positive results..
    Digital has a good opportunity to lead the way and diversify
    a bit.  Isn't all this a subset of the Multimedia wave?
    
    Kris..

    
    
    I'm not out to revolutionize an industry - I've got MIDI gear and I'm
    not up for hacking everything from scratch.  If "organizations" want to
    pioneer a new path, I'm perfectly willing to let them take the risk. 
    I'd rather use my inferior MIDI stuff for now, while the brilliant
    thinkers decide what the rest of use need will next.
    
    If Stallman or one of the equivalent groups has something like this
    under development, I'd be happy to contribute - if it's anything I can
    use and it will be ready in the next 6 months.  Otherwise, I'd be just
    as happy to see what I can come up on my own.
    
    Somebody offered a suggestion that we contact some of the existing MIDI
    software vendors about doing a port.  I, for one, think this is an
    excellent suggestion, as long as we can do this without screwing up our
    current employment situation.  So, how would we do this?  And secondly,
    who do we contact at each company?
    

>                     <<< Note 2782.20 by KOBAL::DICKSON >>>

>    Do those prices for the VLC include the system licence, etc?
    
     ??? Don't know. 
   
>    Can you buy a word processor for it for under $400?

	Probably not but it is in DEC's best interest to see that you
	can or these things will never get into the mainstream
	(VLC especially, less so the Ultrix/Unix DECstations as
	they are supposedly already the next great wave (ACE stuff) and
	will therefore out of necessity have this).


	Chad

    re .22
    
    >I forgot to state again that...a redesign or major enhancement
    >to the MIDI spec is one sure way to start a new exciting era
    >in this business.
    
    .. and a surefire way to guarantee incompatibility with existing
    instruments and MIDImuxes.  I disagree, Kris.  First time, I think..
    
    karl

    
    Re: -1
    
    Yeah Karl, you're right.  Furthermore who are *WE* to tell the music 
    industry how to improve MIDI.  Classic DEC "Hacker's Machismo"
    
    Not to dump water on anyone's fire, but, frankly, NT is a better target 
    than UNIX and Motif (or VMS and Motif).  The bottom line is that 
    SOMEONE has to make money here.  Most musicians and even programmer
    musicians don't have a lot of money.  Even a $4000 VAX or DECstation
    is a bit much for most of us.  Furthermore, any feature you could care
    to want to implement on an "advanced" operating system like VMS or,
    to a lesser degree, UNIX, you could easily do on Mr. Cutler's gift 
    to Microsoft and the world.
    
    my $.02
    
    -Ed
    

>    .. and a surefire way to guarantee incompatibility with existing
>    instruments and MIDImuxes.  I disagree, Kris.  First time, I think..

Karl,

Actually...I am expecting almost everybody to disagree with me ;-)

In my opinion, it will take a major effort to improve MIDI and other things...

It is almost impossible to do anything today without some legal
hassles if one has to work with existing proprietary systems.

The hardest route is the best...in the long run.

The MIDI standard and performance is not at par with today's
computer systems performance...so...how do you build more efficient
MIDI-based systems without improving the MIDI standard?

Kris..
    
 

re                       <<< Note 2782.27 by FUEL::graham >>>

> The MIDI standard and performance is not at par with today's
> computer systems performance...so...how do you build more efficient
> MIDI-based systems without improving the MIDI standard?

	Super-set it.

> Kris..

	Reg
    
 

>   Yeah Karl, you're right.  Furthermore who are *WE* to tell the music 
>    industry how to improve MIDI.  Classic DEC "Hacker's Machismo"
    
Ed...check your MIDI history again...the MIDI stardard was originated
by computer programmers who had interest in music.  Mathews and Oppenheimer
were no musicians by any strecth of imagination.  They are hackers.

>    Not to dump water on anyone's fire, but, frankly, NT is a better target 
>    than UNIX and Motif (or VMS and Motif).  The bottom line is that 
>    SOMEONE has to make money here.  

You will notice that I recommended the idea of a generic toolkit earlier...
the purpose...to isolate OS dependencies.  There're tools that will allow you
to generate API for different environments...be it Windows...Motif..Openlook..
Mac..etc...Look up Neuron Data's tool in the SICVAX::GUI_TOOLS Cconference.
Actually, DIGITAL has rights to resell the product and teach programming for
Neuron Data.  I see no conflict with my idea of an 'open' toolkit.

Kris..

    
    Personal DECstation specs (and some other stuff that was easier to
    leave in than edit out, for comparison):
    
    
                              Personal      DECstation     DECstation
                             DECstation     5000/100's     5000/200's
                             ----------     ----------     ----------
    o Entry price (CLP$)       $3,995         $6,495         $11,995
    
    o CPU Processor            R3000A         R3000A         R3000A
    o Clock Speed            20MHz/25MHz    25MHz/33MHz       40MHz
    o Performance
      - SPECmark              16.3/19.1      19.3/25.3        32.4
      - MIPS                  21.6/26.7      27.0/29.8        42.9
    
    o Minimum memory             8MB            8MB            16MB
    o Maximum memory            40MB           128MB          480MB
    o Memory SIMMS              parity        parity           ECC
    
    o Internal storage      one 3.5"disk    two 3.5" disks    none
                            one 3.5"floppy  one 5.25" drive
    
    o Entry graphics
      - Resolution            1024x768,      1280x1024      1280x1024
      - Planes, Refresh     8-plane,72HZ    1-plane,72HZ   1-plane,72HZ
      - Mechanism             built-in       MX Graphics    MX Graphics
      - 2D Vectors/Sec        153K/183K       108K/114K       248K
      - Million Pixels/Sec    5.7M/6.4M       7.9M/8.0M       20.3M
    
    o Multimedia
      - Sound in/out            built-in     TURBOchannel  TURBOchannel
      - Speaker (8-bit @8KHz)   internal        external       external
        telephone-quality
    o On-board I/O Interfaces
      - SCSI                    Yes             Yes            Yes
      - Ethernet               Thick           Thick          Thick
      - Serial                1 RS232         2 RS232        2 RS232
      - X.25/full modem         yes             yes            yes
        control
    o TURBOchannel Bus        2 slots         3 slots        3 slots
      - MX                      yes             yes            yes
      - HX                      yes             yes            yes
      - TX                      yes             yes            yes
      - DECvideo/PIP            yes             yes            yes
      - PXG/8 plane             yes             yes            yes
      - PXG+/8 plane            yes             yes            yes
      - PXG+/24 pl/Z            yes             yes            yes
      - PXG/TURBO+/96 Pl        yes Through     yes            yes
                                    TCE Box
    o Multiscreen support       yes             yes            yes
    o TURBOchannel Expander     yes             yes            yes
      Box
    
    ------------------------------------------------------------------------
    
    By the way, the easiest way to get more MIDI performance is just
    support multiple MIDI out ports.  With some straightforward way of
    mapping parts (or "virtual channels") to (port number, MIDI channel)
    you can do arbitrarily complex stuff.  As Tom Janzen now and again
    points out, the current MIDI standard is capable of supporting over 650
    note on/note off pairs PER SECOND, which is an awful lot of stuff.
    I think the 16 channel limit is more of a real limitation than the 32K/sec
    bit rate, but multiple output ports solves both "problems" handily. 

>    o Multimedia
>      - Sound in/out            built-in     TURBOchannel  TURBOchannel
>      - Speaker (8-bit @8KHz)   internal        external       external
>        telephone-quality

It would be nice to get 16bit with 44.1+ KHz for CD sound quality. Shouldn't
be too hard to get the signal processor to go at that resolution.

Kris..
  

    That is what the external TURBOchannel option gives you.

   >Ed...check your MIDI history again...the MIDI stardard was originated
    >by computer programmers who had interest in music.  Mathews and Oppenheimer
    >were no musicians by any strecth of imagination.  They are hackers.   
    
    Yeah, hackers with a long history of working with musicians.  How much 
    influence has DEC (the company, not the products) had on music?
    
    I applaud the idea of a portable MIDI environment, but there is no 
    *MUSICAL* reason for creating it.  It could be really sexy to have 
    "open systems" MIDI environment, but just what advantage would that
    give to a musician?
    
    I'm hearing lots of talk about features, but nothing about benefits.
    
    -Ed
    
    
    

    Ah, this is the age-old problem of marketing.  You can't justify
    developing a product for which there is no market.  And, by the time
    there is a market, somebody else is already filling it.  Which leads
    one to conclude that you always have to design for a market that
    doesn't yet exist.
    
    So, why design a Motif MIDI environment?  There is no market now.  What
    you have to look at is the future market.  One popular vision of the future
    market is one where everybody, including home users, have X-terminals. 
    These terminals will have applications that don't care what OS is under
    them as far as the user is concerned.  Also, lots of applications will
    be available to the user who will become picky about the UI.  In this
    (fantasy) world, access to software libraries, memory and MIPS will be 
    easy and cheap.  It is anticipated that users will get to know and use
    basically one kind of interface that runs on anything that looks like 
    Motif.
    
    More and more people will be interested in MIDI, but these people will
    not the be the hackers they are now.  They will be musicians that are
    reluctanct to mess with anything that looks technical but does have an
    easy Motif interface.  So, the benefit will not be realized by
    hard-core MIDIholics.  The benefit will be realized by regular
    musicians or home computer users that don't want to be bothered by
    details.  This interface may well keep use of MIDI transparent to the
    user once cables are hooked up.
    
    As to whether or not such a system will ever get into the hands of a
    novice, I think that is quite likely.  You can now get this kind of
    power (to some extent) for under $4000.  In ten years, every home might
    have such a system.  May not be that individuals buy them.  Could be
    that their companies buy them and that they start using them for
    personal benefit as well as business.  So, people who may never have
    tried MIDI might get hooked.  A new MIDImarket window opens.
    
    You won't add new capability for current MIDIholics.  This project
    would benefit those who want to diddle with it for fun but don't want
    to get into the hairy details of MIDI.  In fact, this might include
    managers and such who want to do multi-media applications.  These folks
    will have money and won't think twice about hooking up a synth box to
    their Motif workstation and adding snazzy audio to their presentations
    *IF* the software is as easy to use as any other Motif application.
    
    Steve

    
    Why do I need Motif when I already have Windows & Mac?
    
    Furthermore, why do I even need the client/server multimedia 
    environment DEC is proposing?  I can see it now, we will make
    "teleperforming" a part of the multimedia platform along with
    teleconferencing.
    
    I remember seeing a blurb about Stevie Wonder, Howard Jones and some
    other keyboard artists "jamming" in LA and London with MIDI links between 
    the two cities.  I think that's when the term "teleperforming" was 
    coined.
    
    

>    Why do I need Motif when I already have Windows & Mac?

Ed...nobody would be forced to use any particular GUI against their
wishes...this is a free world ;-)

There are tools today that will allow a developer to generate
interfaces for Motif, Windows, Mac, Opelook, Ascii..etc....

>Furthermore, why do I even need the client/server multimedia
>environment DEC is proposing?

Looks like you don't have too much faith in your company to make
any kind of impact.  Remember...much of MIDI gear is becoming very
computerized...and people like Stevie Wonder do not write protocols
or GUIs....a visit to the programming departments of major midi houses
like Opcode or Digidesign will confirm this.  There're people inside Digital
with skill sets similar to the midi demi-gods at Opcode or Digidesign.

I was asked recently to help set up a Mac LAN here in major recording
studio.....

At this year's AES, Opcode and Digidesign egineers were heard saying that 
they were looking at the Silicon Graphics "Indigo" to develop the MIDI
workstation of the future.  This is not a farce.

Micheal Jackson's "Black and White" video used a * network* of Silicon 
Graphics workstations to develop the 'morphing' scenes.

>    I remember seeing a blurb about Stevie Wonder, Howard Jones and some
>    other keyboard artists "jamming" in LA and London with MIDI links between 
>    the two cities. 

True...they did this over Sprint fibre lines....another area that Digital
could explore if our marketeers can get their act together.  

Many recordings are done today with session artists in different geographies..

What are we waiting for...for someone else to corner the market before we
blame ourselves...?

Kris..

    At the risk of revisiting the X_pc vs Y_pc topic... One real advantage
    of VMS/Unix-based Motif vs Mac/Windows is the suitability of those
    operating systems to multitasking. I'm far from an authority on any of
    these operating systems, but I believe that VMS and Unix would better
    support concurrent programs with lots'o'interprocess communication. The
    sequencer is humming, while another process changes patches on the fly,
    another is controlling the mix, another is capturing the result as a
    MIDI file, etc. Getting PCs (other than Amigas?) to do this kind of
    thing requires programming heroics, methinks. I'm imagining that a
    Motif based system would allow anyone with net access to contribute
    MIDI stuff.
    
    The fact that there's no installed base to speak of, and that this
    could be a hacker's domain, would allow imaginative people to invent
    functionality that might someday become a MIDI standard.
    
    - Hoyt

    
    Jeez, you go away for a few days ...
    
    If we were asking for Digital dollars to do this I would understand the
    questioning and other probes regarding possible markets, anticipated
    revenues, etc.  And I can understand that some of the more far-sighted
    marketeers might actually understand that software designed to easily
    port to advanced platforms has strategic value to the organization,
    even if it's for "recreational" software.
    
    But enough of that!  Until the company decides it's interested, this is
    midnight engineering, and we don't need no stinkin' budget.  We're
    building a tool for our own uses, with the devices we have (plan to
    have) at hand.  This is pure design, unsullied by compromises unrelated
    to the purpose.  This project has begun, and marketeering issues are
    hereby relegated to other notes/conferences.
    
    BTW, it's personally pleasing to see the suggestions for future
    functionality contributed by the notes here.  Touchscreen could be cool
    in some situations.  The application cooperation is a design goal for
    the API.  Speaking of which, I'll start a separate note for API issues.
    

	> (paraphrased) why Motif when I have Wv3 and Mac?

	Because if the marketting and executives have their way then
	in a few years there won't be windows or Macs, there will
	be ACE machines with OSF/Motif or Windows NT.  This would be the chance
	for DEC to be at the beginning instead of missing the boat.

	Unfortuinately, while the managers see the market of
	tomorrow in terms of HW (and OS maybe), they are concentrating
	this on today's applications ideas, noton tomorrows needs.
	Ie, they say tomorow we have Motif for everything but they only
	see Spreadsheets, databases, etc that "normal" folks do today
	with their PCs, not the specialty market that will grow tomorrow (MIDI).

	Chad

re .20

>    Do those prices for the VLC include the system licence, etc?
Yes
>    Can you buy a word processor for it for under $400?
EDT comes for free:-)

I don't believe that for Digital employees there would be a charge for using
any Digital layered products on your home system. 

Nigel

    A couple of comments.. Hoyt, all the things you mention that look like
    they require multitasking like sequence playing, patch changes,
    controlling the mix, can be done NOW with current software based
    sequencers.  This is not to say that multitasking wouldn't be
    beneficial, just that the examples you gave are addressed already.
    
    Another question I have to ask is, *IS* the MIDI market growing ? 
    Every retailer I talk to whines about slow sales, less new MIDI
    technology coming out, saying that 1987-88 were the glory years.
    Kind of like with VAX/VMS sales.  What we're seeing now is refinement,
    evolution and not revolution.  Most folks that might be interested
    already HAVE some sort of setup.  And they've learned the hard way that
    the recorded music they make is not so easily sold, thereby
    discouraging further investment.  So I challenge the assertion that
    MIDI is a growing market.
    
    karl

	The Mac can multitask and the Apple MIDI manager allows you to hook
	up any MIDI application with any other MIDI applications.  Only prereq
	is that they support the Apple Midi Manager interface.

	Chad

	ps:  I think the MIDI market is the same as the general economy,
	stagnant.  I think it will grow again if it can get past the
	hobbyist stage into the home stage, which will be hard (maybe
	not as we know it for example) and into the business stage
	(for multi-media and other types of presentations, etc).

	

    Re: .41
    
    The real growth in MIDI in the future will be for the home.  Like Karl
    says, the pro market is probably close to saturation.  Products like
    the QY10, Tiger Cub, Sound Canvas, Sound Blaster etc. are where the
    bucks will be, as the home market is potentially *much* larger than the
    pro market will ever be.  Why do you think the General MIDI standard was
    developed?  
    
    						Brian

	Dr. T's KCS 3.0 on the Amiga
	(I didn't upgrade) has inter-process communication
	and multiple MIDI access (mixing in one process while playing in 
	another, and would do other stuff if I had bought the modules).
	Oh yeah, the notator editor can access a score that's playing at
	the same time, I got that.

	Don't forget to put a line in the functional spec that all code
	is in C and follows both the corporate coding standard in 
	the Digital Guide to Software Engineering from Digital Press
	(or also the Software Engineering Manual 1988) as well as
	the guidelines in the NAS Guide to Developing Portable Software
	(for obvious reasons.), and ANSI guidelines.
	Following a coding standard will make it easier for developers
	to exchange code without having to adjust to varying idiosyncratic
	dialects, avoid common errors and side effects, improve
	portability, and improve robustness, maintability and durability.
Tom

	The pro market is probably saturated in terms of absolute numbers,
	but the "ultimate" MIDI software has yet to be built so there
	is room.  As PCs and Macs disappear in the future and ACE/APPLE-IBM
	takes over (I'm just be optimistic here), there will be a need
	for *real* software for the hot-boxes to run.

	Chad

re    <<< Note 2782.45 by RTOEU::CLEIGH "Chad in Munich at RTO, DTN 865 3976" >>>
>                                    -< .\] >-

>	The pro market is probably saturated in terms of absolute numbers,
>	but the "ultimate" MIDI software has yet to be built so there

	Errr, yes sortof;  there is probably more than enuf pro gear
in the hands of the pros but....   as today's pros get cycled out by
tomorrow's wanna-be pros....  more pro gear gets sold, right ? 

>	is room.  As PCs and Macs disappear in the future and ACE/APPLE-IBM
>	takes over (I'm just be optimistic here), there will be a need
>	for *real* software for the hot-boxes to run.

	The underlying hardware platform is rapidly becoming 
irrelevant;   "GIMME  MOTIF !"    ?

	R

>        <<< Note 2782.46 by ULTRA::BURGESS "Mad Man across the water" >>>
>                   -< Sell to the wanna-bees and gonna-bees >-

>re    <<< Note 2782.45 by RTOEU::CLEIGH "Chad in Munich at RTO, DTN 865 3976" >>>
>>                                    -< .\] >-

>>	The pro market is probably saturated in terms of absolute numbers,
>>	but the "ultimate" MIDI software has yet to be built so there

>	Errr, yes sortof;  there is probably more than enuf pro gear
>in the hands of the pros but....   as today's pros get cycled out by
>tomorrow's wanna-be pros....  more pro gear gets sold, right ? 

No, not sort of.  The same way the pros are now running, for example, VISION 
and not sequencer 2.5 or whatever one of the earlier Opcode Mac sequencers
was, they will in the future want to run, for example, Opcode's newest Super-
Vision-in-your-face v9.5.  And today's pros don't run Mac Plus/SE anymore,
rather IIcx/ci, etc.  They always slowly work up to the "current state of
the art."  (notice that we are talking software here, not the latest whiz bang
keyboard or module).

>>	is room.  As PCs and Macs disappear in the future and ACE/APPLE-IBM
>>	takes over (I'm just be optimistic here), there will be a need
>>	for *real* software for the hot-boxes to run.

>	The underlying hardware platform is rapidly becoming 
>irrelevant;   "GIMME  MOTIF !"    ?

I dread having to go to Motif from XUI on my VS and I hope I don't lose the
Mac interface at home.  "Motif, just say no!"

>	R

Chad

    
    Pretty soon, PCs will have enough compute power to calculate waveforms
    on-the-fly. That will spell the end of the MIDI synth boxes and usher
    in a new era of synth software (I mean synth, not sequencer).
    Workstations have enough horsepower to do it now to some degree.
    
    I believe MIDI will be subsumed into existing computer network technology.
    Worrying about the bandwidth going from a computer to the MIDI boxes is
    unnecessary, since the boxes will go away soon.
    
    
    

    I don't think so.  As PC power increases due to technology
    improvements, so do the synth boxes.  As I recall, the D70 I use has an
    embedded processor (what, a 8960 or some such) as well as DSP and other
    processors on board working in parallel.  The internal busses are
    probably (my guess) more efficient than would be found with a PC of
    comparable value.  On-board memory has figures that are similar to some
    PCs.  But, it's all in one package and has all the peripherals needed
    to make juice.  True, PC power is increasing.  But, synth box
    capabilities are keeping pace.  
    
    Also, even in my lowly system, I can drive not one but two MIDI busses 
    since my MC50 has two MIDI output streams.  I'm already at a level
    where I can emulate an ensemble.  I can add another 30 voices on a
    whole 'nuther D70 bus if I want.
    
    The MC50 and D70 together cost about as much as a PC system alone. 
    But, I'd have to add more software and hardware to "catch up" to my
    current capabilities.  I'd like a PC.  But, I can't justify it yet.
    
    What I do think will happen in the future is that the difference
    between PCs and synths will blur.  But, there will continue to be a
    niche for a system that is customized for synth processes, just as
    there continues to be computers that are designed to handle only
    certain types of problems (like massively parallel computers).
    
    Steve

    I thought ALL synths 'calculate waveforms on the fly'.
    
    karl

    REAL synthesizers do so, oftimes with high-resolution analog
    computations. Typical modern machines just play back samples, with
    maybe the teeniest bit of simple convolution.  Korg's highly-touted
    "Waveshaping" was described on Usenet as being as simple as passing
    each sample word through a translation table.
    
    There are starting to be machines like the D70 and K4 that implement
    fairly serious computation (resonant filtration) in software.  With
    pretty serious hardware assist, though.
    
    	Eirikur
    
    
    

    What I meant is that general purpose computers are getting to be
    powerful enough to be used to compute waveforms in real-time. You can
    just send the output stream through your i/o bus to a D/A convertor and
    on to the speakers...
    
    I know that IRCAM (and probably many other places) has been doing
    computed audio in "batch mode" and playing it back after the processing
    is complete. An example of this is a program called CHANT which
    synthesizes pretty good vocals - singing lyrics. Unless you have big
    bucks for high speed processing (I don't know if it requires Cray-sized
    computes) your alternative is to store the data stream on disk and play
    it later.
    
    My point is that soon "cheap" computers will be fast enough to this.
    So why buy a dedicated box, when you can use a general purpose computer
    with the right software? You can then upgrade your studio by buying
    more gpc's and software upgrades. It's not here today, but it will
    happen soon...

    I think it boils down to economy.  Currently, I would have to pay an
    awful lot to get a general-purpose PC or workstation with software and
    hardware that can match the performance of my MC50/D70 combo.  If I could 
    have gotten better from a standard PC and software alone at the same price 
    I would have gone with that.  I think that situation will continue.  The 
    technology used in synths nowadays is on the order of 8088 and 6510 stuff.  
    They're taking advantage of how cheap that "old" technology is and the fact 
    that synths can rather easily take advantage of cheap implementation of 
    parallel architectures.
    
    
    Steve

    I agree with Steve.  Avoiding current-technology MIDI SGU's because
    realtime waveform computing power (if not software) will be here Real 
    Soon Now is like avoiding purchasing a MAC because a future O.S.
    version might require more memory than it does today.
    
    We used to SELL based on futures.. now we preach technology avoidance 
    based on futures.
    
    karl

	A project of this scope, and size, and so many separate pieces, and
	so much real-time involved, is best expressed as an object-oriented
	system int he requirements document, the design, and the
	implementation (e.g. c++)
tom

    
    I hadn't thought of it exactly in those terms, but I tend to agree,
    Tom.  While thinking of the API I was concentrating on the gozinto and
    comzoutof, which is really what object-oriented stuff is about, right?
    
    It looks like we're not going to be able to do a whiteboard session (at
    least not in person), so anyone with thoughts to contribute should do
    so here.
    
    I haven't had time to do any writing on the API description, due to
    impending move (personal), but expect to get some time on it over the
    holiday break.
    
    Issues I'm concerned about:
    
    	1. port contention - how do the applications allocate a MIDI port?
    	   Do they really need to?  Example, how would a librarian and a
    	   sequencer share the same port without confusion?
    
    	2. where should the timing data come from, the application or the
    	   API?  The API has better access to the underlying hardware and
    	   can reach the system timer, if necessary (like for high ppqn
    	   values), but it seems that traditional, PC based designs do this
    	   in the applications.
    
    I'm planning to order documentation on the Apple MIDI Manager, unless
    someone here has one they can make available.  I don't expect it to be
    very expensive.  Is anyone else interested in this document while I'm
    ordering?
    

    re .56 
    
    Yes, I am interested in a copy of the Midi Manager doc. I saw a
    preliminary one about two years ago, and it seemed rather useless. As I
    recall, there was no support for sysex, so I abandoned my plan to
    migrate to using it. Perhaps the implementation is more complete now...

    re: -.1 
     To be protable, I think we need to work in terms of drivers.  That is,
    we need, for example, to have a small program that will do the driving
    to a MIDI port.  This program will be configurable for the platforms
    that the system will run on.  But, its interface to other programs will
    be standard (ala C++ or other object oriented programming).  To make
    this successful, we need to think in terms of modules and such.  We
    might consider creating a general-purpose toolkit with dummy sections.
    For example, create a program that looks to the system like it drives a
    MIDI port on a GPX, even though we really don't have the hardware
    configured yet.
    
    A good direction might involve segmenting the toolkit up as a superset
    of the Motif toolkit and setting some standards.  Might look at other
    kits that already do this.  Might come up with a standard set of tools
    that all higher-level applications can use. 
    
    Steve

    
    I agree, Steve.  In fact, when Kris Graham mentioned doing a toolkit he
    struck a chord for me.  The MIDI port driver pretty much has to be a
    low level module that can be easily swapped out as we move around to
    different platforms.
    
    So far, I see two major divisions of functionality in the toolkit:
    
    1) MIDI port services, and
    2) MIDI file services.
    
    Anyone have anything to add, or comments?
    

	RE: USenet -- Steve


	I will say that COMMUSIC is a lot more organized than rec.music.synth.
	It takes them a year to put aout a compilation tape.

	But they did have a bunch of them get together
	and produce their own album more or less
	including a guy from Scotland.  They described the gear
	there.  Sounded like it looked like one of those new york
	showrooms :-)

	Chad

	ps: Mike Metlay was one of the movers of that project

    
    Since most vendors have provided device drivers (X11 severs) to
    the public (X Consortium), shouldn't we be able to steal some of
    this 'free' code to learn about the various hardware?  Even the
    Mac, now has an X server.
    
    Time to start drafting the "Toolkit Architectural Document"?
    
    Kris..

    
    I figured that since we would probably develop for our own platforms
    first, acquiring knowledge of the underlying hardware would be
    relatively easy...but there probably is sone neat stuff buried in the X
    sources.  Isn't this stuff online somewhere?
    
    Anybody have a good example document we can cut and gut to use as our
    Architectural Document?
    

    >but there probably is sone neat stuff buried in the X
    >sources.  Isn't this stuff online somewhere?
    
    DECWRL::/pub/X11 has the X11R5 sources.
    
    Kris..