Menu
▾
▴
linuxsampler-devel
|
From: Rui N. C. <rn...@rn...> - 2004-06-14 15:35:32
|
Hi everybody,
This is the first 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.
Just to put everybody in sync again :)
Sorry for the long post(s).
Enjoy.
--
rncbc aka Rui Nuno Capela
rn...@rn...
--------------------------------------------------------------------------
* * * * * * * * * * * * * * * * PART I * * * * * * * * * * * * * * * *
---------------------------- Original Message ----------------------------
Subject: qsampler is cheesy :)
From: Benno Senoner
Date: Thu, June 10, 2004 1:26
--------------------------------------------------------------------------
I just made a quick experiment: took the 3D knob a guy posted on the LAD
list and pasted them over a QS screenshot, see attachment. I must admit
looks quite cheesy !! :)
Perhaps at a later stange it will be better to use knobs instead of
faders to save space on th QS GUI, for now faders are ok and thanks to
Qt's power replacing a fader with know is very little work.
cheers,
Benno
---------------------------- Original Message ----------------------------
Subject: Re: qsampler is cheesy :)
From: Rui Nuno Capela
Date: Thu, June 10, 2004 11:14
--------------------------------------------------------------------------
>
> I just made a quick experiment: took the 3D knob a guy posted on the
> LAD list [...]
>
The guy who posted the knobs in fact mentioned Peter Eschler's LDrum, a
sample based drum machine for Linux, Jack powered and Qt based just like
Qsampler:
http://www.sinussource.de/ldrum/
>
> [...] and pasted them over a QS screenshot, see attachment.
> I must admit looks quite cheesy !! :)
>
Yes. I admit the knobs are very good looking.
>
> Perhaps at a later stange it will be better to use knobs instead of
> faders to save space on th QS GUI, for now faders are ok and thanks
> to Qt's power replacing a fader with know is very little work.
>
Guess we may contact Peter et al. for joining Qt style and artwork forces?
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: qsampler is cheesy :)
From: Mark Knecht
Date: Thu, June 10, 2004 14:32
--------------------------------------------------------------------------
Benno Senoner wrote:
> I just made a quick experiment: took the 3D knob a guy posted on the
> LAD list and pasted them over a QS screenshot, see attachment.
> I must admit looks quite cheesy !! :)
>
> Perhaps at a later stange it will be better to use knobs instead of
> faders to save space on th QS GUI, for now faders are ok and thanks
> to Qt's power replacing a fader with know is very little work.
>
> cheers,
> Benno
Gosh, I guess it's just preferences, but I don't think QSampler is cheesy
at all! I do think that there is a lot of space that could be used in
better ways, but I didn't think that visual beauty was Rui's goal right
now.
Personally I don't care much for knobs. When you run at high screen
resolution they can often be difficult to adjust in small increments.
I do like the knobs you picked out though, They look quite nice.
As for saving space, if you want the stream fill percentage in the final
gui then couldn't it be in some sort of green under the name on the left?
That would save lots of space. Other than volume and panning how many
other things will you want? I can suggest possibly channel by channel
LADSPA plugins and submix buses, and those could be buried in a channel
setup dialog very easily I think.
Anyway, I'm actually getting pretty used to QSampler's layout! I vote for
a fine Camenbert if anything at all. ;-)
- Mark
---------------------------- Original Message ----------------------------
Subject: QS,LS communication Re: qsampler is cheesy :)
From: Benno Senoner
Date: Thu, June 10, 2004 18:37
--------------------------------------------------------------------------
Rui Nuno Capela wrote:
>> Perhaps at a later stange it will be better to use knobs instead of
>> faders to save space on th QS GUI, for now faders are ok and thanks
>> to Qt's power replacing a fader with know is very little work.
>>
>
> Guess we may contact Peter et al. for joining Qt style and artwork
> forces?
>
yes make sense. Rui could you do that please (explaining him a bit what we
want to do etc) and then let us know what responded ?
for example reduz (Juan L.) has already done some pixmap based slider and
ledchain (for peak meters) widgets in Qt (GPLed) and he will probably do
pixmap based knobs too so we could reuse that stuff too.
I think using knobs make probably sense since it save space. see the NI
Kontakt interface:
http://www.native-instruments.com/uploads/pics/multi16.gif
with volume, pan, tuning , implementing them as sliders would eat up too
much space (either vertically or horizontally) and if you ask me, volume
faders are always vertical in real mixers so it's a bit unnatural to
drive them horizontally (but that's a personal opinion).
Another idea could be having the peak meters (like in Kontakt) and below
the stream usage bar so that that the GUI does not become too large.
BTW how many times/sec do you update the buffer streaming percentage ?
The problem with LSCP I see is that if we make lots of separate requests
(one for each sampler channel) multiplied by the number of requests/sec
the number can become pretty big.
eg 40 sampler channels * 5 requests/sec = 200 requests/sec one request
each 5msec.
Since LSCP is synchronous,
eg
client: GET BUFFER PERCENTAGE of channel 1
LS: ... response ...
client: GET BUFFER PERCENTAGE of channel 2
LS: ... response ...
etc ...
there is a lot of rescheduling between the LS server and the GUI which is
not quite what we want.
So we could solve the problem in two ways: allow grouping of LSCP
commands so that the GUI sends out a batch of commands and then gets all
the responses in one rush, that way if we send out 40 GET BUFFER
PERCENTAGE commands there is only one context switch from the GUI to the
LSCP server and then back to the GUI which will process the results.
Or alternatively as Christian said, solve it using events so that LS
asynchronously sends the buffer percentages when they change.
Christian what do you think ?
To me the grouping of commands does not look that bad since it requires
only one single TCP socket and the data rate of responses is still driven
by the client (the GUI).
eg if the GUI sends out 5 get buffer percentage commands per sec then it
will get the same amount of responses per sec.
if the GUI stalls for some reason, the LSCP server would not flood the
GUI with messages it is not able to process.
Regarding events, will the events delivered only via UDP ?
I think we need to let users stay in the TCP domain if they wish because
UDP is harder to route through firewalls, nat routers etc. (so in theory
the client could open 2 sockets, one for commands and one for async
events which it would get from LS).
I think QS should not do more than a total of max 5-20 client/server
transactions/sec, that way we avoid unnecessary rescheduling as when we
send out a get buffer/status etc command for each sampler channel.
cheers,
Benno
---------------------------- Original Message ----------------------------
Subject: Re: QS,LS communication Re: qsampler is cheesy :)
From: Rui Nuno Capela
Date: Thu, June 10, 2004 22:01
--------------------------------------------------------------------------
Benno Senoner wrote:
>
>>>Perhaps at a later stange it will be better to use knobs instead of
>>>faders to save space on th QS GUI, for now faders are ok and thanks
>>> to Qt's power replacing a fader with know is very little work.
>>>
>>
>>Guess we may contact Peter et al. for joining Qt style and artwork
>>forces?
>>
>
> yes make sense. Rui could you do that please (explaining him a bit
> what we want to do etc) and then let us know what responded ?
>
OK. I'll try to, having the enough time ;)
>
> for example reduz (Juan L.) has already done some pixmap based slider
> and ledchain (for peak meters) widgets in Qt (GPLed) and he will
> probably do pixmap based knobs too so we could reuse that stuff too.
>
Any URLs for me checking it out? Is this reduz the same one of
cheesetracker fame?
> I think using knobs make probably sense since it save space.
> see the NI Kontakt interface:
> http://www.native-instruments.com/uploads/pics/multi16.gif
> with volume, pan, tuning , implementing them as sliders would eat up
> too much space (either vertically or horizontally)
> and if you ask me, volume faders are always vertical in real mixers so
> it's a bit unnatural to drive them horizontally
> (but that's a personal opinion).
>
But we don't have tune and pan already, do we? Nevertheless I personally
prefer volume to be sliders, as they are right now, and tune and pan
controls as knobs makes more sense to me. But let's leave that to your
LAD's discussion ;-)
>
> Another idea could be having the peak meters (like in Kontakt) and
> below the stream usage bar so that that the GUI does not become too large.
>
T think we have stream buffer fill usage, not audio peak meters. They're
not one and the same, AFAICT, are they? Of course we can have it like a
custom widget, other than Qt's QProgressBar which I found easier to fit.
I'm also introducing peak meters on qjackctl, very experimental yet (see
screenshot attached). Maybe I can steal that code to qsampler :)
>
> BTW how many times/sec do you update the buffer streaming percentage ?
>
It's a user configurable option: View|Options...|Display|Auto refresh
(msec). The default is 500 msec. In the future, the updating is (supposed
to/will be) event driven, via a UDP stream, as on the LSCP draft.
>
> The problem with LSCP I see is that if we make lots of separate requests
> (one for each sampler channel) multiplied by the number of requests/sec
> the number can become pretty big.
>
I agree, but we can have a kind of trade off. IMO the displayable data
doesn't need to be strictly realtime, or in other words, a instantaneous
snapshot. It can be cumulative and presented as just sense data to show
the user that everything is working alright. That way the refresh cycle
can be quite longer, without loosing much information, and less than 2
times a second for example (as it is now by default :)
>
> Regarding events, will the events delivered only via UDP ?
> I think we need to let users stay in the TCP domain if they wish because
> UDP is harder to route through firewalls, nat routers etc. (so in theory
> the client could open 2 sockets, one for commands and one for async events
> which it would get from LS).
>
Just for the record, QS already listens on a UDP socket, but does not do
much with that, it only blindly prints what it receives on the messages
window. And that part of the code is not yet thread safe, so don't count
on it for the time being, without probably crashing QS.
>
> I think QS should not do more than a total of max 5-20 client/server
> transactions/sec, that way we avoid unnecessary rescheduling as when
> we send out a get buffer/status etc command for each sampler channel.
>
Grouping is fine, at least if in just one command we could get the status
of all current channels, for stream and voice usage. That makes
rescheduling rate independent of the number of channels, as far as
client/server communication is concerned, which is a good thing.
BTW on stream usage, having that QS only shows the least filled buffer
usage percentage, couln't it be a lil'more obvious that LS would just make
it ready available on the command response, instead of the whole bunch of
filled streams as it's currently doing? I think it's a nonsense having
such a command transaction that is called so frequently and then wastes so
much raw data.
I would prefer that LS would just deliver the least data for the show in
the first place, nothing more, nothing less. That would help too.
Talking about changes on the LSCP... Christian? :)
I've noticed this late that the GET CHANNELS command is about to change
it's response radically from the current count of channels to a comma
separated list of channel ids. Wouldn't it be nicer to keep the current
semantics exactly as it is, and introduce a brand new command, eg. LIST
CHANNELS, just for the new purpose ?
OK. Following the same convention, GET DEVICES command would return the
current device count, and eg. LIST DEVICES would return the list of the
device ids.?
This is just about having command naming consistency and, you guessed
right, compability :)
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: QS,LS communication Re: qsampler is cheesy :)
From: Christian Schoenebeck
Date: Thu, June 10, 2004 23:22
--------------------------------------------------------------------------
Es geschah am Donnerstag, 10. Juni 2004 19:37 als Benno Senoner schrieb:
> So we could solve the problem in two ways: allow grouping of LSCP
> commands so that the GUI sends out a batch of commands
> and then gets all the responses in one rush, that way if we send out
> 40 GET BUFFER PERCENTAGE commands there is only one context switch
> from the GUI to the LSCP server and then back to the GUI which will
> process the results.
>
> Or alternatively as Christian said, solve it using events so that LS
> asynchronously sends the buffer percentages when they change.
>
> Christian what do you think ?
UDP Events, definitely. But that's not an important issue to me either. We
add UDP Event support when all basic commands from the TCP part are
completely implemented.
CU
Christian
---------------------------- Original Message ----------------------------
Subject: Re: QS,LS communication Re: qsampler is cheesy :)
From: Christian Schoenebeck
Date: Thu, June 10, 2004 23:33
--------------------------------------------------------------------------
Es geschah am Donnerstag, 10. Juni 2004 23:01 als Rui Nuno Capela schrieb:
> But we don't have tune and pan already, do we? Nevertheless I personally
No, not yet.
> Just for the record, QS already listens on a UDP socket, but does not do
> much with that, it only blindly prints what it receives on the messages
> window. And that part of the code is not yet thread safe, so don't count
> on it for the time being, without probably crashing QS.
No problem, it will take some time til we start with UDP events.
> BTW on stream usage, having that QS only shows the least filled buffer
> usage percentage, couln't it be a lil'more obvious that LS would just
> make it ready available on the command response, instead of the whole
> bunch of filled streams as it's currently doing? I think it's a nonsense
> having such a command transaction that is called so frequently and then
> wastes so much raw data.
Actually my original idea was the GUI to dynamically display meters for
all buffers, so it might help on debugging the disk thread. But sure we
can add a command to only return the least filled buffer.
> I've noticed this late that the GET CHANNELS command is about to change
> it's response radically from the current count of channels to a comma
> separated list of channel ids. Wouldn't it be nicer to keep the current
> semantics exactly as it is, and introduce a brand new command,
> eg. LIST CHANNELS, just for the new purpose ?
>
> OK. Following the same convention, GET DEVICES command would return the
> current device count, and eg. LIST DEVICES would return the list of the
> device ids.?
Agreed. I thought about exactly that but when I wrote the changes I
decided it would be trivial to get the amount from the comma separated
list.
> This is just about having command naming consistency and, you guessed
> right, compability :)
Would you like to update the draft document yourself?
CU
Christian
---------------------------- Original Message ----------------------------
Subject: Re: QS,LS communication Re: qsampler is cheesy :)
From: Rui Nuno Capela
Date: Fri, June 11, 2004 10:13
--------------------------------------------------------------------------
Hi,
About the changes on the LSCP draft document, there goes below the summary
of my proposal.
Attached you may find the changed doc
(draft-linuxsampler-protocol-08.sxw). Please check it out for correctness
in form and contents (as a side note, it was the first time I've used
OOo's native format :).
4.2.6 Getting all created audio output device count
GET AUDIO_OUTPUT_DEVICES
returns the current audio output device count.
4.2.7 Getting all created audio output device list
GET AVAILABLE_AUDIO_OUTPUT_DEVICES
returns a comma-semarated list of all created audio output
device number IDs.
4.3.6 Getting all created MIDI input device count
GET MIDI_INPUT_DEVICES
returns the current MIDI input device count.
4.3.7 Getting all created MIDI input device list
GET AVAILABLE_MIDI_INPUT_DEVICES
returns a comma-semarated list of all created MIDI input
device number IDs.
4.4.3 Getting all created sampler channel count
GET CHANNELS
returns the current sampler channel count.
4.4.4 Getting all created sampler channel list
GET AVAILABLE_CHANNELS
returns a comma-separated list of all current sampler
channel number IDs.
Note that I've rephrased some of the new commands: instead of a new
particle, LIST, which I confess was my hasty suggestion, may I yet again
suggest to stay in the GET realm, such as GET AVAILABLE_... to imply for a
comma-separated command response?
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: QS,LS communication Re: qsampler is cheesy :)
From: Christian Schoenebeck
Date: Fri, June 11, 2004 12:26
--------------------------------------------------------------------------
Es geschah am Freitag, 11. Juni 2004 00:58 als Rui Nuno Capela schrieb:
>> Actually my original idea was the GUI to dynamically display meters
>> for all buffers, so it might help on debugging the disk thread. But
>> sure we can add a command to only return the least filled buffer.
>
> Yeah, and just one new command that would return the least filled
> buffer percentage, stream and voice count for ALL channels in one
> transaction. How should we call it? GET SNAPSHOT?
I would prefer to do such things later by using UDP Events instead of
adding further TCP commands that actually do a static, fix set of
existing commands, because the latter is kind of nasty. So I would prefer
to let the client to enable/disable the events he's actually interested
in and those will be frequently sent to the client via UDP. We could also
limit the frequency of those events to limit the stress.
>>> OK. Following the same convention, GET DEVICES command would return
>>> the current device count, and eg. LIST DEVICES would return the list
>>> of the device ids.?
>>
>> Agreed. I thought about exactly that but when I wrote the changes
>> I decided it would be trivial to get the amount from the comma
>> separated list.
>
> Great! Shall we stick with my suggestions, that are:
>
> GET CHANNELS - return current channel count (NO CHANGE)
> LIST CHANNELS - return comma-separated list of channel number ids (NEW)
> GET DEVICES - return current channel count (CHANGE)
> LIST DEVICES - return comma-separated list of device number ids (NEW)
Sure.
> > Would you like to update the draft document yourself?
>
> If that means changing that "draft-linuxsampler-protocol-07.sxw" OOo
> file, that's online on LS.org, consider it done. Guess it will bump
> to 08
Great!
> then... However I will leave that all-in-one-snapshot command out,
> while you think about it :)
As said, I believe it would be nasty. Other opinions?
CU
Christian
---------------------------- Original Message ----------------------------
Subject: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Rui Nuno Capela
Date: Fri, June 11, 2004 16:57
--------------------------------------------------------------------------
Hi,
Please find attached my latest LSCP draft document,
(draft-linuxsampler-protocol-08.sxw). Sorry if this is wasting precious
bandwidth, but I couldn't resist to review it on my own.
Again, here goes the summary of the command section changes:
4.2.6 Getting all created audio output device count
GET AUDIO_OUTPUT_DEVICES
returns the current audio output device count.
4.2.7 Getting all created audio output device list
GET AVAILABLE_AUDIO_OUTPUT_DEVICES
returns a comma-semarated list of all created audio output
device number IDs.
4.3.6 Getting all created MIDI input device count
GET MIDI_INPUT_DEVICES
returns the current MIDI input device count.
4.3.7 Getting all created MIDI input device list
GET AVAILABLE_MIDI_INPUT_DEVICES
returns a comma-semarated list of all created MIDI input
device number IDs.
4.4.3 Getting all created sampler channel count
GET CHANNELS
returns the current sampler channel count.
4.4.4 Getting all created sampler channel list
GET AVAILABLE_CHANNELS
returns a comma-separated list of all current sampler
channel number IDs.
Note that I've rephrased some of the new commands: instead of a new
particle, LIST, which I confess was my hasty suggestion, may I yet again
suggest to stay in the GET realm, such as GET AVAILABLE_... to imply for a
comma-separated command response?
Cheers.
--
rncbc aka Rui Nuno Capela
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Christian Schoenebeck
Date: Fri, June 11, 2004 21:09
--------------------------------------------------------------------------
Es geschah am Freitag, 11. Juni 2004 17:57 als Rui Nuno Capela schrieb:
> Again, here goes the summary of the command section changes:
>
[SNIP]
>
> 4.4.3 Getting all created sampler channel count
>
> GET CHANNELS
>
> returns the current sampler channel count.
>
>
> 4.4.4 Getting all created sampler channel list
>
> GET AVAILABLE_CHANNELS
>
> returns a comma-separated list of all current sampler
> channel number IDs.
>
>
> Note that I've rephrased some of the new commands: instead of a new
> particle, LIST, which I confess was my hasty suggestion, may I yet
> again suggest to stay in the GET realm, such as GET AVAILABLE_...
> to imply for a comma-separated command response?
Hmmm... I liked the LIST idea more. :)
GET CHANNELS
LIST CHANNELS
or:
GET CHANNEL_COUNT
GET/LIST CHANNELS
???
Opinions?
CU
Christian
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Vladimir Senkov
Date: Sat, June 12, 2004 17:34
--------------------------------------------------------------------------
Rui Nuno Capela wrote:
>Vladimir,
>
>Just to have you in sync whith this thread, that was taking place off
>list... sorry if we forget you on the CC's.
>
>You're free to comment :)
>
>
Thanks!
You may have noticed my late-last-night attempt to refactor some of the
lscpserver code.
Hope i didn't break too much stuff . . . :) I did a quick check with the
GUI and telnet and it looked OK.
I think LIST is a cool idea. AVAILABLE_xxx was a bit confusing . . .
sometimes in the protocol you have to have space sometimes an underline
character, etc. I think LIST gets rid of that and it's something easier
to follow, remember, not to mention the commands will get shorter.
I also have a few other suggestions. Some are just cosmetic . . . If we
are all in agreement about them i could update the doc myself so that
would not waste anybodys time.
3.1 Simple unidirectional communication. I'd like to call it a "Simple
request/response communication mode".
I'd like to also change 3.2 to be called something like "Event
subscription and notification"
Now a more substantial proposal . . . I know all the good reasons for
making event notifications UDP based, but there are some drawbacks from
that as well. More and more users now are "security aware". That doesn't
mean they know anything about security, of course, but they know it's
"bad" to have no firewall and they now have them on by default just about
anywhere.
Microsoft SP2 for XP for example has a FW that is enabled by default. If
you had XP for a while and everything was working fine don't be
surprised if your applications stop working after you've installed SP2 on
it. Many corporations now use automated methods to apply patches. So one
day you come to work and your PC is already rebooted with the latest
patches from MS and nothing works anymore :)
So, if we have a GUI running on XPSP2 or above . . . users will have to
punch a hole in that to allow UDP to get in.
How in the world are they going to do that if they don't know the port
number is my first question . . . I don't remember for sure, but i think
you might not even be able to allow "all udp" in.
Many linux distors are now also coming with a FW enabled (or at least as
a recommended option during install). While some users may have no
problems with configuring iptables, etc, others may be in trouble there.
Another example is someone with a wireless laptop and one of those access
points with NAT in them. Depending on where the LS engine
resides, packets may need to be natted. There are other examples as well,
i'm just trying to be brief :)))
So what i'm suggesting is . . . why not use TCP for that as well. Either
a separate TCP connection initiated by the client (this is a key for FW,
NAT, etc.) or even the same one. If we use the same we'll have to
introduce some locking on the server side so that the resultssets can not
be interrupted by the event notification. I think we can handle that
fairly easily. It not add any real latency there for notifications,
because the entire resultset is produced at the same time (and will
likely fit in a single packet).
We can prepend any event notification with something to make them stand
out . . . like:
EVENT:<event code>:<event data>\r\n
(it will look a lot like ERR or WRN).
This way the liblscp on the client side will easily handle that.
There is (of course) another way of dealing with FW/NAT/etc. We can force
the client to send a UDP packet (ping for example) to help FW/NAT device
to setup state first thing after the subscription, but it's not always
going to help and there may be timing issues as subscription may be
processed by the server with some delay.
Basically, i like UDP for it's efficiency but i've seen when folks are
trying to design protocol based on it and they end up redesigning (a poor
man's) TCP. We are already talking about reachability testing, dead peer
detection, etc. With TCP we can (sometimes) just rely on it's own
mechanisms. Eventually we might start talking fragmentation . . . it
could get nasty there.
There is a price to pay there of course but i think it may be worth it.
I'm sorry i'm starting to go down this rathole perhaps a bit too late. To
be honest i had these thoughts before and i kept discussing them with
myself and now finally convinced myself that the overhead will probably
be worth it.
What do you guys think?
We can discuss this on any other media (list/irc/etc) if you'd like.
Regards,
Vladimir.
---------------------------- Original Message ----------------------------
Subject: Re: draft-linuxsampler-protocol-08.sxw (was: QS,LS communication)
From: Christian Schoenebeck
Date: Sat, June 12, 2004 19:54
--------------------------------------------------------------------------
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 !!!
CU
Christian
Es geschah am Freitag, 11. Juni 2004 22:09 als Christian Schoenebeck schrieb:
> Es geschah am Freitag, 11. Juni 2004 17:57 als Rui Nuno Capela schrieb:
> > Again, here goes the summary of the command section changes:
>
> [SNIP]
>
>> 4.4.3 Getting all created sampler channel count
>>
>> GET CHANNELS
>>
>> returns the current sampler channel count.
>>
>>
>> 4.4.4 Getting all created sampler channel list
>>
>> GET AVAILABLE_CHANNELS
>>
>> returns a comma-separated list of all current sampler
>> channel number IDs.
>>
>>
>> Note that I've rephrased some of the new commands: instead of a new
>> particle, LIST, which I confess was my hasty suggestion, may I yet
>> again suggest to stay in the GET realm, such as GET AVAILABLE_...
>> to imply for a comma-separated command response?
>
> Hmmm... I liked the LIST idea more. :)
>
> GET CHANNELS
> LIST CHANNELS
>
> or:
>
> GET CHANNEL_COUNT
> GET/LIST CHANNELS
>
> ???
>
> Opinions?
>
> CU
> Christian
* * * * * * * * * * * * * * END OF PART I * * * * * * * * * * * * * *
--------------------------------------------------------------------------
|
|
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 * * * * * * * * * * ...
[truncated message content] |
Thanks for helping keep SourceForge clean.
X