sequencer: handling non-registered parameter numbers....

sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

hello alsa gurus !

i have bought a peavey studiomix midi controller on ebay, and it sends 
NRPN messages (non-registered parameter numbers). when i move a slider, 
it sends the slider number encoded in 98 and 99 and the value in the 
DATA ENTRY controllers 6 and 38. i would like to map these to ordinary 
midi controllers, or better yet, get nrpn support into ardour.

how do i get nrpn controller values from the alsa sequencer without 
having to parse the individual events and put them together by hand ?

grepping through alsa-lib, i found

static struct extra_event_list_t {
         int event;
         int (*decode)(snd_midi_event_t *dev, unsigned char *buf, int 
len, snd_seq_event_t *ev);
} extra_event[] = {
         {SND_SEQ_EVENT_CONTROL14, extra_decode_ctrl14},
         /*{SND_SEQ_EVENT_NONREGPARAM, extra_decode_nrpn},*/
         /*{SND_SEQ_EVENT_REGPARAM, extra_decode_rpn},*/
};

which makes me think it might not yet be implemented....

any hints or fine manuals around ?

(disclaimer: i know absolutely *nothing* about the alsa seq code, my 
level of understanding is matthias' example client.)

best,

jörn

-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Sunday 15 June 2003 18.16, Joern Nettingsmeier wrote:
[...]
>          /*{SND_SEQ_EVENT_NONREGPARAM, extra_decode_nrpn},*/
>          /*{SND_SEQ_EVENT_REGPARAM, extra_decode_rpn},*/
> };
>
> which makes me think it might not yet be implemented....

I'm using NRPNs to control the mixer in the current development 
version of Audiality, and they appear to be working just fine, and 
just like one would expect.


> any hints or fine manuals around ?

Do you need one? :-)

What you get is plain <control, value> tuples, and that's all there is 
to it. (Well, it's all I *want* anyway, as I don't want to do stuff 
that's outside the MIDI spec...)

Here's some code, which isn't heavily tested, but does seem to do the 
job:

static void alsaseq_read(struct A_device *dev, unsigned frames)
{
        int more = 1;
        snd_seq_event_t *ev;
        ALSASEQ_data *d = (ALSASEQ_data *) dev->driver_data;
        dev->read_ms->time = aev_timer;
        while(more)
        {
                more = snd_seq_event_input(d->seq_handle, &ev);
                if(more < 0)
                        break;

                switch (ev->type)
                {
                  case SND_SEQ_EVENT_CONTROLLER:
                        dev->read_ms->control(
                                        ev->data.control.channel,
                                        ev->data.control.param,
                                        ev->data.control.value);
                        break;
                  case SND_SEQ_EVENT_NONREGPARAM:
                        dev->read_ms->nrpn(ev->data.control.channel,
                                        ev->data.control.param,
                                        ev->data.control.value);
                        break;

		...

                  case SND_SEQ_EVENT_PITCHBEND:
                        dev->read_ms->bend(ev->data.control.channel,
                                        ev->data.control.value);
                        break;
                }
                snd_seq_free_event(ev);
        }
}


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Paul Davis]

>hello alsa gurus !
>
>i have bought a peavey studiomix midi controller on ebay, and it sends 
>NRPN messages (non-registered parameter numbers). when i move a slider, 
>it sends the slider number encoded in 98 and 99 and the value in the 
>DATA ENTRY controllers 6 and 38. i would like to map these to ordinary 
>midi controllers, or better yet, get nrpn support into ardour.
>
>how do i get nrpn controller values from the alsa sequencer without 
>having to parse the individual events and put them together by hand ?

ardour doesn't use the sequencer.

and i don't consider the nrpn messages any different from any other
controller. from libmidi++'s persepective, there are 127 controller
ID's, each with a value. whatever standard mapping they may have to
gain, pan, or nrpn is completely ignored.

14 bit value support is almost impossible to provide: the midi spec is
just ridiculous for that. 

--p


-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

hello david !

thanks for your reply.

David Olofson wrote:
> On Sunday 15 June 2003 18.16, Joern Nettingsmeier wrote:
> [...]
> 
>>         /*{SND_SEQ_EVENT_NONREGPARAM, extra_decode_nrpn},*/
>>         /*{SND_SEQ_EVENT_REGPARAM, extra_decode_rpn},*/
>>};
>>
>>which makes me think it might not yet be implemented....
> 
> 
> I'm using NRPNs to control the mixer in the current development 
> version of Audiality, and they appear to be working just fine, and 
> just like one would expect.
> 
> 
> 
>>any hints or fine manuals around ?
> 
> 
> Do you need one? :-)

where did i make the impression that i have *any* clue about progamming 
?  yes i do :)

> What you get is plain <control, value> tuples, and that's all there is 
> to it. (Well, it's all I *want* anyway, as I don't want to do stuff 
> that's outside the MIDI spec...)
> 
> Here's some code, which isn't heavily tested, but does seem to do the 
> job:

either i have not understood the semantics of nrpm, or nrpm  events are 
not detected as such. when i move a slider, i always get four separate 
normal controller events: two on 98/99 encoding the control number as a 
14bit value, and two on 6 and 38 encoding the data.

the case SND_EVENT_NONREGPARAM is never reached.
now one of three things must be broken (in decreasing order of 
likelihood): me, my wacky peavey controller, or alsa-lib.

?

-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

Paul Davis wrote:
>>hello alsa gurus !
>>
>>i have bought a peavey studiomix midi controller on ebay, and it sends 
>>NRPN messages (non-registered parameter numbers). when i move a slider, 
>>it sends the slider number encoded in 98 and 99 and the value in the 
>>DATA ENTRY controllers 6 and 38. i would like to map these to ordinary 
>>midi controllers, or better yet, get nrpn support into ardour.
>>
>>how do i get nrpn controller values from the alsa sequencer without 
>>having to parse the individual events and put them together by hand ?
> 
> 
> ardour doesn't use the sequencer.

i'm aware of that. i was planning to use a virmidi card, which ardour 
could grab raw, and to write a little mapper that maps nrpns to 
arbitrary normal controllers. this can be patched between the midi in 
port and the virtual device with aconnect. (if i have understood virmidi 
devices correctly.)

> and i don't consider the nrpn messages any different from any other
> controller. from libmidi++'s persepective, there are 127 controller
> ID's, each with a value. whatever standard mapping they may have to
> gain, pan, or nrpn is completely ignored.

understood. the problem is, it won't work automatically with nrpn-based 
controllers, since two nrpn "events" and two data entry events (yes, 
both 14 bit) must be grouped together and transmogrified into one 
[controller,value] tuple.

> 14 bit value support is almost impossible to provide: the midi spec is
> just ridiculous for that. 

i wouldn't have dared to say so for lack of experience, but i had this 
creeping feeling it might be the case. :)

maybe i should consider dropping 14-bit resolution (the crappy faders on 
the peavey hardly manage 127 distinct positions) and just use the MSB 
part of the 14bit controller. ardour does perform lowpass filtering of 
controller values, right ?

-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 09.51, Joern Nettingsmeier wrote:
[...]
> > What you get is plain <control, value> tuples, and that's all
> > there is to it. (Well, it's all I *want* anyway, as I don't want
> > to do stuff that's outside the MIDI spec...)
> >
> > Here's some code, which isn't heavily tested, but does seem to do
> > the job:
>
> either i have not understood the semantics of nrpm, or nrpm  events
> are not detected as such. when i move a slider, i always get four
> separate normal controller events: two on 98/99 encoding the
> control number as a 14bit value, and two on 6 and 38 encoding the
> data.

Well, that does sound like your ALSA setup isn't parsing those CCs, 
but just letting them through. I don't get the raw CCs at all here, 
but I do get the decoded NRPNs. (IIRC, that's why I threw the NRPN 
code in in the first place. I have CC parsing code for it as well, 
but those CCs never arrived.)

I've been using an Audigy card with various ALSA drivers from 0.9.0rc6 
and up, but I'm not entirely sure this works with versions before 
0.9.3. The ALSA sequencer support in Audiality isn't very old, so it 
might be that I've only used it with 0.9.3.


> the case SND_EVENT_NONREGPARAM is never reached.
> now one of three things must be broken (in decreasing order of
> likelihood): me, my wacky peavey controller, or alsa-lib.

I dunno 'bout *you*, but your code makes one suspect. ;-) If the 
controller actually sends the CCs involved in NRPNs, it *should* 
work, if ALSA cares to decode it - and this is a generic MIDI thing, 
so one would assume it's done in some place like alsa-lib, rather 
than inside drivers. I'm not sure about that, though.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:

> either i have not understood the semantics of nrpm, or nrpm  events are 
> not detected as such. when i move a slider, i always get four separate 
> normal controller events: two on 98/99 encoding the control number as a 
> 14bit value, and two on 6 and 38 encoding the data.
> 
> the case SND_EVENT_NONREGPARAM is never reached.
> now one of three things must be broken (in decreasing order of 
> likelihood): me, my wacky peavey controller, or alsa-lib.

The driver code and alsa-lib does not handle nonreg and reg parameters.
They simply pass them like standard controllers, so the four event 
sequence is ok. I think that we may add this piece code to seq_midi_event.c.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 10.29, Jaroslav Kysela wrote:
[...]
> The driver code and alsa-lib does not handle nonreg and reg
> parameters. They simply pass them like standard controllers, so the
> four event sequence is ok. I think that we may add this piece code
> to seq_midi_event.c.

This is weird... Wonder what's actually happening in there. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

On Mon, 16 Jun 2003, David Olofson wrote:

> On Monday 16 June 2003 10.29, Jaroslav Kysela wrote:
> [...]
> > The driver code and alsa-lib does not handle nonreg and reg
> > parameters. They simply pass them like standard controllers, so the
> > four event sequence is ok. I think that we may add this piece code
> > to seq_midi_event.c.
> 
> This is weird... Wonder what's actually happening in there. :-)

If you have USB midi device, I think that we had driver versions which 
works directly with sequencer events so probably it is the case.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 10.57, Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, David Olofson wrote:
> > On Monday 16 June 2003 10.29, Jaroslav Kysela wrote:
> > [...]
> >
> > > The driver code and alsa-lib does not handle nonreg and reg
> > > parameters. They simply pass them like standard controllers, so
> > > the four event sequence is ok. I think that we may add this
> > > piece code to seq_midi_event.c.
> >
> > This is weird... Wonder what's actually happening in there. :-)
>
> If you have USB midi device, I think that we had driver versions
> which works directly with sequencer events so probably it is the
> case.

Nope, I don't have any USB MIDI devices; only an SB Audigy Platinum... 
(And a Layla20, for which there is no MIDI support yet.)

I'm going to have another look at it. There has to be some explanation 
why it mysteriously Just Works(TM).


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:
> 
> 
>>either i have not understood the semantics of nrpm, or nrpm  events are 
>>not detected as such. when i move a slider, i always get four separate 
>>normal controller events: two on 98/99 encoding the control number as a 
>>14bit value, and two on 6 and 38 encoding the data.
>>
>>the case SND_EVENT_NONREGPARAM is never reached.
>>now one of three things must be broken (in decreasing order of 
>>likelihood): me, my wacky peavey controller, or alsa-lib.
> 
> 
> The driver code and alsa-lib does not handle nonreg and reg parameters.
> They simply pass them like standard controllers, so the four event 
> sequence is ok. I think that we may add this piece code to seq_midi_event.c.
> 
 > 						Jaroslav

thanks for the clarification. i'd be glad to help, but i doubt i could 
meet the coding standards of alsa-lib. at least i could help test it.
do you or anyone of the alsa core developers have plans to tackle this 
some time soon ? i'd love to be able to use my controller box for the 
LinuxTag presentations in mid-July.

best,

jörn


-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:

> Jaroslav Kysela wrote:
> > On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:
> > 
> > 
> >>either i have not understood the semantics of nrpm, or nrpm  events are 
> >>not detected as such. when i move a slider, i always get four separate 
> >>normal controller events: two on 98/99 encoding the control number as a 
> >>14bit value, and two on 6 and 38 encoding the data.
> >>
> >>the case SND_EVENT_NONREGPARAM is never reached.
> >>now one of three things must be broken (in decreasing order of 
> >>likelihood): me, my wacky peavey controller, or alsa-lib.
> > 
> > 
> > The driver code and alsa-lib does not handle nonreg and reg parameters.
> > They simply pass them like standard controllers, so the four event 
> > sequence is ok. I think that we may add this piece code to seq_midi_event.c.
> > 
>  > 						Jaroslav
> 
> thanks for the clarification. i'd be glad to help, but i doubt i could 
> meet the coding standards of alsa-lib. at least i could help test it.
> do you or anyone of the alsa core developers have plans to tackle this 
> some time soon ? i'd love to be able to use my controller box for the 
> LinuxTag presentations in mid-July.

I am working on it right now, but it requires to add new states to 
sequencer event encoder...

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

On Mon, 16 Jun 2003, Jaroslav Kysela wrote:

> > thanks for the clarification. i'd be glad to help, but i doubt i could 
> > meet the coding standards of alsa-lib. at least i could help test it.
> > do you or anyone of the alsa core developers have plans to tackle this 
> > some time soon ? i'd love to be able to use my controller box for the 
> > LinuxTag presentations in mid-July.
> 
> I am working on it right now, but it requires to add new states to 
> sequencer event encoder...

Initial code is in CVS. It is not tested, but hopefully, without any major 
bugs. It seems that we have also missing encoding of CONTROL14 events.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Paul Davis]

>Initial code is in CVS. It is not tested, but hopefully, without any major 
>bugs. It seems that we have also missing encoding of CONTROL14 events.

14 bit MIDI is almost impossible to parse in any sane fashion. if you
read the spec carefully, you'll see that it requires a timeout be
attached to each and every CC message received. why? because of the
order they transmit the low and high nibbles. the basic idea embodied
in the protocol is to send the low byte and then the high byte if *and
only if* necessary. thus, when you receive the low byte, you don't
know if the high byte is coming or not.

its clearly designed for hardware rather than software
implementations, and its really, really ugly.


-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Paul Davis]

>maybe i should consider dropping 14-bit resolution (the crappy faders on 
>the peavey hardly manage 127 distinct positions) and just use the MSB 
>part of the 14bit controller. ardour does perform lowpass filtering of 
>controller values, right ?

it doesn't filter the values directly, but the various things that use
them do interpolate. for example, if you bind to a gain fader, there
is no smoothing of the changes in terms of what is sent to the core,
but the core will interpolate to avoid zipper noise. this is so that
the interpolation is centralized, and we don't have to care where gain
changes (for example) come from.

when bound to plugin parameters, its really up to the plugin
author. most of steve's set interpolate where necessary.

--p



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 11.10, David Olofson wrote:
[...]
> I'm going to have another look at it. There has to be some
> explanation why it mysteriously Just Works(TM).

Yep, the explanation is most probably that I was using ALSA rawmidi 
input... :-) With the ALSA sequencer "driver" I get the CC events and 
no NRPNs or anything.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 13.19, Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
> > > thanks for the clarification. i'd be glad to help, but i doubt
> > > i could meet the coding standards of alsa-lib. at least i could
> > > help test it. do you or anyone of the alsa core developers have
> > > plans to tackle this some time soon ? i'd love to be able to
> > > use my controller box for the LinuxTag presentations in
> > > mid-July.
> >
> > I am working on it right now, but it requires to add new states
> > to sequencer event encoder...
>
> Initial code is in CVS. It is not tested, but hopefully, without
> any major bugs.

Does this code remove the (N)RPN related CC events, or does it just 
decode (N)RNPs in parallel? The latter will cause (N)RPNs to be 
doubled in apps that understand both "raw" CCs and cooked (N)RPNs. 
(Like Audiality as of a few minutes back.)

I think filtering the CCs out is the Right Thing(TM) to do when 
(N)RPNs are actually used, but if some apps want to use the full 
range of "raw" CCs, that won't work. Those apps won't see the (N)RPN 
related CCs, and they won't look for (NON)REGPARAM events. (Even if 
they did, they wouldn't be able to extract the underlying CCs 
reliably.)

Maybe ALSA shouldn't mess with (N)RPNs at all, unless applications ask 
for it?


> It seems that we have also missing encoding of
> CONTROL14 events.

Now *that's* fun stuff... *heh*

BTW, I think "applications might know better" applies here too. Apps 
that want to bother with 14 bit controls might do stuff that's 
intimately tied to the control intperpolation/smoothing. The only 
"correct" way to implement 14 bit CCs seems to involve a timeout, 
which will add latency to all CCs that can be 14 bit, and apps that 
want to be smart about it to reduce latency may not be able to do so 
without getting at the raw CCs.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
> 
> 
>>>thanks for the clarification. i'd be glad to help, but i doubt i could 
>>>meet the coding standards of alsa-lib. at least i could help test it.
>>>do you or anyone of the alsa core developers have plans to tackle this 
>>>some time soon ? i'd love to be able to use my controller box for the 
>>>LinuxTag presentations in mid-July.
>>
>>I am working on it right now, but it requires to add new states to 
>>sequencer event encoder...
> 
> 
> Initial code is in CVS. It is not tested, but hopefully, without any major 
> bugs. It seems that we have also missing encoding of CONTROL14 events.

rats. sourceforge is soooo broken. it's a great service they have 
provided, but if they go belly up, most of open-source development 
grinds to a halt... :(

whatever. thanks very much, jaroslav!

i'm checking it out as i type (the umpteenth attempt succeeded at last)...

regards,

jörn


-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)







-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
> 
> 
>>>thanks for the clarification. i'd be glad to help, but i doubt i could 
>>>meet the coding standards of alsa-lib. at least i could help test it.
>>>do you or anyone of the alsa core developers have plans to tackle this 
>>>some time soon ? i'd love to be able to use my controller box for the 
>>>LinuxTag presentations in mid-July.
>>
>>I am working on it right now, but it requires to add new states to 
>>sequencer event encoder...
> 
> 
> Initial code is in CVS. It is not tested, but hopefully, without any major 
> bugs. It seems that we have also missing encoding of CONTROL14 events.
> 
> 						Jaroslav

shit. anon cvs seems to be lagging behind. do you happen to have a patch 
? otherwise it will probably be another day before i can test it...





-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)







-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

On Mon, 16 Jun 2003, David Olofson wrote:

> On Monday 16 June 2003 13.19, Jaroslav Kysela wrote:
> > On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
> > > > thanks for the clarification. i'd be glad to help, but i doubt
> > > > i could meet the coding standards of alsa-lib. at least i could
> > > > help test it. do you or anyone of the alsa core developers have
> > > > plans to tackle this some time soon ? i'd love to be able to
> > > > use my controller box for the LinuxTag presentations in
> > > > mid-July.
> > >
> > > I am working on it right now, but it requires to add new states
> > > to sequencer event encoder...
> >
> > Initial code is in CVS. It is not tested, but hopefully, without
> > any major bugs.
> 
> Does this code remove the (N)RPN related CC events, or does it just 
> decode (N)RNPs in parallel? The latter will cause (N)RPNs to be 
> doubled in apps that understand both "raw" CCs and cooked (N)RPNs. 
> (Like Audiality as of a few minutes back.)
> 
> I think filtering the CCs out is the Right Thing(TM) to do when 
> (N)RPNs are actually used, but if some apps want to use the full 
> range of "raw" CCs, that won't work. Those apps won't see the (N)RPN 
> related CCs, and they won't look for (NON)REGPARAM events. (Even if 
> they did, they wouldn't be able to extract the underlying CCs 
> reliably.)
> 
> Maybe ALSA shouldn't mess with (N)RPNs at all, unless applications ask 
> for it?

I think that events are clear, so all applications using direct 
sequencer API should handle them as well.

> > It seems that we have also missing encoding of
> > CONTROL14 events.
> 
> Now *that's* fun stuff... *heh*
> 
> BTW, I think "applications might know better" applies here too. Apps 
> that want to bother with 14 bit controls might do stuff that's 
> intimately tied to the control intperpolation/smoothing. The only 
> "correct" way to implement 14 bit CCs seems to involve a timeout, 
> which will add latency to all CCs that can be 14 bit, and apps that 
> want to be smart about it to reduce latency may not be able to do so 
> without getting at the raw CCs.

Yes, Paul mentioned it and I see that the standard is not so good. Does it 
affect also XRPN encoding (some LSB or MSB bytes might be missing)?
In that case the current implementation is broken.

I see some ways to do things correctly:

1) duplicate events (deliver both raw CONTROLLER + combo events)
2) do not generate combo events at all, use only raw controller events
3) introduce timeouts (I hate this idea)

I will stay with 2) for the moment (so nothing will change).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[Jaroslav Kysela]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1028 bytes --]

On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:

> Jaroslav Kysela wrote:
> > On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
> > 
> > 
> >>>thanks for the clarification. i'd be glad to help, but i doubt i could 
> >>>meet the coding standards of alsa-lib. at least i could help test it.
> >>>do you or anyone of the alsa core developers have plans to tackle this 
> >>>some time soon ? i'd love to be able to use my controller box for the 
> >>>LinuxTag presentations in mid-July.
> >>
> >>I am working on it right now, but it requires to add new states to 
> >>sequencer event encoder...
> > 
> > 
> > Initial code is in CVS. It is not tested, but hopefully, without any major 
> > bugs. It seems that we have also missing encoding of CONTROL14 events.
> > 
> > 						Jaroslav
> 
> shit. anon cvs seems to be lagging behind. do you happen to have a patch 
> ? otherwise it will probably be another day before i can test it...

Attached.

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs

[-- Attachment #2: Type: TEXT/plain, Size: 8311 bytes --]

Index: seq_midi_event.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/seq_midi_event.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- seq_midi_event.h	19 Apr 2002 17:29:59 -0000	1.4
+++ seq_midi_event.h	16 Jun 2003 11:19:12 -0000	1.5
@@ -30,13 +30,14 @@
 
 /* midi status */
 struct snd_midi_event_t {
-	int qlen;	/* queue length */
-	int read;	/* chars read */
-	int type;	/* current event type */
+	int qlen;		/* queue length */
+	int read;		/* chars read */
+	int type;		/* current event type */
 	unsigned char lastcmd;
 	unsigned char nostat;
+	unsigned char xreg_hit;
 	int bufsize;
-	unsigned char *buf; /* input buffer */
+	unsigned char *buf;	/* input buffer */
 	spinlock_t lock;
 };
 
Index: seq_midi_event.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_midi_event.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- seq_midi_event.c	31 Jan 2003 15:19:34 -0000	1.10
+++ seq_midi_event.c	16 Jun 2003 11:19:12 -0000	1.11
@@ -36,9 +36,11 @@
 /* from 0 to 7 are normal commands (note off, on, etc.) */
 #define ST_NOTEOFF	0
 #define ST_NOTEON	1
+#define ST_CONTROLLER	3
 #define ST_SPECIAL	8
 #define ST_SYSEX	ST_SPECIAL
 /* from 8 to 15 are events for 0xf0-0xf7 */
+#define ST_XREG_PARM	16
 
 
 /* status event types */
@@ -54,6 +56,8 @@
 static void two_param_ctrl_event(snd_midi_event_t *dev, snd_seq_event_t *ev);
 static void one_param_event(snd_midi_event_t *dev, snd_seq_event_t *ev);
 static void songpos_event(snd_midi_event_t *dev, snd_seq_event_t *ev);
+static unsigned char get_xreg_hit_bit(unsigned char c);
+static void xreg_event(snd_midi_event_t *dev, snd_seq_event_t *ev);
 static void note_decode(snd_seq_event_t *ev, unsigned char *buf);
 static void one_param_decode(snd_seq_event_t *ev, unsigned char *buf);
 static void pitchbend_decode(snd_seq_event_t *ev, unsigned char *buf);
@@ -98,14 +102,15 @@
 };
 
 static int extra_decode_ctrl14(snd_midi_event_t *dev, unsigned char *buf, int len, snd_seq_event_t *ev);
+static int extra_decode_xrpn(snd_midi_event_t *dev, unsigned char *buf, int len, snd_seq_event_t *ev);
 
 static struct extra_event_list_t {
 	int event;
 	int (*decode)(snd_midi_event_t *dev, unsigned char *buf, int len, snd_seq_event_t *ev);
 } extra_event[] = {
 	{SNDRV_SEQ_EVENT_CONTROL14, extra_decode_ctrl14},
-	/*{SNDRV_SEQ_EVENT_NONREGPARAM, extra_decode_nrpn},*/
-	/*{SNDRV_SEQ_EVENT_REGPARAM, extra_decode_rpn},*/
+	{SNDRV_SEQ_EVENT_NONREGPARAM, extra_decode_xrpn},
+	{SNDRV_SEQ_EVENT_REGPARAM, extra_decode_xrpn},
 };
 
 /*
@@ -253,11 +258,20 @@
 	spin_lock_irqsave(&dev->lock, flags);
 	if (dev->qlen > 0) {
 		/* rest of command */
+		if (c & 0x80) {		/* error? state inside data? */
+			if (dev->type == ST_XREG_PARM) {
+				if (c != dev->buf[0])
+					goto __new_command;
+				goto __end;
+			}
+			goto __new_command;
+		}
 		dev->buf[dev->read++] = c;
 		if (dev->type != ST_SYSEX)
 			dev->qlen--;
 	} else {
 		/* new command */
+	      __new_command:
 		dev->read = 1;
 		if (c & 0x80) {
 			dev->buf[0] = c;
@@ -273,13 +287,42 @@
 		}
 	}
 	if (dev->qlen == 0) {
+		/* handle xrpn special case here */
+		if (dev->type == ST_CONTROLLER &&
+		    dev->buf[1] >= MIDI_CTL_NONREG_PARM_NUM_LSB &&
+		    dev->buf[1] <= MIDI_CTL_REGIST_PARM_NUM_MSB) {
+		    	dev->type = ST_XREG_PARM;
+		    	dev->xreg_hit = get_xreg_hit_bit(dev->buf[1]);
+		    	dev->qlen = 2;		/* we need more bytes */
+			goto __end;
+		}
+		if (dev->type == ST_XREG_PARM) {
+			rc = get_xreg_hit_bit(dev->buf[1]);
+			if (rc == 0 || (rc & dev->xreg_hit)) {
+				reset_encode(dev);
+				dev->type = ST_CONTROLLER;
+				dev->read = 1;
+				rc = 0;
+				goto __end;
+			}
+			dev->xreg_hit |= rc;
+			if (dev->xreg_hit == 0x0f) {	/* finished */
+				xreg_event(dev, ev);
+				rc = 1;
+				goto __end;
+			}
+			dev->qlen = 2;		/* we need more bytes */
+			rc = 0;
+			goto __end;
+		}
+		/* handle standard midi events */
 		ev->type = status_event[dev->type].event;
 		ev->flags &= ~SNDRV_SEQ_EVENT_LENGTH_MASK;
 		ev->flags |= SNDRV_SEQ_EVENT_LENGTH_FIXED;
 		if (status_event[dev->type].encode) /* set data values */
 			status_event[dev->type].encode(dev, ev);
 		rc = 1;
-	} else 	if (dev->type == ST_SYSEX) {
+	} else if (dev->type == ST_SYSEX) {
 		if (c == MIDI_CMD_COMMON_SYSEX_END ||
 		    dev->read >= dev->bufsize) {
 			ev->flags &= ~SNDRV_SEQ_EVENT_LENGTH_MASK;
@@ -295,6 +338,7 @@
 		}
 	}
 
+      __end:
 	spin_unlock_irqrestore(&dev->lock, flags);
 	return rc;
 }
@@ -341,6 +385,44 @@
 	ev->data.control.value = (int)dev->buf[2] * 128 + (int)dev->buf[1];
 }
 
+static unsigned char get_xreg_hit_bit(unsigned char c)
+{
+	switch (c) {
+	case MIDI_CTL_NONREG_PARM_NUM_MSB:
+	case MIDI_CTL_REGIST_PARM_NUM_MSB:
+		return 1;
+	case MIDI_CTL_NONREG_PARM_NUM_LSB:
+	case MIDI_CTL_REGIST_PARM_NUM_LSB:
+		return 2;
+	case MIDI_CTL_MSB_DATA_ENTRY:
+		return 4;
+	case MIDI_CTL_LSB_DATA_ENTRY:
+		return 8;
+	default:
+		return 0;
+	}
+}
+
+/* encode xreg event */
+static void xreg_event(snd_midi_event_t *dev, snd_seq_event_t *ev)
+{
+	int i;
+
+	ev->type = (dev->buf[1] == MIDI_CTL_NONREG_PARM_NUM_MSB ||
+		    dev->buf[1] == MIDI_CTL_NONREG_PARM_NUM_LSB) ?
+		    SNDRV_SEQ_EVENT_NONREGPARAM : SNDRV_SEQ_EVENT_REGPARAM;		
+	ev->data.control.param = 0;
+	ev->data.control.value = 0;
+	for (i = 1; i < 9; i += 2) {
+		switch (get_xreg_hit_bit(dev->buf[i])) {
+		case 1: ev->data.control.param |= dev->buf[i+1] << 7;	break;
+		case 2: ev->data.control.param |= dev->buf[i+1];	break;
+		case 4: ev->data.control.value |= dev->buf[i+1] << 7;	break;
+		case 8: ev->data.control.value |= dev->buf[i+1];	break;
+		}
+	}
+}
+
 /*
  * decode from a sequencer event to midi bytes
  * return the size of decoded midi events
@@ -441,12 +523,12 @@
 	unsigned char cmd;
 	int idx = 0;
 
+	cmd = MIDI_CMD_CONTROL|(ev->data.control.channel & 0x0f);
 	if (ev->data.control.param < 32) {
 		if (count < 4)
 			return -ENOMEM;
 		if (dev->nostat && count < 6)
 			return -ENOMEM;
-		cmd = MIDI_CMD_CONTROL|(ev->data.control.channel & 0x0f);
 		if (cmd != dev->lastcmd || dev->nostat) {
 			if (count < 5)
 				return -ENOMEM;
@@ -458,11 +540,9 @@
 			buf[idx++] = cmd;
 		buf[idx++] = ev->data.control.param + 32;
 		buf[idx++] = ev->data.control.value & 0x7f;
-		return idx;
 	} else {
 		if (count < 2)
 			return -ENOMEM;
-		cmd = MIDI_CMD_CONTROL|(ev->data.control.channel & 0x0f);
 		if (cmd != dev->lastcmd || dev->nostat) {
 			if (count < 3)
 				return -ENOMEM;
@@ -470,8 +550,48 @@
 		}
 		buf[idx++] = ev->data.control.param & 0x7f;
 		buf[idx++] = ev->data.control.value & 0x7f;
-		return idx;
 	}
+	return idx;
+}
+
+/* decode reg/nonreg param */
+static int extra_decode_xrpn(snd_midi_event_t *dev, unsigned char *buf, int count, snd_seq_event_t *ev)
+{
+	unsigned char cmd;
+	char *cbytes;
+	static char cbytes_nrpn[4] = { MIDI_CTL_NONREG_PARM_NUM_MSB,
+				       MIDI_CTL_NONREG_PARM_NUM_LSB,
+				       MIDI_CTL_MSB_DATA_ENTRY,
+				       MIDI_CTL_LSB_DATA_ENTRY };
+	static char cbytes_rpn[4] =  { MIDI_CTL_REGIST_PARM_NUM_MSB,
+				       MIDI_CTL_REGIST_PARM_NUM_LSB,
+				       MIDI_CTL_MSB_DATA_ENTRY,
+				       MIDI_CTL_LSB_DATA_ENTRY };
+	unsigned char bytes[4];
+	int idx = 0, i;
+
+	if (count < 8)
+		return -ENOMEM;
+	if (dev->nostat && count < 12)
+		return -ENOMEM;
+	cmd = MIDI_CMD_CONTROL|(ev->data.control.channel & 0x0f);
+	bytes[0] = ev->data.control.param & 0x007f;
+	bytes[1] = (ev->data.control.param & 0x3f80) >> 7;
+	bytes[2] = ev->data.control.value & 0x007f;
+	bytes[3] = (ev->data.control.value & 0x3f80) >> 7;
+	if (cmd != dev->lastcmd && !dev->nostat) {
+		if (count < 9)
+			return -ENOMEM;
+		buf[idx++] = dev->lastcmd = cmd;
+	}
+	cbytes = ev->type == SNDRV_SEQ_EVENT_NONREGPARAM ? cbytes_nrpn : cbytes_rpn;
+	for (i = 0; i < 4; i++) {
+		if (dev->nostat)
+			buf[idx++] = dev->lastcmd = cmd;
+		buf[idx++] = cbytes[i];
+		buf[idx++] = bytes[i];
+	}
+	return idx;
 }
 
 /*

Re: sequencer: handling non-registered parameter numbers....

[Paul Davis]

>Yes, Paul mentioned it and I see that the standard is not so good. Does it 
>affect also XRPN encoding (some LSB or MSB bytes might be missing)?
>In that case the current implementation is broken.

now that i think about it, i recall what i realized was the MIDI
spec's intent: you are supposed to be stateful when parsing 14 bit
controls. you always know the most recent MSnibble, and so when the
new LSnibble comes in, you just merge them. libmidi++ does this
already. the problem remains that you can't provide "atomic" access to
the controller state: if it changes so that both the high and low
nibbles need to be transmitted, an application can end up seeing it in
the intermediate, undefined state where the LSnibble has been updated,
but not the MSnibble.

hence the timeouts needed to be able to delay updating the LSnibble so
that you can be sure no pending change to the MSnibble is coming.

--p




-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: sequencer: handling non-registered parameter numbers....

[David Olofson]

On Monday 16 June 2003 18.03, Jaroslav Kysela wrote:
[...]
> > Maybe ALSA shouldn't mess with (N)RPNs at all, unless
> > applications ask for it?
>
> I think that events are clear, so all applications using direct
> sequencer API should handle them as well.

Yes, that's a point... However, if ALSA intercepts the underlying CCs 
for (N)RPNs, there is no way to use them as normal CCs by just 
looking at the (NON)REGPARAM events. For examyple, if something sends 
only CC 98 ("NRPN fine"), the app will get nothing.


[...14 bit controls...]
> Yes, Paul mentioned it and I see that the standard is not so good.
> Does it affect also XRPN encoding (some LSB or MSB bytes might be
> missing)?

Well, the "Data Entry" CC pair *is* one of those ugly 14 bit things.


> In that case the current implementation is broken.

That goes for Audiality too. Dunno if I care, because I can't really 
do anything useful with 7 bit values anyway. I just store the other 
CC values and act on CC 38 ("Data Entry (fine)").

I think people would expect ALSA to do the Right Thing, though - 
whatever that is....


> I see some ways to do things correctly:
>
> 1) duplicate events (deliver both raw CONTROLLER + combo events)
> 2) do not generate combo events at all, use only raw controller
> events
> 3) introduce timeouts (I hate this idea)

Unless I'm mistaken about the (N)RPNs being normal 14 bit controllers, 
1) would require timeouts as well - although it would allow 
applications to bypass them by grabbing the raw CCs instead.

Either way, if that timeout isn't part of the spec, there is no way of 
implementing this correcly. You can't wait forever, and it's not safe 
to set it short and let occasional wrong values through. :-/


> I will stay with 2) for the moment (so nothing will change).

Ok.


BTW, what about apps sending (NON)REGPARAM events? Is it possible, and 
if so, are they converted into CCs even when passed directly to other 
ALSA sequencer apps?


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: sequencer: handling non-registered parameter numbers....

[Joern Nettingsmeier]

Jaroslav Kysela wrote:
> On Mon, 16 Jun 2003, Joern Nettingsmeier wrote:
> 
> 
>>Jaroslav Kysela wrote:
>>
>>>On Mon, 16 Jun 2003, Jaroslav Kysela wrote:
>>>
>>>
>>>
>>>>>thanks for the clarification. i'd be glad to help, but i doubt i could 
>>>>>meet the coding standards of alsa-lib. at least i could help test it.
>>>>>do you or anyone of the alsa core developers have plans to tackle this 
>>>>>some time soon ? i'd love to be able to use my controller box for the 
>>>>>LinuxTag presentations in mid-July.
>>>>
>>>>I am working on it right now, but it requires to add new states to 
>>>>sequencer event encoder...
>>>
>>>
>>>Initial code is in CVS. It is not tested, but hopefully, without any major 
>>>bugs. It seems that we have also missing encoding of CONTROL14 events.
>>>
>>>						Jaroslav
>>
>>shit. anon cvs seems to be lagging behind. do you happen to have a patch 
>>? otherwise it will probably be another day before i can test it...
> 
> 
> Attached.

hi jaroslav !

i've read and tried to understand the patch... now since this is against 
alsa-core, how am i supposed to test it, since it's not in alsa-lib ?
i read some files in alsa-lib, and it seems a lot of code in alsa-core 
is duplicated there. i played around a bit, but i couldn't figure out 
how to make the new alsa-core functions available to alsa-lib...

is there some (dirty) way to use the alsa-core api directly for testing?
(sorry for such elementary questions, but i'm really green and alsa is a 
frightening thing for beginners :)

btw, current (anonymous) cvs is broken, there are a number of warnings 
related to alsa-kernel/core/seq/seq_midi_event.c and the nrpn functions...

best regards,

jörn


-- 
All Members shall refrain in their international relations from
the threat or use of force against the territorial integrity or
political independence of any state, or in any other manner
inconsistent with the Purposes of the United Nations.
	-- Charter of the United Nations, Article 2.4


Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)






-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php