I still think that using PortMIDI would simplify the low-level MIDI.
The only comment earlier was that there was no PortMIDI for mac OS9.
I have been in contact with portmidi people and they stopped working
on os9 as they thought that there were no users anymore, but it would
be possible to reopen that if we wanted it.

So I started to look at it.  First thoughts are that although portMIDI
deals with realtime events it does not handle MIDI files, so we would
either have to persuade them to integrate, or we need to separate the
realtime from file.

To that end I have created two new files (not to be used!) called
InOut/fmidi.c and InOut/pmidi.c what are respectively the files midi
and portmidi stuff.  I have made minimal changes to pmidi.c to use
portmidi open and get events.  This not in anyway complete; I have
started the change to the PmEvent structure but I am getting lost in
the confusions (in my mind) of MIDI.

I was thinking of a two stage process -- first to get fmidi.c to the
state of compilation and equivalent to current code.  Then to get
pmidi.c to a working state.  This would break MIDI until it was
stable, so I suggest leaving the current mididevice.c and midirecv.c
as they are while the new code is done.

I suspect that we really need someone who knows MIDI to take a lead or
at least a management/watch.  Is this going the correct way?  Surely
continual patching of the current low-level code cannot be a stable
future.  How much can be replaced with clearer code?

Just early morning thoughts

==John ffitch

On 7/12/04 2:38 AM, jpff@codemist.co.uk etched in
stone:

> I still think that using PortMIDI would simplify the low-level MIDI.
> The only comment earlier was that there was no PortMIDI for mac OS9.
> I have been in contact with portmidi people and they stopped working
> on os9 as they thought that there were no users anymore, but it would
> be possible to reopen that if we wanted it.

Question: In changing to PortMIDI, will Csound's "internal interface" for
Midi change?  i.e.  Will the following function prototypes and expected
behavior remain the same:

void OpenMIDIDevice(void)
long GetMIDIData(void)
void CloseMIDIDevice(void)

If so, then there is no problem on OS 9.  These functions are already
implemented in a separate file, MacMidi.c, and mididevice.c is not being
used.

Even if this is not the case, I would say go ahead and proceed with the
implementation of PortMidi.

I currently have serious doubts about the legality of distributing an LGPLed
Csound for MacOS 9 which links with the OMS Midi library, anyways.

The end of section 6 of the LGPL says

"It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system.  Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute."

I've attached a copy of the redistribution license for OMS.

Question:  Did anyone ever fill out and send in a copy of this license to
Opcode when developing the Midi support for Mills Csound ??

It is not clear to me whether the redistribution license applies to the
OMSGluePPC.lib object code which is linked into Perf or if it only applies
to the runtime libraries installed by the OMS installer.  If we cannot
redistribute the portions of the SDK needed to relink Perf, then we cannot
fulfill the requirements of section 6 of the LGPL because OMS is "does not
normally accompany the operating system."

The issues are further complicated by the fact that Opcode is no longer a
separate entity (having been acquired by Gibson) and seems to have ceased
almost all business activities.

I would appreciate the opinion of John ffitch or anyone else who understands
the LGPL on this matter.

Thanks.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

In my current draft void OpenMIDIDevice(void) and void
CloseMIDIDevice(void) are unchanged.  GetMIDIData is returning a
PmEvent rather than a long.  That still needs thought.

I do not know about the OMS Midi library and its licence.  I do not
even know who wrote that code -- possibly Mills?  Hum
==John ffitch

On 7/12/04 6:25 AM, jpff@codemist.co.uk etched in
stone:

> In my current draft void OpenMIDIDevice(void) and void
> CloseMIDIDevice(void) are unchanged.  GetMIDIData is returning a
> PmEvent rather than a long.  That still needs thought.

I could probably work around this, but it may not matter anyways ...

> I do not know about the OMS Midi library and its licence.  I do not
> even know who wrote that code -- possibly Mills?  Hum

Maybe Matt knows something about this ?

If we cannot determine otherwise, I think that I will be forced to assume
OMS is incompatible with the LGPL and remove the real-time Midi code for
MacOS 9.

:(

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

> > I do not know about the OMS Midi library and its licence.  I do not
> > even know who wrote that code -- possibly Mills?  Hum
>
> Maybe Matt knows something about this ?
>
> If we cannot determine otherwise, I think that I will be forced to assume
> OMS is incompatible with the LGPL and remove the real-time Midi code for
> MacOS 9.


mike berry initially wrote the oms support- probably some changes by me
at some point.

are you talking about the omsglue libs?  those are from the oms sdk
the latest version i have is from jan 98 - i know its harder and harder
to find it since opcode no longer exists.  it might be on sourceforge
though?


-m

On 7/13/04 3:01 PM, Matt J. Ingalls etched in stone:

> 
>>> I do not know about the OMS Midi library and its licence.  I do not
>>> even know who wrote that code -- possibly Mills?  Hum
>> 
>> Maybe Matt knows something about this ?
>> 
>> If we cannot determine otherwise, I think that I will be forced to assume
>> OMS is incompatible with the LGPL and remove the real-time Midi code for
>> MacOS 9.
> 
> 
> mike berry initially wrote the oms support- probably some changes by me
> at some point.
> 
> are you talking about the omsglue libs?  those are from the oms sdk
> the latest version i have is from jan 98 - i know its harder and harder
> to find it since opcode no longer exists.  it might be on sourceforge
> though?

Yes, I am talking about the OMS Glue libraries.  I have a copy of the Jan 98
SDK which contains a "Redistribution License."  I attached a copy of the
license to my earlier email. ([CSOUND-DEV:4911] Re: Thinking aloud on MIDI)

I had two questions:

Was this license ever filled out and sent to Opcode?  (This was necessary it
seems for redistribution).

Do you think that the license applies directly to the code in the OMS Glue
libraries or does it only apply to the stuff an OMS installer puts on your
system?

The consequence of the former scenario is that we are not allowed to
redistribute the OMS Glue libraries or headers to end users and thus are
unable to comply with section 6 of the LGPL unless we remove the OMS support
from Perf.  (At least this is how I read the respective licenses).

Matt, I would really appreciate your opinion.

Thanks.

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/