Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 2014-08-17 at 08:24 -0700, Len Ovens wrote: On Sun, 17 Aug 2014, Ralf Mardorf wrote: On Sat, 2014-08-16 at 09:45 -0700, Len Ovens wrote: 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. I disagree. I never heard zipper noise, when I fade in or out or when using MIDI panning. Usually those steps aren't audible when fading or panning, but I often missed steps for static levels. Speaking for synth from the 80th and 90th, for the panning synth usually didn't use all 128 values, but 128 steps usually are used for the volume. I don't remember audible steps when fading, but I remember that there were not enough steps for optimal mixing. YMMV! I don't know if it matters, but was that a linear fade or log? I don't know? On Sun, 2014-08-17 at 16:15 +, Fons Adriaensen wrote: Suppose you have *real* faders which have a range of 127 mm. That's not far from a typical size on a pro mixer. Would you ever adjust them by half a millimeter ? Good point! As I already pointed out, I never noticed zipper noise when sending volume control to a synth, but sometimes 128 steps (and IIRC all 128 steps were used) were not enough. Perhaps it was neither linear nor log, but bad programmed usage of those steps. I remember that for panning often less then 10 steps were provided, I dislike/d this a lot. IIRC panning sometimes didn't effect a hold note, it was used for the next played note, so at least this can't be compared to a digital mixer. -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 2014-08-17 at 17:44 -0700, Len Ovens wrote: On a DAW, we sort of do this already by recording using the fader (and audio device gain) for trim and then mixing down using the fader for fine tuning. However, as I commented earlier, sometimes a harsh effect can introduce the need to: - re-record the track - add a gain section after the effect(s) before the fader. This may be as simple as using the output level the effect already has. Indeed, digital mixing needs a learning curve that isn't needed for analog mixing. An analog mixer provides a trim pot and an EQ, but no effects for each channel, for effects there are inserts and pre and post fader aux sends. Most people don't own analog mixers with automation. Users of Linux DAWs should by default add and activate (even if it's bypassed) FIL-plugin [1] for each channel. And care a little bit about old school audio mixing. E.g what's the mind of using a compressor for each channel and fading in and out and in and out during a song? All you need is FIL-plugins parametric EQ post effects, pre fader, not completely equal to an anlog mixer, but exactly what's needed and can be done for e.g. Qtractor's mixer. [1] FIL-Plugins There's one plugin in this first release, a four-band parametric equaliser. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameters are being changed. All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use. - http://kokkinizita.linuxaudio.org/linuxaudio/ladspa/index.html -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Mon, 2014-08-18 at 11:00 +0200, Ralf Mardorf wrote: On Sun, 2014-08-17 at 17:44 -0700, Len Ovens wrote: On a DAW, we sort of do this already by recording using the fader (and audio device gain) for trim and then mixing down using the fader for fine tuning. However, as I commented earlier, sometimes a harsh effect can introduce the need to: - re-record the track - add a gain section after the effect(s) before the fader. This may be as simple as using the output level the effect already has. Indeed, digital mixing needs a learning curve that isn't needed for analog mixing. An analog mixer provides a trim pot and an EQ, but no effects for each channel, for effects there are inserts and pre and post fader aux sends. Most people don't own analog mixers with automation. Users of Linux DAWs should by default add and activate (even if it's bypassed) FIL-plugin [1] for each channel. And care a little bit about old school audio mixing. E.g what's the mind of using a compressor for each channel and fading in and out and in and out during a song? All you need is FIL-plugins parametric EQ post effects, pre fader, not for Qtractor the fader for synth plugins is pre everything ;), that's bad design, but I guess not the audio stream is controlled, but the synth volume. For an anlog mixer this would be: Not using the fader of the mixer, but the synth volume for mixing, so you'll get 100% parasitic noise from effects, even if the synth volume is very low. Anyway, you want to build a remote control for digital mixers and can't care about wrong usage of good designed digital mixers and you can't care about bad designed digital mixers. -- http://iknowwhereyourcatlives.com/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, Aug 17, 2014 at 06:34:25PM -0700, Len Ovens wrote: I would think ((Gain+54)/64)*7f uses a lot less CPU time than a real (proper) log. Think 8 fingers (plus thumbs?) fading around 80 steps in a small time. Remember that this calculation has to be done at both ends too and the receiving end also has to deal with doing more calculation on as many as 64 tracks of low latency audio at the same time (amongst other things). In the equation you mention, 'gain' is in dB, it doesn't make any sense otherwise. So after applying the inverse of that equation you need to convert from dB to a linear gain value. If M is the value sent by the controller (0..127) and G the gain in db then G = (64 * M / 127) - 54 which will be in the range -54..+10 dB. M = 0 is probably interpreted as 'off' instead of -54 dB as a special case. Step size is 64 / 127 dB or 0.504 dB. A slightly better mapping would be 80 step of 0.5 dB for the range +10...-30, then smoothly increase the step size to arrive at a minimum gain of -70 dB or so. Even for this the calculations are trivial. There is no problem with CPU use. On the sender side you transmit 0..127 which is just 7 bits of an ADC measuring the voltage from a linear fader or pot, there is no mapping at all. On the receiver side, the conversion needs to be done just once per 25 ms or so and only when the gain changes. Then interpolate linearly in between, or not at all if the value hasn't changed. The resulting CPU load is absolutely irrelevant compared to what has to be done anyway. As an example, my 4-band EQ LADSPA does this sort of calculations for each of its 13 parameters. And calculating the internal filter parameters is a bit more complicated than dB to linear. It makes no difference at all in CPU use which is dominated by the per-sample processing. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On 08/18/2014 10:12 AM, Ralf Mardorf wrote: Qtractor the fader for synth plugins is pre everything ;), that's bad design, but I guess not the audio stream is controlled, but the synth volume. while on midi tracks, qtractor mixer/track faders simply deals midi channel volume (cc#7) and panning (cc#10) messages and that's from its birth model design (mainly due external/outboard midi h/w). iow. qtractor midi track faders doesn't deal or affect synth-generated audio signal whatsoever, at least directly--it all depends on each synth midi implementation, that is--so pre or post-fader conventions doesn't apply nor make much sense there. fwiw. all generated audio signal from synth/instrument plugins is routed to some (optional) audio output bus (default sink is master). and yes that will be the one true audio fader you probably should look when dealing midi instrument plugins audio output. remember that the qtractor mixer might NOT ever be the final stage of a mix; qtractor is not, never was, won't ever be, a monolithic solution :) hth. cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 17 Aug 2014, Ralf Mardorf wrote: On Sat, 2014-08-16 at 09:45 -0700, Len Ovens wrote: 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. I disagree. I never heard zipper noise, when I fade in or out or when using MIDI panning. Usually those steps aren't audible when fading or panning, but I often missed steps for static levels. Speaking for synth from the 80th and 90th, for the panning synth usually didn't use all 128 values, but 128 steps usually are used for the volume. I don't remember audible steps when fading, but I remember that there were not enough steps for optimal mixing. YMMV! I don't know if it matters, but was that a linear fade or log? Right now with 1024 steps in the range around 0 where we would be doing most of our mixing (0 on the fader, about -4 signal?) it is 4 steps to go from -0.1 to -0.0, That is 0.025 of a db. Does that kind of fineness really need to be used for mixing? The problem is that the faders are linear, so with 127 levels, by the time you are down -20 you are 1 click per db instead .1db with 1024. So if you are mixing a hot level, for example, I often record my guitar raw and then add effects later which really adds to the level, so I may be mixing it in quite low, I have bigger steps in my control range. So Allen Heath uses 127 levels on their top end digital control surfaces, How do they do it? Well they have two different scales: - fader: ((Gain+54)/64)*7f - also used for sends - Gain: ((Gain-10)/55)*7f - this is preamp gain I think in both cases only the 7f is hex (their chart is colour coded and hex numbers are blue, decimal are black). SO the fader has two clicks per db from -45 to +10 and the gain value seems to be 9 steps for 4 DB on the bottom (+10 to +22) and slowly increases towards +65 at the top where there are 12 steps for 5db. This means they are starting out with a linear value from the motorized fader (pot or encoder - if it was me it would be an encoder) and prescale it from a higher resolution, or they start with a log pot or encoder in the first place. The fact that they post the formula leads me to believe they do the former (though I think if it was me, I might have an encoder made with that built in). So the problem with 127 levels is not that it is too little so much as how those levels are applied. SO far as I know, all control surfaces on keyboards have linear CC values. The upside of using 127 levels is a lot less MIDI noise. Even though most interfaces not longer go at 30khz, most are 100meg or gig networks, bandwidth for a large number of channels still counts. (plus I think they run audio on there as well) It gets away from using pitchbend for faders with it's built in limit of 16. The upside of using 1024 (or more) levels: It is easy, no need to compute a level. Just like 192 samples/second, it makes for good advertizing. At some levels, it does give finer control... of course by the time you get to -40 or so, you have less resolution than scaled 127 level control. Pots vs. encoders: My preference for encoders is two fold. One, they have a very direct built in relationship between location and value. A pot will be different from one to the next and need to be callibrated once in a while (the Mackie controller has instructions for doing this). Two, there is no wear in the read area as a pot has with a wiper (assuming an optical encoder). They are expensive, but in a $25K control surface, I expect that kind of quality. A rotary encoder with 1024 pulses per rotation is about $50 in singles, One with 8 bits out and 256 states per rev is about $35. The ones used in most control surfaces with the push button are 24 clicks per rev and use mechanical contracts... but cost only $2.50 each, there are actually 96 clicks per rotation, but 4 clicks are required to sense direction (2 bit greycode) so it is possible to go for clicks for the first value and then assume the next click is the same direction from then on. The ones used in a mouse are even cheaper... -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 17 Aug 2014 16:15:58 + Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 17, 2014 at 08:24:38AM -0700, Len Ovens wrote: So Allen Heath uses 127 levels on their top end digital control surfaces, How do they do it? Well they have two different scales: - fader: ((Gain+54)/64)*7f - also used for sends - Gain: ((Gain-10)/55)*7f - this is preamp gain Suppose you have *real* faders which have a range of 127 mm. That's not far from a typical size on a pro mixer. Would you ever adjust them by half a millimeter ? 127 steps, provided they are mapped well, and zipper noise is avoided by interpolation or filtering, should be enough. The real problem is that many SW mixers * don't use a good mapping, * and don't have any other gain controls. The latter may force you to use the fader in a range where it has bigger steps. Ciao, Well that got me thinking! Presumably this should be set up as a proper log law, so even if the steps represent (say) 0.5dB that still gives a control range of over 60dB -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 17 Aug 2014, Will Godfrey wrote: On Sun, 17 Aug 2014 16:15:58 + Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 17, 2014 at 08:24:38AM -0700, Len Ovens wrote: So Allen Heath uses 127 levels on their top end digital control surfaces, How do they do it? Well they have two different scales: - fader: ((Gain+54)/64)*7f - also used for sends - Gain: ((Gain-10)/55)*7f - this is preamp gain Suppose you have *real* faders which have a range of 127 mm. That's not far from a typical size on a pro mixer. Would you ever adjust them by half a millimeter ? 127 steps, provided they are mapped well, and zipper noise is avoided by interpolation or filtering, should be enough. The real problem is that many SW mixers * don't use a good mapping, * and don't have any other gain controls. The latter may force you to use the fader in a range where it has bigger steps. Well that got me thinking! Presumably this should be set up as a proper log law, so even if the steps represent (say) 0.5dB that still gives a control range of over 60dB Actually, I got the idea that we should not only do that, but that we should use a gain or trim to put the signal in the area (level wise) where we have the smallest gain steps. On a DAW, we sort of do this already by recording using the fader (and audio device gain) for trim and then mixing down using the fader for fine tuning. However, as I commented earlier, sometimes a harsh effect can introduce the need to: - re-record the track - add a gain section after the effect(s) before the fader. This may be as simple as using the output level the effect already has. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sun, 17 Aug 2014, Will Godfrey wrote: On Sun, 17 Aug 2014 16:15:58 + Fons Adriaensen f...@linuxaudio.org wrote: On Sun, Aug 17, 2014 at 08:24:38AM -0700, Len Ovens wrote: So Allen Heath uses 127 levels on their top end digital control surfaces, How do they do it? Well they have two different scales: - fader: ((Gain+54)/64)*7f - also used for sends - Gain: ((Gain-10)/55)*7f - this is preamp gain Suppose you have *real* faders which have a range of 127 mm. That's not far from a typical size on a pro mixer. Would you ever adjust them by half a millimeter ? 127 steps, provided they are mapped well, and zipper noise is avoided by interpolation or filtering, should be enough. The real problem is that many SW mixers * don't use a good mapping, * and don't have any other gain controls. The latter may force you to use the fader in a range where it has bigger steps. Well that got me thinking! Presumably this should be set up as a proper log law, so even if the steps represent (say) 0.5dB that still gives a control range of over 60dB I forgot to add: I would think ((Gain+54)/64)*7f uses a lot less CPU time than a real (proper) log. Think 8 fingers (plus thumbs?) fading around 80 steps in a small time. Remember that this calculation has to be done at both ends too and the receiving end also has to deal with doing more calculation on as many as 64 tracks of low latency audio at the same time (amongst other things). Also remember, this is only of use if you are building a control surface (I am) and not buying one where you get what you get. Add to that, even if you are building your own control surface, do you want to use Yet Another standard that you then have to make middle-ware for so that the SW you are talking to will understand? AH does supply middle-ware (for OSX) that takes the above values and converts them (both ways) so that their control surface looks to the sw like a Mackie (just about put Wackie) control surface. Talk about lot of computations in you music box! -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 2014-08-16 at 03:00 -0400, Tim E. Real wrote: One can use the pitch wheel for something other than pitch. It is per-channel. You can have up to 16 14-bit pitch wheels (or knobs/sliders/etc), per interface, each routed to whatever you want. You would just have to reserve some channels, or even a whole interface. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014 11:32:06 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: 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. All computers do that. Just put a DI-box with ground lift between your audio interface and the speakers and the noise is gone. Dennis ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Saturday 16 August 2014 06:49:59 Dennis Schulmeister did opine And Gene did reply: On Sat, 16 Aug 2014 11:32:06 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: 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. All computers do that. Just put a DI-box with ground lift between your audio interface and the speakers and the noise is gone. Dennis And get someone electrocuted. That doesn't happen on my watch because they'll never get it plugged in, I would not allow it. There are several ways to fix a noise inducing ground loop, but a ground lift adapter is not one of them. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014 09:30:51 -0400 Gene Heskett ghesk...@wdtv.com wrote: And get someone electrocuted. That doesn't happen on my watch because they'll never get it plugged in, I would not allow it. There are several ways to fix a noise inducing ground loop, but a ground lift adapter is not one of them. Thanks Gene, and I so totally agree! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
A DI-box with transformers galvanically isolates, but I won't discuss ground loops and ground lifts. Isn't the digital noise audible regarding to electric smog inside the computer? Hm? By a short test I couldn't hear the digital noise from an ADA8000 output (but mains hum and/or a ground loop is audible from the ADA8000 [1]). The digital noise seems to come only from the RME PCIe card's analog IOs. Anyway, I mentioned this kind of noise, because many computer home studios suffer from this noise and MIDI data caused by pitch bend could become audible, while controllers that send less data usually aren't audible. Regards, Ralf [1] I get this hum from analog audio only from some Behringer equipment, one device was repaired by Behringer, there are no issues with gear from other vendors. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, Aug 16, 2014 at 09:30:51AM -0400, Gene Heskett wrote: All computers do that. Just put a DI-box with ground lift between your audio interface and the speakers and the noise is gone. Dennis And get someone electrocuted. That doesn't happen on my watch because they'll never get it plugged in, I would not allow it. There are several ways to fix a noise inducing ground loop, but a ground lift adapter is not one of them. A DI-box with ground lift does not interrupt safety ground. It just ensures that there is no ground connection via the audio path. Both items connected to it will (should) still have their own safety ground. Whether it will reduce interference from MIDI in a sound card is questionable. MIDI is isolated anyway. If anything of it leaks into the analog audio path that means the sound card has a problem. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014 18:01:12 +0200 Ralf Mardorf ralf.mard...@alice-dsl.net wrote: A DI-box with transformers galvanically isolates Absolutely. That's why I said put a DI-box in between. Isn't the digital noise audible regarding to electric smog inside the computer? My experience is that the noise comes from the ground-wire and that the ground-lift kills the noise completely. Dennis ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Aug 16, 2014, at 12:09, Fons Adriaensen f...@linuxaudio.org wrote: Whether it will reduce interference from MIDI in a sound card is questionable. MIDI is isolated anyway. If anything of it leaks into the analog audio path that means the sound card has a problem. DIN MIDI is isolated, but more and more devices use USB for MIDI, which is not isolated. Big step backwards! Any device that has both audio I/O on analog cable and also USB MIDI is an immediate suspect when digital hash shows up in my audio signals. Thanks, Bill Gribble ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 2014-08-16 at 16:09 +, Fons Adriaensen wrote: On Sat, Aug 16, 2014 at 09:30:51AM -0400, Gene Heskett wrote: All computers do that. Just put a DI-box with ground lift between your audio interface and the speakers and the noise is gone. Dennis And get someone electrocuted. That doesn't happen on my watch because they'll never get it plugged in, I would not allow it. There are several ways to fix a noise inducing ground loop, but a ground lift adapter is not one of them. A DI-box with ground lift does not interrupt safety ground. It just ensures that there is no ground connection via the audio path. Both items connected to it will (should) still have their own safety ground. Correct! Whether it will reduce interference from MIDI in a sound card is questionable. I guess it wont reduce this kind of noise. MIDI is isolated anyway. If anything of it leaks into the analog audio path that means the sound card has a problem. Increase the volume and you will hear digital noise from the analog IOs of a card inside of the computer. Move the mouse and extra noise will be audible, no MIDI is needed to get annoying noise. MIDI noise is very silent compared to mouse noise, but there is some noise. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014, Tim E. Real wrote: Pitch bend, which the mackie faders use, is specified in the MIDI standard and in the MCP spec as: Ex yy zz in one event. Correct. Pitch bend is the only truly 14-bit encapsulated message. There is also one more, real time Song Position Pointer (F2, LSB, MSB). I think it is 12-bit though. One can use the pitch wheel for something other than pitch. It is per-channel. You can have up to 16 14-bit pitch wheels (or knobs/sliders/etc), per interface, each routed to whatever you want. 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. You would just have to reserve some channels, or even a whole interface. Yay Mackie! And others doing this. That is the way my project is set up. (well the config file I am using right now) But do I wish MIDI had included at least one /more/ encapsulated 14-bit message per channel. 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... I am well aware that controllers are 7 bits in an event. The MIDI standard does double up some of them for 14 bit, I think you are referring to what I will call 14-bit aggregate 7-bit controllers, as opposed to 14-bit (N)RPN controllers. Yes, nrpn is actually a take off on them. It uses one of those pairs with two othe data bytes in front but I am not aware of anyone who uses them. In my searches for products/software that use them I have seen a few. Good to plan for it anyway. I think ALSA can use it too - I think it is one of the event types. 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. Speaking of which... I was looking at the MIDI codes for some more upscale Control surfaces: Allen Heath iLive control surfaces Yamaha CL series mixers Both of these use NRPN (Non-Registered Parameter Number) for some of their Wow, so they just ate up 16,384 available 7-bit NRPN controllers. That's an entire interface full. Any 14-bit controllers at all on these AH models? If so, do they have detailed info on exactly how it is sent, and options? If not, do you have a way of reading what comes out of them (and when)? 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 AH 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
Re: [LAD] [LAU] Ardour MIDI tracer
The JACK MIDI API delivers and acccepts normalized MIDI data ONLY. No running status. No clever merging or filtering. Bytes in... bytes out. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014, Paul Davis wrote: The JACK MIDI API delivers and acccepts normalized MIDI data ONLY. No running status. No clever merging or filtering. Bytes in... bytes out. That makes perfect sense. That way the application designer can expect all MIDI events to be the same way. How about MIDI in from physical MIDI ports that has running status? Are those then converted to normalized events? That does then ask the question if Ardour's midi mapping for control surfaces can accept multi-event commands. I can see that dealing with controller data has some way to go. I would like to help, but am not a c++ programer. Not great at c for that matter. I can see that MIDI/OSC control is tied to the keyboard interface and if there is no keyboard shortcut for a function then MIDI cannot trigger it either. There are relatively few extras in the Control section such as banks. Channel select seems to have some extra stuff too. Adding the mixer strip to the editor means tha select pops the right channel in there. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, Aug 16, 2014 at 4:13 PM, Len Ovens l...@ovenwerks.net wrote: On Sat, 16 Aug 2014, Paul Davis wrote: The JACK MIDI API delivers and acccepts normalized MIDI data ONLY. No running status. No clever merging or filtering. Bytes in... bytes out. That makes perfect sense. That way the application designer can expect all MIDI events to be the same way. How about MIDI in from physical MIDI ports that has running status? Are those then converted to normalized events? the bridge client/code that interacts with the physical port is expected to normalize incoming messages that use running status. not doing so violates the API contract. That does then ask the question if Ardour's midi mapping for control surfaces can accept multi-event commands. ardour maps can be bound to arbitrary byte sequences but i am not convinced they will work for multiple events. not something i've ever tried or thought about. I can see that dealing with controller data has some way to go. the problems with controllers come from the almost absurdly varied ways that h/w manufacturers have chosen to use them. I would like to help, but am not a c++ programer. Not great at c for that matter. I can see that MIDI/OSC control is tied to the keyboard interface and if there is no keyboard shortcut for a function then MIDI cannot trigger it either. not true. any action defined in Ardour can be bound to OSC. there is no linkage between the keyboard shortcuts and OSC. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 2014-08-16 at 09:45 -0700, Len Ovens wrote: 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. I disagree. I never heard zipper noise, when I fade in or out or when using MIDI panning. Usually those steps aren't audible when fading or panning, but I often missed steps for static levels. Speaking for synth from the 80th and 90th, for the panning synth usually didn't use all 128 values, but 128 steps usually are used for the volume. I don't remember audible steps when fading, but I remember that there were not enough steps for optimal mixing. YMMV! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Ardour MIDI tracer
On Sat, 16 Aug 2014, Paul Davis wrote: On Sat, Aug 16, 2014 at 4:13 PM, Len Ovens l...@ovenwerks.net wrote: I can see that dealing with controller data has some way to go. the problems with controllers come from the almost absurdly varied ways that h/w manufacturers have chosen to use them. Yes, I have gone through Ardour's midi maps and read as many other documents as I have had time for. They are all different. that matter. I can see that MIDI/OSC control is tied to the keyboard interface and if there is no keyboard shortcut for a function then MIDI cannot trigger it either. not true. any action defined in Ardour can be bound to OSC. there is no linkage between the keyboard shortcuts and OSC. As always, with any one answer there are 5 new questions, (I hope less) I was basing my statement on: http://manual.ardour.org/using-control-surfaces/midi-binding-maps/ The best place to look for the (long) list of how to address each item is in your keybindings file, which will contain lines that look like this: Is there any relation between the list of available actions keys can be bound to and the OSC actions at all? Is the MIDI interface more closely related to one than the other? I found an OSC monitor, but can't seem to get it to see ardour... I am pretty sure I am doing something wrong. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
