VamPy, a Python wrapper for the Vamp plugin API, is now available.
Using VamPy you can write audio analysis or visualisation plugins for
use in Vamp hosts with a quick and dynamic environment that is
somewhat like working in Matlab or other high-level modelling
environments. VamPy has full two-way support for NumPy, an efficient
numerical library for Python, and for the dynamic typing of Python.
You can download VamPy from :
http://www.vamp-plugins.org/vampy.html
VamPy was written by Gyorgy Fazekas at the Centre for Digital Music,
Queen Mary University of London and is published under a BSD-style
license.
Chris
Hi everybody,
I have a question regarding amplifying a PCM frame. For each frame, I get a
float number, and multiply this number by 2, and then output frames to alsa
one by one using function snd_pcm_writei. But the wav file sounds the same
to me, nothing gets amplified. Could anyone explain this to me? I appreciate
your help!
Warmest regards,
Dripstone
I'm happy to announce a new release from guitarix
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
Release 0.05.1-1 comes with some major changes:
* new jack/port/server connect/monitor/control features
* new level meters
* new noise gate, noise sharper, chorus, bass booster
* new gain control for the jconv input
* reworked jconv settings widget
* a bit polish the GUI
* new skins and reworked skin menu
* various bug fixes
have fun
As ever, suggestions and comments are welcome
________________________________________________________________________
The standalone version of guitarix is based on GTK2+.
But guitarix is also released as a suite of LADSPA plugins
and can be used in e.g. ardour.
guitarix is licensed under the GPL.
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
For capture, guitarix uses the external application
'jack_capture' (version >= 0.9.30) written by Kjetil
S. Matheussen. If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
convolution application 'jconv' created by Fons Adriaensen.
If you don't have it installed, you can look here:
http://www.kokkinizita.net/linuxaudio/index.html
I(hermann) use faust to build the prototype and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://www.musikwissenschaft.uni-mainz.de/~ag/ag.html
: Yann Orlary
http://faust.grame.fr/
regards
Hermann Meyer & James Warden
------------------------------------------
guitarix-dev team
Hi,
I am trying to communicate with a "real" MIDI device through the ALSA RawMidi
API, but it doesn't quite do what I want.
I want to:
- Send a small SysEx package that asks a device for some data
- Receive the answer
What I basically do is (code excerpt / pseudo code):
snd_rawmidi_t *handle_in = 0, *handle_out = 0;
unsigned char ibuf[256];
unsigned char obuf[] = { 0xf0, .., 0xf7 }; /* 6 bytes sysex */
snd_rawmidi_open(&handle_in, NULL, "hw:2,0,0", SND_RAWMIDI_NONBLOCK);
snd_rawmidi_open(NULL, &handle_out, "hw:2,0,0", SND_RAWMIDI_NONBLOCK);
snd_rawmidi_write(handle_out, &obuf, 6);
snd_rawmidi_drain(handle_out);
// wait a little for the answer
// I know I should not do it this way, but for testing purposes..
usleep(1000000);
num = snd_rawmidi_read(handle_in, ibuf, sizeof(ibuf));
I know that the data is sent out, but reading back the answer always gives
me -1 for num.
Trying to do the same thing with 2 instances of the "amidi" program works, though:
First terminal window:
amidi -p hw:2,0,0 -d
Second terminal window:
amidi -p hw:2,0,0 -S "F0.....F7"
Sending the second one out, I immediately get the desired answer on the first
terminal.
I'm sure there is something very basic I am doing wrong, but I fail to see
that at the moment.
Eventually, the whole thing will have to be rewritten for the ALSA sequencer API
anyway, but for a first quick test, I wanted to try it this way.
Any hints are most welcome.
Thanks,
Frank
Greetings all,
I wanted to share with you my latest Linux-based and Linuxaudio.org-related
project that has been sucking up most of my time over the past year or so to
the point it seemed as if I have disappeared off the face of the Earth.
Needless to mention it continues to alter my sleeping/eating patterns with
unprecedented aptitude and with no end in sight ;-).
http://l2ork.music.vt.edu/
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
J?rn Nettingsmeier:
>
> this looks like it could provide a simple way of granting fixed-deadline
> tasks appropriate cpu time without effectively handing the machine over.
> i was quite skeptical of lennart's idea of a userspace daemon to do the
> job reliably, but the scheduler should have pretty good leverage on
> rogue tasks :)
>
Why do you need a special scheduling mode? If you run a watchdog in the
background, you shouldn't handle the machine over.
*****
plug!
*****
"das_watchdog" should be a properly made watchdog. It has saved
me numerous times, and works gently by temporarily turning off
realtime priority for all processes if something happens.
http://archive.notam02.no/arkiv/src/
[paul, i assume this was meant for the list?]
Paul Davis wrote:
> 2009/10/22 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>:
>> hi everyone!
>
> this:
>
>> A feature of BFS is that it detects when an application tries to obtain a
>> realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
>> appropriate privileges to use those policies. When it detects this, it will
>> give the task SCHED_ISO policy instead. Thus it is transparent to the user.
>> Because some applications constantly set their policy as well as their nice
>> level, there is potential for them to undo the override specified by the user
>> on the command line of setting the policy to SCHED_ISO. To counter this, once
>> a task has been set to SCHED_ISO policy, it needs superuser privileges to set
>> it back to SCHED_NORMAL.
>
> doesn't sound like linux or linus style of policy to me. i'll be
> interested to see what happens.
yeah, that's not exactly a touch of genius, but con's user base are,
well, users. making stuff out of the box is how he attracts testers.
in the long run, this should be a limits.conf thing, but in his position
, "wait for your distro to make this work" is a non-starter.
if bfs ever makes it into mainline, this behaviour will surely be shot
down. but the rest sounds interesting. i wonder how the new deadline
scheduler will compare.
hi everyone!
i just came across con kolivas' announcement of the latest release of
the brain fuck scheduler, http://lwn.net/Articles/357451/ .
in it, he explains the idea behind isochronous scheduling (which lennart
brought up when announcing his realtime kit):
> Isochronous scheduling.
>
> Isochronous scheduling is a unique scheduling policy designed to provide
> near-real-time performance to unprivileged (ie non-root) users without the
> ability to starve the machine indefinitely. Isochronous tasks (which means
> "same time") are set using, for example, the schedtool application like so:
>
> schedtool -I -e amarok
>
> This will start the audio application "amarok" as SCHED_ISO. How SCHED_ISO works
> is that it has a priority level between true realtime tasks and SCHED_NORMAL
> which would allow them to preempt all normal tasks, in a SCHED_RR fashion (ie,
> if multiple SCHED_ISO tasks are running, they purely round robin at rr_interval
> rate). However if ISO tasks run for more than a tunable finite amount of time,
> they are then demoted back to SCHED_NORMAL scheduling. This finite amount of
> time is the percentage of _total CPU_ available across the machine, configurable
> as a percentage in the following "resource handling" tunable (as opposed to a
> scheduler tunable):
>
> /proc/sys/kernel/iso_cpu
>
> and is set to 70% by default. It is calculated over a rolling 5 second average
> Because it is the total CPU available, it means that on a multi CPU machine, it
> is possible to have an ISO task running as realtime scheduling indefinitely on
> just one CPU, as the other CPUs will be available. Setting this to 100 is the
> equivalent of giving all users SCHED_RR access and setting it to 0 removes the
> ability to run any pseudo-realtime tasks.
>
> A feature of BFS is that it detects when an application tries to obtain a
> realtime policy (SCHED_RR or SCHED_FIFO) and the caller does not have the
> appropriate privileges to use those policies. When it detects this, it will
> give the task SCHED_ISO policy instead. Thus it is transparent to the user.
> Because some applications constantly set their policy as well as their nice
> level, there is potential for them to undo the override specified by the user
> on the command line of setting the policy to SCHED_ISO. To counter this, once
> a task has been set to SCHED_ISO policy, it needs superuser privileges to set
> it back to SCHED_NORMAL. This will ensure the task remains ISO and all child
> processes and threads will also inherit the ISO policy.
this looks like it could provide a simple way of granting fixed-deadline
tasks appropriate cpu time without effectively handing the machine over.
i was quite skeptical of lennart's idea of a userspace daemon to do the
job reliably, but the scheduler should have pretty good leverage on
rogue tasks :)
has anyone tried the bfs for audio yet?
best,
jörn
Hallo,
this message is to inform the community that in the next edition of the
the "Salon Linux 2010", in march 2010 in Paris, a french Linux event
including a conference cycle, there will be a session around
professional music and video creation with free software.
You can find the call for contribution at
http://www.confsolutionslinuxparis.com/.
The call talk about contribution and not paper because actually
only a presentation is required, not a paper.
We are looking mostly for overviews of availables solutions or
in depth presentations of mainstream ''products''.
Unfortunately, the communication must be in french :-< ...
Feel free to distribute this mail where do you think it may be
appropriate, or to contact me to get more details.
Maurizio De Cecco
--
Music: http://www.myspace.com/mauriziodececco
Blog: http://maurizio.dececco.name/
Software: http://www.jmax-phoenix.org/