Re: [Lmuse-developer] news..

[Tim E. R. <ter...@ro...>]

On July 26, 2013 08:21:39 AM Geoff Beasley wrote:
> Hi boyz.
> 
> I have news to report also. I have just bought a Behringer X32 and
> following some work with Jonathan Woithe from FFADO ( and a firmware
> update coincidentally from Behringer as well !) we have it working 100%
> perfectly under linux. Firewire and Usb.
> 
> This board is just breathtaking.
> http://www.behringer.com/EN/Products/X32.aspx. Rollon those automation
> changes I say :D
> 
> best to you all
> 
> g

OMG What a nice board! 

What does it mean to have FIreWire?
Does this mean you get midi-over-firewire and audio-over-firewire ?
Do you even use good ol' hardware midi at all, G?
Do you still use or require the ALSA system for some things?
You probably use a bridge like a2j instead of the Jack ALSA driver, right? 

----
I was going to say this board could help me test the new 14-bit 
 controller stuff, as I have no actual devices capable of sending 14-bit.

But your board's specs don't seem to show any 14-bit, only 7-bit controllers ?

I can do PC-to-PC 14-bit controllers via midi cable, with ALSA or Jack midi 
 on either end. But the results I am getting PC-to-PC are not the same as 
 with true hardware.
And being so many different MFGs and 14-bit protocol styles...
I looked at a LOT o' stuff: From Behringer to Novation to the Slim Phatty
 to some small embedded midi boards.
I've been researching and whoa, some folks do things... differently.

I brought this up on LAD recently. I said I was not going to use a well-known 
 'infamous' trick which uses a delay - a forced inherent latency due to 
 waiting for the control LSB to arrive, or not. 
But... As of two days ago I see the delay trick is a good  idea when we are
 /expecting/ 14-bit values and MSB, LSB, or both, may be received. 

So, observations show that at least in my crappy PC-to-PC-midi case, there's 
 a maximum time between received ALSA midi messages of about 100 samples.
Jack midi seemed to fare much better on one end. I could not do Jack midi
 on the other end as it's a really old distro pre- jack midi. (I tried to 
 build latest MusE on it. Many edits later I gave up. Old Qt 4.2 !)
Jack was giving me good low times between some messages,
 sometimes even three messages were at the exact same time - great! -
 and that's with ALSA at the other end. All tests done within MusE. 

So the idea is: 
OK you want some 14-bit controller? Then we need to sacrifice a maximum 
 of say 256 samples, in the form of an inherent delay adjustable by you, 
 in order to determine what to do with midi controller messages we receive.

We receive a value MSB but no LSB by 256 samples? You get ONE 14-bit 
 message comprising this MSB plus the existing LSB.
We receive a value LSB within 256 samples of MSB? You get ONE 14-bit
 message comprising that MSB plus LSB.
We receive a value LSB alone, or outside of an LSB time limit? You get ONE
 14-bit message comprising the existing MSB plus this LSB. Note that this
 14-bit message is in addition to any that may have been given to you by
 the above two steps.

The single 14-bit messages YOU get, no matter how they were comprised 
 or the TIME that WE received their MSB and/or LSB, are all time adjusted 
 if necessary to be aligned with this (adjustable) inherent delay latency 
 so that the resulting values YOU get are smooth, albeit delayed.

In this way, hardware single-slider 14-bit controllers can have smoothness 
 in MusE, no jumping no jitter and no 'double message MSB/LSB pairs'. 
Just some control latency - which can be compensated after recording but
 not during 'live' performances.

I guess... ? 

BTW So far, I'm talking about /absolute/ controllers which is what MusE has.
Some products support /relative/, some use 'data increment' messages 
 with the increment value > 1 (it is usually just '1'). 
And there are other modes. Cool.

There are other challenges I'm working on too.

See ya
Tim.