10 Oct
2002
10 Oct
'02
4:39 p.m.
This is my first post on this list, so here goes!......
I've had ardour running on my system for a while now and I really like
it. I've now got hold of a second PC which I am gonna dedicate to
running only ardour (on a debian system). Now once I have all set up
and working well, how would I go about booting directly into ardour? Ie
no logins, no fancy window manager just switch on the pc and it boot
into it (and mount some drives on a network). I'd for obvious reasons
have a dual boot config in order to debug and apt update ;)
Thanks for any help given.
Andy.
10 Oct
10 Oct
4:55 p.m.
On Thu, Oct 10, 2002 at 09:38:08 +0100, Andy Main wrote:
running only ardour (on a debian system). Now once I
have all set up
and working well, how would I go about booting directly into ardour? Ie
no logins, no fancy window manager just switch on the pc and it boot
into it (and mount some drives on a network). I'd for obvious reasons
have a dual boot config in order to debug and apt update ;)
I've never used a debian system, but on SYSV style systems you can add a
script to /etc/init.d/ or /etc/rc.d/rc5.d/ that will be run after X has
started.
In redhat you could also tell the system to login as user X when it boots,
and put jack+ardour in that users .Xclients file.
- Steve
6:21 p.m.
another alternative is to use the xinitrc script, which is the template
used by startx. I would use inittab to start the xserver.
On Thu, 2002-10-10 at 15:53, Steve Harris wrote:
On Thu, Oct 10, 2002 at 09:38:08 +0100, Andy Main
wrote:
--
drh(a)niptron.com
Great spirits have always encountered violent opposition from mediocre
minds.
-- Albert Einstein
They laughed at Einstein. They laughed at the Wright Brothers. But
they
also laughed at Bozo the Clown.
-- Carl Sagan
running only ardour (on a debian system). Now
once I have all set up
and working well, how would I go about booting directly into ardour? Ie
no logins, no fancy window manager just switch on the pc and it boot
into it (and mount some drives on a network). I'd for obvious reasons
have a dual boot config in order to debug and apt update ;)
I've never used a debian system, but on SYSV style systems you can add a
script to /etc/init.d/ or /etc/rc.d/rc5.d/ that will be run after X has
started.
In redhat you could also tell the system to login as user X when it boots,
and put jack+ardour in that users .Xclients file.
- Steve
11 Oct
11 Oct
5:03 a.m.
Hi,
Andy Main hat gesagt: // Andy Main wrote:
This is my first post on this list, so here
goes!......
I've had ardour running on my system for a while now and I really like
it. I've now got hold of a second PC which I am gonna dedicate to
running only ardour (on a debian system). Now once I have all set up
and working well, how would I go about booting directly into ardour? Ie
no logins, no fancy window manager just switch on the pc and it boot
into it (and mount some drives on a network).
I think, without a window manager Ardour would be nearly useless. I
didn't work with Ardour for abour a year, but judging from the
screenshots it has multiple windows, that you couldn't move without a WM.
I would also say, that a login manager like xdm/wdm/gdm/kdm doesn't
use much, if any, resources after you logged in. So removing that
wouldn't make the machine faster for Ardour as well. It goes to sleep
and isn't really felt anymore. Some login managers (gdm/kdm) OTOH give
you the nice possibility to directly login a user. That would be the
easiest solution for an automatic login.
Make Ardour faster you should instead check for servers and stuff
running in the background, that you don't need. You might want to make
a runlevel dedicated to audio work. On Debian, you're normally in
runlevel 2 (check with "runlevel"). You could change this default in
/etc/inittab -- make "id:2:initdefault:" to i.e. "id:4:initdefault:"
-- and then rename everything in /etc/rc4.d/ starting with S, that
you don't need to the same starting with K.
Another thing to consider is using ressource friendly applications.
Make something like sWM (www.small-window-manager.de) or at least
blackbox your window manager, use Vim not Emacs, Dillo not Mozilla,
M. Eddington's minibar not the Gnome/KDE-Panel, mc not Nautilus and so
on.
This way, you could get the most out of your (minimalist) machine.
ciao
--
Frank Barknecht _ ______footils.org__
5:38 a.m.
This is my
first post on this list, so here goes!......
I've had ardour running on my system for a while now and I really
like it. I've now got hold of a second PC which I am gonna dedicate
to running only ardour (on a debian system). Now once I have all
set up and working well, how would I go about booting directly into
ardour? Ie no logins, no fancy window manager just switch on the pc
and it boot into it (and mount some drives on a network).
6:50 a.m.
On Fri, Oct 11, 2002 at 10:35:37 +0100, matthew yee-king wrote:
i like the idea of having a dedicated machine for
multitrack audio
BTW... its a bit like a poor mans radar :)
Paul Davis is/was planning to sell machines that do this. More like a rich
mans radar with the hardware he was planning to use though. ;)
- Steve
12:12 p.m.
On Fri, 11 Oct 2002, Frank Barknecht wrote:
Another thing to consider is using ressource friendly
applications.
Make something like sWM (www.small-window-manager.de) or at least
blackbox your window manager, use Vim not Emacs, Dillo not Mozilla,
M. Eddington's minibar not the Gnome/KDE-Panel, mc not Nautilus and so
on.
This shouldn't make a difference in latency. When Ardour is run in
realtime mode, any slowdowns will only make the GUI sluggish. They
shouldn't affect the audio. And hey, this is why I run linux, so that I
can have mySQL, apache, and all running in the background.
Your advice probably holds true for programs that aren't so easily swapped
out, such as window managers though.
Also, in response to your question about why smaller buffers are better:
Yes, a larger buffer reduces dropouts and can be really handy for
recording live. But, the buffer introduces a delay. So if you were to
record one track, and then try and play that track back while recording
another track sync'd to it, a large buffer would make it really difficult.
It's hard for me to explain, easy to demonstrate. Just set jack to use a
large buffer and then try recording a couple tracks in Ardour. You'll
see.
Taybin
--
http://www.piratesvsninjas.com
3:43 p.m.
* Taybin Rutkin <trutkin(a)physics.clarku.edu> [Oct 11 02 11:10]:
Also, in response to your question about why smaller buffers are better:
Yes, a larger buffer reduces dropouts and can be really handy for
recording live. But, the buffer introduces a delay. So if you were to
record one track, and then try and play that track back while recording
another track sync'd to it, a large buffer would make it really difficult.
I don't agree with this. The buffersize introduces delay, but
a completely predictable delay. Its only when you attempt to use S/W
monitoring that this causes a problem for the performer. With H/W
monitoring I very happily run at 2048*2.
--ant
7902
days inactive
7903
days old
linux-audio-user@lists.linuxaudio.org
7 comments
7 participants
participants (7)
-
Andy Main -
Anthony -
D R Holsbeck -
Frank Barknecht -
matthew yee-king -
Steve Harris -
Taybin Rutkin