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. 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. 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
