Hi,
About a week ago, out of boredom, I started working on
little retro-styled '80s kind of video game, written
in a pretty simple-minded way with gnome, and the graphics
done just by using line drawing primitives. It was just
something to do, I didn't imagine it would amount to anything.
Well, it's turning out surprisingly well (not great, but
better than I was expecting.) So now I'm thinking to add
sound, but apart from some MIDI programming, I really haven't
done any audio programming before (unless you count some
Extended BASIC code on a ti99/4a back in the '80s -- and
nobody would count that.)
So, I found libao ( http://xiph.org/ao/doc/ ) which looks
nice and simple, and the sample program I tried
( http://xiph.org/ao/doc/ao_example.c ) worked right off
the bat, and the idea of synthesizing my own sounds by
constructing waveforms using sine waves is appealing for
a retro styled app like mine (though I have no experience
doing that and only a vague memory of trigonometry), but
I wonder about how to mix sound (add the waveforms, I guess)
and construct them on the fly (or trigger pre-computed
chunks of audio).
In the example code, it plays a one second chunk of audio
with one library call initiating the playback.
So, I imagine that for a game, in order to satisfy the
real-time-ish requirements, I'd instead construct maybe
1/10th or 1/20th second chunks, which would be queued up
in my program for playback, and whenever some event happens
which demands some sound be produced _right now_ (like the
user presses the "fire" button, and so needs some bleeping
laser gun sounds to be produced) I would then start adding
(arithmetic addition) laser-gun-waveform-data into whatever
chunks were already in the queue, and so out would come
the sound...
Does that seem like a reasonable approach?
By chopping the sound up into 1/10t or 1/20th second chunks,
am I apt to cause distortion of some kind?
Is there some other library I might be better off with?
(I looked at SDL, but it seems heavily tilted towards
graphics, and I already have the graphics stuff going alright
under just regular old gnome.)
I might also want to playback some ogg encoded files for maybe
prerecorded sound effects and music to be mixed
in with the synthesized sound effects. libao won't do that by itself, but
I think there are some other libs on xiph.org that do that, but
I'm not sure how well they'd accomodate mixing random bits of
sound in with them.
Saw this: http://www.underbit.com/products/mad/
fixed point mpeg decoder library... Not sure how
easy it'd be to mix in other sounds with its output.
Maybe just decode into memory buffer.
Anyway, just looking for suggestions, esp. if what
I've described so far seems wrong.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Keyboard Magazine carries an article this month about Linux Audio:
http://www.keyboardmag.com/story.asp?sectioncode=29&storycode=17973
-8<--------------------------------
You might think there’s no way a free operating system written by
volunteers could compete when it comes to music production. But in the
past couple of years, all the tools you need to make music have arrived
on Linux.
[...]
hello everyone
One thing that draws my attention is MIDI playing. So far, by using
Timidity and ALSA, I tried to play several MIDI files and it is hard for
me to notice any lag. I only noticed delayed notes when system is under
busy load (I run CPU bound program with nice level above -9).
Things I'd like to discuss are (I am sorry if they sound dumps
because I still study all these stuffs):
1. Is it me just who is not professional enough to notice any difference
when using various kernel HZ setting (smooth playing on HZ=x, not so smooth
when HZ=y and so on)? Or, does the delay fall in non-human-perceptible
range thus normal human being can not see the difference?
2. Is it correct that recent ALSA sequencer use RTC as source timer thus
kernel HZ is no longer relevant in the sequencer's point of view?
3. Related to the system load I mentioned above, I think I was seeing
scheduling latency and not really a timing latency. If that's correct,
could you kindly suggest what I must do to show that MIDI timing does
have any relation with HZ?
4. I am also thinking about MIDI recording as a way to show HZ effect.
Since I don't have any MIDI devices (but I plan to buy one if it's
really neccessary), I'd like to explore the correctness of this idea
first. Do you think it is really a proper experiment in HZ test context?
Thank you in advance for your help and attention and I am looking
forward to read your feedback. Sorry if it has been discussed before,
but I fail to completely research it until today.
regards,
Mulyadi
PHASEX-0.10.1 is a buildfix and bugfix release, highly recommended for
anyone who currently has 0.10.0. Here's the changelog:
* Fixed delay buffer size crash bug.
* Rebuilt config.h from configure.ac (fixes undefined PHASEX_DIR).
* Added engine thread cancellation point.
* Changed order of setting up JACK callbacks (might help jackdmp?)
* Moved main sample rate init code from samplerate callback to jack thread.
* Fixed oversampling mode.
* Fixed typo on bank.c.
* Disabled debug output in help.c.
* Added --enable-debug= option to configure.
* Fixed volume of bassy-plucked-lead and zeroed input boost on all
patches.
I'm still looking into issues with older versions of GTK-2.x. It looks
like the current minimum GTK version is somewhere around 2.6 or 2.8. Most
of the non-FC6 build issues appear to be related to this.
Reports for SMP, non-FC6, and jackdmp systems would be very helpful, as
these are the things I can't test right now.
Thank you all for the valuable feedback! I'm already getting a good sense
of what's needed most and where things should go in the project roadmap.
Based on responses so far, the roadmap up to 0.20.0 should look something
like this:
0.11.0 Bugfixes, buildfixes, code cleanups, GUI aesthetic issues.
0.12.0 Rework patch bank system to support alternate patch dirs and
include a patch chooser.
0.13.0 LASH support.
0.14.0 Fine-tune threads (remove locks), optimize dsp code more.
0.15.0 New small features and simple GUI enhancements.
0.16.0 Implement LFO clock-sync for MIDI clock and JACK transport.
0.17.0 JACK MIDI support.
0.18.0 Multitimbral or multiple instance support.
0.19.0 Overhaul parameters to add generic ctlr-float conversions
and add mod-matrix (w/ velocity and aftertouch handling).
0.20.0 OSC and DSSI support.
Cheers,
--ww
--
/* William Weston <weston(a)sysex.net> */
William Weston <weston(a)lysdexia.org> writes:
>> (gdb) bt
>> #0 0xb7f39410 in __kernel_vsyscall ()
>> #1 0xb7e3acf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> #2 0x080518cc in engine_thread (arg=0x0) at engine.c:1125
>> #3 0xb7e383dd in start_thread (arg=0xb4df9bb0) at pthread_create.c:261
>> #4 0xb774bc8e in clone () from /lib/libc.so.6
>> (gdb) The program is running. Exit anyway? (y or n) y
>
> Hmmm... I can't seem to duplicate this one. Are you running SMP, by
> chance? I've added a thread cancellation point in 0.10.1 to see if that
> helps.
Actually yes, a SMP system. I'll try on uniprocessor system too (hope
this evening).
>> Have you considered using widgets from PHAT? I beleive there is no
>> difference between knobs you use and phatknobs. If there are
>> improvements chances are they shoud got in PHAT version too.
>
> I've looked at PHAT, but decided to start off with the basic gtkknob code
> that everyone's been passing around so I could hack on it for a while. I
> have added one modification that's not in the PHAT version: middle click
> centers a knob.
I recently added middle click to PHAT fanslider because I needed "reset
to default" too, so I'd be glad if we have this for phatknob too.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Thu, 2007-05-03 at 19:52 -0700, William Weston wrote:
> On Thu, 3 May 2007, Lars Luthman wrote:
>
> > Very nice sounds. Since you asked for feedback, here is some:
> >
> > * the whole program crashes for me when I pull down the File or Patch
> > menus or try to close the window, with lots of Gtk error messages
> > about invalid style objects. If I change line 241 in gtkknob.c from
> >
> > widget->style = gtk_style_attach(widget->parent->style, widget->window);
> >
> > to
> >
> > widget->style = gtk_style_attach(widget->style, widget->window);
> >
> > it doesn't crash any more. Other behaviour seems to be identical.
>
> Wow... thanks! This change will be put in 0.10.1.
> BTW, what GTK version are you running?
2.8.20 on Debian Lenny.
--ll
--- Stephen Sinclair <radarsat1(a)gmail.com> wrote:
> > Anyway, just looking for suggestions, esp. if what
> > I've described so far seems wrong.
>
> Hi!
> If you're dead set on including audio in your program, and you are
> writing in C++,
No, just C, but thanks anyhow, I'll keep it in mind
in case I ever convert over to C++. C is more fun for
me though, and this is just for fun.
[...]
>
> An even easier way (imho) is to use Chuck, which is an audio language
> built for realtime audio. You can write all your audio routines in
> it, and send messages to your Chuck program telling it when to fire
> events, using an OSC library such as LibLo. It'll make your audio
> programming that much easier, the only difficulty is that you have to
> deal with controlling a separate process. Anyways, I recommend it.
>
> http://ccrma.stanford.edu/software/stk/
> http://chuck.cs.princeton.edu/
> http://liblo.sourceforge.net/ (for talking to chuck from C)
That sounds interesting. I messed with chuck for an hour or
two, maybe a year ago, just played with the examples that came
with it. It struck me at the time as being one
of those things that looks deceptively simple, but that, given
enough effort, could be pushed pretty far out.
>
> I've personally been through the exercise of writing my own audio
> engine from scratch, and finally I'm convinced that using something
> like STK or Chuck makes things much easier and in the end more stable
> as well, so I just thought I'd share that with you.
Hmm. I might be one of those people that has to learn the hard way,
just for my own satisfaction of knowing how things work.
In any case, I have the (probably rather naive) beginnings of
a 16 track mixer engine working based on one of the portaudio test
programs which I hacked up here:
http://www.geocities.com/smcameron/sound_trial.c
The scaling is a bit odd, I noticed... divides the sums by the
number of things summed, which, as that changes as sound clips
enter and leave the mix, tends to make it sound like somebody
is violently twisting the knobs on a compressor.
Seems to use about 1% of the CPU, so that's cool.
-- steve
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Announcing the latest release of the Phase Harmonic Advanced Synthesis
EXperiment (first release featuring a GUI), available for download (source
tarball and FC6 RPMs) at:
http://sysex.net/phasex/
PHASEX is an experimental softsynth for Linux/ALSA/JACK systems with a
good mix of standard and experimental features. Here's a quick
overview of what PHASEX offers:
* GTK GUI: Every paramater is available through the GUI, with parameter
names right-clickable for on-the-fly MIDI controller mapping and
middle-clickable for parameter help.
* 4 Osc / 4 LFO: Oscs and LFOs support multiple sources: MIDI key, tempo,
envelopes, and inputs, all with selectable unipolar/bipolar scaling.
Wavetable includes the basic wave shapes, both bandlimited and
non-bandlimited. Per-osc and per-LFO transpose, pitchbend, and init
phase.
* Modulations: Full AM, FM, and PM (in this case, modulation of phase
offset between left and right channels) routing with per-osc controls.
Each osc can be modulated by any osc or LFO for AM, FM, of PM. Wave
select modulation by LFO modulators is alsa available.
* Filter: Modified Chamberlin filter with LP, HP, BP, BS, LP+BP, HP+BP,
LP+HP, and BS+BP modes, distortion and retro (clean) types, keyfollow
modes, ADSR envelope, and LFO cutoff modulation.
* ADSR Envelope: Standard ADSR envelopes for amplifier and filter.
* Chorus: Stereo crossover chorus with builtin phaser.
* Delay: Stereo crossover delay with LFO modulation capability.
* Key Modes: Mono smooth, mono retrigger, mono multikey (round-robin
mapping of MIDI keys to individual oscs), and full poly modes are
available.
* Input Processing: Inputs may be routed to any combination of oscs and
LFOs. Input boost allows weaker sources to be brought up to level of
oscs. Envelope follower applies input envelope to output.
* Sampling Modes: Supports undersampling and oversampling, giving control
over the ever present quality vs. CPU tradeoff.
Since this is the first public release of PHASEX with a GUI, feedback is
highly encouraged. The project goal is to provide a synthesizer to
experimental and professional musicians alike that is as easy and
enjoyable to use as it is powerful. The next batch of new parameters and
features will be a result of feedback from the community, so please, don't
be shy.
Cheers!
--ww
--
/* William Weston <weston(a)sysex.net> */
pyliblo is a Python wrapper for the liblo OSC library. It does not yet
wrap all of liblo's functionality, but includes everything you need to
send and receive almost any kind of OSC message, using a nice and simple
Python API. OSC can hardly get any easier :)
Also included are two scripts, send_osc and dump_osc, which are similar to
the well known sendOSC/dumpOSC programs, but much simpler and less
cumbersome to install.
Get pyliblo 0.5 here:
http://das.nasophon.de/pyliblo/
Cheers,
Dominic
Announcing the latest release of the Phase Harmonic Advanced Synthesis
EXperiment (first release featuring a GUI), available for download (source
tarball and FC6 RPMs) at:
http://sysex.net/phasex/
PHASEX is an experimental softsynth for Linux/ALSA/JACK systems with a
good mix of standard and experimental features. Here's a quick
overview of what PHASEX offers:
* GTK GUI: Every paramater is available through the GUI, with parameter
names right-clickable for on-the-fly MIDI controller mapping and
middle-clickable for parameter help.
* 4 Osc / 4 LFO: Oscs and LFOs support multiple sources: MIDI key, tempo,
envelopes, and inputs, all with selectable unipolar/bipolar scaling.
Wavetable includes the basic wave shapes, both bandlimited and
non-bandlimited. Per-osc and per-LFO transpose, pitchbend, and init
phase.
* Modulations: Full AM, FM, and PM (in this case, modulation of phase
offset between left and right channels) routing with per-osc controls.
Each osc can be modulated by any osc or LFO for AM, FM, of PM. Wave
select modulation by LFO modulators is alsa available.
* Filter: Modified Chamberlin filter with LP, HP, BP, BS, LP+BP, HP+BP,
LP+HP, and BS+BP modes, distortion and retro (clean) types, keyfollow
modes, ADSR envelope, and LFO cutoff modulation.
* ADSR Envelope: Standard ADSR envelopes for amplifier and filter.
* Chorus: Stereo crossover chorus with builtin phaser.
* Delay: Stereo crossover delay with LFO modulation capability.
* Key Modes: Mono smooth, mono retrigger, mono multikey (round-robin
mapping of MIDI keys to individual oscs), and full poly modes are
available.
* Input Processing: Inputs may be routed to any combination of oscs and
LFOs. Input boost allows weaker sources to be brought up to level of
oscs. Envelope follower applies input envelope to output.
* Sampling Modes: Supports undersampling and oversampling, giving control
over the ever present quality vs. CPU tradeoff.
Since this is the first public release of PHASEX with a GUI, feedback is
highly encouraged. The project goal is to provide a synthesizer to
experimental and professional musicians alike that is as easy and
enjoyable to use as it is powerful. The next batch of new parameters and
features will be a result of feedback from the community, so please, don't
be shy.
Cheers!
--ww
--
/* William Weston <weston(a)sysex.net> */
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user