>That's what drivers are for. ;) The ALSA sequencer shouldn't have to >know of course, but the driver should be able to handle it, and the >architecture should allow a working driver.
i'd agree with that. >> another example of this that i know a bit more about is on the >> tropez+. this has two MIDI output ports, and you can switch between >> them with 2 "unused" MIDI bytes. what should ALSA do if you deliver >> those bytes in a data stream? how can it know what they will do? why >> should it pay any attention at all to them? > >It should pay attention because it's a universal sound architecture that >provides software from low-level driver to API. The low-level driver >is all that needs to know about this. i was asking those questions somewhat rhetorically. the tropez+ driver *does* watch for those special bytes, and will not deliver them. user space is not allowed to switch ports using this mechanism - its a technique restricted to the driver itself. user space gets to open whichever port(s) it wants to open and writes to them. i would have thought that the mtpav driver should do the same thing. if you want to access all 8 ports, you should have 8 access points (whether this is via the sequencer or the rawmidi interface), and write to each one of them. the use of the "Dn" byte(s?) to switch output ports shouldn't be exported to user space. --p ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
