Hi!
According to my oldish midi-spec, controller (decimal) 120 is undefined,
so I was somewhat confused at first when I got it from Rosegarden.
A bit of digging shows that it belongs to the (newish?) GS-spec, and
means All-Sound-Off (as in 'killall -9')
It is a bit ironical that there is a DX7-plugin for Rosegarden, but the
real-McCoy will leave you hanging with notes forever ... no?
mvh // Jens M Andreasen
PS: There is an Mx41beta.zip with alsa and jack waiting for fearless
beta-testers. Do not hesitate, call now!
DS
Hi list,
This is my first post, apologies if it's not on topic
or obvious, but I was wondering if anyone is aware of
a LADSPA plugin for impulse convolution. The only
thing I have found is Steve Harris's impulse
convolver, which is intended for 'fairly short'
impulses and they need to be compiled in anyway. If
there is nothing out there, I will have a go at this:
just wanted to check first.
Thanks
Stefan Turner
___________________________________________________________
Moving house? Beach bar in Thailand? New Wardrobe? Win £10k with Yahoo! Mail to make your dream a reality.
Get Yahoo! Mail www.yahoo.co.uk/10k
>
> From: Dave Robillard <drobilla(a)connect.carleton.ca>
> Date: 2004/11/23 ti AM 07:58:55 GMT
> To: "The Linux Audio Developers' Mailing List"
> <linux-audio-dev(a)music.columbia.edu>
> Ämne: Re: [linux-audio-dev] Freeverb and default control parameters
>
> On Sun, 2004-21-11 at 19:50 +0100, Mathias Lundgren wrote:
> > sön 2004-11-21 klockan 17.26 skrev Dave Robillard:
> > > On Sun, 2004-21-11 at 15:21 +0100, Mathias Lundgren wrote:
> > > > Hi!
> > > >
> > > > I've been trying to implement LADSPA send effects in my latest playtoy.
> > > > I've had some problems with freeverb though. It simple doesn't produce
> > > > any output (execution seems to be veeery demanding) until I specifically
> > > > set some of the parameters to non-default values. I thought the default
> > > > port parameters would take care of this, initializing the plugin with
> > > > sane values to avoid things like these, but perhaps I'm doing something
> > > > wrong... Has anyone else noticed anything similar with freeverb?
> > > >
> > > > /Mathias
> > > >
> > >
> > > Are you specifically setting the default values? They're just hints,
> > > the host still has to set them. Plugins don't initialize ports to
> > > default values IIRC, they will be garbage until you set them to
> > > something.
> > >
> > >
> > > -DR-
> >
> > Yes, I'm specifically setting them, with the values provided by the
> > hinst. Using the hint-values, nothing comes out of it and execution is
> > really slow, when using some "personal" values, things mysteriously
> > begin to work.
> >
> > /Mathias
> >
> >
>
> Looks like the default values for freeverb have both dry and wet gain at
> 0. That would explain it, eh? :)
>
> -DR-
>
I guess it might have something to do with the whole thing. And I don't have a problem with a plugin producing no "pluginnish output" when it's launched, using the default values, but... Even though they're merely
hints, the freeverb init-settings (yeah okay, they're not init-settings, but "hints") really aren't nice to the system, and I don't like that.
/Mathias
Y'all aren't the only ones thinking there's an opportunity in the firewire
audio breakout box market:
http://www.appleinsider.com/article.php?id=756
IF the reports are true--and Appleinsider has a pretty good track
record--this is a pretty good affirmation of opportunity in this market.
Or, at least of apple's attempt to own the market by acccepting a much
lower profit margin.
I would imagine that the more advanced version mentioned--if actually
true--would sport more analog inputs.
Ramsey
Hello,
now that my audio inteerface is working, I can try the wealth of audio
applications.
Starting the SuSE supplied muse (0.7.0) it refuses to start cause it cannot
use /dev/rtc. Since I used the audio group also for providing the realtime
capabilities, I changed the group and mode of /dev/rtc to
crw-rw---- 1 root audio
But then it gives the following error message:
cannot set tick on /dev/rtc: Unpassender IOCTL (I/O-Control)
für das Gerät
precise timer not available
What is missing? Do I have to update the provided muse to a newer version?
Uwe
Hi!
I've been trying to implement LADSPA send effects in my latest playtoy.
I've had some problems with freeverb though. It simple doesn't produce
any output (execution seems to be veeery demanding) until I specifically
set some of the parameters to non-default values. I thought the default
port parameters would take care of this, initializing the plugin with
sane values to avoid things like these, but perhaps I'm doing something
wrong... Has anyone else noticed anything similar with freeverb?
/Mathias
Hi all,
a short announcement for those who might plan to do a presentation at the
next Linux Audio Conference in April 2005 in Karlsruhe: The paper templates
for OpenOffice and LaTeX are now available at:
http://www.zkm.de/lac/downloads.shtml
We are a little late with this for which I am sorry, but I hope you were not
blocked in writing your papers. Reminder: The deadline for paper submissions
(as well as music, workshops, project notes, posters) is January 10th, 2005.
For more details about the conference and the calls for paper etc, please
visit the web page at http://www.zkm.de/lac.
Greetings,
Götz Dipper
Matthias Nagorni
Frank Neumann
Hi (Takashi?)!
The OSS emulation in ALSA is slightly wrong regarding number of
requested buffers. To quote from my own "notes to self" from own source:
/** Setting up the soundcard for CD-HiFidelity Stereo
*
*/
audio.path = "/dev/dsp";
audio.speed = SAMPLERATE;
audio.format = AFMT_S16_LE;
audio.is_stereo = TRUE;
// 3 buffers of 256 bytes == 3 * 64 (16bit) stereo samples
// 0x0002 buffers == n - 1, although Alsa (mis)interpretes oss buffers
// == n!!! Use 0x0003!
//
// 0008 bytes == log2(number of bytes in buffer), 2^8 == 256 == 64
// stereo samples;
audio.bufsize = 0x00030008;
... so ALSA UNDERSHOOTS the number of buffers BY ONE (which of course
will not work for RT-people on the edge.)
mvh // Jens M andreasen
PS: Thanks to the mdk10.1 beeing distributed on DVD by LinuxFormat this
month, work is ongoing for a clean alsa solution of my handyworks ...
DS
On Monday 22 November 2004 18:07, Hans Fugal wrote:
> Is there an app that will dump midi events in human-readable format to
> stdout (or a file, or gui window, whatever)? Preferably it would work on
> SMF as well as realtime (ALSA), and have filters to filter out
> undesirables (e.g. active sensing or perhaps sysex).
The following utilities are included on newest alsa-utils packages. Both can
print the incoming MIDI events as human readable text in realtime.
amidi (using ALSA raw MIDI interface)
amidi is a command-line utility which allows to receive and send SysEx
(system exclusive) data from/to external MIDI devices. It can also
send any other MIDI commands.
-d, --dump
Prints data received from the MIDI port as hexadecimal bytes.
Active Sensing bytes (FEh) will not be shown, unless the -a
option has been given.
arecordmidi (using ALSA sequencer)
arecordmidi is a command-line utility that records a Standard MIDI File
from one or more ALSA sequencer ports.
-d,--dump
Shows the events received as text on standard output.
For SMF files, both Fluidsynth and Timidity can do so.
$ timidity -idvvv music.mid
$ fluidsynth -v music.mid
You can also try my little utilities in C and Pascal, including a midi monitor
utility with GUI interface for Kylix that you can find here:
http://perso.wanadoo.es/plcl/
Regards,
Pedro
Is there an app that will dump midi events in human-readable format to
stdout (or a file, or gui window, whatever)? Preferably it would work on
SMF as well as realtime (ALSA), and have filters to filter out
undesirables (e.g. active sensing or perhaps sysex).
If such a beast doesn't exist, I'll probably hack something up for
myself. If I do, would there be interest in my releasing it?
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460