> 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.
Cheers,
Jason Downer
Hello.
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
one?
Stomper does not work under wine :(
Thanks.
Hello.
I had a couple of articles on drum synths. Check
ftp://ftp.funet.fi/pub/sci/audio/devel/lad/drumsynth/
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.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
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.
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
http://www.notam02.no/arkiv/src/
ABOUT
-----
jack_capture is a small simple program to capture whatever
sound is going out to your speakers into a file.
This is the program I always wanted to have for jack, but no
one made. So here it is.
USAGE
-----
jack_capture [-f filename] [ -b bitdepth ] [-c channels] [ -B bufsize ]
Filename is by default auotogenerated to something like "jack_capture_<date+exact_time>.wav"
Bitdepth is by default FLOAT.
Channels is by default 2.
Bufsize is by default 262144.
ACKNOWLEDGMENT
--------------
Mostly based on the jackrec program in the jack distribution
made by Paul Davies and Jack O'Quin. Automatic filename generation
code taken from the timemachine program by Steve Harries.
--
Hi
On Tues Nov 22 I wrote:
> I've recently moved a system over to Slackware 10.2 which utilises NPTL and
> I'm aware of the issues NPTL has raised in the past. Based on a comment on
> the Jack website though I sort of assumed that things were now in hand and
> that Jack had a workaround in place for the issue.
>
> Despite this I have found that jackd itself (when run using set_rtlimits)
> gives an error (-11, EAGAIN) when "creating realtime thread".
I have since discovered (thanks to strace) that the problem lies in an
mmap2() call which requests a size of around 8MB. It appears to be part of
the NPTL pthread_create() function. The error returned by mmap2() (EAGAIN)
indicates either a locked file or "too much locked memory" (according to the
manpage). Because this is an anonymous map the problem must have been the
latter. Increasing the "locked memory" limit from 20MB to 40MB made jackd
start without having to resort to the LD_ASSUME_KERNEL hack.
Another problem then surfaced: with jackd running under NPTL, jack
applications using NPTL (eg: ardour) suddenly started to require all of
their memory to be lockable. For ardour with a large session this can get
quite large (I saw 130MB at one point last night).
So, with jackd running with LD_ASSUME_KERNEL = 2.4.19 and a memlock limit of
20MB everything worked and ardour (with NPTL - ie: without LD_ASSUME_KERNEL)
was obviously not trying to lock excessive amounts of memory. With jackd
running with NPTL and a large enough memlock limit things work but jack
clients appear to require much more memory be locked.
One thing I will try next is recompiling ardour; perhaps there's something
funny there. In any case though, does any of this ring a bell with anyone?
Regards
jonathan
Hi everyone,
Can anyone give me any examples of Free audio software being used by
professionals?
Anywhere where it performs better, or simply doesn't cost two or more
body parts to use?
Quick answers get bonus points.
James
--
"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)
Hi,
I have two questions concerning the jack callback,
1. what is the preferred way of feeding data from disk to the callback?
Is there a general design pattern agreed upon? Best Practices?
2. What is the preferred way to notify the non-realtime thread that
something happened in the jack-callback?
A condition variable? How to avoid blocking? How do you do it?
I read the tutorial at http://userpages.umbc.edu/~berman3/ , it uses
mutex+condition, is it okay to do this? Are there better ways?
thx
-Richard
hi everyone!
lately there are a number of gmail users filling up the moderation
queues with "message has a suspicious header" bounces.
this is almost always due to people trying to send non-text/plain
content, which for a number of very good reasons is banned on linux-audio-*.
it seems that gmail has an unfortunate default setting that some people
are not aware of... gmail users, please fix your settings!
best,
jörn
Hi Lee
> I just noticed that the sys_get_priority_max and _min syscalls do not
> take the RT priority rlimit into account. Since the watchdog thread
> runs at the -P setting + 10 then if the rlimit is 50 and the user
> specifies -P50 the watchdog thread will fail.
>
> I believe sched_get_priority_max(SCHED_FIFO) needs to take the rlimit
> into account - there's no other way to get the upper limit AFAICT.
I'm not sure what the "set_rtlimit problem" is here - I'm a little confused.
In terms of what set_rtlimits does, it seems to me that the watchdog thread
issue can be easily dealt with: define the max rtpriority value in
/etc/set_rtlimits to be X, knowing that the maximum jackd "-P" option value
one can use is X-10.
Certainly getrlimit()/setrlimit() (which set_rtlimit uses to do its thing)
seem to take the current rtpriority rlimit into account. The former
also returns the rlimit hard limit for the process, which I interpret
to be the "upper limit" mentioned in the original email.
In testing I've done during development, set_rtlimits seems to do the right
thing, based on my understanding of what the right thing is. If I've
misunderstood something though I'm happy to be corrected.
Regards
jonathan