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. -- cheers, tim hall http://glastonburymusic.org.uk/tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
