Re: [Lmuse-developer] [Bulk] Re: More fixes...

[Andrew D. <an...@da...>]

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
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer

-- 
Regards,
Andrew