On December 10, 2014 01:00:45 AM Andrew Deryabin wrote: > Hi Tim! > > 10.12.2014 00:11, Robert Jonsson wrote: > > Hi Tim, > > > > 2014-12-09 3:00 GMT+01:00 Tim E. Real <[email protected] > > > > <mailto:[email protected]>>: > > On November 27, 2014 01:25:47 PM Andrew Deryabin wrote: > > <..> > > > > Howdy. > > Thanks for the test release on LAU Andrew. > > That should raise some eyebrows out there. > > You are freakin' awesome, man! MusE lives on! > > > > Indeed  \o/ > >  > > > > Guys, don't wait for me, for the full release. > > I'm making good progress here - my "persistent ports" idea is > >  actually working now, with both Jack versions and with any midi > > driver! > > But I will likely check in a new branch first with the changes > >  rather than unleash all of this on the public in master. > > Or I'll commit later on, to master. > > Must take care of a few more areas in need of change to support my > > code. > > > > Alright, sounds like a plan. What is in main now feels pretty stable > > so if we wait with your improvements a few months and make another > > release that will be great. > > If you can, do put your changes in a public git, I know it's an extra > > step but I'm hoping the payoff for getting exposure and possibly more > > testing will outweigh it in the long term. > > One more "yes" from me for making your changes public! I'll be a > thorough tester, because I'm interested in such functionality. My usb > midi keyboard can be renamed after reconnection or simply I forget to > turn it on before running MusE. So if such connection things will happen > automatically it would be great!
Exactly. I'm gonna get into this a bit to let you all know what's up and field questions/suggestions etc. After working on this for two months due to a simple user request to NOT auto-fill midi ports at startup which revealed difficulties in supporting that, I have to stop and ask myself what the hell am I doing - will it really be necessary and useful? The answer is yes, and yesterday I also envisioned Andrew's type of scenario as a good example: You've just recorded a song with all your USB midi gear plugged in and everything going - the whole shebango. You save the song and it contains all the USB MIDI Jack routes that were in use at record time. The next day you sit down to do some editing and mixing - non-record stuff. But all your USB MIDI gear is packed away, just you and your computer now! You open the song and hit save. BANG, your USB Jack MIDI routes will all be gone the next time you open the song because they are all gone right now - upon opening the song MusE didn't find them! So right now I'm in the guts and brains of this scheme. Several complicated schemes were tried, then simplified. Yesterday a breakthrough - I seem to have solved AND greatly simplified a key problematic section. Results are encouraging. I can tell you MusE will move from a Jack port ID centric routing system to rely somewhat more on Jack port names or aliases instead. It picks the best name to use from among those available. It absolutely RELIES on this name for reconnection. It shuns "System:*" names and looks to the aliases for a better name instead. Struct 'Route' gains a new member: 'persistentName'. For type JACK_ROUTE this takes effect when member 'jackPort' is ZERO - Such a Route will now be an allowable valid Route node. Ye' follow where I've gone with this? Sure you do! Then there is what the user sees and edits. Here's how I envision the GUI aspects will work, obviously things will need to be presented a bit differently: The strict guiding philosophy was that NO Jack routing node (the items shown in the routing popup menus) shall be removed unless the user specifically says so, either with MusE or another app like QJackCtl. Nothing. User took the time to set everything up and... BANG? No. When a Jack port is removed or does not exist, any corresponding routing popup items will be grayed, with an option or a submenu named "Purge unavailable route?". Also some global functions to for ex. "Purge all unavailable routes", etc. All routing items remain, even if you run with MusE's dummy audio driver. Notice the differences between a port disconnecting vs. disappearing. That was the really REALLY tricky part to detect. Disconnecting means we remove our routing node. Disappearing means we /keep/ the routing node and zero its jackPort, but search some time later for a port by that persistent name . Et voila - "Persistent Routes". There are several other aspects to discuss such as increased song portability, and lack of full support for detection of externally renamed ports while MusE is running :-( Tim. > > Thanks, > Andrew > > > For this release I have some minor issues I have been working on, > > hopefully I can complete those, mostly there are some annoyances with > > the "improved" metronome and some translation fuckups with decimal > > commas, as I discussed before. > > > > If all goes well I think we can make a final release of this iteration > > before the new year. > > > > Regards, > > Robert > > > > > > > > -------------------------------------------------------------------------- > > ---- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clkt > > rk > > > > > > _______________________________________________ > > Lmuse-developer mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/lmuse-developer ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
