On January 27, 2015 10:03:39 PM Andrew Deryabin wrote: > Hi Tim! > > The evening, and at last put my hands on persistent_ports branch. > > Quick report: It works!!! > > Long report :) : > > It works! > My test setup: > > I have usb midi keyboard. The background is that it's changes it's jack > id on every replug. So all connections can be broken during song writing. > The test: > 1. I started muse, made synth track, connected a new midi track to it. > 2. Opened midi ports dialog, created jack-0 device and connected it to > midi_capture_3 (current id of my midi keyboard). > 3. While playing with left hand I unplugged usb cable from keyboard and > then after few seconds replug it. Jack gave it new id: midi_capture_4. > And muse detected it, reconnected and started to receive midi input > without any problem! Great!!
Yes, as mentioned we shun 'system:' names and look for a better name in the port aliases. Unlike before, you'll see that these 'better' names are stored in the song. Any good port system (Jack) will have both a canonical naming scheme and a 'human-readable' scheme. With canonical naming, you've just seen the fatal flaw, the Achilles heel, it's not really a bug, just the 'numbers' cannot be re-used. With 'human-readable' names, we have the 'real' name of the port. MusE will rely on these names NOT changing from day to day. They might with the a2jmidid bridge, and ALSA RAW. Notice there are numbers in those port names. Ironically, Paul said he wants to deprecate port aliases. Without any aliases, I said he better replace all those canonical port names with permanent human readable names then, or we're doomed. Ultimately, as long as there is a human-readable name in the either the port name or aliases, MusE will find it. Paul wants to concentrate on the Metadata API port 'strings', but it seems that these are user-set and won't contain any usable default names. > 4. Then I tested all 3 case scenarios posted by Tim. All of them works > with jack seq and raw midi driver! Saving song without jack connection > and reopening in with jack also restores all connections. > 5. After that I started external jack synth (carla host) and made midi > conenctions to jack-1 (new port) and audio returns to new audio input > track. Then tested all scenarios with this setup too. Honestly, I didn't > believe at that moment, that connections to carla will be restored. But! > I closed all apps. Opened MusE, than loaded song and only after that > loaded carla (with it's saved state). MusE restored *all* connections > correctly! Even ladish can't do this properly sometimes. Yes, not just hardware ports but software as well. (I must ensure that we don't try to auto-connect two of our OWN ports - a connection from a MusE Audio Output track to an Audio Input track.) I considered whether this feature is a job best left to a session manager. But the session manger would have to have a mechanism to inform us of disappearing ports vs. simple disconnections. And what if no session manager is running? And why do I need a session manager to tell me these things when Jack alone can do it? And I don't know if there's a session manager out there which can do the things that I have just taught Jack 1+2 to do. And ALSA too? > Conclusion: I want to say: Wow! Great, great job, Tim :). Thanks for > these efforts. I think that was really tricky to implement such things. Thanks. Was very tricky but I'm glad it seems workable now. > P.S. I also successfully merged persistent_ports branch to my qt5 branch > without any conflict at all! So, my last question is still alive :) Ah yes. So I should continue to develop in my branch? Correct? Soon I will need to do some GUI changes, I don't think it will cause too much trouble. Just the routing popups, to let users finally 'purge' unavailable routes. (Remember my guiding motto: Nothing is deleted unless the user says so.) I will also need to add a new dialog: "Manage Midi Devices". Because until now there has been no way to actually delete any of the user-created Jack mid devices. I will also need to let the user 'purge' any unused/unavailable ALSA devices. The midi ports dialog can then be somewhat less crowded :-) Lastly, I would like to say that I considered whether this feature would be useful for other tracks in general. I thought not. But upon reconsideration, it would be great if unavailable synth plugins would not lose their synth tracks! Then, extend that idea to ALL missing plugins, and we have a robust unbreakable song file system! This is not really a routing issue, just preservation of synth tracks and plugin names. Should be straight forward in theory, similar to the ALSA support I'm trying... Cheers! Tim. > > Regards, > Andrew > > 27.01.2015 10:15, Tim E. Real wrote: > > Here it is, warts and all. > > Remember it's an experimental work in progress ! > > It is full of /large/ commented sections. > > Some greyish ideas and code may change, you know how it is. > > > > It should compile and run out of the box. > > > > It is not ready for prime time yet, but is ready for testing. > > Maybe the users want to try it for fun. Early adopters. > > > > You will see a /large/ amount of debugging output, > > > > relating to Jack and routes and so on. > > > > Results may vary depending on Jack version and Jack Midi driver in use. > > I can't control that. > > > > Jack-2 with ALSA SEQ midi driver OK. ALSA RAW seems OK. > > Jack-1/2 with a2jmidid bridge OK, but maybe 'day-2-day' port rename > > problems. New '-X' submodules in Jack-1/2 not recommended, yet. > > > > Let me know if it works. Give some setup details. > > > > > > You can test a few ways: > > =================== > > 1) > > By wiring up some MusE <->Jack Midi routes > > > > to/from a hot plug-able device like USB midi. > > > > Do all this in the midi configuration dialog. > > Save this as a song. > > > > Then unplug the device. > > Observe the routes disappear from the 'in routes' and 'out routes' > > > > columns of the midi port list, and from QJackCtl etc. > > > > Then re-plug the device. > > Observe the routes soon come back preserved. > > > > 2) > > Then close MusE. > > Then unplug the device. > > Re-start MusE and re-load the song. > > Observe some routes are missing (the device is not plugged in). > > Now re-plug the device. > > Observe all routes are soon restored. > > > > 3) > > Next, run MusE either with Jack stopped or run MusE with the -a switch, > > > > meaning use dummy driver, no audio. > > > > Load the saved song and observe no routes available. > > Re-save the song (to test preservation of persistent routes). > > Then close MusE. Start Jack. Re-start MusE and load the song. > > Observe all routes are soon restored. > > > > 3) > > Similarly, create some Audio Input and Audio Output tracks, and > > > > wire them up to/from Jack ports of a hot plug-able audio device. > > > > Save this as a song. > > Now, I am told that unplugging your main audio device may > > > > crash MusE or Jack, but try it for me. I don't have one. > > > > If you are lucky, MusE will still be running. > > Hopefully if Jack first notifies MusE of the disconnections, you > > > > may be able to re-save the song and it will remember the connections > > next time you start (with audio). Probably not. > > > > But I suspect we can make this work, and stop the crashes. > > I think MusE handling of Jack shutdowns has fallen weak over the years... > > > > 4) > > Exact *same* as step 3). > > Observe all routes are restored. (Or not. Audio part might not be done > > yet.) > > > > Timeline: > > ========= > > GUTS: > > Currently working on similar ALSA support. Don't use ALSA right now ! > > Check a few more areas of routing usage for support needed. > > Stuff. > > > > GUI: > > GUI generally not touched yet. Good thing for QT5 porting ? > > Audio Input/Output track + JackMidi routing popups to be changed for sure. > > They currently don't show these 'hidden' persistent routes. > > > > CLEANUP: > > Large commented sections. > > > > Tim. > > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
