Menu
▾
▴
[Linuxsampler-devel] The Mafia Files - Part I (was: new version of lscp spec)
|
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 * * * * * * * * * * * * * *
--------------------------------------------------------------------------
|
