linuxsampler-devel

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

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 (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...>]

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