Conference napalm::commusic_v1

	Takle a look at what the Apple MIDI manager gives for some ideas
	The programmer's kit is available for a few $$ from APDA, the apple
	developers association.

	Also, USENET rec.music.synth went through this exercise recently and
	folks wrote some SW already I believe, you may want to check there.

	Chad

    
    Any apple buffs got an address for APDA?  Efficiency dictates that we
    recycle useful ideas where possible...
    
    Also, anyone following rec.music.synth?  I asked about this possibility
    early on in the other note and got no indication that they had anything
    going.  Chad, what are they up to?  Have they got something that'll let
    me do sequencing on my VLC?
    

	Sorry, I don't know what the USENET folks were up to.  I read
	a few notes in August or so but had no time to follow it.
	Basically they were trying to do the same thing I think (I remember).

	The APDA 800 number can be gotten in ROUTES::MACINTOSH

	Chad

             <<< ROUTES::$1$DIA4:[NOTES$LIBRARY]MACINTOSH.NOTE;3 >>>
                         -< Apple Macintosh Volume II >-
================================================================================
Note 249.1    Apple Programmer's and Developer's Association (APDA)       1 of 3
LEDS::PRIBORSKY "I'd rather be rafting"              27 lines  14-AUG-1991 11:53
                       -< APDA drops subscription fees >-
--------------------------------------------------------------------------------
    From MacWEEK, 8/6/910, p. 8.  (Not responsible for typos.)
    
    New developments from APDA:  annual subscription fees dropped
    by Wade Williams
    
      Cupertino, Calif. -- Apple this week will announce that it has dropped
    the annual subscription fees for its developer group, APDA.
      APDA is notifying current customers of the change and will consider
    refunding subscriptio nfees on a case-by-case basis, depending on the
    date the customer joined, according to Apple.  Subscription fees had
    ranged from $20 to $35.
      "We're eliminating the annual subscription charge so we can provide
    easier access to our development tools," said Kirk Loevner, director of
    Apple's Developer Services.  Loevner said APDA aslso will offer special
    bundles in the future to help new developers get started.
      In addition, a new catalog has been introduced that replaces APDAlog. 
    The new 144-page APDA Tools Catalog contains color photographs, screen
    shots and detailed descriptions of more than 300 Apple and third-party
    products.  APDA will publish the catalog semiannually, along with
    quarterly updates.
      Apple has also dissolved Developer Tools Express, a separate
    development group that did not offer prerelease or beta products.  Its
    customers will be given membership in APDA.  All customers will be
    required to sign APDA's terms and conditions form to purchase
    prerelease products.
      APDA is at 20525 Mariani Ave., M/S 33-G, Cupertino, Calif. 95014. 
    Phone (408)562-3910 or (800)282-2732; fax (408)562-3971.

    
    
    for posting that phone number - I really didn't want to search a
    conference for that.
    
    Is anyone else aware of a parallel Usenet project?  There's no point in
    developing the same thing if they've got something under way...  Could
    someone with convenient Usenet access post a query?
    

    
    >....parallel Usenet project?
    
    I used to have info on this stuff...lost now.
    
    I will check that newsgroup to see if I can come up with something.
    
    Kris..

    I kinda doubt that Usenet would have access to the kind of resources
    that we do.  I know it sounds pompous, but I think that we, as a group,
    have superior stuff.  We can get Motif on our systems for free.  We can
    use Gobe/Neted to handle graphics, if any of y'all are into (for
    example) notation software.
    
    I think we need to make a bunch of MIDI tools that can be tied
    together under one UI.  We can do it in Motif.  I'm pretty familiar
    with the Gobe/Neted stuff.  It can be used to generate professional
    quality drawings, I should think.  These can be generated in DDIF by
    the widgets.  I'm familiar enough with expert-system-ish stuff to take
    a stab at a micro-tool that could be used to generate and edit notation
    from a MIDI file.  If we can get a "standard" MIDI file loader, I could
    use that to load in the file and draw corresponding notation. 
    Similarly, I could create something that would extract the MIDI file
    from the notation.  
    
    I've already done something very similar to this for Digital but with 
    electrical timing diagrams.  (It's called DECpat.)  Anyway, this is
    they type of thing that I think I can contribute to this type of
    project.  What say we divide up this project and each pick up some part
    of it to work on?  Might have one of us start with the overall
    framework with some standards to settle on (in particular, a set of
    drivers and loaders for MIDI files and maybe sample files?).  Make it
    the type of thing where we can add tools as things go along.
    
    BTW, Gobe/Neted could probably also be used for lots of other graphical
    stuff like sample waveform editors, universal parameter editors,
    jukebox editing, animation and so forth.
    
    Anyway, I'll volunteer to do some sort of notation editor and advise on
    the framework.  Could be a start.  Could incorporate stuff based on
    what can be pulled off the net and hacked beyond all recognition.  Tom
    could add his Algorythms stuff.  It's in C isn't it?  This could become
    a product where you buy the basic setup and can then license out the
    modules as they are needed.
    
    If anybody wants to meet in a conference room after hours to discuss
    this I can probably make arrangements in Maynard (MSO) or Shrewsbury
    (SHR3).  We could get a white board and brainstorm.  We probably need a
    goal.  Could this be the type of thing we could demo at DECUS?  Under
    NMS, we might be able to get some sort of sponsorship within the
    company.  We might even be able to be introduced to and work with customers 
    in developing this as a multi-media tool.
    
    I'm serious.  I'm as serious as anybody on doing this project.
    
    Steve

>      <<< Note 2788.7 by MIZZOU::SHERMAN "ECADSR::Sherman DTN 223-3326" >>>
>
>    I kinda doubt that Usenet would have access to the kind of resources
>    that we do.  I know it sounds pompous, but I think that we, as a group,
>    have superior stuff.  We can get Motif on our systems for free.  We can
>    use Gobe/Neted to handle graphics, if any of y'all are into (for
>    example) notation software.
>    

Sorry Steve, Digital has no monopoly on codeheads and technonerds :-)
They get their hot Unix boxes from Dec, Sun, HP, etc and they put tons
of good tools up for free use.  They run Motif too, etc etc etc.

Ok, so USENET stuff tends to be a little weak on the GUI in terms of
appearance, because they all tend to use the boring free widgets, but 
the software itself is usually excellent and the interface, while lacking 
sex appeal, works the same.

Chad, 
Motif: Just say no

    Hi, Chad!
    
    It's not a monopoly.  And, I think that for every tool Digital has
    there is something comparable "out there".  However, having it all
    under one roof makes it possible for Digital's resources to be more
    valuable than the sum of its parts.  We do have many tools that any of
    us can get for free and with a simple copy over the net.  Most of these
    are well-supported by the developers, documentation and other on-line
    resources (such as notes).  Digital has set some standards that make
    these things work together, often seamlessly.
    
    A case in point is the Gobe/Neted widget set.  And, there is a fistful
    of other such widget sets that can be used with Motif.  These are in
    demand and being used to solve customer problems now.  The quality of
    these widgets tends to be high and they work well together under Motif.
    
    This isn't the only example.  We've had customers that were "sold" on
    Sun.  Then, they came across problems with Sun that caused them to
    swear off them and return to Digital.  We've had many cases of
    performance figures showing Digital machines to be inferior, only to
    find later that Digital machines were still superior when it came to
    real applications.  Even though there are similar products and
    capabilities out there, we are often guilty of selling ourselves short.
    
    Sure, the outside net can get at this kind of stuff.  My point is that
    it is probably a lot easier for us to access this kind of stuff and to
    develop with it within Digital than it is for the folks outside.  It's
    an advantage to either be exploited or lost.
    
    The pendulum swings both ways.  Used to be that internal tools were
    goodness and external tools were badness.  Now, it's that internal
    tools are badness and external tools are goodness.  It swings back and
    forth.  
    
    
    Steve

    I'm not sure exactly what you folks are looking for in an API design,
    but I thought it might be useful to post the header file for my MIDIC
    subroutine library.  This is what I use to control the RS232-to-MIDI
    converter in my DECstation 5000-based demos.  Something very similar
    could be used for other MIDI controllers besides the MIDIC.
    
    All this file does are the standard MIDI functions I found listed in De
    Furia's "The MIDI Book" and that were implemented on both MIDI devices
    used in the demos (Roland D-5 and Ensoniq EPS-16 Plus).  There are
    additional D-5 and EPS-16 header files with more functionality, though
    I haven't gotten into SysEx calls for them yet.
    
    If it's not too useful, at least it isn't a very long file.  I'll post
    it in the next reply.

/* midic.h - Header file for midic.c, for control of Hinton MIDIC.

=======================================================================

        Copyright � Digital Equipment Corporation 1991.
        All Rights Reserved.  Unpublished rights reserved
        under the copyright laws of the United States.

        The software contained on this media is proprietary
        to and embodies the confidential technology of 
        Digital Equipment Corporation.  Possession, use,
        duplication or dissemination of the software and
        media is authorized only pursuant to a valid written
        license from Digital Equipment Corporation.

        RESTRICTED RIGHTS LEGEND   Use, duplication, or 
        disclosure by the U.S. Government is subject to
        restrictions as set forth in Subparagraph (c)(1)(ii)
        of DFARS 252.227-7013, or in FAR 52.227-19, as
        applicable.

=======================================================================

    Edit History

    Which   When        Who     What

    X00-01   2-Apr-91   MDG     First version (7 functions)
    X00-02   9-Apr-91   MDG     Add multi-timbral capability and pitch bend
    X00-03  12-Apr-91   MDG     Add volume function
    X00-04  16-Apr-91   MDG     Add pan function
    X00-05   2-Jul-91   MDG     Add other standard MIDI functions; remove pan
    X00-06   8-Jul-91   MDG     Sustain, sostenuto, breath, foot, data entry
    X00-07   9-Jul-91   MDG     New copyright notice

*/

int midic_init (char []);

int midic_open (char []);

int midic_note_on (int, unsigned char, unsigned char, unsigned char);

int midic_note_off (int, unsigned char, unsigned char, unsigned char);

int midic_timbre (int, unsigned char, unsigned char);

int midic_volume (int, unsigned char, unsigned char);

int midic_mod (int, unsigned char, unsigned char);

int midic_breath (int, unsigned char, unsigned char);

int midic_foot (int, unsigned char, unsigned char);

int midic_data_entry (int, unsigned char, unsigned char);

int midic_sustain_on (int, unsigned char);

int midic_sustain_off (int, unsigned char);

int midic_sostenuto_on (int, unsigned char);

int midic_sostenuto_off (int, unsigned char);

int midic_control_change (int, unsigned char, unsigned char, unsigned char);

int midic_key_pressure (int, unsigned char, unsigned char, unsigned char);

int midic_channel_pressure (int, unsigned char, unsigned char);

int midic_pitch_bend (int, unsigned char, unsigned char);

int midic_all_notes_off (int, unsigned char);

void midic_close (int);

void midic_close_all_channels (int);

    Looks like a good start toward a set of "standard" MIDI C headers.
    I just took a glance over it.  What would it take to make it
    comprehensive as far as the MIDI spec goes?
    
    Steve

	I have written s/w for writing MIDI files and sending MIDI info.
	I can't include it because then Digital would own it, by virtue of
	it being worked on on Digital's assets.  So far, I have never developed
	MIDI s/w on Digital's assets because Digital's assets around me
	couldn't play MIDI; I only did that one PDP11 DAC quartet player.
	So they might own that. 

	Also,
	I think an interface could reflect a decomposition at a higher level,
	since many MIDI functions are identical except for a function code.
	But I didn't really analyze it.
tom

    
    I'd love to cruise in for an afterhours white board session, but the
    commute from So CA kind of kills that idea.  So, if you guys really are
    gonna do something, please go for it, and I'll contribute whatever I
    can from out here.
    
    

    I'd love to help out.  I Live in Nashua NH, and work in Stow MA, so if we
had a brainstorm session after work, I could attend.

bill powers

You might want to look into the Microsoft Multi-Media standard to see what
calls they use. I'm currently using Voyetra's VMP software (Multi-Media
calls) with Turbo C++ to develop a sequencer under MSDOS - These calls
have simplified most of the work involved (and is allowing me to mix in
digitized audio as part of the sequence).

In general, If you mimic these calls, your code might be more portable in the
long run. The other advantage is that someone has thought out these calls
and thier related functions quite well - It should simplify creating a
functional definition of what you are trying to write. 

							Jens

I've chewed on this for a while; I think I have a few ideas worth considering.

First, I think there are multiple levels of design which fall out of this
project:


- a standard set of I/O "driver" routines, consisting of device-dependent and
  device-independent sections (a la XLib's ddx and dix portions); these would
  include comm port and file I/O routines.

- a set of applications which utilize the above, such as "play MIDI file",
  "record MIDI data to file," "edit notation for MIDI file," "edit
  MIDI file," you name it... (just examples, quite open for debate...)

- a set of GUI objects representing an interface to the above applications.


There's a public-domain library of MIDI routines on the Amiga (by Pregnant
Badger, if you're interested) which is pretty full-featured. As far as an
object-oriented design, Bars and Pipes uses such a paradigm extremely
successfully- I don't think the concept of piping I/O through various filters is
patentable at this point, so borrowing it shouldn't be a problem.

My suggestion is that we start with a modest list of apps which would be useful,
develop a working list of perceived needs for utility routines, then implement
one or more at prototype level, using a command-line interface. This would
provide a core of useful programs devoid of GUI license requirements. It would
also avoid developing a beautiful interface to something which was later
completely redone. Once a given app (or set of apps) gets working, we can chew
on the appropriate buttons, sliders, and such to make it whirl.

BTW- I know part of this crosses past the "API" boundary, but it had to go
*someplace*...

Bob

    
    Bob's ideas are good except for one comment...
    
    I don't think it's a good idea to implement a ascii interface
    before the full-fledged GUI.
    
    Object-oriented approach gets defeated and much of the code
    won't be 'reuseable'.
    
    Kris..

Re -1:

>    Object-oriented approach gets defeated and much of the code
>    won't be 'reuseable'.

??? Naaah! I agree with maintaining an OO approach, but I suggest that it be
"two-tracked," i.e. in the underlying functional layer and separately in the GUI
layer. One problem which can occur with OOA/OOD and GUIs is that there's often
a lot of confusion about what constitutes an "object." Intentionally separating
the layers avoids this, and also, as I mentioned, produces something which does
not *need* a GUI to run. (It also, BTW, allows the same functionality to be
plopped under a *different* GUI...)

I also think that mingling presentation knowledge with functional knowledge in
the same object is a bit "unclean," if you get my drift.


The approach I would suggest would be roughly as follows:

	command-line input		GUI
		\			/
		 \		       /
		  \		      /
		   functional modules
			    |
			    |
		       I/O drivers
		       /	 \
		file access	comm port access


The same API used by the GUI would be used from the command line to send messages
(or make calls, if this is a debatable issue) to the functional modules. Besides
having the advantages (IMHO) cited above, this should make isolation of bugs
simpler, as GUI-related errors could be readily identified.

This project definitely threatens to become fun...

Bob

    
    Kris, I think Bob has a good functional breakdown in his reply.  And I
    buy his supporting arguments 100%.  If someone wanted to develop an
    ASCII interface, they should be able to with this approach.
    
    While I don't think the ASCII interface is ever going to be a real
    popular item, I can think of one couple with visual impairments that
    would benefit greatly from being able to let DECtalk do the display
    chores.
    
    Bob, do you have any further ideas about the interfaces between these
    modules?  Anybody?