linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

[Linuxsampler-devel] Load Instrument patch (was: LSCP event notification notes)

[Rui N. C. <rn...@rn...>]

Hi,

Myself wrote:
>
>   I'm sure, for the time being, we can fool things up on the server and,
> upon receiving a LOAD INSTRUMENT command, the server will do:
>
>   1) Check for file validity, by checking for it's existence and naively
> verify if it's of one of the supported formats (gig, dls or whatever).
>
>   2) If yes, send the "OK" response immediately to the client, and set the
> progress status variable to "0" (zero percent). Otherwise an error status
> value will be set (e.g. "ERR").
>
>   3) Load the instrument file as it would do normally, as is.
>
>   4) Right after the load completes, just update the status variable with
> a succesful "OK", or "ERR" otherwise. Let's face it, the error status may
> hold the actual final response to the LOAD INSTRUMENT command, as it was
> until now.
>
>   The value stored on this server channel status variable is exactly the
> one that will be held on the INSTRUMENT_STATUS field of the GET
> CHANNEL_INFO command. Clear?
>
>   Honestly, I think this isn't that hard to do on the server side. The
> actual progress threading and probable libgig changes can be just left to
> when Christians get back. Until then, everybody will be happier, me and
> qsampler :)
>

Not hard at all ;)

As a proof-of-concept, on attachment to this post, you may find a
diff-patch to the linuxsampler_0_2_0_cvs20040613 tarball on ls.org,
corresponding to the source tree just before the latest CVS revolution.
Maybe it's applicable to current CVS HEAD too, however I didn't tested it
yet myself.

Specifically, this patch makes the LOAD INSTRUMENT command to return
immediately, almost/always with an "OK" response, while spawning the
proper instrument file loading in the background.

The new INSTRUMENT_STATUS item from GET CHANNEL INFO inquiry command is
where one checks for a successfull load. The instrument status value holds
the load progress percentage if positive, currently only "0" and "100" ;)
Otherwise, in case of a load exception error, the instrument status
variable will hold a negative value.

As proposed, the instrument file load is considered successful and
complete when and only when INSTRUMENT_STATUS holds a "100" value.


>   If all this is OK, I can make the changes myself to the draft document.
> Yet again, it will bump to v.09. The summary preview of changes are:
>
>   4.4.1 LOAD INSTRUMENT slight semantics change;
>   4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS;
>   6.6 INSTRUMENT_LOADING event type simply vanishes away.
>

Just hoping this patch gets tested and reviewed, and ultimately found
applicable, I'll start making the document changes in no time.

Hope to hear from you.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] front-end questions

[Juhana S. <ko...@ni...>]

Hello.
A quick feature check for Linuxsampler.

I started writing a simple grab&drag multitrack audio sequencer.
I would need an audio engine which can do the following:
 (1) can play long wav files directly from disk, no looping needed;
 (2) each wav file would be shaped with a pre-defined amplitude
     envelope having arbitrary number (e.g., large enough)
     of points, possibly with linear and exp decay shapes;
 (4) can also read the whole sequence in advance.

I already started writing my own simple disk sampler to which
I first feed the sequence data such as
  2.000000 l01
  2.000000 l02
  5.556244 p17
  5.851303 v11
  <time> <wavfile id>   (id could be a number for speed)
Then I set the engine clock to 0.0 and playing can be started.
(Nobody actually forbids sending seq data during the play.)

The amp envelope would be sent to the engine from the sequencer.
The envelope is not part of the wav file, but a part of the sequencer.

I'm still wondering what would be best solution to the following
feature: the multitrack editor has both the amp envelope for the
wav files and the envelope for the whole track. I could premultiply
the amplitude gains together and feed only the wav file envelope to
the engine, but that does not work well if I use lin/exp or exp/exp
types of envelopes. Could Linuxsampler support multiple envelopes?
(I could approximate exp envelopes with linear envelopes and then
precompute the produced linear envelope, though.)

Juhana

[Linuxsampler-devel] [ANNOUNCE] Qsampler 0.0.2 released!

[Rui N. C. <rn...@rn...>]

Hi,

As promised, Qsampler 0.0.2 has been packaged and released, along with
liblscp-0.1.9.99.

This release serves as a syncpoint to latest CVS on linuxsampler.org.
Please find the respective tarballs and selected RPMs on the following
sites:

    http://sourceforge.net/projects/qsampler
    http://qsampler.sourceforge.net
    http://www.rncbc.org/ls

Soon this will be officially featured on the linuxsampler.org downloads
section.

Enjoy.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] LSCP event notification notes

[Rui N. C. <rn...@rn...>]

Vladimir,
>
> I'm sorry, i forgot about this . . . I've added this event to illustrate
> how this *could* be done with events :)
> I have nothing against your proposal to load instruments in the
> background and have an extra status field in CHANNEL_INFO.
> I'm not sure about the implementation on the server though . . . might be
> a bit more difficult. I'll look into that at some point.

  No problem. I'm just insisting to make it official on the draft
protocol specification. I know that's not that immediately obvious to
implement the progress notification/status on the server side, at least
without tweaking on libgig, as Christian once noted.

  Most probably, libgig has to be changed accordingly and the load process
will be spawned as an appropriate thread. A server channel instance
variable will have to be used in anyway to keep channel/instrument status
progress, that gets updated on each loaded chunk.

  I'm sure, for the time being, we can fool things up on the server and,
upon receiving a LOAD INSTRUMENT command, the server will do:

  1) Check for file validity, by checking for it's existence and naively
verify if it's of one of the supported formats (gig, dls or whatever).

  2) If yes, send the "OK" response immediately to the client, and set the
progress status variable to "0" (zero percent). Otherwise an error status
value will be set (e.g. "ERR").

  3) Load the instrument file as it would do normally, as is.

  4) Right after the load completes, just update the status variable with
a succesful "OK", or "ERR" otherwise. Let's face it, the error status may
hold the actual final response to the LOAD INSTRUMENT command, as it was
until now.

  The value stored on this server channel status variable is exactly the
one that will be held on the INSTRUMENT_STATUS field of the GET
CHANNEL_INFO command. Clear?

  Honestly, I think this isn't that hard to do on the server side. The
actual progress threading and probable libgig changes can be just left to
when Christians get back. Until then, everybody will be happier, me and
qsampler :)

  If all this is OK, I can make the changes myself to the draft document.
Yet again, it will bump to v.09. The summary preview of changes are:

  4.4.1 LOAD INSTRUMENT slight semantics change;
  4.4.9 GET CHANNEL INFO response new status field, INSTRUMENT_STATUS;
  6.6 INSTRUMENT_LOADING event type simply vanishes away.


> Any other comments?
>

Oh, just a minor: about CHANNEL_BUFFER_FILL event type (6.4), ermm...
wouldn't it be nicer to just name it BUFFER_FILL ? Note that on all other
event types a sampler channel is always implied, so why include it on the
event name on this one?

Bye now.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] LSCP event notification notes

[Vladimir S. <ha...@so...>]

Rui,

I'm sorry, i forgot about this . . . I've added this event to illustrate 
how this *could* be done with events :)
I have nothing against your proposal to load instruments in the 
background and have an extra status field in CHANNEL_INFO.
I'm not sure about the implementation on the server though . . . might 
be a bit more difficult. I'll look into that at some point.
Any other comments?

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>   After reading the latest LSCP document draft (v.08), I would like to
>expose my early thoughts about the new event protocol specification,
>suggestions for discussion and correction where applicable.
>
>   This event protocol has changed quite radically in this last draft, so
>we may consider we're drawing it again from scratch. So there's no
>better time than now to start it's discussion, having immediate
>implementation in mind, of course.
>
>   Let's get started.
>
>
>   A client registers or subscribes to event types it whishes to be
>notified for. The subscription command is (4.5.1):
>
>   SUBSCRIBE <event-id>
>
>   Where <event-id> is a generic event type identifier, being one of the
>following, as proposed on current draft:
>
>   CHANNELS           (6.1 Number of sampler channels changed)
>   VOICE_COUNT        (6.2 Number of active voices changed)
>   STREAM_COUNT       (6.3 Number of active disk streams)
>   BUFFER_FILL        (6.4 Disk stream buffer fill state changed)
>   CHANNEL_INFO       (6.5 Channel information changes)
>   INSTRUMENT_LOADING (6.6 Instrument loading progress)
>   MISCELLANEOUS      (6.7 Miscellaneous and debugging events)
>
>   One thing I'm kind of dislike is the INSTRUMENT_LOADING event. As
>I've stated before, my favorite approach is having a specific status field
>on the CHANNEL_INFO result set, that indicates the loading status of the
>instrument file.
>
>   Remember that I've been suggesting that the LOAD INSTRUMENT comand
>would return an immediate OK result iff the file is accessible and of the
>correct format and type. The loading process is taken on the
>background and would just keep it's progress internally by the server.
>That progress state would be just queried by any client via the GET
>CHANNEL_INFO command. A new field, e.g. INSTRUMENT_STATUS, shall then be
>included for that particular purpose.
>
>   Possible values for this new field would vary from "0" to "100"
>percent, and finally "OK", implying whether the sampler channel is
>perfectly operational.
>
>   So, no need for klunky LOAD INSTRUMENT with INSTRUMENT_LOADING event
>processing. On the server side, the background progress processing would
>have to be done anyway, so I hope my proposal looks simpler and surely
>does make clients snappy!
>
>   Note that I'm not completely against the INSTRUMENT_LOADING event
>existence. I'm only for having it as an option. It's the responsability of
>the client to decide what to do, if any better. Then, what I wish to
>propose is exactly the following:
>
>   1) Pseudo-asynchronous behaviour of the LOAD INSTRUMENT command, making
>it completely independant of the instrument sample file size or
>complexity. The channel instrument load process is always run in the
>background, and the client *must* not wait blocked for the load
>operation to complete. Never.
>
>   2) A new information field on the GET CHANNEL_INFO result set,
>INSTRUMENT_STATUS, where the current instrument load progress
>percentage and overall operationality of the corresponding sampler channel
>can be queried.
>
>   Assuming this is acceptable, I therefore question the existence of the
>INSTRUMENT_LOADING event type. If my proposal is found viable, then the
>instrument loading progress events may have it's notifications
>broadcasted to the subscribers of the CHANNEL_INFO event type. Is that
>simple :)
>
>   Bottom line is: a client doesn't have to subscribe to event delivery to
>check if the channel load instrument command has completed. Also,
>showing a visual progress bar is an option, not a rule. Either way, my
>suggestion satisfies both the option and the rule :)
>
>   Think I've made myself any clear.
>
>
>Comments please?
>
>Nuff said.
>  
>

[Linuxsampler-devel] LSCP event notification notes

[Rui N. C. <rn...@rn...>]

Hi,

   After reading the latest LSCP document draft (v.08), I would like to
expose my early thoughts about the new event protocol specification,
suggestions for discussion and correction where applicable.

   This event protocol has changed quite radically in this last draft, so
we may consider we're drawing it again from scratch. So there's no
better time than now to start it's discussion, having immediate
implementation in mind, of course.

   Let's get started.


   A client registers or subscribes to event types it whishes to be
notified for. The subscription command is (4.5.1):

   SUBSCRIBE <event-id>

   Where <event-id> is a generic event type identifier, being one of the
following, as proposed on current draft:

   CHANNELS           (6.1 Number of sampler channels changed)
   VOICE_COUNT        (6.2 Number of active voices changed)
   STREAM_COUNT       (6.3 Number of active disk streams)
   BUFFER_FILL        (6.4 Disk stream buffer fill state changed)
   CHANNEL_INFO       (6.5 Channel information changes)
   INSTRUMENT_LOADING (6.6 Instrument loading progress)
   MISCELLANEOUS      (6.7 Miscellaneous and debugging events)

   One thing I'm kind of dislike is the INSTRUMENT_LOADING event. As
I've stated before, my favorite approach is having a specific status field
on the CHANNEL_INFO result set, that indicates the loading status of the
instrument file.

   Remember that I've been suggesting that the LOAD INSTRUMENT comand
would return an immediate OK result iff the file is accessible and of the
correct format and type. The loading process is taken on the
background and would just keep it's progress internally by the server.
That progress state would be just queried by any client via the GET
CHANNEL_INFO command. A new field, e.g. INSTRUMENT_STATUS, shall then be
included for that particular purpose.

   Possible values for this new field would vary from "0" to "100"
percent, and finally "OK", implying whether the sampler channel is
perfectly operational.

   So, no need for klunky LOAD INSTRUMENT with INSTRUMENT_LOADING event
processing. On the server side, the background progress processing would
have to be done anyway, so I hope my proposal looks simpler and surely
does make clients snappy!

   Note that I'm not completely against the INSTRUMENT_LOADING event
existence. I'm only for having it as an option. It's the responsability of
the client to decide what to do, if any better. Then, what I wish to
propose is exactly the following:

   1) Pseudo-asynchronous behaviour of the LOAD INSTRUMENT command, making
it completely independant of the instrument sample file size or
complexity. The channel instrument load process is always run in the
background, and the client *must* not wait blocked for the load
operation to complete. Never.

   2) A new information field on the GET CHANNEL_INFO result set,
INSTRUMENT_STATUS, where the current instrument load progress
percentage and overall operationality of the corresponding sampler channel
can be queried.

   Assuming this is acceptable, I therefore question the existence of the
INSTRUMENT_LOADING event type. If my proposal is found viable, then the
instrument loading progress events may have it's notifications
broadcasted to the subscribers of the CHANNEL_INFO event type. Is that
simple :)

   Bottom line is: a client doesn't have to subscribe to event delivery to
check if the channel load instrument command has completed. Also,
showing a visual progress bar is an option, not a rule. Either way, my
suggestion satisfies both the option and the rule :)

   Think I've made myself any clear.


Comments please?

Nuff said.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Hi All,

As Christian pointed out, things may be unstable for the time being.
Indeed they are. In particular, base classes from driver direcrory are 
calling pure virtuals implemented in a derived classes (in audiodriver 
directory).
I need to find an elegant way to get around this without breaking too 
much of the beauty that Christian architected. If any of you already 
have this fixed or are planning to jump on it please let me know to 
avoid duplicatoin. In the mean time, i'll put that on my TODO list. I 
should be able to get to this on the weekend.
Nothing to worry about, just small issues here and there . . . good news 
is that there is whole bunch of new code and functionality there. I'm 
impressed! I think this is a giant step forward and with steps like that 
we'll see things improve very soon.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Latest CVS commit

[Rui N. C. <rn...@rn...>]

Christian,
>
>> [...] my own snapshots in http://www.rncbc.org/ls/.
>
> Well, it would make more sense to place it on the LS website, don't you
> think?

It's planned to be as soon as I get the qsampler and liblscp web pages
into ls.org, as benno suggested while ago. I'm still preparing some php
scripts or whatever to ease the pain ;)

> I don't like the situation to have various resources, this especially
> accounts to the protocol draft. There should only be one reource for the
> protocol doc otherwise we end in chaos.
>

Already off :)

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Latest CVS commit

[Christian S. <chr...@ep...>]

Es geschah am Montag, 14. Juni 2004 23:35 als Rui Nuno Capela schrieb:
> Hi Christian,
>
> > First off my latest commit may break things a bit, so I uploaded a CVS
> > snapshot tarball before:
> >
> > 	http://www.linuxsampler.org/downloads.html
>
> I've noticed you tagged the cvs snapshot tarball with something like
> version 0.2.0. However the AM_INIT_AUTOMAKE on top configure.in still
> references a 0.1 version. The later is where I pick the linuxsampler

Feel free to fix it. Actually 0.1 was meant for the old single channel version 
(there's also a tag in CVS for this) and 0.2 was meant since then for the 
multi channel version of LS.

> package version tag for my own snapshots in http://www.rncbc.org/ls/.

Well, it would make more sense to place it on the LS website, don't you think? 
I don't like the situation to have various resources, this especially 
accounts to the protocol draft. There should only be one reource for the 
protocol doc otherwise we end in chaos.

> > Rui, I propose you also upload a snapshot of a qsampler version which
> > fits the best to that LS version, so that users have a working
> > environment while we implement the new network protocol draft and deal
> > with the transition due to this.
>
> No problem.
>
> Both qsampler 0.0.1 and liblscp 0.1.9.98 alpha-releases are fundamentally
> working with the latest cvs20040613 snapshot. The same is valid with
> current qsampler and liblscp CVS HEAD. If I'm not terribly mistaken, those
> are even supposed to work on any forthcoming linuxsampler server changes,
> as far as of latest LSCP draft specification (v.08). So don't worry.

Current LS version from CVS HEAD is quite unstable and the protocol transition 
will bring situations where GUI and engine won't work together, so that's why 
I made the snapshot from yesterdays version.

> Nevertheless, I'm planning to package next alpha-releases of qsampler
> 0.0.2 and liblscp 0.1.9.99, starting tomorrow, based on current CVS HEAD
> of course.
>
> Just to have a baseline, just before your "leave" ;)

Fine.

CU
Christian

[Linuxsampler-devel] [qsampler, liblscp] latest CVS commit

[Rui N. C. <rn...@rn...>]

qsampler 0.0.1.94:

* The channel context menu is also accessible by right-clicking
  over the empty workspace area.


liblscp-0.1.9.99 (no version bump):

* Added support for the new LIST commands (draft v.08):

  lscp_list_channels()      => LIST CHANNELS
  lscp_list_audio_devices() => LIST AUDIO_OUTPUT_DEVICES
  lscp_list_midi_devices()  => LIST AUDIO_INPUT_DEVICES

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] Latest CVS commit

[Christian S. <chr...@ep...>]

Hi!

First off my latest commit may break things a bit, so I uploaded a CVS 
snapshot tarball before:

	http://www.linuxsampler.org/downloads.html

Rui, I propose you also upload a snapshot of a qsampler version which fits the 
best to that LS version, so that users have a working environment while we 
implement the new network protocol draft and deal with the transition due to 
this.

Now the changes:

	* src/common: added template class 'optional<>' which can be used e.g. as
	  return type whenever a value might be returned, but don't has to; this
	  template class pretty much acts like a pointer of the given type, but is
	  much more safer than a simple pointer

	* src/audiodriver: added static class AudioDeviceFactory to create audio
	  devices at runtime by using a string and to obtain driver informations
	  of drivers at runtime, driver classes should simply use the macro
	  REGISTER_AUDIO_OUTPUT_DRIVER(DriverName,DriverClass) in their cpp file
	  to register the driver to LinuxSampler (no changes needed anymore in the
	  LS code to add a new audio output driver)

	* src/drivers: added classes to dynamically manage driver parameters; there
	  are two different kinds of parameters: parameters which are need to
	  create a new device (DeviceCreationParameterX) used to e.g. create an
	  audio output device or a MIDI input device and parameters which are only
	  available at runtime, means when a device is already created
	  (DeviceRuntimeParameterX) which will be e.g. used as audio channel
	  parameters and MIDI port parameters

	* src/linuxsampler.cpp: all registered audio output drivers will be shown
	  on the console on startup

	* src/network: implemented configuration of audio output devices via LSCP

Vladimir, sorry I did not have the time to test it, so it maybe buggy as hell. 
But I hope the course is clear with the stuff I commited. MIDI device 
configuration can simply be done the same, so you just have to duplicate the 
used technics for MIDI device configuration.

This will be my last commit (major commit at least) for the next four weeks or 
so, once again exams time... Hope you guys won't let development of LS stall 
in the meantime !!!

CU
Christian

P.S. Maybe you even get Benno to move his ass !

[Linuxsampler-devel] The Mafia Files - Part II (was: new version of lscp spec)

[Rui N. C. <rn...@rn...>]

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     * * * * * * * * * * * * * * *

[Linuxsampler-devel] The Mafia Files - Part I (was: new version of lscp spec)

[Rui N. C. <rn...@rn...>]

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   * * * * * * * * * * * * * *
--------------------------------------------------------------------------

[Linuxsampler-devel] new version of lscp spec

[Vladimir S. <ha...@so...>]

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.

[Linuxsampler-devel] [qsampler] latest CVS commit

[Rui N. C. <rn...@rn...>]

qsampler 0.0.1.93:

* Added small wait event loop on qsamplerMainForm::stopServer(),
  so let local server terminate gracefully and stabilize, and
  avoiding a probable segfault on exit, which was preventing the
  correct salvage of settings and configuration.

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] dependency to boost library?

[Mark K. <mk...@co...>]

Christian Schoenebeck wrote:
> Es geschah am Mittwoch, 9. Juni 2004 23:26 als be...@ga... schrieb:
> 
>>Hi,
>>I agree with Mark,
>>copy the 30 lines, even if's 100 or 200.
> 
> 
> Already done.
> 
Thanks.

Re: [Linuxsampler-devel] dependency to boost library?

[Christian S. <chr...@ep...>]

Es geschah am Mittwoch, 9. Juni 2004 23:26 als be...@ga... schrieb:
> Hi,
> I agree with Mark,
> copy the 30 lines, even if's 100 or 200.

Already done.

> The less dependencies we have the easier it's to maintain and
> port LS to new platforms.
>
> I assume this stuff does not get used in the real time thread right ?

No, I just use it for device configuration.

CU
Christian

Re: [Linuxsampler-devel] dependency to boost library?

[<be...@ga...>]

Hi,
I agree with Mark,
copy the 30 lines, even if's 100 or 200.
The less dependencies we have the easier it's to maintain and
port LS to new platforms.

I assume this stuff does not get used in the real time thread right ?

cheers,
Benno
http://www.linuxsampler.org


Scrive Christian Schoenebeck <chr...@ep...>:

> Hi!
> 
> I'm currently thinking about adding a dependency in LS to the boost library:
> 
> 	

-------------------------------------------------
This mail sent through http://www.gardena.net

Re: [Linuxsampler-devel] dependency to boost library?

[Mark K. <mk...@co...>]

Christian Schoenebeck wrote:
> Hi!
> 
> I'm currently thinking about adding a dependency in LS to the boost library:
> 
> 	http://www.boost.org
> 
> It has many convenient, portable classes and templates and part of it will 
> make it into the upcoming C++ standard one day.
> 
> One thing I could really need at the moment is this:
> 
> 	http://www.boost.org/boost/optional.hpp
> 
> because the classes I designed for the driver configuration issue have 
> optional return values, means a method might return a value but doesnt have 
> to (e.g. keywords DEPENDS, RANGE_MIN, RANGE_MAX etc. from the new LSCP 
> draft), see http://www.boost.org/libs/optional/doc/optional.html for more 
> about this topic.
> 
> So the question now is do you think its worth to add this dependency or should 
> I just rewrite / copy the relevant part of "this optional" template for our 
> purpose? I mean it might be overkill to add this lib only for the small 
> amount I need (about 30 lines) but maybe we need something else from this lib 
> one day?
> 
> CU
> Christian
> 

Well, I just looked at boost from a user's perspective. It approaches 
7MB of code. I don't know how often that library changes, but I don't 
like the idea of having to build it very often to keep up to date with 
your work.

Maybe you can copy the 30+ lines for now, but plan on adding the 
dependency later when LS is more stable and closer to some sort of real 
usable release?

Thanks for taking input.

Cheers,
Mark

[Linuxsampler-devel] [qsampler] latest CVS commit

[Rui N. C. <rn...@rn...>]

qsampler 0.0.1.92:

* Maximum channel volume percent setting is now a global option,
  provided to override the default (which is 100%).

* Client/server transaction timeout option upper limit has been
  increased from 5000 to 60000 milliseconds.

Bye.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

[Linuxsampler-devel] dependency to boost library?

[Christian S. <chr...@ep...>]

Hi!

I'm currently thinking about adding a dependency in LS to the boost library:

	http://www.boost.org

It has many convenient, portable classes and templates and part of it will 
make it into the upcoming C++ standard one day.

One thing I could really need at the moment is this:

	http://www.boost.org/boost/optional.hpp

because the classes I designed for the driver configuration issue have 
optional return values, means a method might return a value but doesnt have 
to (e.g. keywords DEPENDS, RANGE_MIN, RANGE_MAX etc. from the new LSCP 
draft), see http://www.boost.org/libs/optional/doc/optional.html for more 
about this topic.

So the question now is do you think its worth to add this dependency or should 
I just rewrite / copy the relevant part of "this optional" template for our 
purpose? I mean it might be overkill to add this lib only for the small 
amount I need (about 30 lines) but maybe we need something else from this lib 
one day?

CU
Christian

Re: [Linuxsampler-devel] [qsampler] latest CVS commit

[Rui N. C. <rn...@rn...>]

Mark,
>
>     Since LS right now doesn't handle multiple MIDI channels correctly
> (or at least I cannot get it to) I tried running multiple instances of
> QS, but I always found that the second instance cannot connect to the LS
> server. I tried using the same 8888 port, and I tried choosing a
> different port number, but I continued to have trouble.
>
>     Is it possible right now to run multiple copies? If so can you
> publish a short set of instrctions on how to do it?
>

Nope, sorry. This is currently a LS server limitation, it only accepts one
client connection at a time.

In time it will do the multi-client trick, I'm sure.

The liblscp server interface had this capability since it's birth, but it's
parser was considered too crude to be part of the linuxsampler server
standards. No hard feelings, really :)

I've been focused on the client interface lately, so the server side has
been stuck if not buried. Maybe I can find the time to raise it back from
the dead :)

OTOH, that MIDI channel issue has been already addressed, just waiting for
a fix.

Bye now.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.1 released!

[Vladimir S. <ha...@so...>]

Mark,

IMHO Midi will not go to QS. Midi will go to LS. QS is a GUI that 
controls LS by speaking LSCP to it :)
When it comes to VSTi it will go to LS also . . .

Regards,
Vladimir.

Mark Knecht wrote:

> Christian Schoenebeck wrote:
>
>> Es geschah am Dienstag, 8. Juni 2004 10:07 als Rui Nuno Capela schrieb:
>>
>>>> SET AUDIO_OUTPUT_CHANNEL_PARAMETER <device-id> <audio-chan>
>>>> VOLUME=<volume>
>>>
>>>
>>> I think what Mark would really like is if this could be a realtime
>>> parameter. Will it be? :)
>>
>>
>>
>> Wait a second; LSCP is NOT meant for realtime operation. It's main 
>> purpose is to setup the sampler session, although it also provides 
>> settings like volume, etc. But realtime control will be part of the 
>> DMIDI Midi Input Device implementation.
>>
>> CU
>> Christian
>>
> Which is how it's done on GSt, correct? All control - volume, panning, 
> etc., is over MIDI in my environment.
>
> I didnt catch that distinction earlier.
>
> However, this does raise some strangeness about the use of QS long 
> term. Should my MIDI be going to LS directly, or should it be going to 
> QS which is the app I actually run? In the QS model I really don't 
> (and shouldn't) know anything about LS really. However, today I talk 
> to the underlying LS instance in QJackCtl.
>
> Sort of a strange model.
>
> How would this work if QS was a Windows VSTi? The user would want to 
> send MIDI to QS on the Windows box, and then QS would have to get it 
> sent to LS on the Linux box somehow?
>
> Or would QS reference the LS instance so that MIDI went directly to 
> it? That would be better for latency, etc.
>
> Sort of confusing...
>
> - Mark
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] [qsampler] latest CVS commit

[Mark K. <mk...@co...>]

Rui Nuno Capela wrote:
> qsampler 0.0.1.91:
> 
> * A channel context menu is now featured, by right-clicking over
>   each sampler channel strip.
> 
> BYe,

Rui,
    Since LS right now doesn't handle multiple MIDI channels correctly 
(or at least I cannot get it to) I tried running multiple instances of 
QS, but I always found that the second instance cannot connect to the LS 
server. I tried using the same 8888 port, and I tried choosing a 
different port number, but I continued to have trouble.

    Is it possible right now to run multiple copies? If so can you 
publish a short set of instrctions on how to do it?

    I'll be downloading the newest enhancements today.

Thanks,
Mark

Re: [Linuxsampler-devel] Load Progress meter, Was: [ANNOUNCE] QSampler 0.0.1 released!

[Rui N. C. <rn...@rn...>]

benno wrote:
>
> Ok no problem then, lets postpone this stuff.
> But then please Rui please increase the default timeout in QS to
> 60 secs or so because loading these PMI pianos on slow boxes could take
> really long.
>

It's your option. On qsampler menu, go to View/Options.../Server and set
up the timeout value as you wish. But, wait a moment... it has an upper
limit of 5 secs :(

Meanwhile, you can hack a bigger maxValue property in
qsamplerOptionsForm.ui file, line 445. Try to increase to 60000
(millisecs).

I will fix that soon...

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...