Menu
▾
▴
[Linuxsampler-devel] The Mafia Files - Part II (was: new version of lscp spec)
|
From: Rui N. C. <rn...@rn...> - 2004-06-14 15:40:26
|
Hi everybody,
This is the second and last part of a digest I could gather from the
exchange that was taking place off-list and
led to the latest draft-linuxsampler-protocol changes, as announced by
Vladimir.
Sorry for the long post(s).
Enjoy.
--
rncbc aka Rui Nuno Capela
rn...@rn...
--------------------------------------------------------------------------
* * * * * * * * * * * * * * * * PART II * * * * * * * * * * * * * * * *
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Rui Nuno Capela
Date: Sat, June 12, 2004 23:51
--------------------------------------------------------------------------
Christian Schoenebeck wrote:
>
> We should come to a decision, I want at least the audio device
> configuration part to implement this weekend, because I guess I won't
> have time to work on LS the next four weeks or so (semester exams).
>
> So shout out your opinions everybody, QUICK !!!
>
OK. I agree in falling back to the LIST verb, instead of GET
AVAILABLE_.... So the new LIST commands are:
LIST CHANNELS
return a comma-separated list of the channel number IDs.
LIST AUDIO_OUTPUT_DEVICES
return a comma-separated list of the audio output device number IDs.
LIST MIDI_INPUT_DEVICES
return a comma-separated list of the MIDI input device number IDs.
As before, I can re-edit the document, as the changes are now pretty easy.
Just say yes :)
About Vladimir's concerns about UDP, I'll say that it's somewhat overkill.
It will be rare to have QS/LS communicate over WAN boundaries, where
firewalls are common (and in the only right place, BTW).
I say it's overkill, because IMO it will be quite unusual to have a
firewall between a client and the server. Com'on guys, you're not asking
for using LSCP over the Internet, are you? Of course it's perfectly
possible, given that you know what you're doing and obviously you have
access to the firewall/filtering stuff.
But what about the average user? I think he/she, and in fact us, will
almost use QS/LS on a LAN environment, where using firewalls are just
evidence of deep paranoia :).
OTOH, Vladimir's probably right when he talks about XP SP2. I think in
that cases it's feasible to give precise instructions for putting event
LSCP to work there. Don't you think?
Even on those paranoid OSes, the average user will do QS/LS locally (i.e.
using the loopback interface), so all this firewall problems may become
minor. IMHO.
Bye now.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Rui Nuno Capela
Date: Sun, June 13, 2004 0:40
--------------------------------------------------------------------------
OK. Here it is, my latest revised LSCP doc, now with LIST commands.
However I would confess I'm a lil'bit regretful about this :) My
suggestion about not introducing the new LIST verb was based on existing
pattern: commands that return comma-separated lists are indeed of the form
GET AVAILABLE_..., e.g:
GET AVAILABLE_ENGINES
(should we change this to LIST ENGINES ? too late :)
GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
(or better LIST AUDIO_OUTPUT_DRIVERS ?)
GET AVAILABLE_MIDI_INPUT_DRIVERS
(LIST AUDIO_OUTPUT_DRIVERS ?)
so I thought it was quite logical to have:
GET AVAILABLE_CHANNELS
(instead of LIST CHANNELS)
GET AVAILABLE_AUDIO_OUTPUT_DEVICES
(instead of LIST AUDIO_OUTPUT_DEVICES)
GET AVAILABLE_MIDI_INPUT_DEVICES
(instead of LIST MIDI_INPUT_DEVICES)
as these commands are still to be implemented.
OK. Just exposing my trivial thoughts, that I favour syntax consistency
vs. shorter command verbs. And just in case you back off your opinions,
the latest doc is still valid, of course ;)
Bye again.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Rui Nuno Capela
Date: Sun, June 13, 2004 12:50
--------------------------------------------------------------------------
Hi Vladimir,
Just a note about my/your thoughts...
>
> 1) FWs are getting way too common. Punching holes in them requires
> knowing the port number ahead of time. This is currently not the case.
>
"My" liblscp has all that TCP/UDP stuff ready and working, at least as the
current LSCP specification cares about. Just like a proof-of-concept.
However one thing I've assumed in the design, where you have a serious
point:
The server always listens on one same fixed port number, either for TCP or
UDP. That is 8888 at the moment. The fact is the client picks an UDP port
to listen on it's side. This point is where the firewalling issue rises,
indeed.
>
> 2) Efficiency of UDP is not as simple to achieve as it may seem.
>
IMHO UDP is still the optimal choice and solution for the LSCP event
stream. It's fundamentally unidirectional (server to client) and we surely
don't care about reliability or casuality. Using TCP here is certainly
overkill, theoretically speaking ;)
>
> 3) Implementing TCP/UDP solution is more difficult and bug prone
> comparing to TCP solution.
>
Hmmm. Again, the TCP/UDP solution has already a pretty functional
implementation: liblscp. At least, it's like on the ItWorksForMe(tm)
league :)
Besides that, I'm getting to the point where Vladimir is bottom line right
in the firewall issue, so instead of having one TCP connection we probably
better having two TCP streams, one for the command stream, as it is now,
and other for the event stream. Therefore the server would listen on two
distinct TCP ports (e.g. 8888 and 8889 respectively) which ought to be
configured deterministically on a firewall environment.
Man, this is a bomb on LSCP implementation. Think we better let Christian
do his exams peacefully :)
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Benno Senoner
Date: Sun, June 13, 2004 13:12
--------------------------------------------------------------------------
I agree with Vladimir,
UDP is a bit klunky and does not buy us real speed advantages,
perhaps for Voice over IP or real time audio stereams (LS headless
cluster units that stream
UDP audio to a master box) but for LSCP the speed advantage is not
measurable.
So the ideal solution is as Rui said:
TCP port 8888 for issuing LSCP commands from client to server
TCP port 8889 for the server sending asynchronous events to the client.
That way we don't need to worry about reliability problems and the whole
protocol works in any situation regardless of firewalls etc.
So I'd say when Rui has time he could add this capability to liblscp. (or
when the lscp server will support it, so no hurry :) ).
PS: I think we should go back to the LS mailing list to discuss these
issues so that other developers can partecipate too, seems like a secret
affair here :)
the linuxsampler mafia :)))
cheers,
Benno
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 16:50
--------------------------------------------------------------------------
One last message to linuxsampler mafia :)
No problem with two connections. In fact, i don't think we should care.
It's up to the client. (later on this).
I'd like to point out some details (as i understand them):
1) Client always opens both connections.
2) Events are sent with the actual data, not just notification to ask
client to do LSCP query.
3) SUBSCRIBE commands are sent over the second connection? Then we could
have:
4) Connections can be opened independent from one another, i.e. there
might be a client that only needs "second" connection for notifications .
. .
5) OK. now about ports. Why two server ports? Let's have one on the
server and if client wants to open 1,2,3,4,5...x connections to that why
not?
6) As you can see, there is no need at this point to have two
connections :) If client wants to open two he can open two. The point is
they work exactly the same from the protocol standpoint. If client sends
"SUBSCRIBE XXX" then he'll start getting "EVENT:NNN:XXX" messages back
over that same connection. Server really doesn't care if that's connection
number 1, number 2, etc.
So if it's easier for a particular client implementation to get certain
events over a separate connection as well as talk certain commands over a
separate connection, it could open several connections (all to the same
port) and do his thing whatever way he sees fit.
If you guys don't have a problem with that, i could type this proposal up
and forward it to the list for further discussion.
Regards,
Vladimir.
PS: As i said before i'm sorry that i brought this up too late when time
was already spent coding UDP stuff. But i think this might be the case
when it's better late then never :)
Plus, when we refactor software it only becomes better. It's like war and
peace, you have to keep rewriting it :)
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Mark Knecht
Date: Sun, June 13, 2004 18:12
--------------------------------------------------------------------------
Benno Senoner wrote:
> I agree with Vladimir,
> UDP is a bit klunky and does not buy us real speed advantages,
> perhaps for Voice over IP or real time audio stereams (LS headless
> cluster units that stream UDP audio to a master box) but for LSCP
> the speed advantage is not measurable.
> So the ideal solution is as Rui said:
> TCP port 8888 for issuing LSCP commands from client to server
> TCP port 8889 for the server sending asynchronous events to the client.
Is there a case for a subscribe operation from a client to be informed by
the server of the port that it will receive acynchronous event feedback
on? Instead of 8889 being fixed, should a subscribe operation define
that? I'm thinking this might better support a single server, multiple
client environment, so that only the intended target does something
instead of all QSamplers on the network.
I see in Vladimir's next email that he sees subscribe happening over the
second port, so I'm probably confused about how this will all get set up,
but hopefully my question is at least understood.
Thanks,
Mark
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 19:54
--------------------------------------------------------------------------
Mark,
With TCP anything can be the same port on the server and client will pick
a random port.
My idea is to have the exact same protocol on all connections. Because of
that, we don't really need two different ports on the server.
If the client chooses to use one connection to talk req/response and
another connection to talk subscribe/event it's fine with the server. But
it could use the same connection to do both if it wants to. Then
everything is well for both single and multiclient setups.
Otherwise if subscribe is happenning one one connection but events are to
be sent on another, we'll have to keep track of the mapping and subscribe
will have to tell the server what connection is to be used for events,
etc, etc. In other words, more complicated.
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Mark Knecht
Date: Sun, June 13, 2004 20:04
--------------------------------------------------------------------------
Vladimir Senkov wrote:
> Mark,
>
>
> With TCP anything can be the same port on the server and client will
> pick a random port. My idea is to have the exact same protocol on
> all connections. Because of that, we don't really need two different
> ports on the server. If the client chooses to use one connection to
> talk req/response and another connection to talk subscribe/event
> it's fine with the server. But it could use the same connection to
> do both if it wants to. Then everything is well for both single and
> multiclient setups.
>
> Otherwise if subscribe is happenning one one connection but events
> are to be sent on another, we'll have to keep track of the mapping
> and subscribe will have to tell the server what connection is to be
> used for events, etc, etc. In other words, more complicated.
>
> Regards,
> Vladimir.
>
Vladimir,
Hi. I guess my thought was more about overhead on the client. why
should the client see interactions between the server and a different
client? If the client's machine only passes port 8889 up to it's
client, but ignores port 8890 since that's on some other computer,
then it's a bit less for the client to deal with.
This is all pretty minimal stuff anyway. I doubt that client cares
much, so I was just asking.
Take care,
Mark
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 20:33
--------------------------------------------------------------------------
Mark,
Client will only see what it requested. It will not see any other
client's traffic.
Client will establish TCP connection with the server and send a SUBSCRIBE
command to it over that connection. Server will remember that it needs to
send certain events (whatever client requested) down this SAME connection
only.
Here is an example of how loading an instrument could look like:
(In this example the same connection is used for both event notifications
and lscp req/response)
assuming connection is already established by the client . . .
CLIENT:SUBSCRIBE INSTRUMENT_LOADING_PROGRESS
SERVER: OK
CLIENT: LOAD INSTRUMENT something.gig 0 0
SERVER: EVENT:123:something.gig 25%
SERVER: EVENT:123:something.gig 50%
SERVER: EVENT:123:something.gig 75%
SERVER: EVENT:123:something.gig 100%
SERVER: OK
Or the same thing could happen over two different connections:
assuming both connections are already established by the client . . .
CLIENT(conn2): SUBSCRIBE INSTRUMENT_LOADING_PROGRESS
SERVER(conn2): OK
CLIENT(conn1): LOAD INSTRUMENT something.gig 0 0
SERVER(conn2): EVENT:123:something.gig 25%
SERVER(conn2): EVENT:123:something.gig 50%
SERVER(conn2): EVENT:123:something.gig 75%
SERVER(conn2): EVENT:123:something.gig 100%
SERVER(conn1): OK
note, 100% and OK may come in any order! examples above show 100% coming
in first, but this may not always be the case.
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Rui Nuno Capela
Date: Sun, June 13, 2004 20:57
--------------------------------------------------------------------------
Vladimir Senkov wrote:
>
> With TCP anything can be the same port on the server and client will
> pick a random port. My idea is to have the exact same protocol on
> all connections. Because of that, we don't really need two different
> ports on the server. If the client chooses to use one connection to
> talk req/response and another connection to talk subscribe/event
> it's fine with the server. But it could use the same connection to
> do both if it wants to. Then everything is well for both single and
> multiclient setups.
>
> Otherwise if subscribe is happenning one one connection but events
> are to be sent on another, we'll have to keep track of the mapping
> and subscribe will have to tell the server what connection is to be
> used for events, etc, etc. In other words, more complicated.
>
The server must know how to distinguish which connection is, whether
command request/response or event streaming. The case of distinct ports
make this obvious.
Using the same port, we have to make a state on the protocol and the
SUBSCRIBE and UNSUBSCRIBE commands are the only type of requests the
client is supposed to send to the server on this connection stream type.
The SUBSCRIBE transaction *must* be the very first one to take place on
this connection, letting the server map it's state as a event stream and
not as an ordinary command response one.
Let me picture this, to let this clear (ASCII art :)
1. Command type stream connection.
Server Client
|<------connect---------|
|-------accept--------->|
| |
|<------request---------|
|-------response------->|
| |
|<------request---------|
|-------response------->|
| . |
| . |
| . |
|<------request---------|
|-------response------->|
| |
|<-----disconnect------>|
2. Event type stream connection.
Server Client
|<------connect---------|
|-------accept--------->|
| |
|<------SUBSCRIBE-------|
|-------response------->|
| |
|--------event--------->|
|--------event--------->|
|--------event--------->|
| . |
| . |
| . |
|--------event--------->|
| |
|---------PING--------->|
|<--------PONG----------|
| |
|--------event--------->|
|--------event--------->|
|--------event--------->|
| . |
| . |
| . |
|--------event--------->|
| |
|<-----UNSUBSCRIBE------|
|-------response------->|
|<-----disconnect------>|
Note that the only valid trasaction on this event type connection is the
PING/PONG. After the SUBSCRIBE transaction the flow is almost the time
from server to client (the event messages). You can think of this just
like a one-way pipe.
Having only one connection, that handles both types of streams, is
complete black magic to me ;) How can the client distinguish an event from
a command response if those can happen interleaved? I know it's possible,
but it can become a mess...
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 21:36
--------------------------------------------------------------------------
Hi Rui,
> The server must know how to distinguish which connection is, whether
> command request/response or event streaming. The case of distinct
> ports make this obvious.
>
That is if you have TWO distinct protocols. I'm suggesting to use a
single protocol.
If both connections use the exact same protocol then there is nothing to
distinguish.
> Using the same port, we have to make a state on the protocol and the
> SUBSCRIBE and UNSUBSCRIBE commands are the only type of requests the
> client is supposed to send to the server on this connection stream type.
> The SUBSCRIBE transaction *must* be the very first one to take place
> on this connection, letting the server map it's state as a event stream
> and not as an ordinary command response one.
>
So the server has to maintain state to remember who is subscribed to what.
It will have to do that anyway, no matter how we do it.
So, why not have a single protocol/port/connection then?
Again, if you really want multiple connections you are free to have that
anyway, it's always up to the client how many times he wants to connect
and what he uses those connections for.
For example, i can envision a separate application that is only interested
in some events from LS and doesn't do any req/resp or only does a few
things, while other apps (like QSampler) want it all! :)
> Let me picture this, to let this clear (ASCII art :)
>
> 1. Command type stream connection.
>
> Server Client
> |<------connect---------|
> |-------accept--------->|
> | |
> |<------request---------|
> |-------response------->|
> | |
> |<------request---------|
> |-------response------->|
> | . |
> | . |
> | . |
> |<------request---------|
> |-------response------->|
> | |
> |<-----disconnect------>|
>
>
> 2. Event type stream connection.
>
> Server Client
> |<------connect---------|
> |-------accept--------->|
> | |
> |<------SUBSCRIBE-------|
> |-------response------->|
> | |
> |--------event--------->|
> |--------event--------->|
> |--------event--------->|
> | . |
> | . |
> | . |
> |--------event--------->|
> | |
> |---------PING--------->|
> |<--------PONG----------|
> | |
> |--------event--------->|
> |--------event--------->|
> |--------event--------->|
> | . |
> | . |
> | . |
> |--------event--------->|
> | |
> |<-----UNSUBSCRIBE------|
> |-------response------->|
> |<-----disconnect------>|
>
>
> Note that the only valid trasaction on this event type connection is
> the PING/PONG. After the SUBSCRIBE transaction the flow is almost the
> time from server to client (the event messages). You can think of this
> just like a one-way pipe.
>
Well, since we are using TCP i'd argue that we don't need PING/PONG
anymore. And again, i'd argue that there is no reason to have a
restriction on having req/resp on the same connection. It's up to the
client to use the same connection for req/resp or not. But why restrict
this? Let the server answer any requests just like it does with SUBSCRIBE
requests.
> Having only one connection, that handles both types of streams, is
> complete black magic to me ;) How can the client distinguish an event
> from a command response if those can happen interleaved? I know it's
> possible, but it can become a mess...
>
I'd suggest simple rules to avoid any confusion there:
1) Event is always a single line and has a format of
"EVENT:<code>:DATA\r\n" 2) No resultset line may ever start with EVENT:
substring.
3) Any resultset MUST be sent together from start to finish, in other
words, EVENTs MUST be between resultsets, but may not be in the middle of
them. (Or at the minimum between lines of the resultset but not in the
middle of the line.)
Depending on the client implementation of req/resp, it may be
easier/cleaner to use a separate connection for the subscribe/event
communication.
Client implementation may for example be sync or async . . . with async
it will not be any difference at all if you use the same connection for
events or not. But the sync implementatoin may be a little more
complicated if a single connection is used and may choose to use two.
Again, if the client implementation feels that two connections are easier
for it, why not.
I just think it will be easier on the server to just have single port,
single protocol, multiple connections will have to be supported anyways .
. .
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Rui Nuno Capela
Date: Sun, June 13, 2004 22:07
--------------------------------------------------------------------------
>
> Again, if the client implementation feels that two connections are
> easier for it, why not.
> I just think it will be easier on the server to just have single port,
> single protocol, multiple connections will have to be supported
> anyways . . .
Yes, and to satisfy both connection modes the server *must* follow one
simple rule:
* All event messages *must* be sent to, and only to, the socket connection
where the SUBSCRIBE command is received.
This rule applies whether the client maintains a single or a double
connection.
On my part, which is about liblscp, I'll eventually implement the double
connection client model, exactly as I pictured on my last note.
I'm feeling we can rest now :)
Cheers.
--
rncbc aka Rui Nuno Capela
P.S. Please remember to post your verdicts about the changes to the draft
document. Do we stick with a) GET AVAILABLE_..., or b) LIST ? Either way,
the respective versions of the doc can be found on
http://www.rncbc.org/ls/.
P.P.S. Do you think we can glue a digest of this thread and post it to the
maillist? Or is it "cosa nostra"? :)
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Christian Schoenebeck
Date: Sun, June 13, 2004 22:48
--------------------------------------------------------------------------
Es geschah am Sonntag, 13. Juni 2004 23:07 als Rui Nuno Capela schrieb:
>> Again, if the client implementation feels that two connections are
>> easier for it, why not.
>> I just think it will be easier on the server to just have single port,
>> single protocol, multiple connections will have to be supported
>> anyways . . .
>
> Yes, and to satisfy both connection modes the server *must* follow one
> simple rule:
>
> * All event messages *must* be sent to, and only to, the socket
> connection where the SUBSCRIBE command is received.
>
> This rule applies whether the client maintains a single or a double
> connection.
>
> On my part, which is about liblscp, I'll eventually implement the
> double connection client model, exactly as I pictured on my last note.
Good ideas!
> I'm feeling we can rest now :)
And I at least hope to have the audio device configuration stuff done til
tomorrow. Unfortunately I won't have the time to update the CHANNEL
commands til tomorrow, means the version I will commit won't be able yet
to assign an audio output device for a sampler channel via LSCP, means a
broken LS version, at least until the new SET CHANNEL AUDIO_OUTPUT_DEVICE
command will be implemented.
So, should I make branch in CVS or will somebody have the time to
implement that mandatory command (SET CHANNEL AUDIO_OUTPUT_DEVICE)?
Vladimir? Benno?
It's not much work and not hard either, but I simply won't the time for
it, sorry! Exams are priority.
> P.S. Please remember to post your verdicts about the changes to the
> draft document. Do we stick with a) GET AVAILABLE_..., or b) LIST ?
> Either way, the respective versions of the doc can be found on
> http://www.rncbc.org/ls/.
As nobody answered I just implemented it that way now:
GET AUDIO_OUTPUT_DEVICES (amount of devices)
LIST AUDIO_OUTPUT_DEVICES (list of devices: "0,3,5")
If you decide to change it, just edit those lines in src/network/lscp.y,
issue a 'make parser' and commit the new generated parser files to CVS.
And please: only ONE place for the protocol document. You all should have
write (FTP) access to the LS webserver, so place it there, please!
> P.P.S. Do you think we can glue a digest of this thread and post it
> to the maillist? Or is it "cosa nostra"? :)
Nothing against it!
CU
Christian
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 23:12
--------------------------------------------------------------------------
Rui,
Christian,
Great! Looks like we are all in agreement now.
Yes, events MUST be sent only to the same connection where subscribe was
received.
I'd love to implement a few things on the lscp server side. I usually
can only do that on weekends and late nights though . . . If Benno beats
me to the punch with it i'm not going to object either :)
And i did comment about "LIST" :) I'm happy with it!
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw
From: Vladimir Senkov
Date: Sun, June 13, 2004 23:50
--------------------------------------------------------------------------
Christian,
I didn't know i had write access to LS webserver. How do i gain/use it? I
could edit the protocol spec with stuff from our last discussions . . . I
could then post a quick notice to the list about this so that everybody
could read the latest draft . . .
We just need to develop a locking mechanism so that only one person edits
the document at any one time.
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: [Linuxsampler-devel] new version of lscp spec
From: Vladimir Senkov
Date: Mon, June 14, 2004 5:26
To: lin...@li...
--------------------------------------------------------------------------
Hi Everybody,
Linuxsampler mafia has been secretly discussing future of LSCP protocol
this weekend :)
I tried to capture that discussion (as well as my own bias :) in a new
verion (08) of the spec.
I've just uploaded it to the website.
Mafia, you know who you are :) let me know if i missed/misinterpreted
something, or just plain "misused trust" . . . hopefully i'll have a
chance to fix it in this life :)
Everybody else please comment on it as well.
Changes:
Events. Subscribe/notify, etc.
LIST instead of GET AVAILABLE_ for channels, audio outputs and midi
inputs. Some other changes and rewording of 3.1 and 3.2.
removed chapter 7 (too lazy?) excuse: only requests were SPEC'd in this
format. events are now more like warnings . . . they are not specified in
this format. Do they need to be?
Regards,
Vladimir.
--------------------------------------------------------------------------
* * * * * * * * * * * * * * * THE END * * * * * * * * * * * * * * *
|
