On Mon, Feb 22, 2010 at 3:24 PM, Tim E. Real <termtech(a)rogers.com> wrote: there's currently no established mapping from JACK MIDI port names to ALSA client identifiers. Given that *any* client can create ports that represent such a mapping, and can name them as it wishes, it would be unwise to rely on any such mapping.

On Monday 22 February 2010 21:24:58 Tim E. Real wrote: That is what you get for mixing systems. But why do you as a developer care about that? Surely its the users responsibility? And the users will know which jack-midi-to-alsa-midi bridge they use and how this names the ports? (Don't try to be smarter then the user, its never working out correctly.) But why is your app giving midi-ports both for jack and alsa at the same time? Have fun, Arnold

On Mon, Feb 22, 2010 at 5:59 PM, Gabriel M. Beddingfield &lt;gabrbedd(a)gmail.com&gt; wrote: 1) it makes the app quite a bit more complex 2) it introduces yet another name mapping scheme from ALSA<->JACK 3) its a job best left for specialized clients like a2jmidid 4) it makes it harder to write an app that can be used with or without JACK shall i go on? :)

On Mon, Feb 22, 2010 at 6:11 PM, &lt;fons(a)kokkinizita.net&gt; wrote: my experience with ardour3 tells me this: JACK MIDI and ALSA MIDI are opposites in this respect: * ALSA MIDI is fundamentally poor for realtime MIDI driven synthesis and parameter control BUT very convenient for system control * JACK MIDI is very inconvenient for system control but fundamentally good for realtime MIDI driven synthesis and parameter control we've adopted some relatively simple designs in a3 that make JACK MIDI ports *not* being used for RT synthesis etc look (API-wise) pretty much like an ALSA MIDI port (by interposing a FIFO between the process callback and everything else) i don't really see too many ways out of this dilemma. injecting information into a JACK client (or any piece of software really) that is intended for use in an RT-constrained piece of code is really so different than injecting it for non-RT purposes that i don't think there is a way to just get the best of both worlds with no effort. --p

On February 23, 2010 04:53:59 am Ralf Mardorf wrote: Ah, I thought maybe that's what was meant - why both at the same time. Well, I figure I'll add switches only if necessary, otherwise if they can both work together, why not let them? Someone might have devices that only work well with ALSA and other devices that can only work well through Jack midi (like FFADO?) or whatever. Actually you're right in a way, I am planning to add 'disable' switches, and it *should* rightly have them, in case users don't want one or the other, but default for now will be both at the same time. Unless things go sour... Tim.

"Tim E. Real" &lt;termtech(a)rogers.com&gt; writes: If a2jmidid is used in dbus mode, you can map ports through the dbus calls: <method name="map_alsa_to_jack_port"> <arg name="alsa_client_id" type="u" direction="in" /> <arg name="alsa_port_id" type="u" direction="in" /> <arg name="map_playback" type="b" direction="in" /> <arg name="jack_port_name" type="s" direction="out" /> </method> <method name="map_jack_port_to_alsa"> <arg name="jack_port_name" type="s" direction="in" /> <arg name="alsa_client_id" type="u" direction="out" /> <arg name="alsa_port_id" type="u" direction="out" /> <arg name="alsa_client_name" type="s" direction="out" /> <arg name="alsa_port_name" type="s" direction="out" /> </method> lpatchage and ladish use this to display one box per alsa client and to merge mapped alsamidi ports and jack audio ports into same box given that jack client name and alsa client name matches. Of course this is a workaround for subopitmal jack API. Other workaround is the alias mechanism. Hopefully one day jack API itsell will get fixed, in 2020 maybe :] As side note, a2jmidid and its jack internal client incarnations should use multiple clients. And then the client autorenames hit the fan. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>