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

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Es geschah am Freitag, 2. Juli 2004 23:36 als Rui Nuno Capela schrieb:
> >> Is it also OK to remove from CVS all those auto-generated files? I mean
> >> the ones generated after a 'make -f Makefile.cvs' ? I don't see the
> >> point having it on the repository, do you?
> >
> > Yes I do. The advantage is you can compile the library even without
> > having to install the auto tools. That's why they are there.
> >
> > It's like the same with the parser in LS. You can regenerate it if you
> > have lex & yacc installed by doing 'make parser', or just stick with our
> > pregenerated parser source files.
>
> Oops, about too late. Already committed. Damn, it was just minutes ago.
>
> To save the day, I can always do the autocrap-bootstrap myself and check
> in the regenerated files, if it pleases you. Must I?

Np, forget it. I forgot the libtool aspect. You need to have libtool installed 
to create the lib and libtool has a dependency to parts of autotools. so ...

> OTOH, I've already packaged all my stuff, which is available on the usual
> place (http://www.rncbc.org/ls). You might build your (official) tarball
> now :)

Yeah, maybe tomorrow.

Btw, you could also commit the Borland/Win stuff. Maybe you create a win32 
directory or something for the fake headers. Once gigextract's dependency to 
libaudiofile is replaced by libsndfile, then even gigextract will be 
conveniently compilable on Windows.

CU
Christian

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Christian,
>
>> Is it also OK to remove from CVS all those auto-generated files? I mean
>> the ones generated after a 'make -f Makefile.cvs' ? I don't see the
>> point having it on the repository, do you?
>
> Yes I do. The advantage is you can compile the library even without
> having to install the auto tools. That's why they are there.
>
> It's like the same with the parser in LS. You can regenerate it if you
> have lex & yacc installed by doing 'make parser', or just stick with our
> pregenerated parser source files.
>

Oops, about too late. Already committed. Damn, it was just minutes ago.

To save the day, I can always do the autocrap-bootstrap myself and check
in the regenerated files, if it pleases you. Must I?

Sorry for the inconvenience. I didn't mean no harm.

OTOH, I've already packaged all my stuff, which is available on the usual
place (http://www.rncbc.org/ls). You might build your (official) tarball
now :)

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

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Es geschah am Freitag, 2. Juli 2004 20:58 als Rui Nuno Capela schrieb:
> > So, it's ok, go ahead and commit it.
>
> I'll do it after changing the License and URL on the specfile as you asked.

Good.

> Is it also OK to remove from CVS all those auto-generated files? I mean
> the ones generated after a 'make -f Makefile.cvs' ? I don't see the point
> having it on the repository, do you?

Yes I do. The advantage is you can compile the library even without having to 
install the auto tools. That's why they are there.

It's like the same with the parser in LS. You can regenerate it if you have 
lex & yacc installed by doing 'make parser', or just stick with our 
pregenerated parser source files.

CU
Christian

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Christian,
>>
>> BTW, do you know the difference between pkglib_ and lib_ prefixes? The
>> later seems to be more standard :)
>
> I wasn't sure either, but AFAIK the only difference is the target
> directory.
>>From the libtool doc ("9.3.2 Building Libtool Libraries"):
>
>>  Automake predefines the variable `pkglibdir', so you can use
>>  pkglib_LTLIBRARIES to install libraries in $(libdir)/@PACKAGE@/.
>
> That was the only difference I found.
>

That's it. I remember now that I disliked to install the libraries under
"${prefix}/lib/libgig" (as the pkglib_ prefix seems to imply) and
preferred the "${prefix}/lib" instead. One less line under
"/etd/ld.so.conf" is one less line under my worries.

Feeling even better now.

> So, it's ok, go ahead and commit it.
>

I'll do it after changing the License and URL on the specfile as you asked.

Is it also OK to remove from CVS all those auto-generated files? I mean
the ones generated after a 'make -f Makefile.cvs' ? I don't see the point
having it on the repository, do you?
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Es geschah am Freitag, 2. Juli 2004 18:04 als Rui Nuno Capela schrieb:
> > Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES?
>
> No special reason. IIRC I was having some trouble with the libtoolization
> which seemed to be solved by that change. Something regarding the target
> shared libraries not having the .so suffix or else. I've never and
> probably never will grok the misteries of the autotools karma :)
>
> BTW, do you know the difference between pkglib_ and lib_ prefixes? The
> later seems to be more standard :)

I wasn't sure either, but AFAIK the only difference is the target directory=
=2E=20
=46rom the libtool doc ("9.3.2 Building Libtool Libraries"):

>  Automake predefines the variable `pkglibdir', so you can use=20
>  pkglib_LTLIBRARIES to install libraries in $(libdir)/@PACKAGE@/. =20

That was the only difference I found.

So, it's ok, go ahead and commit it.

CU
Christian

Re: [Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Christian,

>> Please note that the C++ source code wasn't touched in any way. On
>> attachment you may find a complete diff-patch of the proposed changes.
>
> Looks fine, except:
>
>>>diff -duPr libgig-0.7.0/libgig.spec.in libgig-0.7.1/libgig.spec.in
>
>>+Copyright:	LGPL
>
> That's GPL, not LGPL at the moment.
>

Of course. Sorry :)

>
>>+URL:		http://www.linuxsampler.org/
>
> That should be http://stud.fh-heilbronn.de/~cschoene/projects/libgig/ for
> the moment, I will move the site to http://www.linuxsampler.org/ though
> when I have time (in a couple of weeks).
>

Right.


>> diff -duPr libgig-0.7.0/src/Makefile.am libgig-0.7.1/src/Makefile.am
>> --- libgig-0.7.0/src/Makefile.am	2004-05-03 15:16:58.000000000 +0100
>> +++ libgig-0.7.1/src/Makefile.am	2004-07-01 10:19:08.000000000 +0100
>> @@ -1,11 +1,11 @@
>> -# set the include path found by configure
>> -INCLUDES= $(all_includes)
>> -
>>  # to prevent compile errors on some systems
>>  AM_CXXFLAGS = -pedantic
>>
>> -pkglib_LTLIBRARIES = libgig.la
>> -libgig_la_SOURCES = RIFF.cpp RIFF.h DLS.cpp DLS.h gig.cpp gig.h
>> +libgigincludedir = $(includedir)
>> +libgiginclude_HEADERS = RIFF.h DLS.h gig.h
>> +
>> +lib_LTLIBRARIES = libgig.la
>
> Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES?
>

No special reason. IIRC I was having some trouble with the libtoolization
which seemed to be solved by that change. Something regarding the target
shared libraries not having the .so suffix or else. I've never and
probably never will grok the misteries of the autotools karma :)

BTW, do you know the difference between pkglib_ and lib_ prefixes? The
later seems to be more standard :)

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

[Linuxsampler-devel] Packaging libgig 0.7.1 for win32

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

Hi,

Maybe this seems an heresy, but I've just tried to build libgig on win32.

After faking some missing header files, line "unistd.h" and "stdint.h",
the build goes fine and fails only on gigextract.exe due to missing
dependencies like audiofile.

Resulting gigdump.exe, dlsdump.exe and rifftree.exe seems to work just fine.

On attachment you may find the fake headers and a Borland C++ 5 (free)
makefile.

Just sharing my worries :)

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

[Linuxsampler-devel] Re: Packaging libgig 0.7.1

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

Es geschah am Freitag, 2. Juli 2004 11:30 als Rui Nuno Capela schrieb:
> Please note that the C++ source code wasn't touched in any way. On
> attachment you may find a complete diff-patch of the proposed changes.

Looks fine, except:

>>diff -duPr libgig-0.7.0/libgig.spec.in libgig-0.7.1/libgig.spec.in
[snip]
>+Copyright:	LGPL

That's GPL, not LGPL at the moment.

[snip]
>+URL:		http://www.linuxsampler.org/

That should be http://stud.fh-heilbronn.de/~cschoene/projects/libgig/ for the 
moment, I will move the site to http://www.linuxsampler.org/ though when I 
have time (in a couple of weeks).

> diff -duPr libgig-0.7.0/src/Makefile.am libgig-0.7.1/src/Makefile.am
> --- libgig-0.7.0/src/Makefile.am	2004-05-03 15:16:58.000000000 +0100
> +++ libgig-0.7.1/src/Makefile.am	2004-07-01 10:19:08.000000000 +0100
> @@ -1,11 +1,11 @@
> -# set the include path found by configure
> -INCLUDES= $(all_includes)
> -
>  # to prevent compile errors on some systems
>  AM_CXXFLAGS = -pedantic
>  
> -pkglib_LTLIBRARIES = libgig.la
> -libgig_la_SOURCES = RIFF.cpp RIFF.h DLS.cpp DLS.h gig.cpp gig.h
> +libgigincludedir = $(includedir)
> +libgiginclude_HEADERS = RIFF.h DLS.h gig.h
> +
> +lib_LTLIBRARIES = libgig.la

Is there a reason to replace pkglib_LTLIBRARIES by lib_LTLIBRARIES?

CU
Christian

[Linuxsampler-devel] Packaging libgig 0.7.1

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

Hi Christian,

While trying to use libgig to traverse the actual instrument names of a
.gig file, which will be quite handy feature for qsampler, I've made some
janitor changes mainly regarding the packaging of libgig.

For example, I've added a .spec and .pc file, for RPM generation and
pkg-config stuff respectively. I've also changed some bits and bolts on
the autocrap/libfool stuff. Nothing much, but quite enough to render some
regular RPMs (libgig and libgig-devel) for my platforms of choice (SUSE
9.1, Mdk 10.0 and FC1 PlanetCCRMA). As usual, you can check those out
from:

    http://www.rncbc.org/ls

I know that some of you are Debian folks, so these changes won't affect
you much. Nevertheless I'd like for you to try this out too, at least the
tarball :)

Please note that the C++ source code wasn't touched in any way. On
attachment you may find a complete diff-patch of the proposed changes.

The bottom line goes like this: I'm proposing a version bumping to 0.7.1
and asking if it would be a Good Thing to commit all this to
cvs.linuxsampler.org, as I think it's the central repository of libgig.

Is it alright?

Hope to hear from you soon.

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

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

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

Es geschah am Donnerstag, 1. Juli 2004 04:26 als Vladimir Senkov schrieb:
> Guess why?
> Basically stl map's accessor operator can't be used on a map unless we
> are sure that what we are looking for is already there, otherwise it
> will add it to the map!

Sure, you always have to use find() to check if a key exists in a STL map.

> PS: Benno, did you say you were going to install some bugtracking software?

AFAIK he cannot install a bugtracker on the www server. He only mentioned that 
mysql and php is available. Anyway, we should agree about one system before 
installing one. As already said; I can install a bugtracking system when my 
exams are over. These are the ones I would suggest:

	* bugzilla
	* mantis
	* gnats

The advantage of gnats is AFAIK that you cannot only access it via 
webinterface, but also per email and AFAIK with Tcl GUI frontend and command 
line tools, but I have not seen it in action yet.

CU
Christian

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

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

Guys,

Found a funny problem by typo :)

GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
Alsa,Jack
GET AUDIO_OUTPUT_DRIVER INFO Al
ERR:0:There is no audio output driver 'Al'.
GET AVAILABLE_AUDIO_OUTPUT_DRIVERS
Al,Alsa,Jack

Guess why?
Basically stl map's accessor operator can't be used on a map unless we 
are sure that what we are looking for is already there, otherwise it 
will add it to the map!
For example:
std::map <String, int> test;
test["test1"] = 1;
(at this point there is one element in the map. we can iterate the map 
and iter->first will be "test1" and iter->second will be 1).
if (test["test2"]) smth();
smth() will not execute of course.
But now if we iterate thru the map we'll find that there is a SECOND 
entry with iter->first == "test2" and iter->second == 0.

So if you don't mind i'll modify some factory code to use count() to 
make sure entries exist instead of using accessor operator.

Regards,
Vladimir.

PS: Benno, did you say you were going to install some bugtracking software?

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

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

Hi Rui, Christian,

>>Another thing, probably unrelated, is that OnSetValue() only gets called
>>when we set the parameter value as a string, with SetValue(String val) but
>>not with SetValue(int i). Is this intentional?
>>    
>>
>
>Originally, my intention was that the parser just supplies a string for a 
>parameter value, so the parser does not have to know what type the respective 
>parameter is (bool, int, string,...), so it would always call 
>SetValue(String s) which has to be implemented by all Parameter classes and 
>they implement the conversion from string to their own type
>(e.g string -> int) and then they call OnSetValue(<their_type> val) to let the 
>device driver react on parameter value changes.
>
>  
>
I think that's cool. We just need a place to initialize parameters and 
that place should not be in the constructor.
Are you OK with me putting it into the factory::create then?

Regards,
Vladimir.

PS: Multiconnection single threaded LSCPServer seems to be working OK 
(for me). I'm thinking about clearning it up a bit and checking it in 
some time this week. While i'm at it i'll also add notification support.
My current thinking is that perhaps singlethreaded way of doing things 
is sufficient for control. Notifications will be delivered in "real 
time" under control of whoever is generating them or (if required) by a 
separate thread that is responsible for sending notifications.
Right now i'm reading a command (line) and dispatching it into the 
parser, then reading another one, dispatching, etc, etc. Sequentially.
Chances are we are not going to be blocked on read in the middle of the 
command/line. I could add support for that also but that will make the 
code a bit less clear.

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

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

Es geschah am Mittwoch, 30. Juni 2004 09:48 als Rui Nuno Capela schrieb:
> Another thing, probably unrelated, is that OnSetValue() only gets called
> when we set the parameter value as a string, with SetValue(String val) but
> not with SetValue(int i). Is this intentional?

Originally, my intention was that the parser just supplies a string for a 
parameter value, so the parser does not have to know what type the respective 
parameter is (bool, int, string,...), so it would always call 
SetValue(String s) which has to be implemented by all Parameter classes and 
they implement the conversion from string to their own type
(e.g string -> int) and then they call OnSetValue(<their_type> val) to let the 
device driver react on parameter value changes.

CU
Christian

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

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

Vladimir,

>
> It looks like the problem you described with CREATE MIDI_INPUT DEVICE
> not taking any parameters is twofold. First issue is not C++, it's just
> that i forgot to include that syntax in lscp.y :)
>

It /was/ twofold. The missing syntax was in deed noticed and restored. As
of yesterday's, it's already commited.

Now it's a purely C++ problem.

>
> So we can't really set most parameters to anything other than defaults
> during device creation time.
>

Hmm. Regarding the MIDI inpuit ports parameter, I did also tried fixing
the default to 1 (one) instead of 0 (zero) -- something done on
MidiInputDevice::ParameterPorts::DefaultAsInt(). However, even then, the
alsa_seq port don't get actually created, that is, OnSetValue() does not
get ever called.

Another thing, probably unrelated, is that OnSetValue() only gets called
when we set the parameter value as a string, with SetValue(String val) but
not with SetValue(int i). Is this intentional?

>
> I'm thinking that we'll have to make changes to devicefactory so that
> Create calls default constructor and then calls some other method that
> will set the parameters _after_ the constructors are all done.
> I'm thinking devices will have only one constructor and after calling it
> factory will interate thru all parameters and set them one by one. That
> will make sure that OnSetValue is called and the backend stuff is in the
> right state.
>

I'm pretty convinced it's all due to that constructor vs. virtual methods
you're arguing. Go for it! :)

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

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

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

Hi Rui,

It looks like the problem you described with CREATE MIDI_INPUT DEVICE 
not taking any parameters is twofold. First issue is not C++, it's just 
that i forgot to include that syntax in lscp.y :)
I can't check it in right now because i'm still cleaning up something in 
the same file for multiple connections . . . as soon as i'm done with 
that i'll check this fix in. Maybe even tonight.

But . . . that would be too easy :)
I've also found something about parameters that i dislike. It's generic 
issue with all parameters, not midi related.
Basically, they have parameterized and a default constructor that calls 
InitDefault to set the value. It is expected that the underlying things 
will be done to match the default setting of a parameter.
for example, when you create MIDI_INPUT_DEVICE parameter active is 
defaulted to true.
InitDefault() will set the parameter value and Sampler.cpp will then 
make the device to listen, so it matches the default.
Problem is, if i create MIDI_INPUT_DEVICE and specify that i want active 
to be false, parameter is set to false but Sampler.cpp is not going to 
care so it will still make the device listen.
If the default were set to false and Sampler.cpp was changed not to 
listen, then the opposite will not work because OnSetValue() is only 
called when the value is changed, not when the constructor is ran.
Unfortunately we've got pure virtuals and virtuals around and those make 
it impossible for us to do certain things in the constructor. So, for 
example, when MIDI_INPUT_DEVICE is created it is creating it's 
parameters as part of it's constructor (currently). At this time we MUST 
NOT call things like CreateMidiPort or what not.
So we can't really set most parameters to anything other than defaults 
during device creation time.

I'm thinking that we'll have to make changes to devicefactory so that 
Create calls default constructor and then calls some other method that 
will set the parameters _after_ the constructors are all done.
I'm thinking devices will have only one constructor and after calling it 
factory will interate thru all parameters and set them one by one. That 
will make sure that OnSetValue is called and the backend stuff is in the 
right state.

Does that sound good to everyone?
If so, I'm going to think about it a little bit and rework this stuff a 
little bit this coming (long) weekend.

Regards,
Vladimir.

Rui Nuno Capela wrote:

>As predicted for today,
>
>linuxsampler 0.2.x:
>
>* Unconsolidaded MIDI input related channel commands are back:
>  SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device>
>  SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port>
>  SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan>
>
>* Still useful for compability with legacy clients, an almost
>  deprecated command gets re-implemented:
>  SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver>
>
>* Optional parameter list on MIDI input device creation fixed,
>  but not quite fully effective yet:
>  CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...]
>
>As is getting usual, my efforts are mainly in maintaining good
>ol'compability with existing client legacy interfaces. If the name of
>qsampler is coming to your mind, you're a genius ;)
>
>Bye.
>  
>

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

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

Rui Nuno Capela wrote:
> As predicted for today,
> 
> linuxsampler 0.2.x:
> 
> * Unconsolidaded MIDI input related channel commands are back:
>   SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device>
>   SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port>
>   SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan>
> 
> * Still useful for compability with legacy clients, an almost
>   deprecated command gets re-implemented:
>   SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver>
> 
> * Optional parameter list on MIDI input device creation fixed,
>   but not quite fully effective yet:
>   CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...]
> 
> As is getting usual, my efforts are mainly in maintaining good
> ol'compability with existing client legacy interfaces. If the name of
> qsampler is coming to your mind, you're a genius ;)
> 
> Bye.

Thanks!

(And good luck to Portugal in the next round!)

- Mark

[Linuxsampler-devel] [linuxsampler] Latest CVS commit

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

As predicted for today,

linuxsampler 0.2.x:

* Unconsolidaded MIDI input related channel commands are back:
  SET CHANNEL MIDI_INPUT_DEVICE <chan> <midi-device>
  SET CHANNEL MIDI_INPUT_PORT <chan> <midi-port>
  SET CHANNEL MIDI_INPUT_CHANNEL <chan> <midi-chan>

* Still useful for compability with legacy clients, an almost
  deprecated command gets re-implemented:
  SET CHANNEL MIDI_INPUT_TYPE <chan> <midi-driver>

* Optional parameter list on MIDI input device creation fixed,
  but not quite fully effective yet:
  CREATE MIDI_INPUT_DEVICE <midi-driver> [<key>=<val>...]

As is getting usual, my efforts are mainly in maintaining good
ol'compability with existing client legacy interfaces. If the name of
qsampler is coming to your mind, you're a genius ;)

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

Re: [Linuxsampler-devel] Set MIDI Input patch (2)

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

Vladimir,
>
> Sure looks like a bug i should be able to fix it tonight when i come
> home if it's not too late.
> Thanks for bringing this up!
>

Not at all. I'm in the same ship ya know?

If you don't mind, I'll commit my patch today, in less than 6 hours.

>
> PS: I was trying to add multi-connection support last night but ran out
> of time, maybe i'll finish it tonight.
>

There's some example code on liblscp that already does the job,
practically. It's also ready for the new event stream. Look in
liblscp/examples/server.{c,h}. The code is structured as for a C library
module, you can even choose between a multiplexed or a multithreaded
server.

Once ago I've tried to merge into linuxsampler server code base, but that
stumbled on the parser usage. Didn't had the time to find a better way of
coupling the yacc/lex generated parser code and the callback model of
liblscp example server interface, where a fifo pipe would be a solution.

In other words, my main problem was/is on how to encapsulate the yacc/lex
parser, having it as a stand-alone instance for each client connection,
with it's own callback feeding pipe. The question was/is on how to map the
client connection descriptor to a corresponding encapsulated parser
instance, on callback time. I ran out of time too :)

Oh well.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Set MIDI Input patch (2)

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

Hi Rui,

Sure looks like a bug i should be able to fix it tonight when i come 
home if it's not too late.
Thanks for bringing this up!

Regards,
Vladimir.

PS: I was trying to add multi-connection support last night but ran out 
of time, maybe i'll finish it tonight.

Rui Nuno Capela wrote:

>Hi Vladimir,
>
>(New patch attached)
>
>  
>
>>I'm not sure why you couldn't see alsa ports created. I've tried
>>this last night several times and it was working ok.
>>Try this:
>>CREATE MIDI_INPUT_DEVICE Alsa
>>OK[0]
>>SET MIDI_INPUT_DEVICE_PARAMETER 0 ports=1
>>
>>    
>>
>
>Aha. I was trying just that but with the single command line:
>CREATE MIDI_INPUT_DEVICE Alsa ports=1
>
>It does not create the alsa_seq port. But yours do. Isn't those supposed
>to be equivalent?
>
>OTOH, can you shed me some light on how can it be done internally in C++?
>I'm not found in discovering it by trial-and-error :). OK. I've been
>trying this:
>
>  std::map<String,String> params;
>  params["ports"] = "1";
>  pDevice = pSampler->CreateMidiInputDevice("Alsa", params);
>
>This does not create the intended alsa_seq port. In analogy to the above,
>the following does work:
>
>  std::map<String,String> params;
>  pDevice = pSampler->CreateMidiInputDevice("Alsa", params);
>  std::map<String,DeviceCreationParameter*> params2 =
>pDevice->DeviceParameters();
>  params2["ports"]->SetValue("1");
>
>So I think there's a lil'bug on device creation parameterization. Can't
>find why yet, as I'm still overpuzzled with this new parameter monster :)
>
>  
>
>>So AcquirePorts is called when the "ports" parameter is set. I've
>>discussed it with Christian and although not yet documented (spec needs
>>updating) ports are supposed to be created and removed similarly to audio
>>channels via the above SET command.
>>
>>    
>>
>
>Yes I know that. But it seems that the parameter doesn't get properly set
>on MidiInputDevice creation time.
>
>Or is it just me?
>
>On attachment is an updated patch, just with the "hack" above, which
>applies specifically for the SET CHANNEL MIDI_INPUT_TYPE command
>re-implementation, while creating an ALSA MIDI input device with at least
>one actual alsa_seq port.
>
>With this, our legacy client(s) will be happy again :)
>
>Cheers.
>  
>

Re: [Linuxsampler-devel] Set MIDI Input patch (2)

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

Hi Vladimir,

(New patch attached)

>
> I'm not sure why you couldn't see alsa ports created. I've tried
> this last night several times and it was working ok.
> Try this:
> CREATE MIDI_INPUT_DEVICE Alsa
> OK[0]
> SET MIDI_INPUT_DEVICE_PARAMETER 0 ports=1
>

Aha. I was trying just that but with the single command line:
CREATE MIDI_INPUT_DEVICE Alsa ports=1

It does not create the alsa_seq port. But yours do. Isn't those supposed
to be equivalent?

OTOH, can you shed me some light on how can it be done internally in C++?
I'm not found in discovering it by trial-and-error :). OK. I've been
trying this:

  std::map<String,String> params;
  params["ports"] = "1";
  pDevice = pSampler->CreateMidiInputDevice("Alsa", params);

This does not create the intended alsa_seq port. In analogy to the above,
the following does work:

  std::map<String,String> params;
  pDevice = pSampler->CreateMidiInputDevice("Alsa", params);
  std::map<String,DeviceCreationParameter*> params2 =
pDevice->DeviceParameters();
  params2["ports"]->SetValue("1");

So I think there's a lil'bug on device creation parameterization. Can't
find why yet, as I'm still overpuzzled with this new parameter monster :)

>
> So AcquirePorts is called when the "ports" parameter is set. I've
> discussed it with Christian and although not yet documented (spec needs
> updating) ports are supposed to be created and removed similarly to audio
> channels via the above SET command.
>

Yes I know that. But it seems that the parameter doesn't get properly set
on MidiInputDevice creation time.

Or is it just me?

On attachment is an updated patch, just with the "hack" above, which
applies specifically for the SET CHANNEL MIDI_INPUT_TYPE command
re-implementation, while creating an ALSA MIDI input device with at least
one actual alsa_seq port.

With this, our legacy client(s) will be happy again :)

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

P.S. Don't forget to do a "make parse" under "src/network", after applying
the patch, as it changes the lscp.y source.

Re: [Linuxsampler-devel] Set MIDI Input patch

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

Hi Rui,

I'm not sure why you couldn't see alsa ports created. I've tried this 
last night several times and it was working ok.
Try this:
CREATE MIDI_INPUT_DEVICE Alsa
OK[0]
SET MIDI_INPUT_DEVICE_PARAMETER 0 ports=1

So AcquirePorts is called when the "ports" parameter is set. I've 
discussed it with Christian and although not yet documented (spec needs 
updating) ports are supposed to be created and removed similarly to 
audio channels via the above SET command.

Once port is created, you can use these commands:
GET MIDI_INPUT_PORT INFO 0 0
SET MIDI_INPUT_PORT_PARAMETER 0 0 alsa_seq_bindings='64:0'

Let me know how it goes.

Regards,
Vladimir.

Rui Nuno Capela wrote:

>Hi,
>
>Another week, another monday and another patch :)
>
>The attached patch makes some progressions but also some fixes on the
>latest MIDI input consolidation stuff as committed by Vladimir.
>
>Sorry to insist, but this brings back the unconsolidated commands:
>
>  SET CHANNEL MIDI_INPUT_DEVICE <sampler-channel> <midi-device-id>
>  SET CHANNEL MIDI_INPUT_PORT <sampler-channel> <midi-port>
>  SET CHANNEL MIDI_INPUT_CHANNEL <sampler-channel> <midi-channel>
>
>To maintain my beloved compability, the following command has been
>re-implemented:
>
>  SET CHANNEL MIDI_INPUT_TYPE <sampler-channel> <midi-driver-type>
>
>The patch also makes the optional parameter list effective in:
>
>  CREATE MIDI_INPUT_DEVICE <midi-driver-type> [<param>=<value>,...]
>
>However I could not make it to show up any actual ALSA sequencer port.
>Even with this patch applied, current CVS HEAD's MIDI input triggering
>it's at fault. At least as far as I could try.
>
>Strangely enough, I'm missing how MidiInputDevice::AcquirePorts(), and the
>MidiInputDevice::CreatePort() executive is ever reached with current code
>path.
>
>Vladimir?
>  
>

[Linuxsampler-devel] Set MIDI Input patch

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

Hi,

Another week, another monday and another patch :)

The attached patch makes some progressions but also some fixes on the
latest MIDI input consolidation stuff as committed by Vladimir.

Sorry to insist, but this brings back the unconsolidated commands:

  SET CHANNEL MIDI_INPUT_DEVICE <sampler-channel> <midi-device-id>
  SET CHANNEL MIDI_INPUT_PORT <sampler-channel> <midi-port>
  SET CHANNEL MIDI_INPUT_CHANNEL <sampler-channel> <midi-channel>

To maintain my beloved compability, the following command has been
re-implemented:

  SET CHANNEL MIDI_INPUT_TYPE <sampler-channel> <midi-driver-type>

The patch also makes the optional parameter list effective in:

  CREATE MIDI_INPUT_DEVICE <midi-driver-type> [<param>=<value>,...]

However I could not make it to show up any actual ALSA sequencer port.
Even with this patch applied, current CVS HEAD's MIDI input triggering
it's at fault. At least as far as I could try.

Strangely enough, I'm missing how MidiInputDevice::AcquirePorts(), and the
MidiInputDevice::CreatePort() executive is ever reached with current code
path.

Vladimir?
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Christian Schoenebeck wrote:
> Es geschah am Sonntag, 27. Juni 2004 20:11 als Mark Knecht schrieb:
> 
>>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.
> 
> 
> As far as I can remember we agreed already months ago to do it that way; means 
> only one MIDI input per sampler channel. That's how it's defined in the 
> network protocol.
> 
> And sure, if one instrument is selected multiple times on different sampler 
> channels, there's of course only one copy of the instrument data / samples in 
> memory. That's what the 'InstrumentResourceManager' class is for:
> 

Great! I have no recollection of the decision, but I'm of course very 
happy that you see it this way. I have often used 2-3 piano tracks 
driving a single gig file.

thanks,
Mark

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Hi All,

I've just checked in some stuff.
The objective was to convert the MIDI into the new infrastructure to 
support new LSCP.
The code is, Like Christian said, buggy as hell :)
Unfortunately i didn't do anything with the MacOS stuff (that another 
way of saying i broke it).
Alsa stuff seems to work though. Due to time constraints i could not 
test it really well, but some basic configurations do seem to work.
Fixed some minor bugs here and there . . .

Big chunks on TODO list now are:
update LSCP spec
Converting MacOS MIDI. (pretty easy, but it would be nice to be able to 
test).
Audio channels and their LSCP support. (basic audio output stuff works 
now, but not for audio channel commands last time i checked)
Fixing bugs (i'm sure you guys will report some soon).
Working with Rui to work out the client/server issues (compatibility, 
deprecated commands, etc)
Some code documentation (a lot of it was forgotten in the heat of the 
night :)
Testing, testing, testing.

I should be able to cover some of that stuff in the next two weekends. 
After that i'll be travelling for about a month. I hope Christian will 
be back then and fix everything :)

known bugs:
"midi port name" bug. once set all port names are the same :)
"midi port name" doesn't do anything, could set alsa midi port name 
maybe . . .
trying too many alsa ports. exception handling needs to be better.

man we need that bug tracking system i keep forgetting everything :(
Let's set that up and get it populated with some bugs!

Regards,
Vladimir.

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Es geschah am Sonntag, 27. Juni 2004 20:11 als Mark Knecht schrieb:
> 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.

As far as I can remember we agreed already months ago to do it that way; means 
only one MIDI input per sampler channel. That's how it's defined in the 
network protocol.

And sure, if one instrument is selected multiple times on different sampler 
channels, there's of course only one copy of the instrument data / samples in 
memory. That's what the 'InstrumentResourceManager' class is for:

	http://www.linuxsampler.org/doc/InstrumentResourceManager.pdf

It loads a file into memory when it's demanded for the first time by an engine 
and automatically frees it from memory if no sampler channel needs the 
instrument anymore.

The 'InstrumenResourceManager' even notifies the engines, when an instrument 
file needs to be reloaded (for what reason ever), waits till all engines have 
signaled back to be ready for the reload, then reloads the respective file 
and notifies the engines when the reload is done, so they can safely continue 
to render audio. That's how it's already implemented.

CU
Christian