Nedko Arnaudov wrote: > This silly, new qjackctl release disabling jack midi? With versions > before user could at least connect (non intuitive, yes, but useable > workaround). Why the hell should you remove functionality?!? This does > not promote JACK MIDI, it is against it. Do we want 18 months+ for users > to start using JACK MIDI? > Where did this magic 18+ number come around? QjackCtl _never_ had any JACK-MIDI functionality built on it. So quite frankly I did not remove a damn thing. I just fixed an inconsistency, a bug that was lurking trough sloppy JACK API interpretation and being there since long before the pre-JACK-MIDI days. In fact, the fix will be actually needed for going through coming changes which will be done for JACK-MIDI support in future QjackCtl (BTW that happening will bump version tagging to 0.3.x, is that's any relevant). If you're not happy with it, and if you find connecting JACK-MIDI applications paramount to your daily use, please don't upgrade. Stay with 0.2.21 or older. Actually, the upgrade is only really recommended if you're doing the firewire/freebob stance. All else is nitpicking. OTOH, which JACK MIDI client application is already generally available and productive? At least for 18 months already? Tell me please. I'd really like to know. JACK-MIDI is still under work. Although some infrastructure is already there, I'm pretty sure it is not quite in general use, let alone promotion. As I said, the JACK-MIDI functionality will be handled properly in coming QjackCtl releases, as it should be, like when proper JACK MIDI backend drivers interface gets in place. Then you can start telling users the prospect you have some real JACK-MIDI functionality. Then you'll probably get some real client applications too. Once again, if you are a developer of some JACK-MIDI client application you probably know what to do. And you should be prepared to change your code too, as the JACK-MIDI API is still not frozen still. Bye now. -- rncbc aka Rui Nuno Capela rncbc@xxxxxxxxx
