16 Sep
2009
16 Sep
'09
7:44 a.m.
Greetings,
Thank you for all your great feedback on the last two betas!
phasex-0.12.0-beta4 addresses all of the concerns brought up so far:
Velocity: Many of you have noticed that velocity and aftertouch
were completely unsupported. Now, velocity (with aftertouch) can be
mapped to directly to oscillators and LFOs (by setting the source),
used as a modulation source (adjust volume w/ AM or pitch w/ FM), or
mapped to the filter in the filter-lfo section.
GUI: Some of you mentioned that the colors were too dark with too
little contrast, so now there are four GTK theme options: Dark
(original purple background), Light (orange background), System (use
the system GTK theme), and Custom (choose any gtkrc file for your
theme). There have also been issues with getting phasex to fit on
small screens (usually netbooks). The knob images have been trimmed
down vertically (just blank pixels), and the padding between widgets
has been almost completely cut out. The font can be selected in the
preferences. Additionally, a true fullscreen mode has been added.
It is now possible to fit phasex into an 800x600 desktop.
Atom processors: Compiler optimization flags for the Intel Atom
processors have been added to the build system. Run './configure
--enable-arch=atom' to build for the Atom. To force 32- or 64-bit
builds, use 'atom32' or 'atom64'.
The rest is just small tweaks and bugfixes, such as fixing the
segfault on quit issue, fixing all the compiler warnings, minor
updates to the build system, new menu items, etc.
As I don't have access to a netbook right now, please let me know
how it works out with the Atom or other low-power CPU, or on any
machine with a screen smaller than 1024x768. Of course, feedback
from the rest of you is highly welcome, too ;-}
Visit http://sysex.net/phasex/beta for source tarball, Fedora 11
RPMS, or Fedora 8 RPMS.
Cheers,
--ww
16 Sep
16 Sep
8:19 a.m.
New subject: Help needed: Pianist needed for piano+electronics piece "open Cluster"
Hi sorry for slightly off-topic posting and possible cross-postings, but
maybe (hopefully) there's some talented pianist(s) on the list.
This is for a conservatory assignment. I won't go too much in the
details here, but...
I'm in search of a pianist willing to volunteer in playing (and possibly
record) a piece for piano + electronics. The electronics are intended as
'tape' (but are based on 'virtual' piano, so would be happy to revisit
them with a real recording).
I would provide the score (comprising the piano part and an
'expressionistic' representation of the electronics - btw this was done
with rosegarden+lilypond+inkscape) and of course the electronics
recording itself.
The piece is written with fairly strict 'absolute' timing (1 bar per
second) but the performer can (should) feel free to 'play' with the
electronics as if they were another 'performer', even improvise if s/he
likes, that's why the graphical representation of the electronics.
You would of course get the deserved credit.
Thanks and Kind regards,
Lorenzo.
18 Sep
18 Sep
5 a.m.
On Wed, Sep 16, 2009 at 02:44:24AM -0700, William Weston wrote:
Greetings,
Thank you for all your great feedback on the last two betas!
phasex-0.12.0-beta4 addresses all of the concerns brought up so far:
Velocity: Many of you have noticed that velocity and aftertouch
were completely unsupported. Now, velocity (with aftertouch) can be
mapped to directly to oscillators and LFOs (by setting the source),
used as a modulation source (adjust volume w/ AM or pitch w/ FM), or
mapped to the filter in the filter-lfo section.
GUI: Some of you mentioned that the colors were too dark with too
little contrast, so now there are four GTK theme options: Dark
(original purple background), Light (orange background), System (use
the system GTK theme), and Custom (choose any gtkrc file for your
theme). There have also been issues with getting phasex to fit on
small screens (usually netbooks). The knob images have been trimmed
down vertically (just blank pixels), and the padding between widgets
has been almost completely cut out. The font can be selected in the
preferences. Additionally, a true fullscreen mode has been added.
It is now possible to fit phasex into an 800x600 desktop.
Atom processors: Compiler optimization flags for the Intel Atom
processors have been added to the build system. Run './configure
--enable-arch=atom' to build for the Atom. To force 32- or 64-bit
builds, use 'atom32' or 'atom64'.
It built quickly and easily with that flag on my EEE.
The rest is just small tweaks and bugfixes, such as fixing the
segfault on quit issue, fixing all the compiler warnings, minor
updates to the build system, new menu items, etc.
As I don't have access to a netbook right now, please let me know
how it works out with the Atom or other low-power CPU, or on any
machine with a screen smaller than 1024x768. Of course, feedback
from the rest of you is highly welcome, too ;-}
Many of my old patches break up and create Xruns on my little 1.6Ghz EEE. A few of them
work fine though.
The new layout and look-and-feel is much better for a netbook. Everything fits on the
screen now, much nicer.
Visit http://sysex.net/phasex/beta for source tarball,
Fedora 11
RPMS, or Fedora 8 RPMS.
Thanks!
I played around with it for a few minutes, and made this little sketch:
http://www.archive.org/download/KenRestivoArchivePart2/padmix.ogg
Great synth, fun to play with, and really easy to come up with interesting sounds using
it.
Thanks again for writing and maintaining it!
-ken
10:10 p.m.
I played around with it for a few minutes, and made this little sketch:
http://www.archive.org/download/KenRestivoArchivePart2/padmix.ogg
Woke me up at 1:17, that's for sure ;)
Looking fwd to trying new Phasex soon!
Norv
__________________________________________________________________________________
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/
11:31 p.m.
On Fri, Sep 18, 2009 at 05:10:44PM -0700, Norval Watson wrote:
Yeah, sorry, I don't use compression :-)
-ken
I played around with it for a few minutes, and made this little sketch:
http://www.archive.org/download/KenRestivoArchivePart2/padmix.ogg
Woke me up at 1:17, that's for sure ;)
Looking fwd to trying new Phasex soon! 
22 Sep
22 Sep
9:52 a.m.
I get "wrong" sound. JACK reports no xruns.
http://nedko.arnaudov.name/tmp/phasex.wav
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
10:24 a.m.
Nedko Arnaudov <nedko(a)arnaudov.name> writes:
I get "wrong" sound. JACK reports no xruns.
http://nedko.arnaudov.name/tmp/phasex.wav
Some more info...
Switching tabs in my window manager (ion3) causes artefacts in phasex
sound. I run jack2 in realtime mode, dsp load is about 15%. I run
a 2.6.23.1-rt11 kernel. I run the opensource radeon driver. My audiocard
and rtc IRQ threads run at higher priority than JACK (82 and 98). JACK
runs at priority 80.
# ps -eLo rtprio,pid,spid,class,args |sort -rn|head -n 20
99 4 4 FF [posix_cpu_timer]
99 3 3 FF [migration/0]
98 845 845 FF [IRQ-8]
97 5 5 FF [softirq-high/0]
82 1232 1232 FF [IRQ-20]
80 12779 22340 RR /usr/bin/jackdbus auto
80 12779 22338 RR /usr/bin/jackdbus auto
80 12779 22337 RR /usr/bin/jackdbus auto
77 22421 22424 FF phasex-01
75 22421 22427 RR phasex-01
75 22342 22355 RR /usr/bin/a2jmidid dbus
50 9 9 FF [softirq-block/0]
50 989 989 FF [IRQ-17]
50 921 921 FF [IRQ-16]
50 8 8 FF [softirq-net-rx/]
50 854 854 FF [IRQ-15]
50 851 851 FF [IRQ-14]
50 80 80 FF [IRQ-9]
50 7 7 FF [softirq-net-tx/]
50 6 6 FF [softirq-timer/0]
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
30 Sep
30 Sep
9:10 a.m.
On Tue, 22 Sep 2009, Nedko Arnaudov wrote:
Nedko Arnaudov <nedko(a)arnaudov.name> writes:
> I get "wrong" sound. JACK reports no xruns.
>
> http://nedko.arnaudov.name/tmp/phasex.wav
Yup. I know the sound well, and hopefully now it's nothing more
than a memory. The broken ringbuffer read has been fixed, and now
uses two buffer periods instead of one. 0.12.0-pre1 should treat
you right.
Some more info...
Switching tabs in my window manager (ion3) causes artefacts in phasex
sound. I run jack2 in realtime mode, dsp load is about 15%. I run
a 2.6.23.1-rt11 kernel. I run the opensource radeon driver. My audiocard
and rtc IRQ threads run at higher priority than JACK (82 and 98). JACK
runs at priority 80.
0.12.0-pre1 now defaults to SCHED_RR and should behave a little
better. I can run muse, hydrogen, and six instances of phasex on my
Turion laptop, clock it down to 1.6GHz, fire off a couple mprime
stress tester threads, and switch tabs to my heart's content without
hearing the "wrong" sound now. This has been tested both with and
without the opensource radeon drm. If you can, enable BackingStore
in the "Device" section of your xorg.conf so the knobs don't have to
be redrawn every tinme you switch tabs.
The clocks in my Turion really don't like the 2.6.23-rt or
2.6.24-rt kernels, so all of this has been tested on 2.6.31-rt11.
This is the first kernel on this particular laptop that can give me
drm, exa acceleration, and backing store at the same time.
# ps -eLo rtprio,pid,spid,class,args |sort -rn|head -n
20
99 4 4 FF [posix_cpu_timer]
99 3 3 FF [migration/0]
98 845 845 FF [IRQ-8]
97 5 5 FF [softirq-high/0]
82 1232 1232 FF [IRQ-20]
80 12779 22340 RR /usr/bin/jackdbus auto
80 12779 22338 RR /usr/bin/jackdbus auto
80 12779 22337 RR /usr/bin/jackdbus auto
77 22421 22424 FF phasex-01
75 22421 22427 RR phasex-01
75 22342 22355 RR /usr/bin/a2jmidid dbus
50 9 9 FF [softirq-block/0]
50 989 989 FF [IRQ-17]
50 921 921 FF [IRQ-16]
50 8 8 FF [softirq-net-rx/]
50 854 854 FF [IRQ-15]
50 851 851 FF [IRQ-14]
50 80 80 FF [IRQ-9]
50 7 7 FF [softirq-net-tx/]
50 6 6 FF [softirq-timer/0]
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
It's been suggested in the past to put the softirq-high threads at a
high priority (just under the rtc, like you have done), but I get
xruns whenever I put it above JACK. What kind of audio hardware
and clock hardware do you have? Just curious.
Give 0.12.0-pre1 a spin and let me know how it goes.
http://sysex.net/phasex
Cheers,
--ww
9:26 a.m.
William Weston <weston(a)sysex.net> writes:
On Tue, 22 Sep 2009, Nedko Arnaudov wrote:
I fixed it by tweaking the thread priorities in phasex settings window.
midi_thread_priority = 70;
engine_thread_priority = 75;
Are you sure that it was caused by a ringbuffer problem?
Nedko Arnaudov <nedko(a)arnaudov.name>
writes:
> I get "wrong" sound. JACK reports no xruns.
>
> http://nedko.arnaudov.name/tmp/phasex.wav
Yup. I know the sound well, and hopefully now it's nothing more than
a memory. The broken ringbuffer read has been fixed, and now uses two
buffer periods instead of one. 0.12.0-pre1 should treat you right.
Some more info...
Switching tabs in my window manager (ion3) causes artefacts in phasex
sound. I run jack2 in realtime mode, dsp load is about 15%. I run
a 2.6.23.1-rt11 kernel. I run the opensource radeon driver. My audiocard
and rtc IRQ threads run at higher priority than JACK (82 and 98). JACK
runs at priority 80.
0.12.0-pre1 now defaults to SCHED_RR and should behave a little
better. I can run muse, hydrogen, and six instances of phasex on my
Turion laptop, clock it down to 1.6GHz, fire off a couple mprime
stress tester threads, and switch tabs to my heart's content without
hearing the "wrong" sound now. This has been tested both with and
without the opensource radeon drm. If you can, enable BackingStore in
the "Device" section of your xorg.conf so the knobs don't have to be
redrawn every tinme you switch tabs.
The clocks in my Turion really don't like the 2.6.23-rt or 2.6.24-rt
kernels, so all of this has been tested on 2.6.31-rt11. This is the
first kernel on this particular laptop that can give me drm, exa
acceleration, and backing store at the same time.
> # ps -eLo rtprio,pid,spid,class,args |sort -rn|head -n 20
> 99 4 4 FF [posix_cpu_timer]
> 99 3 3 FF [migration/0]
> 98 845 845 FF [IRQ-8]
> 97 5 5 FF [softirq-high/0]
> 82 1232 1232 FF [IRQ-20]
> 80 12779 22340 RR /usr/bin/jackdbus auto
> 80 12779 22338 RR /usr/bin/jackdbus auto
> 80 12779 22337 RR /usr/bin/jackdbus auto
> 77 22421 22424 FF phasex-01
> 75 22421 22427 RR phasex-01
> 75 22342 22355 RR /usr/bin/a2jmidid dbus
> 50 9 9 FF [softirq-block/0]
> 50 989 989 FF [IRQ-17]
> 50 921 921 FF [IRQ-16]
> 50 8 8 FF [softirq-net-rx/]
> 50 854 854 FF [IRQ-15]
> 50 851 851 FF [IRQ-14]
> 50 80 80 FF [IRQ-9]
> 50 7 7 FF [softirq-net-tx/]
> 50 6 6 FF [softirq-timer/0] It's been suggested in the past to put the
softirq-high threads at a
high priority (just under the rtc, like you have done), but I get
xruns whenever I put it above JACK. What kind of audio hardware and
clock hardware do you have? Just curious.
soundcard is emu10k1 (sblive value)
no idea about clock hardware
Give 0.12.0-pre1 a spin and let me know how it goes.
If there is JACK MIDI, there will be one thread less, right?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
9:42 a.m.
On Wed, 30 Sep 2009, Nedko Arnaudov wrote:
I fixed it by tweaking the thread priorities in phasex settings window.
midi_thread_priority = 70;
engine_thread_priority = 75;
Are you sure that it was caused by a ringbuffer problem?
The ringbuffer problem was the sure culprit of the bad sound
generated on my machine. The old code blindly assumed that JACK
would want to read the entire buffer period at once. If nframes in
the process callback changes between calls, it was possible to read
off the end of the ringbuffer. Usually this would happen during a
CPU crunch.
Do you get the same or better realtime performance by setting the
softirq-high thread to SCHED_OTHER?
That's the plan ;-}
> I get "wrong" sound. JACK reports no
xruns.
>
> http://nedko.arnaudov.name/tmp/phasex.wav
Yup. I know the sound well, and hopefully now it's nothing more than
a memory. The broken ringbuffer read has been fixed, and now uses two
buffer periods instead of one. 0.12.0-pre1 should treat you right.
It's been
suggested in the past to put the softirq-high threads at a
high priority (just under the rtc, like you have done), but I get
xruns whenever I put it above JACK. What kind of audio hardware and
clock hardware do you have? Just curious.
soundcard is emu10k1 (sblive value)
no idea about clock hardware Give
0.12.0-pre1 a spin and let me know how it goes.
If there is JACK MIDI, there will be one thread less, right? --
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Thanks Nedko. You prompted me to make some serious fixes to both
the phasex codee and to my -rt laptop!
Cheers,
--ww
3 Oct
3 Oct
7:05 p.m.
New subject: 0.12.0-pre1 report (Was: phasex-0.12.0-beta4)
William Weston <weston(a)sysex.net> writes:
On Wed, 30 Sep 2009, Nedko Arnaudov wrote:
I fixed it by tweaking the thread priorities in phasex settings window.
midi_thread_priority = 70;
engine_thread_priority = 75;
Are you sure that it was caused by a ringbuffer problem?
The ringbuffer problem was the sure culprit of the bad sound generated
on my machine. The old code blindly assumed that JACK would want to
read the entire buffer period at once. If nframes in the process
callback changes between calls, it was possible to read off the end of
the ringbuffer. Usually this would happen during a CPU crunch.
I ran 0.12-pre1 with default parameters (i removed the ~/.phsaex/
directory) and i still hear artifacts with default parameters. Adjusting
priorities still fixes the problem. However I made a patch with beta4
and it now sounds different with pre1. Also, selecting gtk system theme
has no effect (it worked with beta4).
I wonder why last commit in the git repo is from July, you obviously
have something newer :)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
> I get "wrong" sound. JACK reports no
xruns.
>
> http://nedko.arnaudov.name/tmp/phasex.wav
Yup. I know the sound well, and hopefully now it's nothing more than
a memory. The broken ringbuffer read has been fixed, and now uses two
buffer periods instead of one. 0.12.0-pre1 should treat you right.
5572
days inactive
5589
days old
linux-audio-user@lists.linuxaudio.org
10 comments
5 participants
participants (5)
-
Ken Restivo -
Lorenzo -
Nedko Arnaudov -
Norval Watson -
William Weston