From: Tim E. R. <ter...@ro...> - 2012-06-20 22:37:08
|
On June 20, 2012 10:42:19 AM Robert Jonsson wrote: > 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... Well, actually I didn't notice any difference, and well it is another pain to run yet another daemon. So I'll probably stick with -X for now. And the naming is different. Gee I wish someone would make up their mind about what what is 'capture' and what is 'playback'. Jack2 reversed the definitions from Jack1, yet a2jmidid seems to have kept the old ones. > > >> * 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? Not really, it is perfectly 'legal' in MusE to have multiple driver devices which are the same physical device. The main issue is midi tracks will have the two devices inputting causing double notes. I think the whole issue can be simply resolved by me refining how and if the ports are filled automatically at start. But I could not automate it any more than this, so I should get down and add the 'fill with ALSA devices' and 'fill with Jack midi devices' buttons in the midi ports list as I've been saying, and DON'T auto-fill at start, so to let the user decide what to fill with. Else we go back to square one with NO automatic filling of the ports list and the user must manually select, or create in the case of Jack midi, each device. Yeah the two 'fill' buttons would help there. > > > 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 :) Slowly working towards separation so that it can be optioned-out. A bit tricky. Flo, it's the reason for some of the large commented sections in the driver midi processing (seek and stop handling) - these sections are meant to be re-activated, or at least revisited when optionable ALSA is completed. But for the moment, the use of the ALSA driver sequencer timer means I had to revert to using code sections which handle it (seek, stop). These current sections can be removed later. I say tricky because the mere fact that we will even allow ALSA and Jack midi at the same time means we must support this current code in this form under that condition. I can probably make it work with a series of #ifdef ALSA_SUPPORT etc. If user chooses not to compile with ALSA, the other newer sections are used (they're more efficient, proper 'total' Jackified). And remember DSSI requires ALSA support (for passing midi events) ! So options will need to be more fine-grained as in: ALSA driver support yes/no DSSI support - requires ALSA yes/no Notice that we should allow "ALSA driver support = no" and "DSSI support = yes". That allows to remove all ALSA driver support while still keeping DSSI. > > > 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 guess my take on all of this is that Jack is Jack, and since we are a fully Jackified app then let's not list ALSA devices by default when Jack runs. It is up to the user to ensure their Jack midi devices are installed and recognized by Jack. What else can we do? If all fails for the user, THEN they activate our ALSA switch. Users who need Jack ALSA support AND some other Jack driver like firewire have that option in a2jmidid. Or, again, they can activate our ALSA switch (or our future ALSA compile option flag). Tim. > > > >> 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 > |