Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

Audio engineering myths - Was: Half-OT: Fader mapping - was - Ardour MIDI tracer

by Ralf Mardorf

JFTR some kinds of special audio effects people often think they are inventions of the digital age already were done in the year I was born. Audio engineering in the early days https://www.youtube.com/watch?v=hnzHtm1jhL4 pitch shifting while keeping the length without digital algorithms :D. Since I'm a child from the 80th born in 1966, there's a remake from Jello Biafra's The last temtation of reid in 1990: https://www.youtube.com/watch?v=PQ0VMDmGdx0

11 years, 2 months

Half-OT: Fader mapping - was - Ardour MIDI tracer

by Grekim Jennings

> On Sat, 2014-08-23 at 07:56 -0400, Grekim Jennings wrote: > > I have a Presonus Audiobox which can sound fine for an acoustic > > guitar, but throw a drum at it and it is automatically over full > > scale and unusable. > > Actually you cant blame a preamp, if the microphone is missing a PAD > switch. A pad would solve the problem, but it's hardly a requirement of a good microphone and a purist would probably say it's a bad idea to add that to a mic. It's just not a professional preamp so I didn't have high expectations.

11 years, 2 months

Re: [LAD] [LAU] Ardour MIDI tracer

by Len Ovens

On Sun, 17 Aug 2014, Will Godfrey wrote: > On Sun, 17 Aug 2014 16:15:58 +0000 > Fons Adriaensen <fons(a)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? A&H 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

11 years, 2 months

Re: [LAD] [LAU] Ardour MIDI tracer

by Tim E. Real

On August 15, 2014 05:24:51 PM Len Ovens wrote: > On Fri, 15 Aug 2014, Paul Davis wrote: > > On Wed, Aug 13, 2014 at 10:16 PM, Len Ovens <len(a)ovenwerks.net> wrote: > > Is it just me? Has anyone else looked at pitch bend events on the > > Ardour MIDI Tracer? Quick test: > > > > ================================================ > > - edit->Preferences->Control surfaces. > > - select both enabled and feedback for generic MIDI. > > - double click on it and select bcf2000 with mackie protocol > > - open an external midi monitor (using qmidiroute here) and connect > > it to > > Ardours MIDI control out. > > - also open Ardours MIDI tracer window and connect it to the same > > output. > > (Now qmidiroute will be in decimal and MIDI Tracer is hex..) > > - use the mouse to move the gain up and down on channel one with an > > audio track. > > ================================================= > > > > the trace shows MIDI messages. there are no 10 or 14 bit MIDI messages. > > only "controllers" with 14 bit state. 14 bit state is sent as two > > messages (when necessary). the tracer shows each individual message. > > 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. You would just have to reserve some channels, or even a whole interface. Yay Mackie! And others doing this. But do I wish MIDI had included at least one /more/ encapsulated 14-bit message per channel. > WHere x = channel, yy = LSB > (7 bits) and zz = MSB (7 bits). This is one event. This the way I send > fader info to Ardour and It is also the way Ardour sends info back to me > when I use a mouse to move a fader. Lets compare the output of the tracer > with qmidiroute: (using fader5 as happens) > > tracer db qmidiroute midi > =========================================================================== > Pitch Bend chn 5 1a -0.5 Ch 5, Pitch 4378 (111a) e4 1a 42 > crt/alt/mousewheel down > Pitch Bend chn 5 09 -0.5 Ch 5, Pitch 4361 (1109) e4 09 42 > Pitch Bend chn 5 79 -0.5 Ch 5, Pitch 4345 (10f9) e4 79 41 > There is no second midi event with the msb, this info is missing. > > 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". > 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. > > 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 > messages. The A&H uses this because they have run out of controllers (I > would guess) and still only get 7 bits for their faders. They use three > events, the first one has the mixer channel (as well as the midi channel), > the second has a code for what in the channel it controls (0x17 for fader) > and the third is the data. 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)? NOT with ALSA sequencer or any of the 'snooper' apps I've seen. It must be either a true UART HW project or a low-level API for reading the MIDI data. Does anyone out there know of a *true* sniffer application that handles all 7-bit and 14-bit controller types and displays them conveniently and correctly? > Yamaha uses four events, the first two carrying > the controller number (they have not bothered to group them the way A&H > has) and the last two are MSB and then LSB. The wiki for NRPN says the > controller number for the first two bytes should be 0x63 and 0x62, > however, Yamaha has these listed backwards. As there are other typos in > the same page, this may just be a typo too. These are 14-bit NRPN controllers. > I do not know if the Ardour midimap binding msg="byte byte byte" would > handle this or not. I know Jack would consider this 4 events and probably > not accept just the first status byte with 8 running status data bytes > following as a single event. I think Jack does not care. It simply passes on whatever bytes it receives. This is a blessing for me actually. I have to make my own encoder/decoder (this converts raw 7-bit midi to/from MusE controllers) but at least *I* control what goes on inside there. (I'd like to take this opportunity for a bit of an update): It's been a year since I reported how I was attempting to finish adding true, full 14-bit midi controller support to MusE (that's 7-bit controllers, 14-bit aggregate 7-bit controllers, 7 bit RPN and NRPN controllers, and 14-bit RPN and NRPN controllers). I said I found that ALSA sequencer API doesn't handle 7-bit RPN. And wouldn'tcha know it, my keyboard sends only 7-bit. As I say, it means I have to make my own encoder/decoder. I think possibly the ALSA RAW API is what I want. But MusE uses the ALSA sequencer API, big job to switch to RAW. Fortunately MusE also uses Jack Midi. I said that I /could/ have taken Jack's raw midi data and fed it to/from an ALSA encoder/decoder - but again, no 7-bit RPN. So it's /all/ home-brew for me! Workin' on C++ classes all these months. My efforts are moving along, but slowly. I'm trying to make it a library 'cause it seems useful for other apps, but right now some of it very specific to MusE. Trust me, robust controller support needs some fairly 'acrobatic' code, and user options concerning formatting. Example: I read where one company manufactured a whole line of small embedded midi board products. Only to have a user point out that they didn't do 7-bit RPN conventionally (they used the LOWER 7 bits of data), but the company owner said there was nothing he could do until next designs and he actually argued vigorously that his way was correct (well, he is right but the almost universal convention is the other way - the UPPER 7 bits). See what I mean? I scoured the 'net for product docs and found wide variations in implementations, even though they are all 'correct'. Cheers. Greetings Len. Tim.

11 years, 2 months

Optimisations

by Will Godfrey

A long time ago ... in a land far away :) I did some assembler programming on the Acorn Archimedes (ARM 2/3) and worked out a series of additions and subtractions that would perform very fast multiplication of awkward numbers by known amounts. Is there any point in doing this for C programs, or are modern compilers sophisticated enough to do such things themselves? If anyone is interested *7 is: RSB R1, R0, R0, LSL #3 -- 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.

11 years, 2 months

Re: [LAD] Drivers for RME (USB) MADI device (Madiface XT)

by Jonathan Woithe

On Mon, 11 Aug 2014 15:06:24 +0200 Adrian Knoth wrote: > On 08/11/14 05:47, D. Sen wrote: > > I was advised by Paul Davis to inquire on this list whether there has > > been or is likely to be any activity in developing ALSA drivers for the > > RME Madiface XT device. Its a USB device and as such makes it very > > amenable to a portable audio work. > > > > I have used PCIe based Madiface in the past using ALSA. However, I could > > not get the USB based Madiface XT to work. The device was recognized > > correctly (as per the SYSLOG) - however no drivers were loaded. > > > > Any help would be very much appreciated. > > As I said a year ago, it should also be possible to sniff the USB > connection, but this requires a device and a volunteer to do so. You'd > then run Windows in a VM and capture the USB packets with wireshark or > any other USB sniffer. > > Jonathan Woithe may have additional information, since he wrote the > drivers for FF400 and FF800. The FF400 and FF800 are, obviously, both firewire devices. Due to the bus structure and the way it operates there will be nothing in common between this and any of the RME USB or PCIe interfaces. The drivers for the FF400 and FF800 are in FFADO, and while you may get some high level ideas from things like our mixer interface, unfortunately our existing code is unlikely to provide much in the way of direct assistance when looking at devices using other interfaces. Having gone down the protocol analysis route before (albeit not on the RME devices) what Adrian has suggested is entirely feasible for the USB variant. It will be time consuming, but sniffing the USB bus isn't difficult technically speaking and - most importantly - doesn't require special hardware now we have VMs. Obviously the ideal situation is to obtain documentation from the manufacturers, so contacting them as Adrian suggested would be worth a shot. Regards jonathan

11 years, 2 months

Update of zita-at1

by Fons Adriaensen

Zita-at1-0.4.0 is now avaliable at the usual place: <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html> Bugfixes, MIDI channel selection added. 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)

11 years, 2 months

Stoat 1.0 Release

by Mark D. McCurry

Hello all, The first release of stoat is available. Stoat is a S.T.atic (LLVM) O.bject file A.nalysis T.ool which is a rewrite of sfpv (Static Function Property Verification) due to the very quick bitrot of the clang API (stoat uses only the llvm optimizer pass API). This tool is designed to evaulate if any realtime function can end up calling a non-realtime function eg a jack process callback being able to call malloc or free. It does this by: 1) Using either inline or external function whitelists and function blacklists to establish which functions are safe and unsafe. 2) Extracting a function callgraph (including virtual function calls) from the LLVM IR representation of code (which is effectively one level above assembly) 3) Perform simple deductions based upon the callgraph This approach is designed to work best for C/C++ projects and for realtime verification, but fairly little stops it from generalizing to other languages (assuming the other languages compile with llvm) and other function properties. Existing annotations from sfpv should still work, though the only project that I've seen using them has been jalv so far. As this might seem quite abstract, here is an example usage with non-timeline: http://log.fundamental-code.com/2014/08/15/stoat-tutorial-example Project Home: https://github.com/fundamental/stoat Report bugs to: https://github.com/fundamental/stoat/issues Mark

11 years, 2 months

revisiting pulse and jackdbus

by Len Ovens

On Tue, 12 Aug 2014, Max wrote: >> Pulse on jack. > > Would you suggest that your method is better and should be the > canonical way to do pulse on jack? If so, shall we write up an > alternative WalkThrough on the jackoudio wiki that helps people > setting that up? Something more to add. If you are using a debian based distro (ubuntu for example) the jackd executable needs to be chmod -x or you will find odd things happen if you manage to crash jackdbus. Generally some well meaning program will come along and start jackd making qjackctl of no use and making module-jackdbus-detect unable to set up the pa-jack bridge. The command killall -9 jackd needs to be run. I now concider this has rissen above anoyance to bug. Jackd2 and jackdbus should be packaged separately. If needed the jackdbus version can come with a script that has jack_control's innards, but acts like jackd. (uses jackd's config file and takes jackd's arguments on the CL... may as well give it jackd's name too). For my use, all it would have to do is ignore the arguments and run jack_control start which would restart with the parameters I chose before or do nothing if it is already running. -- Len Ovens www.ovenwerks.net

11 years, 2 months

[ANN] MOD Duo's Kickstarter campaign to be launched in mid September

by Gianfranco Ceccolini

Greetings Linux Audio Users and Developers !!! I'm very happy to inform that we will launch the MOD Duo's Kickstarter campaign in mid September. The MOD Duo is our second model and we've been putting a lot of engineering in it based on the feedback we had from the MOD Quadra experience. We deeply hope it becomes a device that empowers the Linux Audio community, bringing together developers and musicians. A pre-campaign site was created to warm up the communication engines: http://stepontothefuture.com. Hope you all enjoy and spread the word Kind regards Gianfranco Ceccolini The MOD Team

11 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev