Hydrogen 0.8.2 is out! :)
Features:
__General__
* Very user-friendly, modular, fast and intuitive graphical interface based
on QT 3
* Sample-based stereo audio engine, with import of sound samples
in .wav, .au
and .aiff formats
__Sequencer and mixer__
* Pattern-based sequencer, with unlimited number of patterns and ability to
chain patterns into a song
* Up to 64 ticks per pattern with induvidual level per event and variable
pattern length
* 32 instrument tracks with volume, mute, solo, pan capabilities
* Ability to import/export song files
* Unique human velocity, human time and swing functions
* Export to .wav
* Jack-trasport support
__Other__
* OSS and Jack audio drivers, with assignable Jack ports
* ALSA MIDI input with assignable midi-in channel (1..16, ALL)
* Import/export of drumkits
* Midi-in record
Changes:
* Audio file preview in load instrument dialog
* Jack transport improvements
* 4 Ladspa FX send per instrument
* Show recent used songs
* QT Style selection option in Preferences Dialog
* New keybindings
* Bug fix in load/save song
* LRDF support (optional)
* Several GUI improvements
* Better Midi-in support
* virtual keyboard (using qwertyuiop...)
* Ability to record midi-in or virtual keyboard notes in a pattern
Download:
http://hydrogen.sourceforge.net
Happy drumming! ^_^
--
Alessandro <Comix> Cominu
http://hydrogen.sf.net
e-mail: comix(a)despammed.com
Icq: 116354077
Linux User # 203765
[...Codito Ergo Sum...]
I had an idea the other day, and I wanted to bounce it around for
feedback before I invest any real time into it. While I have done
some minor kernel hackng over the years, I am not experienced in the
audio subject area.
Background:
Despite the various and sundry advances in linux audio, I find there
are still legacy apps that are built against the OSS API. This is
problematic since the legacy OSS model has blocking semantics. To get
multiple audio streams, one must use an audio server such as esd,
aRts, etc. Wouldn't it be nice if all the legacy apps "just worked"?
Without blocking each other?
Idea:
Suppose one were to write a kernel module that implemented the OSS
API, but had non-blocking semantics, and instead of driving a sound
card, the module encapsulated the OSS API calls somehow and passed
them back to a user-space audio server.
Ao, for example: suppose we had a system with alsa and the proposed
passback driver. xmms is playing via esd-passback-alsa, which is a
modified version that supports input from the passback driver and
outputs via alsa. The user fires up Ogle, which only has OSS output
code (I'm not sure if this is true; just an example). /dev/dsp is the
passback driver, and when ogle opens it, it succedes, even through
someone else is using the sound card (esd). The passback driver
"passes back" all of Ogle's ioctls to a modified version of esd,
which, in turn multiplexes the audio with whatever else is playing
(xmms, in this example), and plays it via alsa.
I'm not precisely sure how I would to handle the actual "passing
back". Probably a separate device file /dev/dsp-passback, which is
read by the audio server.
Can anyone say why this idea can not, or should not be implemented?
Now that I've articulated the idea, would anyone care to take over the
implementation?
Greetings,
I am aware of PortMixer, which is a simple API that abstracts volume controls.
Is anyone aware of any other crossplatform, cross-API mixer abstraction layers
out there?
AudioScience is looking for/considering building a library that will wrap
ALSA, audioscience HPI, windows WAVE, WDM mixers in a common API.
If such a library doesn't exist, why is that?
1) Too hard
2) Too easy
3) No use
4) other?
I'd welcome your comments.
regards
Eliot
AudioScience Inc.
Hello,
I'm a trying to make a piece of code to mix 2 WAV files and hear the
output on my headphones. I've spent hours trying differents things with
no success and now I feel I should ask for some light from experienced
people :)
I've found explanations on how to mix audio streams on this page :
http://www.vttoth.com/digimix.htm. But it doesn't really fits my own
situation since samples I get with libsndfile are signed values. My piece of
code works well for some files, but for others, it makes unpleasant
clicks.
I think I use a wrong algorithm, wich one do you use for such a
situation ?
Maybe I also use wrong data types, wich one should I use ?
Is there any framework wich does such a task well ? I had a look at
SndObj which seems to do such things but it's also quite old and not
maintained against today configurations.
Here is the guilty :
#include <stdio.h>
#include <ao/ao.h>
#include <math.h>
#include <fcntl.h>
#include <string.h>
#include <sys/types.h>
#include <sndfile.h>
#define BUFFER_SIZE 1024
#define DYNAMIC_RANGE 65535
int main( int argc, char **argv ) {
/* variables pour libao */
ao_device * device;
ao_sample_format format;
int default_driver;
/* variables pour libsndfile */
SNDFILE * wav1;
SNDFILE * wav2;
SF_INFO sfinfo;
SF_INFO sfinfo2;
/* float volumized */
static short buffer1 [BUFFER_SIZE];
static short buffer2 [BUFFER_SIZE];
static short mixed_buffer [BUFFER_SIZE];
int max_frames;
int buffer_cpt;
int number_of_buffers;
int i;
/* faut remplir la stucture sfinfo avec des zéros */
memset (&sfinfo, 0, sizeof (sfinfo)) ;
/* -- Initialize -- */
if(!(wav1 = sf_open(argv[1], SFM_READ, &sfinfo))) exit(0);
if(!(wav2 = sf_open(argv[2], SFM_READ, &sfinfo2))) exit(0);
ao_initialize();
/* -- Setup for default driver -- */
default_driver = ao_default_driver_id();
format.bits = 16;
format.channels = sfinfo.channels;
format.rate = sfinfo.samplerate;
format.byte_format = AO_FMT_LITTLE;
/* -- Open driver -- */
device = ao_open_live(default_driver, &format, NULL /* no options */);
if (device == NULL) {
fprintf(stderr, "Error opening device.\n");
}
/* la duree de jeu est en fonction de la longueur
* du plus long fichier */
if ( sfinfo.frames > sfinfo2.frames ) {
max_frames = sfinfo.frames;
} else {
max_frames = sfinfo2.frames;
}
number_of_buffers = max_frames / BUFFER_SIZE * 2;
for ( buffer_cpt = 0; buffer_cpt <= number_of_buffers; buffer_cpt++ ) {
/* -- lecture depuis les fichiers -- */
sf_read_short (wav1, buffer1, BUFFER_SIZE);
sf_read_short (wav2, buffer2, BUFFER_SIZE);
/* -- mixage, cf. http://www.vttoth.com/digimix.htm -- */
for ( i = 0; i <= BUFFER_SIZE; i++ ) {
mixed_buffer[i]
= buffer1[i] + buffer2[i] - buffer1[i] * buffer2[i] / DYNAMIC_RANGE;
}
/* -- envoi dans la carte son -- */
ao_play(device, (char *) mixed_buffer, sizeof(mixed_buffer));
}
ao_close(device);
ao_shutdown();
exit(0);
}
/* EOF */
Thanks :-)
--
Alex
> From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
>
> Hmm... Linn Drum provided good drum samples, but Lindrum
> has only an unexisting sound directory. Is that a good idea?
Nope. Not a good idea.
But providing the original Linn Drum samples wouldn't be a good idea either.
As it was pointed out earlier the company is still in business and the
drummachine will be renamed in the next release. So i will not package the
original Linn Drum samples.
But IANAL and maybe someone can enlighten me on this. How about samples from
classics like the 808 or 909 (or Linn Drum)? Can i package these samples with
my drummachine? I don't own these machines thus they are not sampled by
myself instead i got them from the internet and other sources.
PE
--
"Without music, life would _O_/ \_O_/ +----------------------+
be a mistake - I would / )) [] | Peter Eschler |
only believe in a god who \\ // | peschler(a)t-online.de |
knew how to dance." (Nietzsche) // \\ +----------------------+
Hi all,
I want to announce the first pre alpha release of JackMix.
[What:]
JackMix is a mixer for jack and my justification to be in this list.
Currently it only supports 4 hardcoded inputs and 3 aux (mono) outs and 1
stereo out. But I hope to make this configurable in the next time...
The outputs are organized in volumegroups, currently implemented is the aux
group with a variable number of out and the stereo group with (guess it) 2
outs.
JackMix uses parts of the kde-infrastructure (admin-dir) and Qt for the GUI.
You need Qt and jack with their include-files.
[Why:]
This first release is for testing. Testing what others might think about such
an idea. Testing if it builds on other pc's too. Testing my abilitites for
getting criticism...
[Where:]
Download it from
http://roederberg.dyndns.org/~arnold/file_share/?showdir=./jackmix
Homepage (so far): http://roederberg.dyndns.org/~arnold/jackmix
[Building:]
At the present time you need to do a "make -f Makefile.cvs" after unpacking
and before doing the usual "./configure && make".
The configure-checks are probably not working the right way but they check for
Qt and do some kind of checking for jack so I assume its enough for 0.0.1...
[Future:]
Planned features:
- Dynamic adding and removing of inputs and outputs.
- Saving and restoring the configuration.
- More Volumegroups. For example groups with 3 or 5.1 outputs...
- Effects using ladspa.
Maybe this makes you interested.
Thanks for testing JackMix,
Arnold
--
Get my public-key from pgp.mit.edu or pgp.uni-mainz.de
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
>From: peschler(a)t-online.de (Peter Eschler)
>
>Lindrum is an open-source drummachine that offers ten channels, realtime
Hmm... Linn Drum provided good drum samples, but Lindrum
has only an unexisting sound directory. Is that a good idea?
Regards,
Juhana
The latest version of the realtime Linux Security Module is now
available in the usual directory, <http://www.joq.us/realtime>.
This version handles the new concurrent groups mechanism Linus
introduced in 2.6.4. It still works with earlier 2.6 kernels. There
are no functional changes. Unless you are running 2.6.4, there is no
reason to upgrade.
The realtime LSM is an installable kernel module that enables realtime
capabilities for any 2.6.x kernel without needing to directly patch
the kernel. It was written by Torben Hohn and Jack O'Quin, who make
no warranty concerning the safety, security or even stability of your
system when using it. It is provided under the provisions of the GPL.
Thanks to Martin Habets for pointing out this kernel change and then
showing me how to handle it.
--
joq
as the subject indicates, i have reworked my ladspa.h patch proposal,
cleaning up comments and dropping the version tag to v1.2.
the accompanying example host and plugin code has also been revised,
in particular 'host.c' for better readability.
no attachment to clutter your inbox this time. you can find the files
at http://quitte.de/ladspa .
tim
For what it's worth, I think the omission of strings for enumerated ports is the most blatant omission of ladspa, and it must be rectified. The implementation details are not as important to me as the fact that it gets done somehow.
RDF is not an acceptable place for this data because enumerated values are a required feature, but having to use RDF to get this data breaks the S in ladspa.
-Ben Loftis