>Sfront is capable of hosting a MIDI-only streamer today, I
>think (or at the most, with moderate changes to the sfront
>core). Basically, it would involve writing a control driver
>along the lines of the control driver that lets you hook up
>a real-time MIDI keyboard into sfront. See:
>
>http://www.cs.berkeley.edu/~lazzaro/sa/sfman/devel/driver/index.html#contro
l
>
>for very rough documentation about writing control drivers.
OK, cool. I don't quite see (mostly because I don't really
understand network programming) how a web-based session based
on sfront would work. When I click on the link, it opens
up a streaming RTP port and invokes some sort of handler
program. The handler program gets the header, makes sa.c
and compiles it into a new executable. Presumably, it
then forks off the new executable, and somehow hands off
control of the RTP port socket to the new one? Is that
right?
>Sfront also supports SASL control drivers (the example gliss
>shipped with sfront glisses up a piano keyboard using a MIDI
>control driver, and down a piano keyboard using SASL control
>driver events), but extending this to a streamer is more
>complex -- basically, the control driver needs to know the
>name (or for encoded MP4-SA, the token number) associated
>with the SAOL instrs, in order to hook up the SASL and SAOL
>events appropriately.
Of course, in the strict by-the-book standard, the SAOL
and SASL are being delivered from the same server (or set
of servers), so presumably the name matching is handled at
encode time. You highlight an interesting outside-the-
standard problem, though. If I have a "SASL controller",
like a MIDI controller, but capable of sending SASL over
a wire to a running SAOL orchestra, how do I tell the
controller what the names of the instruments and controllers
in the orchestra are?
Yet another good MS thesis for computer-music students!
>Any chance that current versions of these documents
> [IS 14496-3sec1, the main Audio part, and IS 14496-1,
> the MPEG-4 Systems standard] will be made
>available for download by non-MPEG members soon? Last time I
>checked the general-purpose MPEG info sites pointed to by mpeg.org,
>versions of these documents were of the pre-FDIS era ...
Sadly, I can't make any promises about this. I'm probably
legally not allowed to even distribute the SA part; I'm
allowing myself to believe that it is still ethical to do
so since I wrote so much of it. But these other parts
are edited by other people and owned by the ISO, so...
The final ballot for Audio closes in about a month, and
so the ISO will publish the official standard soon after
that. I don't know when Systems closes -- it may be
three months or more.
I don't like this situation any more than you do. Let me
send some emails to the ISO folks and see if there are
any other alternatives -- it makes no sense for enthusiastic
implementors to be blocking on the ISO publication pipeline.
Many people on this list may be affiliated with organizations
that are members of their respective national standards
bodies, in which case they are entitled to prepress copies
of the standard. Anyone who thinks they might be can contact
me off the list and I can try to help them find out.
Best,
-- Eric
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:39 EDT