Hi Tim, 08.11.2015 20:17, Tim E. Real пишет: > On November 8, 2015 10:25:06 AM Andrew Deryabin wrote: >> Hi Tim, >> >> 06.11.2015 05:22, Tim E. Real пишет: >>> Hi, more routing fixes. >>> The Graphical Routing dialog is virtually fully usable now >>> >>> regarding the actual trees and connections, >>> despite some unfinished minor graphical things. >> Checked - it works :). As usual I have one question. In advanced router >> is there an ability to connect individual channels of multi-output >> instruments? > Yup. > I was hoping you'd get a kick out of the ability - your > SimpleDrums multi-channel modification is awesome and > provided inspiration and testing. > > Maybe it's not so obvious, but you click on the individual channel > 'dots' in the left and right panes and then click the 'connect' button. Hmm :). From the first time of testing I decided not to look at code and feel like an ordinal user. May be that's why I didn't get how to make this. What I've tried: In the left pane (for example) I find the needed instrument's channel and double-click on it. I imagined that now router should enter in so called 'connect mode' when it waits for another double-click on needed channel at the right pane. But nothing happened.
Now it's clear that my way was an alternate to yours - with button. But in your case there are 3 clicks and mouse moves and in my case - only 2. I don't want to say that button's way is not so perfect, but double-clicking way is more intuitive imho. > > Note that Omni routes are also possible - you click on the named items > (the items above the channel bars) and click 'connect'. > > If a route is possible, the 'connect' button will be enabled. > If the route exists, the 'remove' button will be enabled. > > To remove clutter, click an item in one pane, then click the > 'filter src/dst routes' buttons to see only the possible routes > in the other pane. (Work continues on the filter features.) > > Note that Midi Track to Midi Port routes were 'fudged'. > They are 'faked' to look like routes because we don't actually > support such routes ATM - Midi Track output is fixed by a single > output port and channel. > But the code to support multiple Midi Track to Midi Port routes > is in MusE and ready to switch with the simple change of a #define. > My biggest challenge in enabling that #define will be simply how > to present the overwhelming new info to the user - quite simply > it involves the question of how do we remove the familiar Midi Track > 'Port' and 'Channel' properties from the Track List and instead > present the user with something they can easily see and work with > for multiple output routes (and input routes). Working on it... > > Hang in there, more routing commits coming today. > Icons ! > And a well deserved break for some polish and shine. Wow, thanks for explanation! Waiting for bells and whistles :). > > Tim. > >>> --- >>> >>> Hey, I noticed some frame overflow fixes. >>> >>> I guess that doubles our effective synth operating time, eh? >>> Yay ! >>> I've seen it many times quit after about 2.5 hours with those warnings. >>> >>> Wow, you know, I thought Jack used 64-bit wide frames, but upon checking >>> >>> I see it is: >>> typedef uint32_t jack_nframes_t; >>> >>> I /was/ going to talk about harmonizing our frame variables type with >>> Jack's,> >>> by creating a typedef that we can easily change later at will, say... >>> >>> typedef uint64_t MusEFrame; >>> >>> or even >>> >>> typedef jack_nframes_t MusEFrame; >>> >>> but this is unnecessary now, since you are aiming for unsigned int >>> throughout MusE, and Jack only uses a 32-bit unsigned type. >>> >>> Still, using a typedef might be desirable. More manageable, and proper. >>> What do you think? >> By now I made quick fix when SimpleDrums stopped playing with lots of >> frame warnings (while all other synths worked fine). >> It seems, that typedefs are the most proper way to handle this type of >> overflows, but require more changes to code. >> May be create an issue? >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer -- Regards, Andrew ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
