linuxsampler-devel

[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] SET CHANNEL MIDI_INPUT

[Mark K. <mar...@gm...>]

Hello,
   My LS script files to date have used only a couple of MIDI commands:

CREATE MIDI_INPUT_DEVICE ALSA
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
SET CHANNEL MIDI_INPUT 0 0 0 0

The first two are documented in the LCSP document online but the last
one isn't. Could someone tell me what the four parameters are? I had
been guessing that it was the following:


SET CHANNEL MIDI_INPUT <sampler-channel> <MIDI_INPUT_DEVICE #>
<MIDI_INPUT_DEVICE port-number> <MIDI-channel-number>

but it doesn't seem correct:

CREATE MIDI_INPUT_DEVICE ALSA
OK[0]
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
OK
SET MIDI_INPUT_PORT_PARAMETER 0 1 ALSA_SEQ_BINDINGS="64:32"
ERR:0:There is no port 1

So, how do I bind my second MIDI input to LS? I'm trying to go beyond
16 MIDI inputs on LS now. QJC shows:

64: MIDI 1
-> 0: MIDI 1
-> 32: MIDI 2

Why isn't the 32: a second port?

I changed the script to say:

CREATE MIDI_INPUT_DEVICE ALSA
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:32"

which works (graphically - untested with MIDI as of yet) according to
QJC but looks sort of wrong to me. When is a port a port?

Thanks,
Mark

[Linuxsampler-devel] Re: SET CHANNEL MIDI_INPUT

[Mark K. <mar...@gm...>]

Replying to myself...

So I tried some more commands:

[mark@Godzilla LS-Scripts]$ echo GET AVAILABLE_MIDI_INPUT_DRIVERS | nc
localhost 8888
ALSA
[mark@Godzilla LS-Scripts]$ echo GET MIDI_INPUT_DRIVER INFO ALSA | nc
localhost 8888
DESCRIPTION: Advanced Linux Sound Architecture
VERSION: 1.13
PARAMETERS: ACTIVE,PORTS
.
[mark@Godzilla LS-Scripts]$ echo GET MIDI_INPUT_DRIVER_PARAMETER INFO
ALSA PORTS | nc localhost 8888
TYPE: INT
DESCRIPTION: Number of ports
MANDATORY: false
FIX: false
MULTIPLICITY: false
DEFAULT: 1
.
[mark@Godzilla LS-Scripts]$

[mark@Godzilla LS-Scripts]$ echo GET MIDI_INPUT_DRIVER_PARAMETER INFO
ALSA ACTIVE | nc localhost 8888
TYPE: BOOL
DESCRIPTION: Enable / disable device
MANDATORY: false
FIX: false
MULTIPLICITY: false
DEFAULT: true
.
[mark@Godzilla LS-Scripts]$

But I'm not sure how I discover the second port?

As an experiment I tried:

CREATE MIDI_INPUT_DEVICE ALSA
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
CREATE MIDI_INPUT_DEVICE ALSA
SET MIDI_INPUT_PORT_PARAMETER 1 0 ALSA_SEQ_BINDINGS="64:32"

which creates two MIDI inputs for LS but one of them does not go away
when LS is killed.



On Tue, 1 Mar 2005 09:56:53 -0800, Mark Knecht <mar...@gm...> wrote:
> Hello,
>    My LS script files to date have used only a couple of MIDI commands:
> 
> CREATE MIDI_INPUT_DEVICE ALSA
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
> SET CHANNEL MIDI_INPUT 0 0 0 0
> 
> The first two are documented in the LCSP document online but the last
> one isn't. Could someone tell me what the four parameters are? I had
> been guessing that it was the following:
> 
> SET CHANNEL MIDI_INPUT <sampler-channel> <MIDI_INPUT_DEVICE #>
> <MIDI_INPUT_DEVICE port-number> <MIDI-channel-number>
> 
> but it doesn't seem correct:
> 
> CREATE MIDI_INPUT_DEVICE ALSA
> OK[0]
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
> OK
> SET MIDI_INPUT_PORT_PARAMETER 0 1 ALSA_SEQ_BINDINGS="64:32"
> ERR:0:There is no port 1
> 
> So, how do I bind my second MIDI input to LS? I'm trying to go beyond
> 16 MIDI inputs on LS now. QJC shows:
> 
> 64: MIDI 1
> -> 0: MIDI 1
> -> 32: MIDI 2
> 
> Why isn't the 32: a second port?
> 
> I changed the script to say:
> 
> CREATE MIDI_INPUT_DEVICE ALSA
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:0"
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS="64:32"
> 
> which works (graphically - untested with MIDI as of yet) according to
> QJC but looks sort of wrong to me. When is a port a port?
> 
> Thanks,
> Mark
>

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Es geschah am Dienstag 01 M=E4rz 2005 18:56 als Mark Knecht schrieb:
> Hello,
>    My LS script files to date have used only a couple of MIDI commands:
>
> CREATE MIDI_INPUT_DEVICE ALSA
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS=3D"64:0"
> SET CHANNEL MIDI_INPUT 0 0 0 0
>
> The first two are documented in the LCSP document online but the last
> one isn't. Could someone tell me what the four parameters are?

The reason that it's not mentioned there is that it was actually deprecated=
=20
very long time ago. So we even did not take into the specs.

The "recommended" way is to use these three 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>

> I had=20
> been guessing that it was the following:
>
>
> SET CHANNEL MIDI_INPUT <sampler-channel> <MIDI_INPUT_DEVICE #>
> <MIDI_INPUT_DEVICE port-number> <MIDI-channel-number>

which is correct, and btw in doubt you can alway check src/network/lscp.y=20
which defines the protocol grammer in Backus-Naur form. So this file is=20
actually used to ompile the LSCP parser.

> but it doesn't seem correct:
>
> CREATE MIDI_INPUT_DEVICE ALSA
> OK[0]
> SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS=3D"64:0"
> OK
> SET MIDI_INPUT_PORT_PARAMETER 0 1 ALSA_SEQ_BINDINGS=3D"64:32"
> ERR:0:There is no port 1

Maybe I got you wrong, but it seems to me there's a little misapprehension.=
=20
What you are trying to do above with the 3rd command is to connect the=20
foreign ALSA Sequencer client port 64:32 with the 2nd port of the MIDI inpu=
t=20
device #0 in LS. But a MIDI input device in LS has only one port by default=
,=20
so you are trying to connect to a port within LS which does not exist. Or=20
graphically:

LinuxSampler          Some MIDI Source
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D          =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D

(MIDI Device 1)       (Foreign MIDI device)
    |                     |
    +-(Port 0) <------->  +-(Port 0 [64:0])
                          |
           ??? <------->  +-(Port 1 [64:32])

So the correct way is to create a MIDI input device with 2 (or more) ports =
in=20
LS first:

 CREATE MIDI_INPUT_DEVICE ALSA PORTS=3D2

or alternatively to increase the number of ports after you created the devi=
ce:

 CREATE MIDI_INPUT_DEVICE ALSA
 SET MIDI_INPUT_DEVICE_PARAMETER 0 PORTS=3D2

After that the connection to the 2nd port works:

 SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS=3D"64:0"
 SET MIDI_INPUT_PORT_PARAMETER 0 1 ALSA_SEQ_BINDINGS=3D"64:32"

Hope this makes it clear.

CU
Christian

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

[Mark K. <mar...@gm...>]

Christian,
   Thanks. Very clear description and very helpful. Te thought that I
had to set the number of ports was in my mind but I couldn't figure
out from the LSCP document exactly how to do it. Seems like I was
close asking for parameters and finding ports but I somehow never
found the instructions to add PORTS=3D2 to that command.

   The scripts are changed and visially at least working well. I'll do
some audio testing later this evening.

Thanks again,
Mark


On Tue, 1 Mar 2005 20:55:52 +0100, Christian Schoenebeck
<sch...@so...> wrote:
> Es geschah am Dienstag 01 M=E4rz 2005 18:56 als Mark Knecht schrieb:
> > Hello,
> >    My LS script files to date have used only a couple of MIDI commands:
> >
> > CREATE MIDI_INPUT_DEVICE ALSA
> > SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS=3D"64:0"
> > SET CHANNEL MIDI_INPUT 0 0 0 0
> >


>=20
>  CREATE MIDI_INPUT_DEVICE ALSA PORTS=3D2
>=20
> or alternatively to increase the number of ports after you created the de=
vice:
>=20
>  CREATE MIDI_INPUT_DEVICE ALSA
>  SET MIDI_INPUT_DEVICE_PARAMETER 0 PORTS=3D2
>=20
> After that the connection to the 2nd port works:
>=20
>  SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS=3D"64:0"
>  SET MIDI_INPUT_PORT_PARAMETER 0 1 ALSA_SEQ_BINDINGS=3D"64:32"
>=20
> Hope this makes it clear.
>=20

:-)) Thanks!

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

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

Es geschah am Dienstag 01 M=E4rz 2005 21:23 als Mark Knecht schrieb:
> Christian,
>    Thanks. Very clear description and very helpful. Te thought that I
> had to set the number of ports was in my mind but I couldn't figure
> out from the LSCP document exactly how to do it. Seems like I was
> close asking for parameters and finding ports but I somehow never
> found the instructions to add PORTS=3D2 to that command.

Yeah, my fault. You know LSCP was actually intended primarily for the use b=
y a=20
frontend application. And the usual way to create a new or alter an existin=
g=20
audio/MIDI device would be the frontend to "ask" the sampler for details=20
about drivers and driver parameters at runtime, that is the frontend would=
=20
ask what drivers are there, which paramters those drivers offer, what the=20
purpose of those driver parameters are, type, possible values, default valu=
e,=20
dependencies, etc.
So that way the LSCP language is absolutely independent of the implementati=
on=20
of each driver and independent of what drivers are actually there and that'=
s=20
why those driver details are not covered by the LSCP specs at all.

I planned to make extra specs for the drivers we have, so you could read wh=
at=20
parameters each driver offers, but haven't found the time yet to do it. If=
=20
somebody likes to start such a documentation, it would be very much=20
appreciated! Docbook for instance might be a good choice.

CU
Christian

Re: [Linuxsampler-devel] SET CHANNEL MIDI_INPUT

[Mark K. <mar...@gm...>]

On Wed, 2 Mar 2005 16:08:43 +0100, Christian Schoenebeck
<sch...@so...> wrote:
> Es geschah am Dienstag 01 M=E4rz 2005 21:23 als Mark Knecht schrieb:
> > Christian,
> >    Thanks. Very clear description and very helpful. Te thought that I
> > had to set the number of ports was in my mind but I couldn't figure
> > out from the LSCP document exactly how to do it. Seems like I was
> > close asking for parameters and finding ports but I somehow never
> > found the instructions to add PORTS=3D2 to that command.
>=20
> Yeah, my fault. You know LSCP was actually intended primarily for the use=
 by a
> frontend application. And the usual way to create a new or alter an exist=
ing
> audio/MIDI device would be the frontend to "ask" the sampler for details
> about drivers and driver parameters at runtime, that is the frontend woul=
d
> ask what drivers are there, which paramters those drivers offer, what the
> purpose of those driver parameters are, type, possible values, default va=
lue,
> dependencies, etc.
> So that way the LSCP language is absolutely independent of the implementa=
tion
> of each driver and independent of what drivers are actually there and tha=
t's
> why those driver details are not covered by the LSCP specs at all.

It all makes sense, and even more sense now since your response
yesterday. It just never dawned on me the answer was quite so simple
and straight forward. That's cool. I understand about not having
enough time. This could also be handled through more examples on the
web site. Maybe my scripts can help in that way? Put up chunck of
LS-script code with a little bit of info on what I'm trying to do?
Maybe that way the user community can grow the knowledge database more
over time? (A wiki maybe?)

>=20
> I planned to make extra specs for the drivers we have, so you could read =
what
> parameters each driver offers, but haven't found the time yet to do it. I=
f
> somebody likes to start such a documentation, it would be very much
> appreciated! Docbook for instance might be a good choice.
>=20
> CU
> Christian
>=20

Cheers,
Mark

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

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

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

[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

[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.