[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian policy on multimedia ?

On Friday 13 January 2006 12:51, Junichi Uekawa was like:
> Hi,
> > > > This kind of thing will surely need some kind of policy document
> > > > specific to multimedia stuff, at least.
> > > >
> > > > I'm not sure if MIDI related stuff are mature enough for this, but I
> > > > think there needs to be some kind of usable sane default for
> > > > MIDI/virtual keyboards setup, or I seem to be setting it up for every
> > > > app.
> >
> > I don't quite understand what you mean by MIDI related stuff not being
> > mature enough, but I assume you speak from a position of better
> > understanding of the issues than I do. Certainly many musicians would
> > consider a functioning MIDI keyboard and connections to be as basic as
> > having a functioning text keyboard. One of the most FAQs that I encounter
> > is "I can't get my MIDI to work". I don't really understand why this
> > can't be made to work out of the box in most cases.
> Considering MIDI, a pre-requirement of MIDI keyboard with ALSA
> configured is more than what most casual users would want. Most people
> would probably have a requirement of a playback of MIDI instrument,
> and probably a leap to a virtual MIDI keyboard before jumping into
> buying a full MIDI I/O setup.

Practically every keyboard manufactured since 198? has a MIDI port - buying a 
full MIDI I/O set-up involves buying a connector cable in most cases. At 
present most gameport type connections require adding snd-seq-midi 
to /etc/modules, most cards use port 0x330 for this. I am pre-supposing the 
use of ALSA here, however the only reasons for not auto-configuring MIDI 
would be that it conflicts with other possible set-ups. I think many more 
casual users would use MIDI if it didn't seem awkward to set up.

> A default MIDI input/output configuration is probably lacking.
> Multiple applications will require individual configuration, and I
> don't know if there is a common framework for routing MIDI
> input-output as much as JACK is doing for audio data.

/dev/midi or /dev/snd/midi* (?)

> For example, I don't know of a way to route a MIDI file to operate
> zynaddsubfx and hydrogen. Maybe a good start (for me) would be
> starting with a how-to, and distilling it into policy.  The policy
> would be the list of requirements for (new) applications to
> interoperate between Debian, such as where to look for the MIDI
> routing setup, and what are the standard expected behaviors for
> virtual keyboards.

I usually use the panel in qjackctl to manage MIDI connections, again this 
pre-supposes using the 'professional' audio set-up of ALSA + Jackd. Why would 
a casual user _not_ want a pro audio set-up?

> > > It would be great if everything had a good default. Do you think this
> > > can be achieved easily ? If it has to be done by patching every
> > > application it might be too error-prone and would take long for
> > > implementation. I don't know if LASH would be a better solution, but
> > > then LASH needs the applications to be LASH aware too - sounds like
> > > quite a bit of work.
> >
> > Persuading all the multimedia upstream and maintainers to implement LASH
> > would be a lot of work and would take time. Like a year or two, even
> > Jackd support is still not universally implemented. However, I think it
> > is a good idea to work towards it. If we're talking about making Debian
> > policy we're in for a long haul anyway. ;)
> LASH sounds like a good thing to implement, but my opinion is that
> Debian is an integrator that integrates all those different apps; and
> I consider it important Debian takes care of documenting how to
> interoperate classic applications with the newer ones, and removing
> those which just simply no longer function.
> I'm not quite up-to-speed with LASH and other new developments, a
> pointer to a quick howto might be appropriate. :P

TBH - Not many people _are_ up to speed with LASH AFAICT.
I'll get back to you on this one when I have a little more time.


tim hall

Reply to: