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

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Hi Vladimir,
>
> Now that the internals of midi input device and midi input ports are
> almost done, i'm beginning to think that it might make sense to
> consolidate the following LSCP commands:
> SET CHANNEL MIDI_INPUT_DEVICE <sampler-channel> <midi-device-id>
> SET CHANNEL MIDI_INPUT_PORT <sampler-channel> <midi-input-port>
> SET CHANNEL MIDI_INPUT_CHANNEL <sampler-channel> <midi-input-chan>
> into a single command:
> SET CHANNEL MIDI_INPUT <sampler-channel> <midi-device-id>
> <midi-input-port> <midi-input-chan>
>

You probably know and already expect that my opinion would go otherwise.
That is, I'm all for a new consolidated command, but I think that keeping
the separated commands is a good thing. Again, compability is my main
reason why, if not flexibility.

>
> I think this makes more sense especially if we ever want to have
> multiple midi inputs connected to the same sampler channel.
> For now i'll assume that only a single input can be connected to a given
> channel, but i'd like to consolidate these 3 commands into 1 because i
> think it will make the protocol more consistent.
> MIDI_PORT object ID is not unique in the system, the same ID can exist
> on different MIDI_INPUT_DEVICEs. That's why in other commands that use
> <midi-port> we MUST specify <device-id> as well. For example: GET
> MIDI_INPUT_PORT INFO <device-id> <midi-port>.
> I think consolidating those 3 into 1 will also eliminate some issues
> such as order of those 3 commands, exception handing associated with
> that, etc, etc. It will make spec smaller too, something we haven't been
> able to do in a while :)
>

I don't mind having a fat spec. OTOH I do realize that by using the
non-consolidated commands, one has to follow some order, that's trivial.
You cannot set a device attribute without knowing which one to set. That's
why SET CHANNEL MIDI_INPUT_DEVICE should be issued before the SET CHANNEL
MIDI_INPUT_PORT and SET CHANNEL MIDI_INPUT_CHANNEL, in this order
respectively.

IIUC a MIDI input device exposes one or more ports. Each port presents the
usual 16 MIDI logical channels. Furthermore, it's pretty usual to have
only ONE MIDI channel mapped to ONE sampler channel, although this must
not be a fundamental design limitation. OTOH, having ONE sampler channel
listening on only ONE MIDI channel it's just usual but mustn't be the
rule.

For that reason, if one wishes to change just the MIDI channel on which a
sampler channel is being triggered, he/she must not have to reissue the
respective MIDI port, or even the MIDI input device identifier. The
currently assigned ones to the intended sampler channel shall be assumed.


> Please comment! I'll implement a single command unless i get bad
> feedback.
>

As I said, you can go and implement it, but I really don't see the point
why you have to. I'll rather help you implementing the individual
(non-consolidated) commands, if that makes you happy, although not happier
;)

Hey, and what about that good old SET CHANNEL MIDI_INPUT_TYPE ? Yeah,
don't wanna be a PITA :) but we can keep it too in the very same fashion
I've made with it's audio counterpart. Of course, you can leave it to me,
once again.

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

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Vladimir Senkov wrote:
> Hi All,
> 
> I'm almost there with the MIDI. 

<SNIP>

> I think this makes more sense especially if we ever want to have
> multiple midi inputs connected to the same sampler channel.
> For now i'll assume that only a single input can be connected to a given
> channel, 

<SNIP>

I agree. If I wanted two devices to both drive a piano Gig file, then 
I'd load the same gig file on two ports and drive them separately. I've 
mentioned this a couple of time, but I don't remember ever getting a 
response - If a single gig is loaded on two or more ports it should NOT 
require any extra samples be loaded into memory. Hopefully it will just 
point both channels to the same samples and the same files on disk. 
There should be little overhead for doing this.

> 
> Please comment! I'll implement a single command unless i get bad
> feedback.
> 

Cannot add much on the command front, but it soulds reasonable to me.

- Mark

[Linuxsampler-devel] SET CHANNEL MIDI_INPUT

[Vladimir S. <han...@im...>]

Hi All,

I'm almost there with the MIDI. Unfortunately i will only be able to do
ALSA driver. Stephane, i'm sorry to break MAC drivers but i don't know
much about it to be able to convert CoreMidi and MidiShare . . . I can
use some help there :)

Now that the internals of midi input device and midi input ports are
almost done, i'm beginning to think that it might make sense to
consolidate the following LSCP commands:
SET CHANNEL MIDI_INPUT_DEVICE <sampler-channel> <midi-device-id>
SET CHANNEL MIDI_INPUT_PORT <sampler-channel> <midi-input-port>
SET CHANNEL MIDI_INPUT_CHANNEL <sampler-channel> <midi-input-chan>
into a single command:
SET CHANNEL MIDI_INPUT <sampler-channel> <midi-device-id>
<midi-input-port> <midi-input-chan>

I think this makes more sense especially if we ever want to have
multiple midi inputs connected to the same sampler channel.
For now i'll assume that only a single input can be connected to a given
channel, but i'd like to consolidate these 3 commands into 1 because i
think it will make the protocol more consistent.
MIDI_PORT object ID is not unique in the system, the same ID can exist
on different MIDI_INPUT_DEVICEs. That's why in other commands that use
<midi-port> we MUST specify <device-id> as well. For example: GET
MIDI_INPUT_PORT INFO <device-id> <midi-port>.
I think consolidating those 3 into 1 will also eliminate some issues
such as order of those 3 commands, exception handing associated with
that, etc, etc. It will make spec smaller too, something we haven't been
able to do in a while :)

Please comment! I'll implement a single command unless i get bad
feedback.

Regards,
Vladimir.

[Linuxsampler-devel] [qsampler] Latest CVS commit

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

qsampler 0.0.2.95:

* Avoid channel voice/stream usage auto-update while
  intrument loading is erroneous or incomplete.

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

[Linuxsampler-devel] LSCP document now under CVS

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

Hi!

I converted the latest network protocol document 
(http://www.linuxsampler.org/api/draft-linuxsampler-protocol-11.sxw) today
into XML. The xml file is located at Documentation/lscp.xml in the 
linuxsampler CVS repository and is compliant to RFC 2629, thus can be 
converted into HTML or RFC common ASCII format by using the 'xml2rfc' tool 
(http://xml.resource.org/).

Please DO NOT continue to maintain the open office format document for LSCP, 
instead use this XML file for changes to the protocol!

At the moment the HTML and TXT files have to be generated manually by using 
'xml2rfc' and uploaded to the www server 
(http://www.linuxsampler.org/downloads.html). Soon we will place a script to 
the CVS server, so that txt and html file will automatically be generated 
whenever a new version of lscp.xml was commited and the website will also 
automatically refreshed of course.

Hope I did not introduce too much Copy&Waste mistakes. ;)

CU
Christian

[Linuxsampler-devel] [qsampler] Latest CVS commit

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

Oops,

qsampler 0.0.2.94:

* Save session filename quotes missing on LOAD INSTRUMENT NON_MODAL.

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

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

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

Hi,

Just a lil'bumpin' :)

qsampler-0.0.2.93:

* Prepared for client event protocol interface,
  via thread-safe QCustomEvent callback posting,
  on attempt to comply with draft-protocol v.11.

liblscp-0.1.9.102:

* Major changes to server event protocol interface
  on attempt to comply with draft-protocol v.11.


This is to say that liblscp already implements the new event notification
protocol, via an alternate but ordinary TCP socket connection, on both
client and server side. Thus officially dropping the now obsoleted UDP
event stream, as of original LSCP specification.

However, current linuxsampler server is not ready for this yet.
Multi-connection/client support is a milestone requirement not yet met by
current linuxsampler server implementation.

As ever, it's work in progress...

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

Re: [Linuxsampler-devel] [qsampler, liblscp] Latest CVS commit

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

Rui Nuno Capela wrote:
> Hi everyone,
> 
> It's getting hot,
> 
> 
> qsampler 0.0.2.92:
> 
> * Mon-modal intrument file loading and status experimental support.
> 
> 
> liblscp 0.1.9.101:
> 
> * Major change to client event protocol interface on attempt
>   to comply with latest draft-protocol v.11.
> 
> * New function entries added: lscp_load_instrument_non_modal(),
>   lscp_set_channel_audio_device() and lscp_set_channel_midi_device().
> 
> 
> Please note that you *must* checkout and install this latest liblscp
> before you can build and run the corresponding qsampler installment.
> 
> Previous qsampler releases are still OK. Hopefully ;)
> 
> Bye.

Cool. Thanks.

A small bug report from the previous version from your page. On my 
system if I don't have the Jack server running but within QSampler I ask 
for Jack support, when I say apply QS completely goes away.

I'm sure I shouldn't ask for Jack when Jack isn't running, but it would 
be nice if the whole app didn't disappear.

I'm running QJC and Rosegarden when this happens in case it's not 
immediately duplicatable.

cheers,
Mark

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

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

Hi everyone,

It's getting hot,


qsampler 0.0.2.92:

* Mon-modal intrument file loading and status experimental support.


liblscp 0.1.9.101:

* Major change to client event protocol interface on attempt
  to comply with latest draft-protocol v.11.

* New function entries added: lscp_load_instrument_non_modal(),
  lscp_set_channel_audio_device() and lscp_set_channel_midi_device().


Please note that you *must* checkout and install this latest liblscp
before you can build and run the corresponding qsampler installment.

Previous qsampler releases are still OK. Hopefully ;)

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

[Linuxsampler-devel] [linuxsampler] Latest CVS commit

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

Hi all,

I've just committed my latest patch:

linuxsampler 0.2.x:

* SET CHANNEL AUDIO_OUTPUT_TYPE <chan> <driver> command is back!
  creates an audio output device instance of the given driver type
  ('Jack' or 'Alsa') with default parameters if none exists,
  otherwise it just picks the first available device and assign
  it to the intended sampler channel.

* The AudioOutputDevice class get's a new pure virtual method,
  Driver(), which is implemented on both of the existing inherited
  classes, AudioOutputDeviceAlsa and AudioOutputDeviceJack, with
  the sole purpose to return the driver type name as a String
  ('Alsa' and 'Jack', respectively).

* The quoting on the filename argument for the LOAD INSTRUMENT
  command has been made optional; you can have both ways, with
  single quotes or none, keeping compability with older LSCP
  specification.

* An additional sanity check is made on LOAD INSTRUMENT, whether
  the sampler channel has an audio output device assigned, thus
  preventing the server from crashing on instrument file load.

* The GET AUDIO_OUTPUT_DEVICE INFO now includes the missing
  'driver' item, as predicted by the draft protocol document.


The draft-protocol document bumped to v.11, and is already uploaded and
available on the linuxsampler.org website.

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

Re: [Linuxsampler-devel] parser generator

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

Christian Schoenebeck wrote:

>>>I don't think I like all these tradeoffs in the protocol definition you're
>>>discussing the last days. :)
>>>      
>>>
>>All of them? There was one tradeoff (disallowing key names that match
>>keywords
>>    
>>
>
>Thats one of the tradeoffs I definitely don't like. Because the driver 
>developer should be able to add any parameter name he wants for his device 
>driver.
>  
>
There is an easy way to solve that is with the coding convention. For 
example, all tokens MUST be uppercase and all parameters MUST be 
lowercase. Does the driver developer care if his driver's parameters 
have to be lowercase? It can even be done for him automatically . . .
I think this solves the issue and we can move on to solve other issues 
that have to do with the application. After all, we are not writing a 
parser, so we don't need to be 'perfect' there. Life and software are 
never perfect but as long as a particular solution solves the problem i 
don't see an issue.
When you say 'one of the tradeoffs' what other tradeoffs do you see. 
Maybe i'm forgetting something but i thought that was the only one.

>>so the parser can be smaller and faster) and one fix (putting quotes
>>around string literals
>>    
>>
>
>Right, that was a relict, nothing against that of course.
>
>  
>
>>OK, maybe there's something out there that does something really clever,
>>like flipping between different lexers according to context. But they've
>>    
>>
>
>That's what I meant. The parser should at least work in such way together with 
>the scanner, so the scanner only feeds the parser with terminal symbols which 
>are defined in current (that is most congruent) grammar rule. The interface 
>between lex and yacc is of course too primitive to allow such things. But 
>there are a lot of parser generators out there, so I still hope we can find 
>one that can do that and maybe even supports BNF, means an abstract 
>definition of the protocol.
>  
>
We could. I'm not sure this is really necessary. The protocol is not 
that incredibly complex that we can't solve our issues using flex/bison 
combo. Again, i'm not a flex/bison person myself so i'd love to learn 
any other software as well so bring it on :) I just don't see any 
urgency in that. To me it's like priority number 65535 :)

Regards,
Vladimir.

Re: [Linuxsampler-devel] parser generator (was: Latest CVS Commit)

[Christian S. <sch...@so...>]

Es geschah am Mittwoch, 23. Juni 2004 00:39 als Simon Jenkins schrieb:
> Christian Schoenebeck wrote:
> >I don't think I like all these tradeoffs in the protocol definition you're
> >discussing the last days. :)
>
> All of them? There was one tradeoff (disallowing key names that match
> keywords

Thats one of the tradeoffs I definitely don't like. Because the driver 
developer should be able to add any parameter name he wants for his device 
driver.

> so the parser can be smaller and faster) and one fix (putting quotes
> around string literals

Right, that was a relict, nothing against that of course.

> OK, maybe there's something out there that does something really clever,
> like flipping between different lexers according to context. But they've

That's what I meant. The parser should at least work in such way together with 
the scanner, so the scanner only feeds the parser with terminal symbols which 
are defined in current (that is most congruent) grammar rule. The interface 
between lex and yacc is of course too primitive to allow such things. But 
there are a lot of parser generators out there, so I still hope we can find 
one that can do that and maybe even supports BNF, means an abstract 
definition of the protocol.

> all got SOME notion of a lexical analysis phase, if only because...

Lexical analysis itself is not the problem.

> The String Problem ~
> can ONLY be resolved lexically!
>
> Think about it... the protocol carries arbitrary, user entered strings.
> How can
> any parser POSSIBLY know where one of these strings ends without a lexical
> clue of some sort? Whatever the parser saw that might signal the end of
> a string
> could just as easily be more characters that were part of the string...
> it would
> have to wait /forever/ before it was sure.

In our case the end of the wait would at least be the line feed character. But 
I agree that's not a good solution, so putting strings in apostrophes or 
quotes is far better from the parser's point of view.

CU
Christian

Re: [Linuxsampler-devel] parser generator (was: Latest CVS Commit)

[Simon J. <sje...@bl...>]

Christian Schoenebeck wrote:

>Hi everybody!
>
>I don't think I like all these tradeoffs in the protocol definition you're 
>discussing the last days. :) 
>
All of them? There was one tradeoff (disallowing key names that match 
keywords
so the parser can be smaller and faster) and one fix (putting quotes 
around string literals
to repair a very large hole in an otherwise fairly tight spec).

>The reason why I left this naive approach of the 
>scanner/parser definition with all its ambiguities was the hope that we could 
>find and move to a good parser generator that doesn't have this annoying or 
>better say radical split between scanner and parser. That's the main problem 
>of these ambiguities, not the protocol definition itself.
>
Its not about the tools. Yes, there are parser generators that accept 
more general
grammars than yacc, eg Accent ( http://accent.compilertools.net ), but 
changing
to one of them wouldn't resolve either of these issues:

The Lex Tradeoff ~
If you don't think its a fair trade, you don't have to make it. Abandon 
lexical
analysis for keywords and Yacc can generate a purely syntactic parser that's
bigger and slower but can distinguish keywords from names by their position
in  the sentence. Switch to Accent? NO DIFFERENCE: You've still got exactly
the same choice of whether or not to speed things up by lexing first.

OK, maybe there's something out there that does something really clever,
like flipping between different lexers according to context. But they've
all got SOME notion of a lexical analysis phase, if only because...

The String Problem ~
can ONLY be resolved lexically!

Think about it... the protocol carries arbitrary, user entered strings. 
How can
any parser POSSIBLY know where one of these strings ends without a lexical
clue of some sort? Whatever the parser saw that might signal the end of 
a string
could just as easily be more characters that were part of the string... 
it would
have to wait /forever/ before it was sure.

Simon Jenkins
(Bristol, UK)

[Linuxsampler-devel] AudioOutputDevice driver patch

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

Hi,

For your patching pleasure :) you may try and test the attached diff-patch
onto current CVS HEAD, which is my latest attempt on keeping backward
compability with older (pre-June13th) linuxsampler LSCP client interfaces.

The fine print goes like this:

* SET CHANNEL AUDIO_OUTPUT_TYPE <chan> <driver> command is back! :)
  I know it's been deprecated, but I think it's too early to break
  existing LSCP scripts or clients (e.g. qsampler), preventing them
  to work properly with the new and future linuxsampler code. It
  creates an audio output device instance of the given driver type
  ("Jack" or "Alsa") with default parameters if none exists,
  otherwise it just picks the first available device and assign it
  to the intended sampler channel.

  It's basicaly equivalent to the follwing commands in succession:

    CREATE AUDIO_OUTPUT_DEVICE <driver>
    SET CHANNEL AUDIO_OUTPUT_DEVICE <chan> <devno>

* The AudioOutputDevice class get's a new pure virtual method,
  Driver(), which is implemented on both of the existing inherited
  classes, AudioOutputDeviceAlsa and AudioOutputDeviceJack, with
  the sole purpose to return the driver type name as a String
 ("Alsa" and "Jack", respectively).

* The quoting on the filename argument for the LOAD INSTRUMENT
  command has been made optional; you can have both ways, with
  single quotes or none, keeping compability with older LSCP
  specification.

* An additional sanity check is made on LOAD INSTRUMENT, whether
  the sampler channel has an audio output device assigned, thus
  preventing the server from crashing on instrument file load.

* The GET AUDIO_OUTPUT_DEVICE INFO now includes the missing
  "driver" item, as predicted by the draft protocol document.


IMPORTANT: As the patch includes small changes on the lex/yacc sources,
you must issue 'make parser' under src/network, before the top level
'make'.

Please notice that these changes will make current linuxsampler CVS
virtally compatible and functional with "older" LSCP scripts and client
interfaces (e.g. qsampler/liblscp). I think it's worth the effort, now
that it's already done ;)

As before, I'm ready to commit this stuff, as soon as there's some
positive feedback. Dictators may speak now...

Take care.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

P.S. Vladimir, as you can see now, I was serious about this backward
compability issue, although it may seem that I'm always happy :) In fact,
I'm really happy to suggest these changes, and most certainly, will be
happier if you and everyone else agrees, just because I think, everybody
would be happier too.

Happy patching! :)

[Linuxsampler-devel] bug tracking system (was: Qsampler 0.0.2 released!)

[Christian S. <sch...@so...>]

Es geschah am Montag, 21. Juni 2004 16:08 als Rui Nuno Capela schrieb:
> How about setting up a bugtracker on ls.org ? Something like Mantis
> Bugtracker (http://www.mantisbt.org), exactly the same tool the ardour and
> alsa teams are using. PHP/MySQL required.

We planned to use a bug tracking system when we go for the first release, 
means when all major features for the first release are *done* and we reached 
the stage to just fix things for the release. At the moment there's still too 
much to do anyway.

I can install a bug tracking system when my exams are over.

CU
Christian

[Linuxsampler-devel] parser generator (was: Latest CVS Commit)

[Christian S. <sch...@so...>]

Hi everybody!

I don't think I like all these tradeoffs in the protocol definition you're 
discussing the last days. :) The reason why I left this naive approach of the 
scanner/parser definition with all its ambiguities was the hope that we could 
find and move to a good parser generator that doesn't have this annoying or 
better say radical split between scanner and parser. That's the main problem 
of these ambiguities, not the protocol definition itself.

So I would suggest to research for a better parser generator instead of doing 
all these unpretty and inconvinient tradeoffs and hacks.

CU
Christian

P.S. case insensitivity does make sense; there's also a LSCP *shell* planned, 
which can handle autocompletion, etc., but not in the near future of course

Es geschah am Montag, 21. Juni 2004 14:17 als Simon Jenkins schrieb:
> Rui Nuno Capela wrote:
> >[...] What about that all-upper-case restriction for command keywords? And
> > the parameter key names _must_ be capitalized or sort of.
>
> My suggestion was that "key names _must_ not match keywords" be the only
> rule -
> its sufficient - and that key names be mixed case by convention, rather
> than by law.
> That would allow for the occasional upper-case name where it made sense,
> eg for
> acronyms (still use ALSA rather than Alsa).
>
> The keywords are all upper case because... thats just the way they are.
> Its not a rule
> exactly (or IMHO shouldn't be) its simply the convention that was
> chosen/adopted.
>
> (FWIW I don't particularly like the upper case keywords because
> 1) its less readable,
> 2) its less typeable,
> 3) there's no need to shout, and
> 4) it isn't 1976 any more.
> But its not my place to rework the protocol according to my personal
> tastes/prejudices,
> especially when I lurked my way through the first eight drafts and am
> not involved in
> the software at either end of the link. So I'm just offering what help I
> can to make the
> parser work at all).
>
> >Isn't it too restrictive? I'd rather have LSCP case insensitive al
> > together.
>
> There's not much advantage in making the protocol case insensitive. Its
> not like
> the software at either end is going to forget to press the shift key.
> More likely it
> would fail to match an oddly cased key name because someone forgot
> ToUpper().
> OK, some people might need to type LSCP by hand, but with a consistent
> set of
> conventions it shouldn't be too hard for them to get it right.
>
> The disadvantages of case insensitivity are
> 1) extra work in the lexical analyser and
> 2) extra opportunity for name/keyword clashes: It would no longer be
> possible to
> use the key name "Channel" because it would now clash with the keyword
> "CHANNEL".
>
> >Again, putting my logs into the fire ;)
>
> Me too. And its not even my fire.
>
> Simon Jenkins
> (Bristol, UK).
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] AudioOutputDevice driver question

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

Rui,

Forgot to mention that LOAD_INSTRUMENT can now be tested (and appears to 
work OK with both background and foreground) on channels that have 
ENGINE loaded and AUDIO_OUTPUT mapped . . .
Maybe i should just throw an exception in lscp server when instrument 
loading is attempted before audio output is mapped, since it is required 
at the instrument loading time. On the other hand, i never bothered to 
look why was it required . . . maybe i should do that first.
For now just please do things in the following order:

CREATE AUDIO_OUTPUT_DEVICE Alsa card='0,0'
ADD CHANNEL
---- the above two can really be done in any order, assuming they both 
have returned OK[0]-----
LOAD ENGINE gig 0
SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0
LOAD INSTRUMENT 'file.gig' 0 0
or
LOAD INSTRUMENT NON_MODAL 'file.gig' 0 0

Regards,
Vladimir.

Re: [Linuxsampler-devel] AudioOutputDevice driver question

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

Hi Rui,

Looks like you are trying to create an audio device at runtime but why 
do you care if one of that type already exists or not? What about the 
parameters? Two alsa devices for example can have completely different 
parameters such as output cards, etc, etc. I'm not sure what the desired 
effect would be . . . if we are trying to simulate single channel 
shouldn't we just delete all audio ouputs before creating a new one? :) 
Just kidding.

You could try playing with <typeinfo> but it will probably be easier to 
just add a pure virtual into AudioOutputDevice base and implementations 
for that into Alsa and Jack classes respectively and that will probably 
be the easiest way to get that kind of info. Basically like we do with 
versions and descriptions.

If this is purely for backward compatibilty you might as well just 
always create a new audio device . . . since parameters are not going to 
be correct anyways it will work just as good :)

I think backward compatibility is important once we actually 
ship/release something. Once we have an installbase/userbase, etc. For 
right now, we are developing, not using :) We already are at 11th 
version of the spec . . . chances are we'll have to first implement 
protocol FULLY, then we'll reallize some things are still missing or 
suboptimal, etc, etc. THEN we'll fix and polish those things in both 
spec and software and then some alpha/beta folks will hopefully give 
this combination some testing and based on their feedback we'll correct 
things again. Hopefully releasing the whole thing soon after that step.
In other words, we are not "code complete" yet, we are still in development.
So we are not there yet and i'm not too worried about the backwards 
compatibility just yet :)

BTW, i've just checked in a SET command to map channels to audio output.
Still plenty of stuff to fix though. I'm hoping to get to input next and 
then it might sort of start working again (a little bit :)

Regards,
Vladimir.

PS: Are you serious about backwards compatibility or are just just 
kidding? I can't tell when you are kidding or not because you seem to 
always be happy :)

Rui Nuno Capela wrote:

>Hi,
>
>In my own trials to re-implement SET CHANNEL AUDIO_OUTPUT_TYPE command,
>I've stumbled in a precise question which I hope the LS engine designer(s)
>would answer:
>
>How can I determine the driver type of an AudioOutputDevice class
>instance? That is, whether it inherits from AudioOutputDeviceAlsa ("Alsa")
>or AudioOutputDeviceJack ("Jack").
>
>OTOH, that driver name is supposed to be included in the resultset of GET
>AUDIO_OUTPUT_DEVICE INFO command, but isn't so, at least in the current
>implementation.
>
>I'd rather have someone giving some hints on how to get this, before I do
>something really hackish ;)
>
>My idea to recreate the LSCPSErver::SetAudioOutputType(String sDriver)
>method goes almost like this:
>{
>    // Check if there's one audio device already created
>    // of the intended type (sDriver)...
>    AudioOutputDevice *pDevice = NULL;
>    std::map<uint, AudioOutputDevice*> devices =
>pSampler->GetAudioOutputDevices();
>    std::map<uint, AudioOutputDevice*>::iterator iter = devices.begin();
>    for (; iter != devices.end(); iter++) {
>        if (iter->second is of sDriver type) { // HOW?
>            pDevice = iter->second;
>        }
>    }
>
>    // If it doesn't exist, create a new one with default parameters...
>    if (pDevice == NULL)
>	pDevice = pSampler->CreateAudioOutputDevice(sDriver);
>
>    // Set it as the current channel device...
>    pSampler->SetAudioOutputDevice(pDevice);
>}
>
>Obviously, my question is summarized on how to write the pseudo-code on
>the line with the HOW? comment.
>
>Christian?
>Vladimir?
>Benno?
>Anyone? :)
>  
>

[Linuxsampler-devel] Mantis, Was: Qsampler 0.0.2 released!

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

Scrive Rui Nuno Capela <rn...@rn...>:


> >
> 
> How about setting up a bugtracker on ls.org ? Something like Mantis
> Bugtracker (http://www.mantisbt.org), exactly the same tool the ardour and
> alsa teams are using. PHP/MySQL required.
> 

Hi,
yes Mantis seems very nice. (the idea of bug tracking categories mentioned
by mark makes sense, even for "bugs" related to GIG files that experience
glitches (which means that the LS gig engine has a bug)
PHP is active on ls.org , for mysql just mail me and I'll create a mysql db
 that we can use for mantis.

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



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

[Linuxsampler-devel] AudioOutputDevice driver question

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

Hi,

In my own trials to re-implement SET CHANNEL AUDIO_OUTPUT_TYPE command,
I've stumbled in a precise question which I hope the LS engine designer(s)
would answer:

How can I determine the driver type of an AudioOutputDevice class
instance? That is, whether it inherits from AudioOutputDeviceAlsa ("Alsa")
or AudioOutputDeviceJack ("Jack").

OTOH, that driver name is supposed to be included in the resultset of GET
AUDIO_OUTPUT_DEVICE INFO command, but isn't so, at least in the current
implementation.

I'd rather have someone giving some hints on how to get this, before I do
something really hackish ;)

My idea to recreate the LSCPSErver::SetAudioOutputType(String sDriver)
method goes almost like this:
{
    // Check if there's one audio device already created
    // of the intended type (sDriver)...
    AudioOutputDevice *pDevice = NULL;
    std::map<uint, AudioOutputDevice*> devices =
pSampler->GetAudioOutputDevices();
    std::map<uint, AudioOutputDevice*>::iterator iter = devices.begin();
    for (; iter != devices.end(); iter++) {
        if (iter->second is of sDriver type) { // HOW?
            pDevice = iter->second;
        }
    }

    // If it doesn't exist, create a new one with default parameters...
    if (pDevice == NULL)
	pDevice = pSampler->CreateAudioOutputDevice(sDriver);

    // Set it as the current channel device...
    pSampler->SetAudioOutputDevice(pDevice);
}

Obviously, my question is summarized on how to write the pseudo-code on
the line with the HOW? comment.

Christian?
Vladimir?
Benno?
Anyone? :)
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

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

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

Rui Nuno Capela wrote:
> Hi Mark,

> Current linuxsampler CVS HEAD is pretty unstable, and somewhat broke
> regarding compability with client/server interface as it was before June
> 13th's revolution :)
> 
> The packages on my site and qsampler.sf.net are related to the
> pre-revolutionary period, only.

OK, I won't bother until you folks get to a point where you think it's 
worth my time. Let me know when.

> How about setting up a bugtracker on ls.org ? Something like Mantis
> Bugtracker (http://www.mantisbt.org), exactly the same tool the ardour and
> alsa teams are using. PHP/MySQL required.
> 
> Cheers.

I like this idea a lot. I think there could be different basic areas 
that we log both bugs and feature requests:

1) LS
2) QS
3) Sound card/Alsa
4) MIDI
5) Gig file compatibility

I'm sure there are others.

I think having a bug tracker is great since the data doesn't get lost or 
forgotten.

Rosegarden also uses a bug tracker, but it looks different than the Alsa 
bug tracker, so maybe that's another option. Personally I like the Alsa 
one a bit more as it's more searchable, but maybe that's just the way 
they've set it up. I think it's part of Sourceforge, or seems to be.

Also, Gentoo uses a bug tracker that's quite involved. Don't know if 
that's an option to look at.

Cheers,
Mark

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

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

Hi Mark,

>
> Hi all,
>     Been away for a week. Is there anything specific for me to look at?
> Looks like there is headway on the programming side. Lots of lex/bison
> stuff?
>
>     Anyway, I'm back so let me know if there are specific things you
> want me to look at.
>
>     Should I download from CVS or Rui's web site? (Rui's seems to be a
> bit easier if it's up to date.)
>

Current linuxsampler CVS HEAD is pretty unstable, and somewhat broke
regarding compability with client/server interface as it was before June
13th's revolution :)

The packages on my site and qsampler.sf.net are related to the
pre-revolutionary period, only.


>
>     BTW - what were the issues just before I left about 'tuning'? I
> wonder if we should set up a real bug reporting system where we could
> log issues about specific gig files instead of trying to track them in
> email?
>

How about setting up a bugtracker on ls.org ? Something like Mantis
Bugtracker (http://www.mantisbt.org), exactly the same tool the ardour and
alsa teams are using. PHP/MySQL required.

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

Re: [Linuxsampler-devel] [linuxsampler] Latest CVS Commit

[Simon J. <sje...@bl...>]

Rui Nuno Capela wrote:

>How can it be that a parser/syntax design is such that it can't resolve
>around distinguishing a keyword from a parameter key name? In my humble
>POV the position within the phrase would suffice to that.
>
>Is it a lex/yacc limitation or what, that a keyword is always taken
>literally, prioritary and unconditianally independant from where it occurs
>whithin a parsed sentence?
>
Its possible to make it work like you say, but its not efficient.

What happens at the moment is:

1. The lexical analyser sees the input first, tokenises it, and gives the
tokens to the parser. The analyser  /doesn't know/  where in the sentence
it is... it simply knows that

CHANNEL             <----- is a keyword it has been told to recognise
Channel                   <----- is not a keyword so it must be a name
2.67                          <----- is a number
"CHANNEL"          <----- is a quoted string
"Channel"                <----- is a quoted string
"2.67"                       <----- is a quoted string
etc etc

2. The parser receives the tokens from the analyser. It knows exactly
where in the sentence it is, but a "sentence", from the parser's POV, is
a sequence of tokens not a sequence of characters.

The purpose of this is to make everything a lot smaller and faster: The
analyser handles the small-scale structure of the language with simple
pattern matching rules, whilst the parser only handles the large-scale
structure of the language with more complex grammatical rules.

But to make it work like this you need a language whose parts can be
identified in the analyser by simple pattern matching, not in the parser
by where they are in a sentence

If you want to distinguish keywords by where they are in a sentence
then you have to abandon the lexical analyser and do /everything/
in the parser.  The parser would have to look at the incoming characters,
one at a time, and decide according to context whether it was seeing
a keyword or a name or a string or a number. This is possible, but its
much more expensive than doing it in a lexical analyser using simple
pattern-matching.

To summarise:
~ Tokenising makes the parser smaller and faster.
~ Therefore the protocol should be tokeniseable.

Unless there's a _strong_ reason not to.

Simon Jenkins
(Bristol, UK)

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

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

Rui Nuno Capela wrote:
> 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.

Hi all,
    Been away for a week. Is there anything specific for me to look at? 
Looks like there is headway on the programming side. Lots of lex/bison 
stuff?

    Anyway, I'm back so let me know if there are specific things you 
want me to look at.

    Should I download from CVS or Rui's web site? (Rui's seems to be a 
bit easier if it's up to date.)

    BTW - what were the issues just before I left about 'tuning'? I 
wonder if we should set up a real bug reporting system where we could 
log issues about specific gig files instead of trying to track them in 
email?

    I'm open to any method that works.

Cheers,
Mark

Re: [Linuxsampler-devel] Default Audio/MIDI devices

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

Hi Vladimir

Our flex/bison guru-on-duty, Simon, has already pointed the right
direction: upgrade to flex-2.5.31. Then reached http://lex.sf.net and
built and installed from source. Finally made the symlink lex -> flex, and
I'm now in biz :)

>
> I'm not sure why you want to bring SET CHANNEL AUDIO_OUTPUT_TYPE back. I
> think we shuold just implement  SET CHANNEL AUDIO_OUTPUT_DEVICE command.
>

Haven't you noticed? That's all about maintaining backward compability
(and functionality) with older (but still current) qsampler ;) Other
existing

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