Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

[ ALSA folks: Josh Green (Smurf sound font editor) was mildly
  contemplating adding the ALSA sequencer as an output destination
  for my MIDI pattern sequencer SoftWerk. I started thinking about
  why it was going to be hard, and it seemed of some relevance to
  this list. Some people may also have ideas about solutions.

  I've set reply-to to point to alsa-devel, because softwerk-dev 
  is member-only.
]

>don't usually offer to help develop a program, so I guess it has to
>start somewhere. Perhaps I'll look into adding sequencer support to
>Softwerk, just n eed to read up on the ++ part of C++ and check out
>the MIDI related code. 

That would be great. You won't really be adding sequencer support to
SoftWerk however, and its probably a bit more complex than it should
be. You'd really be adding the sequencer as a Port type to
libmidi++. And here's why its hard.

Everything that uses libmidi++ would be using the methods defined in
<midi++/channel.h> to deliver MIDI messages of defined types. And they
do. The problem is that by the time these messages get handed to the
underlying MIDI::Port object, they have been rendered as simple byte
streams. The ALSA sequencer (or any other similar system) would exist
as a MIDI::Port type, and so you're going to be handed type-free byte
streams, not typed MIDI messages. I think that the sequencer can be
used to handle this, but certainly not in the intended way unless you
re-parse the data streams so that you deliver typed messages. This
would be an abomination, I think.

This is one of the main reasons for my dislike of the overall design
of the sequencer: it doesn't encapsulate MIDI but requires recoding
the messages as sequencer-API-specific events. This makes life hard
for programs that want to use a common design that allows the
sequencer and raw MIDI devices to be used as equivalent destinations
for data. At least, it seems to.

Instead, it requires the sequencer destination to exist as a more
complex/capable object than a MIDI::Port or alternatively that
MIDI::Port must accept typed messages. The first one messes up a clean
object heirarchy (in essence, the sequencer destination exists in
between the abstraction of a MIDI channel and a MIDI port), and the
second forces a model of what a Port is that doesn't match the reality
of actual devices.

So, as I said, this could be trickier than you (or I) would like :) If
you can see a good re-design of libmidi++ that would solve this
cleanly, I'd be happy to consider doing that. ALSA sequencer support
*is* important.

--p