On Sat, 2014-08-16 at 03:00 -0400, Tim E. Real wrote: It's wise to use several interfaces, even when using 16 channels only for averaged instrument playing MIDI events. However, I want to chime in to mention an issue, you perhaps miss. When sending pitch bend MIDI data, you likely will hear it in the audio signal. For my RME PCIe card I can hear mouse movements and MIDI pitch bend usage in the audio signal, if I send other MIDI events, e.g. much modulation wheel data it's audible too, but pitch bend by it's nature sends much data and most of it likely is unused data. At sane levels my sound card doesn't produce audible hiss caused by it's analog components, but there always is much audible digital noise, even when the computer is idle. I guess it was less loud when I used another PCIe slot, but there always is loud audible digital noise what ever slot I use. I experience/d the same with my TerraTec PCI cards on this machine and with my old mobo. IOW since Len wants to design a mixer control for usage with averaged computers and sound cards, it might be worth to keep in mind that everything that makes the computer work much, likely will be audible as noise in the audio signal. 128 steps for a fader are too less steps, but perhaps 256 or 512 already are enough.

On Sat, 16 Aug 2014, Tim E. Real wrote: That is the limitation with the mackie standard. However, with midi over ethernet, it is not that hard to send two midi ports... on the other hand a standard that allows 40 faders or more where the fader number is one byte would be advantageous. That is the way my project is set up. (well the config file I am using right now) They could... we could probably fake it... after touch and program change are the two odd events with only two bytes instead of three. Soft/firmware probably has to look for them... Yes, nrpn is actually a take off on them. It uses one of those pairs with two othe data bytes in front It is actually a double event and so should be passed as two events in ALSA. I have seen one controller that sends them as five byte events assuming running status. (9 byte for nrpn) However, in reading the jackmidi docs "Clients must not write more than data_size bytes into this buffer. Clients must write normalised MIDI data to the port - no running status and no (1-byte) realtime messages interspersed with other messages (realtime messages are fine when they occur on their own, like other messages)." I had thought this meant I could not stuff two events together like that. But rereading it, I am thinking it means an "event" in jack is one status byte followed by any number of data bytes. That would be fine for sending, but what happens after that? does it get split into separate events in jack? Does jack take separate events and remove status where possible? Jack adds time to every event, so running status would only make sense for two events with the same time stamp. The docs are here: http://www.allen-heath.com/media/Qu-MIDI-Protocol-V1.5.pdf http://www.allen-heath.com/media/iLive-MIDI-Protocol-V1.91.pdf http://www.allen-heath.com/media/GLD-MIDI-and-TCPIP-Protocol-V1.4_2.pdf The qu shows the nrpn as two values but the faders and other level controls only use MSB, the only time LSB is used is for sub data... for example the pan control uses this to set the channels routing to sub bus. The iLive only sends three bytes for the same functions and the GLD does the same. A quick thought on fineness of control. It is true that 127 levels tends to "zipper". However, 127 levels is more than enough for static levels. Ardour (and I assume other DAWs) uses some kind of smoothing to avoid the zipper with fast fader moves. I would expect that A&H would do the same. That is, effectively build in a "slew rate". Think: - fader has moved up - start ramping level - at 10 (or whatever) fine ticks check if new level reached - either stop or continue ramping Really, there are a lot of controllers out there that use CC (0 to 127) for all their levels, so if a DAW wants not to have bug reports about "that zipper noise", they will add smoothing anyway. The second benefit, is that there would be less MIDI traffic. Not just with one byte less per event, but also 127 less events per tick. My old "MIDI and SoundBook for the Atari ST" talks about sequencers having trouble being swamped by pitch control data and ways of dealing with it. I think that is why the original MIDI spec only had one PB per channel. I would suggest it was found that we can hear tuning differences much more than level differences. I think it would have to be HW. Most Midi port are USB today and one does not know what processing happens inside. Those interfaces that use midi over tcp/ip could be sniffed with a normal net sniffer. Yup, Here are a few lines from the Yamaha doc... - (1) If the assigned parameter has fewer than 128 steps - (2) If the assigned parameter has 128 or more but less than 16,384 steps - (3) If the assigned parameter has 16,384 or more but less than 2,097,152 steps I didn't mention the three byte stuff before because I could not find anywhere in the document where it is actually used or how it is implemented. It merely says that in any case where more than one byte is used a change that involves less than all the bytes need only send the byte(s) that changed. It does do some checking. I have not played with it though. While this is true, you cannot control what comes in the door. I may be able to send running status 5 byte messages, but it looks like the jack API does some filtering. I would like to know more about this. It would be wonderful if jack dealt with NRPNs as one event, recognizing them, collecting them and stripping all status bytes but one. They _should_ all get sent as the same time slot, and if not (external slow physical MIDI line) the whole message should be timeed to either the time of the first status byte or the last. (the first makes more sense) This should be the same as double event high precision CC events. This what I am finding. In my case I am on the sending end which is easier. I do get updates from the DAW as well (bank switches for example) and have to deal with those. I do not have motorized faders, but rather a local copy of the fader value for the same effect. I need to trouble shoot this still. I can use the mouse to change the fader level and my program catches that ok, but when I change banks, it doesn't. I can see that the fader info goes out... but I don't seem to be catching it. One more thought on control surfaces and DAWs: Reading what the control surface is supposed to do in some of the DAW manuals and what the controler puts out. I can see that most of the fancy functions are left up to the DAW. There must be a large chunk of code in the DAW just for the control surface. For example, the mackie control surface has buttons to assign the "v-pots" (encoders) to various functions. This switching is left up to the DAW. I get the idea most DAWs are more like the Harris Mixbus where the channel strip is more or less predefined and this is easier. For example a send may be pre or post, in Ardour this would make it two different plugins for remote control as they all go in order. In a Mixbus channel strip, the send could remain in the same place and just have a pre/post parameter. I do not know what the deal between Ardour and Harris is (and I don't have to know, and I am not grumpy whatever it is), but it may preclude the inclusion in Ardour of a full strip or the ability to swap out the fader/meter. I would be happy to buy Mixbus if I could use the channel/bus strips in Ardour3. Ardour3 has a much improved remote control interface. -- Len Ovens www.ovenwerks.net