Linux-audio-user November 2012

linux-audio-user@lists.linuxaudio.org

104 participants
103 discussions

by Brett McCoy

A doom metal tune with a retro feel that a buddy and I worked up for Halloween -- sequenced and recorded in Ardour 3b5*, mixing and final mastering done with MixBus 2.2 with Jamin + LinuxDSP plugins (and some experimenting with the new "Essentials" plugins for MixBus) https://soundcloud.com/brett-mccoy/alhazred-dead-before-dawn *vocals & bass were recorded on a Mac with GarageBand -- Brett W. McCoy -- http://www.brettwmccoy.com ------------------------------------------------------------------------ "In the rhythm of music a secret is hidden; If I were to divulge it, it would overturn the world." -- Jelaleddin Rumi

12 years, 4 months

Re: [LAU] looking for command-line/scriptable mastering software

by Ralf Mardorf

On Sun, 2012-11-25 at 20:23 +0000, Fons Adriaensen wrote: > On Sun, Nov 25, 2012 at 12:05:44PM -0800, J. Liles wrote: > > > You're not likely to get any respect from this community unless/until you > > release your source code under a free/libre license. Who have spent decades > > and 10's of thousands of hours working on projects that we give away freely > > and openly, your software is irrelevant and your request for respect is > > borderline insulting. > > If anything is 'borderline insulting' it's IMHO the above. > > While I can't imagine any good reason for keeping mixer4 source > code closed, the only consequence this should (and will) bring > is the reduced amount of support the author will get from this > (LAU/LAD) community. It should not be any pretext for ad-hominem > comments. And don't forget that many on this list are using things > like Mixbus. Is Harrison 'borderline insulting' as well ? +1 We are living in a free world. I prefer open source, but if somebody has what ever reason not to open the source code, I can decide if I'll use it or not, no need for that noise.

12 years, 4 months

Re: [LAU] looking for command-line/scriptable mastering software

by Ralf Mardorf

On Sun, 2012-11-25 at 15:01 -0500, Al Thompson wrote: > Yes, FM receivers switch to mono when reception is problematic, but > also, because of the L-R, L+R FM stereo derivation, out of phase > content causes problems. I don't remember the details because a) it > was 40 years ago when I studied that, and; b) the majority of music > doesn't have considerable out of phase content, so it's not something > I've been overly concerned with. Mono compatibility is always important. First off all there is still much "phase content" and beside that other things are important, e.g. the sentiment we've got of a ping-pong delay could become completely different from hard left-right to mono.

12 years, 4 months

Re: [LAU] looking for command-line/scriptable mastering software

by grekimj＠acousticrefuge.com

BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; Also consider to what happens when the stereo signals are summed to mono. If your panner is set slightly off-center, L and R will have nearly the same gain (since they need to be identical for a center source) and a delay between them of a fraction of a millisecond or so. Summing L and R will result in quite strong comb filter effects. Thanks for starting some thoughts on the time alignment aspects. Yes, I did make that provision for a mono source, so that the same signal level is added to L and R whether panned or not, but just time shifted in one channel if panned. And full left or full right is a separate 'function' and only has signal in one side. I will add the traditional pan. Is mono compatibility really worth worrying about these days? Because I do not just record signals directly from the A/D converters, but also signals that have already had some processing and probably will have some more later. All serious audio processing in Linux (and in almost all environments where audio is processed digitally) is done in floating point format, for good reasons. Why should I convert each time I read or write a file ? That would only add errors. Okay, makes sense. You could probably eliminate a lot of code by using something like libsndfile. And you would at least be able to read floating point files. I can see also adding options for things like LADSPA or LV2. But, I'd also like the code to run if these things are not present in the system. If all filtering, effects, etc. is done in FP format, it's plain silly to convert to integer just to add some values. And adding also happens even when you don't see it explicitly. Any linear filter is defined by its impulse response. Depending on the type of filter that could be hundreds or even thousands of samples long. So every output sample is a weighted sum of hundreds or thousands of input samples even if not computed explicitly that way. Are you really claiming that doing that in FP is OK while adding a few signals on a mix bus isn't ? There are a couple of outstanding (commercial) fixed point filters out there, by the way. To answer your question, no I basically agree with you. But realize the initial challenge of this project was to make an absolutely pure signal path. And that path is still there if you choose to not use effects. When you do use effects it's 64 bit float because I am wary of 32 bit float. Quote from the Quick Start Guide: There are 3 text files that control Mixer4 and they must be kept in the same directory, at least for now, as the Mixer4 executable. Okay, I thought that's where the confusion was. 'For now' is referring to walking the user through the set up process, not the state of the code. I did not want to get into different directories for the newbie user. I wanted to make initial setup as straight forward as possible. Grekim On Fri 23/11/12 4:34 AM , Fons Adriaensen fons(a)linuxaudio.org sent: On Thu, Nov 22, 2012 at 10:26:10PM -0500, Grekim wrote: > /Maybe neat on headphones, but definitely the wrong thing for > reproduction on speakers. Also bad for mono compatibility. > And since it's closed source it's not possible to change > this to normal panning, which would be a trivial exercise > otherwise./ > > I'd like to learn more about why it's so wrong. There's no one-line answer to that. To understand why it's wrong you have to work out how the signals from the two speakers combine at the ears and compare the result to what happens for a real sound source. For low frequencies the analysis is very simple, you can do it in two minutes just using pencil and paper. Just do it and you'll see. For mid an high frequencies it gets considerably more complex and a lot of psycho-acoustics is involved. The results go against simple intuition, which is why many people have some difficulty accepting them. Also consider to what happens when the stereo signals are summed to mono. If your panner is set slightly off-center, L and R will have nearly the same gain (since they need to be identical for a center source) and a delay between them of a fraction of a millisecond or so. Summing L and R will result in quite strong comb filter effects. > /I've got ~3TB of floating point files here, and I'm not going > to convert them just to be able to use a particular - any - SW./ > > Why did you record in floating point format if your A/D converters are not? Because I do not just record signals directly from the A/D converters, but also signals that have already had some processing and probably will have some more later. All serious audio processing in Linux (and in almost all environments where audio is processed digitally) is done in floating point format, for good reasons. Why should I convert each time I read or write a file ? That would only add errors. A/D and D/A converters are probably the only components in the chain that 'naturally' use an integer format. But even that isn't really true any more. Most high quality converters are not just the bare converter and an analog filter. They have some digital processing going on between the SW interface and the actual converters, e.g. most of the anti-alias filtering will be done digitally in an oversampling converter. And that processing could very well be done in FP format these days. Some high end sound cards (e.g. RME) have native floating point interfaces. There is nothing magic about the 2^16 or 2^24 analog levels that correspond exactly to integer sample values. Change your gain by 0.1 dB and they will be an entirely different set, as good or as bad as any. > / > The summing being exact is quite irrelevant if the rest isn't, > and doesn't need to be anyway./ > > Sorry it's not relevant to you. Aside for the latest version which > does use ALSA, I have about 4 C header files. So there's no libsend > file or anything like that. You could probably eliminate a lot of code by using something like libsndfile. And you would at least be able to read floating point files. If all filtering, effects, etc. is done in FP format, it's plain silly to convert to integer just to add some values. And adding also happens even when you don't see it explicitly. Any linear filter is defined by its impulse response. Depending on the type of filter that could be hundreds or even thousands of samples long. So every output sample is a weighted sum of hundreds or thousands of input samples even if not computed explicitly that way. Are you really claiming that doing that in FP is OK while adding a few signals on a mix bus isn't ? Regarding the latter, it may also help to analyse the situation a bit more rigorously before jumping to easy conclusions. It involves a bit of maths, but nothing esoterical. > /OK, then the info on your site is out of date.../ > > Don't think so. Quote from the Quick Start Guide: There are 3 text files that control Mixer4 and they must be kept in the same directory, at least for now, as the Mixer4 executable. 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)

12 years, 4 months

Synths for live use

by James Stone

Does anyone have any suggestions? Ideally should be lightweight (capable of running on an old eeepc 701), lots of control possibilities (interact with controls via midi knobs), rock solid stable, possible to recall state from command line. Not all of these are essential but I would like it to start up and interact with my kb without too much typing on-stage! I do have a real soft spot for whysynth but the midi learn and recall of state seem tricky/impossible with ghostess? I would also like suggestions for organs (Beatrix?), electric pianos, romplers.. I am seriouslh considering a solid state keyboard or sound module, but it seems it should be possible with linux... Suggestions for reasonably priced hardware (2nd hand?) Options would also be interesting... J

12 years, 4 months

[Fwd: Re: [OT] Beers for live use]

by Ralf Mardorf

-------- Forwarded Message -------- From: Ralf Mardorf <ralf.mardorf(a)rocketmail.com> To: linux-audio-user(a)lists.linuxaudio.org Subject: Re: [LAU] [OT] Beers for live use Date: Sun, 25 Nov 2012 19:50:43 +0100 On Sun, 2012-11-25 at 18:31 +0000, Folderol wrote: > Can you imagine the effect on the audience if we had two musicians playing 4 > keyboards all driving one instance of yoshi :) Something that already could be done with MIDI and computers since MIDI was invented. Yoshimi is good software, that should carry weight. Two musicians playing one synth by 4 keyboards is something very usual.

12 years, 4 months

Music made with Linux: spooky game soundtrack

by Leigh Dyer

Hi all, I know Halloween has passed now, but in the run-up to it I recorded a track to be used as background music for a game being developed by a friend of mine. It's a fun, lighthearted game, so I went with a "kooky" feel rather than anything genuinely scary. You can hear it here: http://pneuman.bandcamp.com/track/main-theme or here, for the ogg-inclined: http://wootangent.net/~lsd/music/switchbreak/candygrappletheme.ogg The harpsichord is Pianoteq, as is the piano in the bridge; the theremin-like sound is a patch on my Waldorf Blofeld; and the tuba and organ are both from the Fluid GM soundfont -- I wouldn't normally reach for a GM sound set when looking for instruments, but in this case they both worked really well. The random bits of percussion from SSO. All sequenced and recorded in Ardour 3! Thanks Leigh

12 years, 4 months

Re: [LAU] RTC/HPET timer permissions

by Ralf Mardorf

On Sun, 2012-11-25 at 03:59 -0600, Brent Busby wrote: > Long ago, I've read many people recommending setting relaxed permissions > on /dev/rtc for using programs like Muse, and I remember back in the > early 2000's even seeing MPlayer requiring this and complaining on the > console when it couldn't get it. > > Pretty much all distros now set default permissions of 0600 root:root on > /dev/rtc now, and MPlayer works now anyway. Is it still necessary or > recommended these days for proper operation of audio apps to have a > user-accessible /dev/rtc? Is there a security risk? Do regular users > need write access, or would a mode like 0640 root:realtime be > sufficient? > > Also, I notice there is a /dev/hpet node too. Same questions apply > there, since I would imagine HPET gives the best time of all. Hi Brent, I still run sudo chgrp audio /dev/hpet ; sudo chmod g+rw /dev/hpet ; sudo modprobe snd-hrtimer for my scripts to start audio sessions, since the question isn't what might be or not be needed. It's also important to be backwards compatible. I notice that for Linux nowadays nobody does take care about this. If application A doesn't do what it should do and does for the last years, simply switch to application B and don't use all the important private data of the last years any more or don't expect your scripts that set up special conditions for some needs by e.g. stopping a service, to work any more. So what ever should be needed to temporarily enable hr timer usage today, IMO it's important that it does work for your machine using alpha software and for your 4 years old stable DAW. 2 Cents, Ralf

12 years, 4 months

Re: [LAU] [OT] Beers for live use

by Charles Henry

On Sat, Nov 24, 2012 at 7:10 PM, Charles Henry <czhenry(a)gmail.com> wrote: > It's quite easy to avoid the major brands in the US, with new > micro-breweries popping up all the time. Colorado beer is amazing--there > are so many good breweries in the eastern part of the state. > Pilsner is my favorite kind of beer, but it's hard to find an authentic > one in the US (KC's Boulevard Pilsner is not even close). Even if it is > SABMiller, I'd go for a Peroni any time, but the only one I can get is > Nastro Azurro (which is equivalently disgusting as a Rolling Rock as far as > I can tell). > > I am currently serving a Belgian golden ale I brewed a month ago. > Everything seemed to go wrong--for example, the mash got too hot, the gruit > was badly prepared, and I came up 2L short on volume during bottling. > Still, it turned out to be very tasty, but not perfect. I will have to > brew again next month to get it just right. Duvel costs about $6 a bottle > here. I had one last week, it was almost worth it. > > As for coding--well, I don't know. Seems I should spend less time > brewing. My preference would be to spend less time working, but we all > know how that goes :) >

12 years, 5 months

OT: Synths for live use

by Ralf Mardorf

On Thu, 2012-11-22 at 12:53 +0100, Jeremy Jongepier wrote: > On 11/22/2012 12:32 PM, Ralf Mardorf wrote: > > Even changing sub-pixel order for the fonts etc. doesn't work. > > Recently I had the same issue. Turned out the monitor settings were > wrong and sharpness was set way too high. > > Regards, > > Jeremy Deleting ~/.cache fixed it.

12 years, 5 months

← Newer
1
2
3
4
5
6
7
...
11
Older →

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-user November 2012