22 May
2009
22 May
'09
12:21 p.m.
On Thu, 21 May 2009 21:52:43 -0700 (PDT)
William Weston <weston(a)sysex.net> wrote:
The above-mentioned script always builds from a clean tarball or
clean copy of the tarball so I always got it so far, but I just
tried it. From a clean directory I ran
configure [options], make, configure [no options], make
and the second make didn't configure.
Judging from what 'top' tells me phasex isn't using that much cpu.
Are you looking at top with voices in play? The CPU consumption
goes up with the number of voices currently being generated.
When idle it chews around 6-15%, with 6 voices playing 25-30%.
It seems like with the default settings I could have at least 3
instances playing at the same time. Does it hurt if it is compiled for
many voices and multiple instances are run with a low voice count each?
In other words, does the compile with many voices impact performance
even if these voices aren't used?
Personally I think that the voice limit defined at compiletime is a
problem, especially if it is that low. Most distributions out there are
pure binary based, so they'll have to make a choice for their users
with a wide variety of machines. Some switch at application start +
sane default or auto-detection would be preferable.
I usually only write scripts that build from source for my distro's
community repository, like this one:
http://aur.archlinux.org/packages/phasex-git/phasex-git/PKGBUILD where
this isn't really an issue, but we are in the process of making a
binary audio repository so we face that problem as well.
Ah, thanks a lot, I will experiment. Does enable-debug have other
implications/sideeffects?
Thanks,
I haven't made a lot of music yet but the sounds that phasex
produces are very inspiring to me (and I just bought nice monitors
and a mic, so I kind of have to make some music now).
The new monitors will make a *huge* difference for any style of
music. You won't regret your purchase. Of course, you'll be hooked
and start shopping for outboard preamps, compressors, eqs, etc...
Or at least that's what happened right after I bought new monitors.
Definitely, this was the best purchase I did, ever. The difference is
huge, now it's really a joy to listen to music, understanding lyrics,
hear and feel bass, stereo image.. it's really great. For now it has to
be enough gear, monitors, e-piano, a nice mic and a linux box full of
audio apps, far more than is needed for making music. Reminds me to try
the phasex audio in :)
On Fri, 22 May 2009, hollunder(a)gmx.at wrote:
Thanks for the detailed explanation. It's almost certainly a different
distro and version of several applications, so I'll try these steps,
even if ./configure && make seems to work.
Thanks for looking into it.
On Thu, 21 May 2009 16:45:08 -0700 (PDT)
William Weston <weston(a)sysex.net> wrote:
These four steps are almost a guarantee that an autoconf enabled
project will build on your system. When compiling anything and
having issues with ./configure && make, I always go for this series
to rebuild all the autogenerated files. Works like a charm most of
the time, especially for packages that weren't released on the same
distro that I'm trying to build for.
Aclocal sets up some system dependent variables that configure
expects to have defined. This usually isn't needed unless you're
building with another version of autoconf, but it doesn't hurt
either.
Autoconf rebuilds configure from configure.ac. Ususally, the
existing configure script will work just fine, but again, it doesn't
hurt.
Automake builds a Makefile for each Makefile.am.
Autoheader builds a config.h from a config-h.in.
You bring up a very good point here. The normal ./configure && make
should just work for most builds. I'm going to look into this some
more and make sure the stable release gets it right. On Thu, 21 May 2009, hollunder(a)gmx.at wrote:
So far I used the following in a script that builds a package from
source:
./configure --prefix="/usr" --enable-arch="native"
make
make DESTDIR="$pkgdir/" install
"$pkgdir/" is just a variable in this script.
"native" is something like i686, this machine is an old-ish amd
athlon XP3000+.
What difference do these steps make?
aclocal
autoconf
automake
autoheader Hi William,
I just tested it a bit and it works really well, a huge
improvement over 0.11.1 and really fun to play around.
However, I found some minor weirdness and what looks like a bug to
me.
1) autogen behaves strangely:
$ ./autogen.sh
**Error**: Directory `.' does not look like the top-level package
directory
This was in the top level dir, the one where autogen.sh is
located.
I should really remove autogen.sh from the source tree. I used it
to create an initial configure.ac, and haven't touched it since.
The following should work for new builds:
aclocal
autoconf
automake
autoheader
./configure --enable-arch=foo (where foo is a gcc supported arch)
make
make install 2) It looks
like make is running configure again, although
configure needs to be run before make can be run, so this seems
to be redundant.
I've noticed this before, normally after running autoconf. Once
the configure script is rebuilt, make shouldn't decide to rebuild
it. Does this happen every time for you, or just after cleaning up
and re-running aclocal and/or autoconf? 3) When
playing a little piano piece I noticed that it cuts off
some notes prematurely for some reason, likely timing related,
even in poly-mode. The attached midi file should work as
demonstration, note how the notes played by the right hand get
cut long before the note-off. Both hands play continuously except
for the end, so it should be easy to spot. Simple sounds like
preset #3 work best.
Sounds like you might be hitting the polyphony limit. What CPU are
you building for? CPU dependent things are configured in
src/phasex.h. Sane defaults where chosen for all the common x86
CPU types (broken up into three classes) so as not to bog down the
realtime system, but depending on CPU power, you might be able to
squeeze a little more out of your machine. src/phasex.h:
# define PHASEX_CPU_POWER 2
#if (PHASEX_CPU_POWER == 2)
# define NUM_VOICES 6
#endif
So this could indeed be the polyphony limit.
Yes it is. I've been keeping it low enough to get full polyphony
out of two instances without choking up the realtime (I generally
run 4-6 instances and run sequencing out of MusE). I've been
thiknking of setting up the default builds with more polyphony and
treating the running of multiple instances as the special cases. Can I pass
this at configure-time somehow or do I need to sed?
You can override the definitions at configure time by passing new
ones as debug flags to the compiler:
./configure --enable-arch=athlon-xp --enable-debug="-DNUM_VOICES=12" 4) A
suggestion:
Especially when playing back files and stopping in between you can
get hung notes that can swell quite immensely and are hard to get
rid of (well, you have to somehow hit the right note to get a
note-off). Similar stuff could happen in other situations.
Something like a panic-button that kills all sounds could help.
The hung notes are most likely due to not receiving note off
messages (a problem with a lot of players when stopping
mid-stream). Phasex responds to the all-notes-off controller
message, but that's not available on a lot of controllers, so the
panic button sounds like a great idea. I'll see about
implementing it for 0.12.0-stable.
That's it for now, thanks a lot for phasex,
it's really fun to
play.
Thanks for your support. Happy music-making!
--ww Enjoy!
I will :)
Best regards,
Philipp