2014-07-16 20:13 GMT+02:00 Aaron L. <elmastero74(a)gmail.com>om>: Thank you. Yes they are. The overhead micing technique is ORTF -- Carlo Ascani | carlorat.me skype: carloratm irc: carloratm@freenode

On 22/07/14 05:52, Robin Gareus wrote: Some great advice someone gave me was to play some music you are very familiar with on your monitors before the mix session to "tune" your ears to the monitors. With the "ear tuning" tip you can get good results with any half decent monitors. A friend of mine has some awful Samson monitors but manages acceptable results. I got some new monitors a while back and auditioned a few including KRK. I ended up getting Adam A5X and am very pleased with them. Happy mixing Roger

Hello there, I synthesized sounds of drums here: http://www.letime.net/vocale/lmmodel1jo.tar.gz to compile use qt5 and sox with a video but my microphone is broken http://youtu.be/NvUZO01-ZOI?list=UU8nvL7tmlr6UxwggMIZbCEg <http://youtu.be/NvUZO01-ZOI?list=UU8nvL7tmlr6UxwggMIZbCEg> Essayez avec cette orthographe : *désolé* pour mon pauvre langage anglais sorry for my poor English language 2014-07-22 8:36 GMT+02:00 Carlo Ascani &lt;carlo.ratm(a)gmail.com&gt;om>:

On Tue, Jul 22, 2014 at 08:36:32AM +0200, Carlo Ascani wrote: I've got a similar setup: 512M, Arch + windowmaker, but can't get A3 to run on it in any usable way - it just eats too much memory. Any tricks ?? 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)

Carlo Ascani wrote: Is it your plugins that are so heavy, or the app the hosts them? Just as there are lightweight window managers around, there are also some lightweight audio processing hosts, such as Ecasound, which is reasonably convenient to use when managed by Nama. -- Joel Roth

On Mon, Jul 21, 2014 at 11:19:47PM -1000, Joel Roth wrote: It's A3 taking something like 330 MB just for an empty session. The only thing I'd want to do with this system is recording (which worked perfectly well for years using A2), no plugins or anything else. I replaced A3 with a simple GUI app doing multichannel recording, metering, playback and a stereo monitor mix with EQ, solo, mute and two aux sends, but ATM no editing. It also allows to set markers and maintain a detailed cue sheet of the recording. It does all I need for a typical classical music production or live session and takes less than 1/10 of the memory plus 1M per channel. Maybe I'll add 3 and 4pt editing, that would make it complete. 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)

On Tue, 2014-07-22 at 13:34 +0200, Ralf Mardorf wrote: PS: I forgot to mention that Ray Rashif sent me a link to an Arch i686 architecture version, ardour2-svn-8472-2-i686.pkg.tar.xz : http://repo.obsoleteaudio.org/i686/

On Tue, 2014-07-22 at 22:59 +0100, James Morris wrote: I didn't use Ardour for a while, I wonder if my old version is broken. Indeed, building ardour2 fails. [rocketmouse@archlinux ~]$ pacman -Qi ardour aubio Name : ardour Version : 2.8.16-1 Description : A multichannel hard disk recorder and digital audio workstation Architecture : x86_64 Name : aubio Version : 0.4.1-1 Description : A tool for extracting annotations from audio signals Architecture : x86_64 [rocketmouse@archlinux ~]$ yaourt -S ardour2 Looks like the "aubio" package is the issue. Ardour2 will not build against the current 0.4.1 package. [snip] In file included from libs/vamp-plugins/plugins.cpp:44:0: libs/vamp-plugins/Onset.h:60:5: error: ‘aubio_pickpeak_t’ does not name a type aubio_pickpeak_t *m_peakpick; ^ libs/vamp-plugins/Onset.h:61:5: error: ‘aubio_onsetdetection_t’ does not name a type aubio_onsetdetection_t *m_onsetdet; ^ libs/vamp-plugins/Onset.h:62:5: error: ‘aubio_onsetdetection_type’ does not name a type aubio_onsetdetection_type m_onsettype; ^ scons: *** [libs/vamp-plugins/plugins.os] Error 1 scons: building terminated because of errors. ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build ardour2.

Hi, Let me pick up this thread again. On 07/22/2014 11:54 AM, Fons Adriaensen wrote: It's amazing, even my now almost 7 year old Thinkpad came with 2GB RAM, and asking around, most people have at least 4, or 8 GB RAM these days. Still, Ardour3's memory usage just became [much] better. (git cairocanvas branch) yes, see below. An empty session is down to 96MB RSS now, (20MB on the heap, the rest for code+stacks), a bit more when running with jackd instead of Ardour's ALSA backend (100-200MB depending on jack's i/o count - but that mem is shared with jackd and actually jackd's). Adding a track to ardour adds about 2MB per channel (default 5 sec buffers @48KSPS for in/out) to that. Previously an empty session took around 300MB RSS here. Depending on how you do statistics, that's an improvement of over 300%. To optimize further: Compiling ardour without lv2 and VST support can help. The initial plugin scan (at application start) can still use quite a bit, depending on the number of plugins and the plugins themselves. That memory is now free()ed before the session is loaded, but there can be initial peaks. There are a few more places where memory consumption could be optimized but the time it'd take to squeeze out the last few MBytes is likely worth much more than buying all remaining users with only 512MB RAM an extra GB :) Kudos to the valgrind team and their brilliant massif tool! Cheers! robin

I feel awkward giving advice to a knowledged dsp programmer, but maybe this will help you. I have an old desktop with a celeron 440 2GHz CPU, and 1GB of RAM (which run on 512MB for a month before the upgrade) which performs quite good after doing the following: Replace systemd with something lighter, like minirc https://github.com/hut/minirc It might be painful depending on what services you run on startup. If you stick to defaults, you're mostly covered. Of course you can't load any extra services, but if you use http://dwm.suckless.org/ you're cutting a lot. I've once compiled X myself and it worked better and was softer on memory, but I don't have benchmarks. Also, disable unused ttys. dwm is extremely handy to me. It's got 3 default view modes, monocle (apps cover whole screen), tile, and floating. All of this under 2000 lines of C code. With patches you get almost any thinkable split mode. The key bindings are vi-based so it's easy to learn them if you used the editor. Everything is customizable before compiling. I should mention that I also custom config my kernels and strip any foreign thing. That makes my atom N270 netbook use 90mb of ram before starting X (which I do through xinit with an .xinitrc). I don't think one can go further than this without cutting needed functionality. But I'm sure qtractor would run on your P4 this way. Bye!

2014-07-22 8:36 GMT+02:00 Carlo Ascani &lt;carlo.ratm(a)gmail.com&gt;om>: Carlo, from here also thanks for sharing your experience. I've used Raspberry PI for jamming live and recording, a P4 with 512MB for rec/mix/master/..., and other PC/laptops with more power, and it all went OK, just with Ardour2/QTractor for many years now, using Raspbian and Musix distros mainly. Haven't yet tried Ardour3 until we compile it for Musix or have some repos for it. I mean, you can record a decent drumkit sound with a pair of mics, In your case you used 8 (which is not easy at all, considering leaks and phase issues) and a P4 and you achieved a great raw sounding that you can later sculpt to your taste. I try to put in practice that of "less is more" (you'll find that most of the publicity of most products tell you almost the opposite). A good source is the key, and I think that with some knowledge, good taste and a relative good pair of ears, you can achieve at least acceptable results with any equipment. You did it, so congrats. And would be great to hear this in context: song, album... --- C. sanchiavedraZ: * NEW / NUEVO: www.sanchiavedraZ.com * Musix GNU+Linux: www.musix.es