From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: using the sequencer with raw byte streams? Date: Mon, 21 Jul 2003 19:27:11 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20030721171249.255CB14C36@Cantor.suse.de> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20030721171249.255CB14C36@Cantor.suse.de> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Paul Davis Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Mon, 21 Jul 2003 13:18:37 -0400, Paul Davis wrote: > > >> i'd like to find a way to connect these two abstractions together > >> somehow, since it would make Ardour play "nice" in the set of > >> sequencer clients that already exist. i can see the "RAW" event type > >> flag, which looks as if it might work for delivery data to the > >> sequencer, but i can't see any mechanism for retrieving unparsed data > >> from the system. can it be done? > > > >to send/receive raw (non-MIDI) byte streams, you can use app-dependent > >type (SND_SEQ_EVENT_USRx or SND_SEQ_EVENT_USR_VARx). > >in this case, both the receiver and the sender clients must know the > >type. the default event encoder/decoder wouldn't handle such events > >(ignored). > > no, i want to send real MIDI but I don't want to force the client of > libmidi++ to use structured events when it already has reasonably > optimized methods for its MIDI output. actually, output is not the > hard part (i could hack in some code to deal with this, even though it > would a bit ugly), its input that is problematic. i need to run the > libmidi++ parser over the raw MIDI data that is received by the Port > abstraction. as far as i can tell, the sequencer doesn't make this > available, only the structured event. for sysex, thats relatively easy > to hack around, but in general, its a problem. having the parser > handle the sysex data but using the sequencer's pre-parsed events for > non-sysex will break MIDI parsing in some cases. there are generic midi-byte encoder/decoder functions in alsa-lib. snd_midi_event_encode() (or snd_midi_event_encode_byte()) and snd_midi_event_decode() would be suitable for your purpose. maybe we can add an API to create a "virtual MIDI" device in the rawmidi form, which exactly virmidi module does but on user-space. i.e. you can open the device like snd_rawmidi_open_sequencer(&rawmidi, ...); or even like snd_rawmidi_open(&handle, "sequencer", ...); > basically, as i've said so many times before, i'd really like the > sequencer to be useful for routing (which implies queuing in some > cases), but to be able to turn off the parser or at least bypass it, > and receive raw MIDI streams on a sequencer port. well, the parsing is anyway necessary, because the midi streams can be merged from multiple ports. otherwise the midi status gets insane. (btw, the event is not queued but bypassed to the destination(s) if you pass it in the case queue = SND_SEQ_QUEUE_DIRECT.) i know your complain about another big problem: the current sequencer system is the lack of transfer of bulk data, which doesn't fit to the buffer size. in theory, it's possible by sending multiple times per buffer-fullness, but there is no protection to combine the split data without interruption from other ports. Takashi ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0