All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Davis <paul@linuxaudiosystems.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: using the sequencer with raw byte streams?
Date: Mon, 21 Jul 2003 13:18:37 -0400	[thread overview]
Message-ID: <E19eeDR-0007hP-00@sc8-sf-list1.sourceforge.net> (raw)
In-Reply-To: Your message of "Mon, 21 Jul 2003 16:44:27 +0200." <s5hvftwhrck.wl@alsa2.suse.de>

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

  reply	other threads:[~2003-07-21 17:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-20 23:28 using the sequencer with raw byte streams? Paul Davis
2003-07-21 14:44 ` Takashi Iwai
2003-07-21 17:18   ` Paul Davis [this message]
     [not found]   ` <20030721171249.255CB14C36@Cantor.suse.de>
2003-07-21 17:27     ` Takashi Iwai
2003-07-29 17:24       ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E19eeDR-0007hP-00@sc8-sf-list1.sourceforge.net \
    --to=paul@linuxaudiosystems.com \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.