> A severe technical problem:
I don't see this as a major issue -- since streams will, in the general
case, be attaching and disconnecting over time, a compiler will need to
be able to make dynamic changes in the source of MIDI events for effects
and SASL instruments. This is easily implemented by a simple pointer
indirection. If your compiler isn't going to handle streams that attach
and disconnect on the fly, then there are several possible ways to handle:
> The problem is that if the MP4 file (yeah, yeah, I know) is streamed over a
> network connection, the SAOL compiler can't determine whether there are MIDI
> events in an SA_Access_Unit until the end of the stream is reached.
[1] When the session is being set up, part of what gets communicated about
each stream is what's going to be communicated in it -- MIDI (yes/no),
SASL (yes/no), etc. If you're doing an IETF-based system, like sfront is
being designed to be, you'd add this into into the Session Description
Protocol block that describes the connection. There must be a similiar way
to handle this in MPEG 4 Systems, and if not there should be.
[2] If you can't do [1], just assume any SA_access_unit has MIDI in it.
> I'd like to propose the following replacement:
The core problem with this replacement is that the priority is inverted
from what users need -- the whole point behind having MIDI visible to
effects instruments was that people [like our friends at SAOL.net] who
are doing real-time work wanted to be able to control things like
volume, reverb depth, etc, from their keyboards -- so, they want to be
controlling (not sharing, but unambigiously controlling) the MIDIctrl[]
array in effects instruments, and do not want to cede this control to
a MIDI file they are playing along with. The "local is better, live is
better" priority also holds true for network musical performance apps.
The natural priority is:
Highest priority -- a local source of MIDI
Middle priority -- a "live" SA_access_unit stream
Lowest priority -- a StructuredAudioSpecificConfig-send midi file.
and each one needs unambigious control, lest you have a local source
and an SA_access_unit fighting over the volume control.
So in summary, COR 1 sec. 1.33.2 (addition of 5.14.3.2.15) is fine
as it stands.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:07 EST