Re: [Lmuse-developer] PATCH: Fix weird controllers WAS: Weird Modulation = 100 bug in Muse 2.0 rc1

[Florian J. <flo...@we...>]

Am 08.01.2012 21:19, schrieb Tim E. Real:
> On January 8, 2012 4:12:37 PM Dennis Schulmeister wrote:
>    
>> On Sat, 07 Jan 2012 21:41:21 -0500
>>
>> "Tim E. Real"<ter...@ro...>  wrote:
>>      
>>>> The most
>>>> important thing is the check for vl->num()<  CTRL_INTERNAL_OFFSET at
>>>> the very end of the patch. I think it's needed in mididev.cpp and
>>>> alsamidi.cpp then, if you want to keep the old code. Of course that
>>>> would be fine with me, too.
>>>>          
>>> Sure, that's the most important one, shocking, really.
>>> Just checking it out now.
>>>        
>> Thinking more about it the best thing might be to send the internal
>> controllers, too. Just tried it. If you dismiss the check on vl->num()
>> and replace putMidiEvent() with putEvent() it works like expected. All
>> controllers and program changes are sent. See the attached file.
>>
>>
>> Yours sincerely,
>> Dennis Schulmeister
>>      
> Not to worry, Dennis. I found the problem, and more !
>
> The real trouble was that our alsa driver's putMidiEvent() neglected
>   to honour CTRL_PROGRAM and CTRL_PITCH control types, thus
>   borking your HW with alsa control messages when they should have
>   been the specific alsa program and pitch snd functions.
>
> It's ironic because over the years I've fixed several places like that, I am
>   so keenly aware of that detail and I thought I had it all wrapped up,
>   and along comes this one right under my nose... Ha!
>
> Note that Jack midi is NOT affected by this !
> There will be no changes I can see for this specific bug.
>    
then the issue i noticed is probably caused by this.
using alsa midi didn't work, using a2jmidid (which offers a jack->alsa 
midi bridge) worked.

> Now, I found a couple of other disturbing issues with the alsa driver.
> When you seek with the cursor it continuously and accumulatively sends
>   out the controllers. It shouldn't do this, only once upon /changes/
> You should see the flourescent display on my old KB, it goes
>   absolutely nuts when I seek with an alsa device - too many messages.
> Some optimizations in there are not being called, I think now because
>   of a little line I changed in the alsa driver's handleSeek() which
>   uses putEvent instead of pushing onto playEvents list. My bad ...
>
> Note here again that Jack midi is fine ! No changes needed.
>    
for all people which have a problem with this: i recommend using 
a2jmidid as a workaround ;)
> Working on it... Commits soon.
>
> Side note:
> -----------
> Someone before asked whether it was possible to 'chain' our midi ports
>   so that two different instruments could be used on the same physical
>   device, but with different channels.
> I replied it was probably doable with our Jack midi devices, but certainly
>   not with our ALSA devices.
> Yes, I think it is possible with our Jack midi devices. I'm glad I made it
>   that way. Because I never considered that type of usage when I made it.
>
> The problem with our alsa is that it is substantially different than
>   our Jack support.
> Primary hurdle is we only create *one* ALSA client port.
> Whereas we can have many client Jack ports, which can be routed to
>   the same physical Jack port to do the 'chain' trick above.
> At some point we should update our ALSA driver, to at least
>   do multiple client ports.
>    
we could add some additional layer between muse and muse's alsa driver: 
a layer which provides "virtual ports", which have a "channels" set and 
an "real" alsa port. such a "virtual port" only sends messages which are 
on its assigned channels to the "real" port, and you can connect 
arbitrarily many (that is, 16) virtual ports to one real port (as long 
the channels don't collide... and even then... nothing will explode). 
instruments are assigned to these _virtual_ ports then.

do you get what i mean?

greetings
flo

> Cheers. Tim.
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Lmuse-developer mailing list
> Lmu...@li...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
>
>