porting 0.5 to 0.9 app

porting 0.5 to 0.9 app

[Luc Tanguay]

Hello,

I'm in the process of porting a 0.5.x app to 0.9.x.  The application is 
Soundtracker.  In this GTK app, I was able to retrieve the file 
descriptor using the 'snd_seq_file_descriptor' function.  The file 
descriptor was then used to establish a callback to process MIDI events. 
 To code looks like:

midi_file_tag = gdk_input_add( snd_seq_file_descriptor( midi_handle),
                 GDK_INPUT_READ,
                 (GdkInputFunction)midi_in_cb,
                 midi_handle);

How do I do the same thing with the new ALSA 0.9.x API ?

thanks


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: porting 0.5 to 0.9 app

[Paul Davis]

>I'm in the process of porting a 0.5.x app to 0.9.x.  The application is 
>Soundtracker.  In this GTK app, I was able to retrieve the file 
>descriptor using the 'snd_seq_file_descriptor' function.  The file 
>descriptor was then used to establish a callback to process MIDI events. 
> To code looks like:
>
>midi_file_tag = gdk_input_add( snd_seq_file_descriptor( midi_handle),
>                 GDK_INPUT_READ,
>                 (GdkInputFunction)midi_in_cb,
>                 midi_handle);
>
>How do I do the same thing with the new ALSA 0.9.x API ?

its very similar, but there may be more than 1 file descriptor
associated with the handle, and the function fills out a pollfd
struct instead of giving you fd's directly. so, try:
	
	include <poll.h>

	struct pollfd *pfd;
	int limit;

	/* find out how many descriptors there are */
	
	limit = snd_seq_poll_descriptors_count(seq_handle); 
	pfd = (struct pollfd *) malloc (sizeof (struct pollfd) * limit);

	/* now get the file descriptors */
	
	snd_seq_poll_descriptors (seq_handle, pfd, limit)

	/* now use pfd[0..limit-1] as desired */

	midi_file_tag = gdk_input_add(pfd[0].fd,
	                 GDK_INPUT_READ,
			 (GdkInputFunction)midi_in_cb,
			 midi_handle);

obviously, if `limit' > 1, the code becomes more complex for hooking
into a GUI event loop, but its not that hard, and in almost every
case, it will be 1. you must check the value, however: it could be <> 1.

--p











_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: porting 0.5 to 0.9 app

[Paul Davis]

>I'm in the process of porting a 0.5.x app to 0.9.x.  The application is 
>Soundtracker.  In this GTK app, I was able to retrieve the file 
>descriptor using the 'snd_seq_file_descriptor' function.  The file 
>descriptor was then used to establish a callback to process MIDI events. 

btw, i wanted to note that this is a poor design. using a GUI event
loop to process real-time MIDI input subjects the MIDI data to
theoretically unbounded delays before it is processed. you should be
handling MIDI input in its own thread, ideally. using the sequencer
with timestamps makes things a bit better, but its still not ideal.

--p

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net

Re: porting 0.5 to 0.9 app

[Luc Tanguay]

Paul Davis wrote:

>>I'm in the process of porting a 0.5.x app to 0.9.x.  The application is 
>>Soundtracker.  In this GTK app, I was able to retrieve the file 
>>descriptor using the 'snd_seq_file_descriptor' function.  The file 
>>descriptor was then used to establish a callback to process MIDI events. 
>>
>
>btw, i wanted to note that this is a poor design. using a GUI event
>loop to process real-time MIDI input subjects the MIDI data to
>theoretically unbounded delays before it is processed. you should be
>handling MIDI input in its own thread, ideally. using the sequencer
>with timestamps makes things a bit better, but its still not ideal.
>
I don't think it's poor design... It's no design at all :-)  Anyway 
thanks for the hint.  I'll see what I can do but can you explain more on 
why using the seq. with timestamps would make things better.  ALSA 
documentation for sequencer is so thin (or I need more hours in a day) 
that it is difficult to get the idea on where it is going (client, 
subscription, port, event, etc.).  I don't have the time to read source 
code of other programs to understand how ALSA could be use in my own 
project and knowing the names of every function and parameters available 
in the library won't do no good.  

Luc


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net