Hi Tim! 31.01.2015 23:09, Tim E. Real wrote: > Hey. > > Still mostly same work in progress, at least now it can continue in master. > All commented sections and most of my 'code markers' cleaned. > > But debugging messages still there. They're still needed. > I will try to #define them out for now... > > ALSA should usable again (fixed an error) but not finished. Thanks, Tim. This is a really killer feature. Now MusE became even better!! :) > > --- > > Been rethinking ALSA support. > Thinking of allowing multiple client ports. > One per MusE MidiAlsaDevice instead of one global client port. > Similar (identical) to our Jack support. > That way I can unify some Jack + ALSA code and behaviour, and our > ALSA devices will have routing capabilities - meaning we can actually > do routing just like our Jack midi devices. > I noticed ALSA 'routing' has to be done with another app like QJackCtl. > > Thing is, ALSA has a neat trick up its sleeve over Jack: Addressing! > One SINGLE client port can be used to separately address many external > client ports. Thus we only NEED one client port. That's why it works now. > So I'm reluctant to ditch that nifty capability. > Because although I could make our ALSA support behaviour appear identical > to Jack behaviour easily right NOW, it would mean abandoning that nice > unique ALSA addressing feature. To KEEP that feature I'm thinking of ways > to support it but it's extra work. > > Also one resulting drawback of multiple client ports and identical behaviour > as Jack midi devices, is the naming scheme. As you can see, our auto-filled > Jack port devices have long unwieldy names. And once you make ADDITIONAL > connections to these ports, the names actually become MEANINGLESS ! > Some I'm pondering ways to fix this long standing naming problem. > We could simply name the devices canonically like "Midi output device 1". > This would solve everything but... these names are not descriptive, > as viewed from Midi and Drum Tracks. > And yet... we do this with Audio Input and Output Tracks, which are given > names like "Input 1", but the difference here is that the users can SEE > these tracks all the time and can easily rename them. Even their mere > position in the track list is a visual reminder of where you externally > connected them. > > --- > > I upgraded to KUbuntu 14.04 and tried Qt5. > (I was forced to, it was < Qt-5.1 ! ) > In the MusE appearance settings only three styles are listed: Windows, > GTK+, and Fusion which I determined was the one in use, which is 'squarish'. > > After using Qt4 Oxygen for so long this shocked me as ugly at first. > I hope other styles are ported soon. You can try qtcurve. It's available for qt5, highly configurable and looks very nice :). As for me it's much nicer then oxygen. > > 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
-- Regards, Andrew ------------------------------------------------------------------------------ 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
