rawmidi

rawmidi

[Patrick Dumais]

I noticed that some drivers tend to send "batch" note-on commands. I mean:
instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
just 02,7f etc... It sends the noteon command only once and assumes that
your application will set itself in a "noteon receive" mode. This is very
annoying because my application expects to receive a command byte each
time. the emu10k1 driver doesn't do that, but snd-virmidi does.

I'm using virmidi because I want 2 apps to read my sbLive midi port. I
aconnect this port to 2 virmidi ports then my apps read from those ports.

Is there any way that I can configure virmidi so that it sends commands
the conventional way, or any other way that I could have 2 applications
reading on the same midi port? (using the alsa sequencer interface is not
an alternative method that I want to consider for the scope of my
applications)

Thanks,
Patrick Dumais
****************************
http://www.dumaisnet.ca:242/


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: rawmidi

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

At Fri, 8 Oct 2004 11:26:39 -0400 (EDT),
Patrick Dumais wrote:
> 
> I noticed that some drivers tend to send "batch" note-on commands. I mean:
> instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
> just 02,7f etc... It sends the noteon command only once and assumes that
> your application will set itself in a "noteon receive" mode. This is very
> annoying because my application expects to receive a command byte each
> time. the emu10k1 driver doesn't do that, but snd-virmidi does.

Yes, virmidi reduces the command byte when the identical
running-status is kept.

Note that this is the correct MIDI implementation.  Many devices
output in this way (although many don't).


> I'm using virmidi because I want 2 apps to read my sbLive midi port. I
> aconnect this port to 2 virmidi ports then my apps read from those ports.
> 
> Is there any way that I can configure virmidi so that it sends commands
> the conventional way, or any other way that I could have 2 applications
> reading on the same midi port? (using the alsa sequencer interface is not
> an alternative method that I want to consider for the scope of my
> applications)

The attached (untested) patch will add no_status option to snd-virmidi
module.  When this is set to 1, the running-status is always output as
you like.

But, again, reducing the identical running-status is the feature of
MIDI byte stream.  Your app should really handle it.


Takashi

[-- Attachment #2: Type: text/plain, Size: 2488 bytes --]

Index: alsa-kernel/core/seq/seq_virmidi.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/seq/seq_virmidi.c,v
retrieving revision 1.12
diff -u -r1.12 seq_virmidi.c
--- alsa-kernel/core/seq/seq_virmidi.c	29 Jun 2004 16:01:14 -0000	1.12
+++ alsa-kernel/core/seq/seq_virmidi.c	8 Oct 2004 15:48:46 -0000
@@ -212,6 +212,8 @@
 		kfree(vmidi);
 		return -ENOMEM;
 	}
+	if (rdev->flags & SNDRV_VIRMIDI_NO_STATUS)
+		snd_midi_event_no_status(vmidi->parser, 1);
 	vmidi->seq_mode = rdev->seq_mode;
 	vmidi->client = rdev->client;
 	vmidi->port = rdev->port;	
Index: alsa-kernel/drivers/virmidi.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/drivers/virmidi.c,v
retrieving revision 1.12
diff -u -r1.12 virmidi.c
--- alsa-kernel/drivers/virmidi.c	30 Jun 2004 14:20:20 -0000	1.12
+++ alsa-kernel/drivers/virmidi.c	8 Oct 2004 15:47:03 -0000
@@ -65,6 +65,7 @@
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;	/* ID for this card */
 static int enable[SNDRV_CARDS] = {1, [1 ... (SNDRV_CARDS - 1)] = 0};
 static int midi_devs[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 4};
+static int no_status[SNDRV_CARDS];
 static int boot_devs;
 
 module_param_array(index, int, boot_devs, 0444);
@@ -75,6 +76,8 @@
 MODULE_PARM_DESC(enable, "Enable this soundcard.");
 module_param_array(midi_devs, int, boot_devs, 0444);
 MODULE_PARM_DESC(midi_devs, "MIDI devices # (1-8)");
+module_param_array(no_status, int, boot_devs, 0444);
+MODULE_PARM_DESC(no_status, "Add running-status always.");
 
 typedef struct snd_card_virmidi {
 	snd_card_t *card;
@@ -109,6 +112,8 @@
 		if ((err = snd_virmidi_new(card, idx, &rmidi)) < 0)
 			goto __nodev;
 		rdev = rmidi->private_data;
+		if (no_status[dev])
+			rdev->flags |= SNDRV_VIRMIDI_NO_STATUS;
 		vmidi->midi[idx] = rmidi;
 		strcpy(rmidi->name, "Virtual Raw MIDI");
 		rdev->seq_mode = SNDRV_VIRMIDI_SEQ_DISPATCH;
Index: alsa-kernel/include/seq_virmidi.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/seq_virmidi.h,v
retrieving revision 1.3
diff -u -r1.3 seq_virmidi.h
--- alsa-kernel/include/seq_virmidi.h	4 Jul 2002 09:41:50 -0000	1.3
+++ alsa-kernel/include/seq_virmidi.h	8 Oct 2004 15:46:42 -0000
@@ -47,6 +47,7 @@
 
 #define SNDRV_VIRMIDI_SUBSCRIBE		(1<<0)
 #define SNDRV_VIRMIDI_USE		(1<<1)
+#define SNDRV_VIRMIDI_NO_STATUS		(1<<2)
 
 /*
  * device record:

RE: rawmidi

[Steve DeRosier]

Patrick,

The "batch" mode that you're seeing is called "running status" by the MIDI STANDARD.  It is standard MIDI that any MIDI device or application really needs to support.  It's not just the drivers that are sending it, but almost any device will send data in that format usually.

I know that doesn't answer your specific question on how to adjust ALSA, but the last thing needed is yet another device or application that doesn't fit the MIDI standard yet dares to say it supports MIDI.

Implementation is not hard, you just need to write your MIDI parser so it keeps track of if it's in running status, what the most recent status byte was, and watch for new status bytes.

On the other hand, if your application is sending output to the drivers of only say "0x90 0x01 0x7F" and the driver output is "0x90 0x01 0x7F 0x02 0x7F" then there really is a problem with the drivers and that should be fixed.

- Steve


-----Original Message-----
From: Patrick Dumais [mailto:pat@dumaisnet.ca]
Sent: Friday, October 08, 2004 8:27 AM
To: alsa-devel@lists.sourceforge.net
Subject: [Alsa-devel] rawmidi



I noticed that some drivers tend to send "batch" note-on commands. I mean:
instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
just 02,7f etc... It sends the noteon command only once and assumes that
your application will set itself in a "noteon receive" mode. This is very
annoying because my application expects to receive a command byte each
time. the emu10k1 driver doesn't do that, but snd-virmidi does.

I'm using virmidi because I want 2 apps to read my sbLive midi port. I
aconnect this port to 2 virmidi ports then my apps read from those ports.

Is there any way that I can configure virmidi so that it sends commands
the conventional way, or any other way that I could have 2 applications
reading on the same midi port? (using the alsa sequencer interface is not
an alternative method that I want to consider for the scope of my
applications)

Thanks,
Patrick Dumais
****************************
http://www.dumaisnet.ca:242/


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: rawmidi

[Clemens Ladisch]

Patrick Dumais wrote:
> I noticed that some drivers tend to send "batch" note-on commands. I mean:
> instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
> just 02,7f etc...

This is running status.  It is used with all status bytes, not only
note-on commands.

> This is very annoying because my application expects to receive a
> command byte each time.

Running status is a required feature of the MIDI specification.  Your
application must be able to handle this.

> the emu10k1 driver doesn't do that, but snd-virmidi does.

The MIDI device connected to your card doesn't do that.

> Is there any way that I can configure virmidi so that it sends commands
> the conventional way,

You'd have to insert a call to snd_midi_event_no_status() at the
appropriate place in virmidi.c.

> using the alsa sequencer interface is not an alternative method
> that I want to consider for the scope of my applications

Using the sequencer is recommended if you don't want to deal with the
raw MIDI data.


Regards,
Clemens



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

RE: rawmidi

[Patrick Dumais]

no that was just an example I did, it sends the stream correctly.

I didnt know that this was the standard. I understand completely why my
app should support running status so i'll implement it. It's not that hard
after all. but about that:

does this "running status" apply only on noteon/off events or on
controls too? should I only be keeping track of 90h commands?

Thanks a lot for your answers

Patrick Dumais
****************************
http://www.dumaisnet.ca:242/

On Fri, 8 Oct 2004, Steve DeRosier wrote:

> Date: Fri, 8 Oct 2004 09:12:25 -0700
> From: Steve DeRosier <derosier@pianodisc.com>
> To: pat@dumaisnet.ca, alsa-devel@lists.sourceforge.net
> Subject: RE: [Alsa-devel] rawmidi
>
> Patrick,
>
> The "batch" mode that you're seeing is called "running status" by the MIDI STANDARD.  It is standard MIDI that any MIDI device or application really needs to support.  It's not just the drivers that are sending it, but almost any device will send data in that format usually.
>
> I know that doesn't answer your specific question on how to adjust ALSA, but the last thing needed is yet another device or application that doesn't fit the MIDI standard yet dares to say it supports MIDI.
>
> Implementation is not hard, you just need to write your MIDI parser so it keeps track of if it's in running status, what the most recent status byte was, and watch for new status bytes.
>
> On the other hand, if your application is sending output to the drivers of only say "0x90 0x01 0x7F" and the driver output is "0x90 0x01 0x7F 0x02 0x7F" then there really is a problem with the drivers and that should be fixed.
>
> - Steve
>
>
> -----Original Message-----
> From: Patrick Dumais [mailto:pat@dumaisnet.ca]
> Sent: Friday, October 08, 2004 8:27 AM
> To: alsa-devel@lists.sourceforge.net
> Subject: [Alsa-devel] rawmidi
>
>
>
> I noticed that some drivers tend to send "batch" note-on commands. I mean:
> instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
> just 02,7f etc... It sends the noteon command only once and assumes that
> your application will set itself in a "noteon receive" mode. This is very
> annoying because my application expects to receive a command byte each
> time. the emu10k1 driver doesn't do that, but snd-virmidi does.
>
> I'm using virmidi because I want 2 apps to read my sbLive midi port. I
> aconnect this port to 2 virmidi ports then my apps read from those ports.
>
> Is there any way that I can configure virmidi so that it sends commands
> the conventional way, or any other way that I could have 2 applications
> reading on the same midi port? (using the alsa sequencer interface is not
> an alternative method that I want to consider for the scope of my
> applications)
>
> Thanks,
> Patrick Dumais
> ****************************
> http://www.dumaisnet.ca:242/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

RE: rawmidi

[Steve DeRosier]

Many (most) of the status bytes can be used in running status.  The exceptions that I know about are the 0xF* messages.  I'd say the critical ones would be 0x80, 0x90, and 0xB0 (pedal controler messages are in here).  Probably the 0xA0 and 0xC0 too, but I'm not as sure about those and I don't happen to have a copy of the MIDI spec at my home office to refer to, maybe someone who's got access to one can check for you.

- Steve


-----Original Message-----
From: Patrick Dumais [mailto:pat@dumaisnet.ca]
Sent: Friday, October 08, 2004 9:21 AM
To: Steve DeRosier
Cc: alsa-devel@lists.sourceforge.net
Subject: RE: [Alsa-devel] rawmidi



no that was just an example I did, it sends the stream correctly.

I didnt know that this was the standard. I understand completely why my
app should support running status so i'll implement it. It's not that hard
after all. but about that:

does this "running status" apply only on noteon/off events or on
controls too? should I only be keeping track of 90h commands?

Thanks a lot for your answers

Patrick Dumais
****************************
http://www.dumaisnet.ca:242/

On Fri, 8 Oct 2004, Steve DeRosier wrote:

> Date: Fri, 8 Oct 2004 09:12:25 -0700
> From: Steve DeRosier <derosier@pianodisc.com>
> To: pat@dumaisnet.ca, alsa-devel@lists.sourceforge.net
> Subject: RE: [Alsa-devel] rawmidi
>
> Patrick,
>
> The "batch" mode that you're seeing is called "running status" by the MIDI STANDARD.  It is standard MIDI that any MIDI device or application really needs to support.  It's not just the drivers that are sending it, but almost any device will send data in that format usually.
>
> I know that doesn't answer your specific question on how to adjust ALSA, but the last thing needed is yet another device or application that doesn't fit the MIDI standard yet dares to say it supports MIDI.
>
> Implementation is not hard, you just need to write your MIDI parser so it keeps track of if it's in running status, what the most recent status byte was, and watch for new status bytes.
>
> On the other hand, if your application is sending output to the drivers of only say "0x90 0x01 0x7F" and the driver output is "0x90 0x01 0x7F 0x02 0x7F" then there really is a problem with the drivers and that should be fixed.
>
> - Steve
>
>
> -----Original Message-----
> From: Patrick Dumais [mailto:pat@dumaisnet.ca]
> Sent: Friday, October 08, 2004 8:27 AM
> To: alsa-devel@lists.sourceforge.net
> Subject: [Alsa-devel] rawmidi
>
>
>
> I noticed that some drivers tend to send "batch" note-on commands. I mean:
> instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
> just 02,7f etc... It sends the noteon command only once and assumes that
> your application will set itself in a "noteon receive" mode. This is very
> annoying because my application expects to receive a command byte each
> time. the emu10k1 driver doesn't do that, but snd-virmidi does.
>
> I'm using virmidi because I want 2 apps to read my sbLive midi port. I
> aconnect this port to 2 virmidi ports then my apps read from those ports.
>
> Is there any way that I can configure virmidi so that it sends commands
> the conventional way, or any other way that I could have 2 applications
> reading on the same midi port? (using the alsa sequencer interface is not
> an alternative method that I want to consider for the scope of my
> applications)
>
> Thanks,
> Patrick Dumais
> ****************************
> http://www.dumaisnet.ca:242/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: rawmidi

[Lee Revell]

On Fri, 2004-10-08 at 11:26, Patrick Dumais wrote:
> I noticed that some drivers tend to send "batch" note-on commands. I mean:
> instead of sending 90h,01h,7Fh everytime, it sends a first 90,01,7f then
> just 02,7f etc... It sends the noteon command only once and assumes that
> your application will set itself in a "noteon receive" mode. This is very
> annoying because my application expects to receive a command byte each
> time. the emu10k1 driver doesn't do that, but snd-virmidi does.
> 
> I'm using virmidi because I want 2 apps to read my sbLive midi port. I
> aconnect this port to 2 virmidi ports then my apps read from those ports.

Why is this even necessary with ALSA?  On Windows multiple apps can just
read from the same physical MIDI port.  Is this a feature?

Lee



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: rawmidi

[Clemens Ladisch]

Steve DeRosier wrote:
> Many (most) of the status bytes can be used in running status.
> The exceptions that I know about are the 0xF* messages.  I'd say
> the critical ones would be 0x80, 0x90, and 0xB0 (pedal controler
> messages are in here).  Probably the 0xA0 and 0xC0 too, but I'm
> not as sure about those and I don't happen to have a copy of the
> MIDI spec at my home office to refer to, maybe someone who's got
> access to one can check for you.

All channel message status bytes (0x80...0xEF) can use running status.
System common messages (0xF0...0xF7) cancel any running status.
Realtime messages (0xF8...0xFF) don't affect running status and can be
inserted anywhere, even in the midst of other commands.

<http://www.borg.com/~jglatt/tech/midispec.htm>


HTH
Clemens



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Rawmidi

[Daniel Viksporre]

I cant compile example programs that use rawmidi.

When I look on my harddrive, I have many rawmidi.h files, but since
2015 they are all 0 bytes. Can that be the reason I cant compile. But
why is those files 0 bytes from the repository Im using?

I get the following error messages...


test.c:(.text+0x507): undefined reference to `snd_rawmidi_open'
test.c:(.text+0x5d8): undefined reference to `snd_rawmidi_open'
test.c:(.text+0x75e): undefined reference to `snd_rawmidi_read'
test.c:(.text+0x846): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x867): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x888): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x894): undefined reference to `snd_rawmidi_drain'
test.c:(.text+0x8c1): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x8e2): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x903): undefined reference to `snd_rawmidi_write'
test.c:(.text+0x90f): undefined reference to `snd_rawmidi_drain'
test.c:(.text+0xa71): undefined reference to `snd_rawmidi_read'
test.c:(.text+0xae0): undefined reference to `snd_rawmidi_write'
test.c:(.text+0xaec): undefined reference to `snd_rawmidi_drain'
test.c:(.text+0xb8f): undefined reference to `snd_rawmidi_drain'
test.c:(.text+0xb9b): undefined reference to `snd_rawmidi_close'
test.c:(.text+0xbaf): undefined reference to `snd_rawmidi_drain'
test.c:(.text+0xbbb): undefined reference to `snd_rawmidi_close'

Re: Rawmidi

[Takashi Sakamoto]

Hi,

On Dec 27 2015 15:29, Daniel Viksporre wrote:
> I cant compile example programs that use rawmidi.
> 
> When I look on my harddrive, I have many rawmidi.h files, but since
> 2015 they are all 0 bytes. Can that be the reason I cant compile. But
> why is those files 0 bytes from the repository Im using?
> 
> I get the following error messages...
> 
> 
> test.c:(.text+0x507): undefined reference to `snd_rawmidi_open'
> test.c:(.text+0x5d8): undefined reference to `snd_rawmidi_open'
> test.c:(.text+0x75e): undefined reference to `snd_rawmidi_read'
> test.c:(.text+0x846): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x867): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x888): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x894): undefined reference to `snd_rawmidi_drain'
> test.c:(.text+0x8c1): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x8e2): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x903): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0x90f): undefined reference to `snd_rawmidi_drain'
> test.c:(.text+0xa71): undefined reference to `snd_rawmidi_read'
> test.c:(.text+0xae0): undefined reference to `snd_rawmidi_write'
> test.c:(.text+0xaec): undefined reference to `snd_rawmidi_drain'
> test.c:(.text+0xb8f): undefined reference to `snd_rawmidi_drain'
> test.c:(.text+0xb9b): undefined reference to `snd_rawmidi_close'
> test.c:(.text+0xbaf): undefined reference to `snd_rawmidi_drain'
> test.c:(.text+0xbbb): undefined reference to `snd_rawmidi_close'

Can you show command lines to compile your 'test.c'?


Regards

Takashi Sakamoto

Re: Rawmidi

[Clemens Ladisch]

Daniel Viksporre wrote:
>test.c:(.text+0x507): undefined reference to `snd_rawmidi_open'

This message comes from the linker.

If the compiler itself does not complain, then you have no
problem with rawmidi.h.

The linker error is probably caused by not linking with the
ALSA library; add -lasound to the compiler command.


Regards,
Clemens

Re: Rawmidi

[Daniel Viksporre]

2015-12-27 9:18 GMT+01:00, Clemens Ladisch <clemens@ladisch.de>:
> Daniel Viksporre wrote:
>>test.c:(.text+0x507): undefined reference to `snd_rawmidi_open'
>
> This message comes from the linker.
>
> If the compiler itself does not complain, then you have no
> problem with rawmidi.h.
>
> The linker error is probably caused by not linking with the
> ALSA library; add -lasound to the compiler command.
>
>
> Regards,
> Clemens
>
>

I compiled with...
gcc  -lasound test.c

I have tried with many different code examples that I have found on
the internet, and error messages stays about the same.

// Daniel

Re: Rawmidi

[Takashi Sakamoto]

On Dec 28 2015 00:22, Daniel Viksporre wrote:
> 2015-12-27 9:18 GMT+01:00, Clemens Ladisch <clemens@ladisch.de>:
>> Daniel Viksporre wrote:
>>> test.c:(.text+0x507): undefined reference to `snd_rawmidi_open'
>>
>> This message comes from the linker.
>>
>> If the compiler itself does not complain, then you have no
>> problem with rawmidi.h.
>>
>> The linker error is probably caused by not linking with the
>> ALSA library; add -lasound to the compiler command.
>>
>>
>> Regards,
>> Clemens
>>
>>
> 
> I compiled with...
> gcc  -lasound test.c
> 
> I have tried with many different code examples that I have found on
> the internet, and error messages stays about the same.

I think cause is the position of linker option. Let's try:
$ gcc test.c -lasound


Regards

Takashi Sakamoto

Re: Rawmidi

[Rob van der Putten]

Hi there


Takashi Sakamoto wrote:

> I think cause is the position of linker option. Let's try:
> $ gcc test.c -lasound

On my box the snd_rawmidi_ stuff is in /usr/include/alsa/rawmidi.h
/usr/include/alsa/asoundlib.h includes alsa/rawmidi.h, so  a #include 
<alsa/asoundlib.h> in the c file should do.

I compile with cc -Wall -lasound -o foo foo.c

Hope this helps.


Regards,
Rob
-- 
ISDS is evil. Abolish ISDS.

Re: Rawmidi

[Rob van der Putten]

Hi there


Rob van der Putten wrote:

> On my box the snd_rawmidi_ stuff is in /usr/include/alsa/rawmidi.h
> /usr/include/alsa/asoundlib.h includes alsa/rawmidi.h, so a #include
> <alsa/asoundlib.h> in the c file should do.
>
> I compile with cc -Wall -lasound -o foo foo.c

Actually cc -Wall -O2 -lasound -o foo foo.c

> Hope this helps.


Regards,
Rob