> I'm hoping that you're thinking of a realtime display, in which the
> peaks roll off to create a true waterfall effect.
Baudline (http://www.baudline.com) is a fantastic viewer that does fft
cascade. I've used it for a couple of years, and it is great for figuring out
how different sounds "work", and it has an oscilloscope-type display as well.
I finally started making my pet music project and realized I need a
drum synth to make some cool sounds. psindustrializer is good but also
need some tr-909-style sounds. I remeber from my old windoze days I
used a nice piece of software called Stomper. Does anybody know any
software for linux with comparable capabilities? Or we need to write
Stomper does not work under wine :(
I had a couple of articles on drum synths. Check
I built the circuit in a00*.jpg at the time when this article
was fresh. The article b00*jpg mentions an earlier article.
I will check that out at library.
Hmm.. I coded a drum synth for Commodore VIC-20 at the time.
VIC provided an audio chip with three oscillators, noise,
and a common volume if I remember correctly. What I did was to
modulate osc pitch and volume parameters with a fast and accurate
(compared to Basic) assembly code. The drum sounds were assigned to
the keys. This was about 1984, inspired by Yamaha's digital RX drum
synths, not by analog drums.
for developers of open source graphics software
>From: "Levi D. Burton" <ldb(a)puresimplicity.net>
>does the idea of documenting various lad design patterns make
>sense to anyone?
Such "LAD Gems" doc would be much needed here too.
(For audio dsp gems, take a look at "musicdsp.org".)
I would appreciate if somebody would take a look at
Ardour and document best gems found there. E.g., the GUI
and audio thread separation and start up sequences.
Likewise for Linuxsampler and one of its GUI frontends.
for developers of open source graphics software
Can anyone give me any examples of Free audio software being used by
Anywhere where it performs better, or simply doesn't cost two or more
body parts to use?
Quick answers get bonus points.
"I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
Anyone have a good suggestion for a tutorial for making accurate
high-resolution high-priority clocks in C? I found some tutorials but
they were kinda old, so wondered if they might be out of date as to how
far real-time scheduling has come on linux. I want to be able to wake up
a pthread very accurately.
I've been contemplating the problem of reconciling different latencies
of various sound sources, but so far the only solutions I have been able
to think of seemed sort of awkward, and googling didn't help much, either.
Specifically, here's the issue I'm looking at: I have a sequencer
application that has several MIDI output ports, each connected to some
device that accepts MIDI input. Those devices may have vastly different
latencies (for instance, I may want to use my digital piano, without any
noticeable latency, together with timidity, which has serious latency,
even when started with options like -B2,8, never mind the latency introduced
by my USB sound card), but of course I don't want to hear a time lag between
those devices. I don't mind a little bit of overall latency; the piano may
wait for timidity as long as they're in sync.
I'm currently scheduling all my events through one queue (is that the
recommended method? I've been wondering whether it would make more sense
to have, say, one queue per output port, but I don't see how this would
help), and the only solution I have been able to think of is to explicitly
schedule events for faster devices at a later time. This is clumsy, and
it's exacerbated by the fact that I'd like to schedule events in terms of
ticks rather than milliseconds. Since latencies are usually measured in
milliseconds, that means I have to convert them to ticks, considering
the current tempo of the queue. There's gotta be a better way.
Ideally, there are two things I'd like to do:
1. Assign a delay dt to each output port, so that an event scheduled
at time t0 will be sent at time t0+dt. Like this, I could compute the
maximum latency of all my devices, and the output port attached to a
device would get a delay of (max latency - latency of device), so
that everything would be in sync.
2. Automatically determine the latencies of the devices I'm talking
to. In theory, this should be possible. For instance, if timidity is
connected to jack, it could get jack's current latency, add its own
latency, and report the result. Is this science fiction?
Any thoughts on these issues would be appreciated!
Disk IO priorities have been discussed on the list before, and they are
now in the mainline kernel (search LKML for "IO priorities" for
details). I think they're only supported by the CFQ scheduler.
This might be fun for someone to experiment with, I'm sure any HDR
application would like this feature.
by Kjetil Svalastog Matheussen <k.s.matheussen＠notam02.no>
E-radium is Radium and a special version of E-UAE.
Radium is a midi music editor for the amiga and E-Uae is an amiga
0.61c -> 0.6d:
-Increased amount of Z3-memory from 32 to 64. Also increased the amount of
chip-mem from 2 to 8 to let there be more time to quit/save after getting
a warning about too little memory. For now, this seems to work...
-Lowered the keyboard repeat rate a bit.
-Fixed make install
-Use standard mouse pointer.
-Upgraded Radium from 0.61c to 0.61d:
-Added scroll-mouse support. Scrolling up is exactly the same as pressing
arrow up, and scrolling down is exactly the same as pressing arrow down.
Has anyone written code for, or even just seen, a 2-D slider widget?
What toolkit was it in? Do people around here prefer QT to GTK+, or
vice versa, and does anyone use FLTK, or something else?
I think the ideal widget would allow the user to click or
click-and-drag a cursor around the 2-D area, returning x and y
coordinates of course; and would allow a bitmap to be displayed
underneath the cursor; and would allow some way to constrain the
cursor movements (eg within a circular area inside the widget).
Such a thing would be great for lots of audio applications, like
controlling filter cutoff and resonance at the same time. That's what
I'll be doing, only a bit more complicated..!