From: Robert J. <spa...@gm...> - 2012-06-20 08:42:31
|
2012/6/20 Florian Jung <flo...@we...>: > Am 19.06.2012 04:22, schrieb Tim E. Real: >> On June 18, 2012 6:31:14 AM Florian Jung wrote: >>> Am 18.06.2012 11:55, schrieb Geoff Beasley: >>>> On 06/18/2012 09:32 AM, Florian Jung wrote: >>>>>> Whaddya think? Do you want me to invert the -A meaning? >>>> >>>> yes, i vote to do this - midi support is still very much the domain of >>>> alsa. why else would we need a2jmidid at all ? >>> >>> we don't need a2jmidid. >>> and MIDI is definitely NOT alsa's domain any more. jack is taking over >>> there as well. >> >> A reply from From Paul Davis to a post just last year. See here: >> >> http://www.ardour.org/node/4336 >> >> " Edward: you are correct: a2jmidid -e is the best option, for all cases >> actually. It has better timing (jitter & latency) characteristics than the >> code which implements the "seq" and "raw" options of the ALSA backend. >> Eventually, the functionality of a2jmidi will be more easily available. >> It also provides "better" port names (well, more human readable ones anyway)." >> >> Wow, I didn't know. I'll switch. > i didn't as well. i'll stick to a2jmidid then ;) Hmm... that wasn't what I was expecting nor hoping for... >> >> * This is definitely an argument to leave the -A switch alone. * > which means..? the behaviour we have right now, or revert it? I'm interpreting you as that we keep the -A switch as it currently is implemented? I don't quite follow the reasoning though, that jack with internal alsa-midi support has poor performance seems to me an argument for having MusE-alsa support default enabled. As I see it the draw back of having both jack and alsa midi enabled at the same time is when there is another jack-alsa bridge (-X seq or aj2midi), then we would get duplicate devices. Are there other drawbacks apart from duplicate devices, internal issues? > honestly, i don't mind any of these two. my only really *important* > concern is that MusE may not DEPEND on alsa (nor on ffado nor anything > platform specific), because that makes muse un-portable. Noble goal! There is however still a lot of code in muse that must be conditionally added before we are portable, I'd like that though :) > alsa support is perfectly fine (even having the "by default get all alsa > ports, except -A is specified" behaviour), as long it's optional. > the -A switch would have no effect on non-alsa systems. > > >> >> Jack midi can handle midi from ALL the drivers. >> It's just that the -X option provides convenience for ALSA users. >> >> I would say from Paul's response that -X is a DEAD END, no? > > if someone would patch jack (maybe has in the last year?), then -X would > of course be better. > >> >> I note that ALL Jack drivers, even the lowly dummy driver, allows >> inter-client Jack midi communication. > yeah. MIDI is no different from audio nor anything. jack is actually no > low-latency-audio server, but a low-latency-data-stream server. it > doesn't really mind which kind of data it passes. > > greetings > flo >> >> So Flo looks like you are both right and wrong here on points, I would say. >> >> Apply this knowledge to documentation as you see fit, folks. >> >> Thanks. Tim. >> >>> >>> i vote _agaist_ inverting the -A meaning, instead i vote for helping the >>> user configure -Xseq. definitely in the documentation (*cough*), and >>> maybe even as dialog: >>> >>> is it possible to detect that jack wasn't launched with -Xseq or -Xraw >>> (i.e., there are no midi ports), and then show an information dialog? >>> >>> greetings >>> flo >>> >> > |