using the sequencer with raw byte streams?

using the sequencer with raw byte streams?

[Paul Davis]

is there a relatively simple way to use the sequencer with raw byte
streams? i want to create an "ASEQ_Port" type for libmidi++, but
unlike the current support port types, the sequencer seems to be
totally based on typed events. libmidi++ allows applications to format
arbitrary messages and have them delivered to a port. it also has its
own sophisticated parser that includes heavy use of libsigc++ to allow
anonymous notification of many more event types than the sequencer
code currently defines. 

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?


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

Re: using the sequencer with raw byte streams?

[Takashi Iwai]

At Sun, 20 Jul 2003 19:28:02 -0400,
Paul Davis wrote:
> 
> is there a relatively simple way to use the sequencer with raw byte
> streams? i want to create an "ASEQ_Port" type for libmidi++, but
> unlike the current support port types, the sequencer seems to be
> totally based on typed events. libmidi++ allows applications to format
> arbitrary messages and have them delivered to a port. it also has its
> own sophisticated parser that includes heavy use of libsigc++ to allow
> anonymous notification of many more event types than the sequencer
> code currently defines. 
 
"arbitrary" includes non-MIDI byte streams?

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


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

Re: using the sequencer with raw byte streams?

[Paul Davis]

>> own sophisticated parser that includes heavy use of libsigc++ to allow
>> anonymous notification of many more event types than the sequencer
>> code currently defines. 
> 
>"arbitrary" includes non-MIDI byte streams?

no, MIDI definitely, but its dominated by sysex stuff (MTC, MMC, dump,
load requests, etc) that the sequencer knows nothing about.

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

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.

--p



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

Re: using the sequencer with raw byte streams?

[Takashi Iwai]

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

Re: using the sequencer with raw byte streams?

[Takashi Iwai]

At Mon, 21 Jul 2003 19:27:11 +0200,
I wrote:
> 
> 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 added this feature to alsa-lib cvs now.
you can create a virtual rawmidi instance with the normal
snd_rawmidi_open() call but using the name "virtual":

	snd_rawmidi_open(&input_handle, &output_handle, "virtual", 0);

then a sequencer port is opened, and the read/write access to the port
is converted from/to MIDI byte streams on this rawmidi instance.
so, basically, you don't need to change your code so much :)
of course, you cannot call read() or write() directly.  instead, use
snd_rawmidi_read() and snd_rawmidi_write().

so far, there is no default connection when it's opened.
the configuration will be extended later to allow the definition of
default connections.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01