Hi guys,
I'm looking to delve into the world of plugins (for both synth and fx),
and of the free API's I find LADSPA, DSSI, and LV2. But the picture is a
little confusing.
It appears that LV2 is "current," that DSSI is deprecated, and that LADSPA
would be deprecated if it weren't so widely adopted. However, LV2 is slow
in being adopted. Is this developer resistance... or is it just too new?
Also, I can't find any applications that will host all 3, nor even
LV2+DSSI. Is there a technical reason for this?
Thanks in advance,
Gabriel
hi everyone!
i'm playing with my shiny new BCF2K, and i'm going to use it some
distance from my machine, so i'm going to try a midi link instead of USB.
what is the maximum length of midi chain that you have used without
problems? i read somewhere that no more than 15 meters are recommended,
which strikes me as pretty short even if it's unbalanced.
my idea is to abuse a cat5 cable as a triple midi loom - do you think
that could work? pinout would be as follows:
1 midi 1 signal
2 midi 1 ground
3 midi 2 signal
4 midi 2 ground
5 midi 3 signal
6 midi 6 ground
7 common +5V
8 common +5V
best,
jörn
Patrick Shirkey <pshirkey(a)boosthardware.com> writes:
> I don't see much point of storing a local copy of a ssh tunneled config
> file. If you are tunnelling the config file should be accessed from the
> remote machine. It's different if you are using multiple qjackctls on
> the same desktop and connecting to local jackd instance/s as well as
> netjack'd instances on remote machines. That seems like a heavy deal and
> as Nedko has mentioned previously it can actually be managed by the LADI
> tools now although that requires running dbus too which is not to
> everyones liking.
Yesterday, I've booted my wife`s windows machine from an Ubuntu LiveCD
and made some remote dbus tests. There are two options to initiate this
through ssh.
The first one is to start socat[1] at both sides and use tcp for
connecting them:
dbus app <-> unix socket <-> socat <-> tcp over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
The other one is to use gabriel [2] at client side. Gabriel uses libssh
[3] to setup socat remotely and tunnels the dbus traffic over ssh
tunnel:
dbus app <-> unix socket <-> gabriel <-> ssh over ethernet <-> socat <-> unix socket <-> dbus daemon <-> dbus app
Gabriel`s approach is of course better in long term, because dbus
traffic is encrypted and because it sets remote part automatically. Bad
news about gabriel is that last commit is from February 2007, it needs a
patch to work with latest libssh (0.3.4) and it allows only one client
to use the local unix socket.
Both approaches have restriction because of the EXTENRAL dbus
authentication mechanism. That mechanism sends unix user id and it is
matched remotely. So in order remote dbus to work, uids should be
same. Of course this is lame and I already have plan for this: the
client side (gabriel/ladish), can get the remote uid through ssh and
change the uid "token".
Plan for the remote capable ladish is to take the gabriel`s
approach. Requirements for the remote (aux) hosts will be - ssh server,
dbus, jackdbus and socat. Requirements for the local (central) host will
be ssh client, libssh, dbus, jackdbus, ladish. ladish will provide dbus
service that will act as manager for remote dbus connections. Such
service could be reused for other remote dbus purposes and as such could
be a separate project (or could be made as part of gabriel).
Multihost ladish is planned for the 2.0 release and wont happen anytime
soon unless someone with high motivation steps to work on this.
I'd like to ask users of multiple-jack-servers-on-same-host (Fons?) to
explain what it is used for and how it works. As I personally dont use
such setup I can't make ladish suitable for such setups without
feedback. Same applies for remote jack management and netjack but I've
gathered some knowledge because of the obvious netjack popularity.
[1] http://www.dest-unreach.org/socat/
[2] http://gabriel.sourceforge.net/
[3] http://www.libssh.org/
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Problem solved by a contributor on LAU.
He sent me a /var/lib/asound.state file from a working Audigy2
installation and, what do you know, it worked.
There is a file that describes the state of the sound card in
/var/lib/alsa/asound.state. When the original (bad) version was replaced
with one from a working Audigy2 sound cared (good version) the card
started working.
The replacement asound.state file has 227 controls vs 216 for the oroginal.
The following 14 switch controls existed only in the good file.
The Master Playback Switch only existed in the good file. If it exists
on the sound card and is muted by default, there would be no sound output.
There are 3 possible duplicated controls.
control.1 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Front Playback Switch'
value.0 true
value.1 true
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Surround Playback Switch'
value.0 true
value.1 true
}
control.3 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Center Playback Switch'
value true
}
control.4 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'LFE Playback Switch'
value true
}
control.5 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Side Playback Switch'
value.0 true
value.1 true
control.7 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'CD Playback Switch'
value.0 true
value.1 true
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Line Playback Switch'
value.0 true
value.1 true
control.11 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Mic Playback Switch'
value.0 false
value.1 false
control.12 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Front Mic Playback Switch'
value.0 true
value.1 true
control.13 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Headphone Playback Switch'
value.0 true
value.1 true
control.15 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
value.0 true
value.1 true
control.20 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Playback Switch'
value false
control.21 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'IEC958 Default PCM Playback Switch'
value true
control.22 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Master Playback Switch'
value true
-----------------
The following controls existed in both files.
Bad file, Good file
Control 29 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Tone Control - Switch'
value.0 false
value.1 falseiface MIXER
Bad file, Good file
control.31 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'IEC958 Optical Raw Playback Switch'
value.0 false
value.1 false
Bad file, Good file NB also see control 13, an apparent duplicate
control.35 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Headphone Playback Switch'
value true
Bad file, Good file
control.39 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'PC Speaker Playback Switch'
value true
Bad file, Good file
control.41 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Phone Playback Switch'
value true
Bad file, Good file NB also see control 9, a possible duplicate
control.46 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Line Playback Switch'
value true
Bad file, Good file NB also see control 7, a possible duplicate.
control.48 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'CD Playback Switch'
value true
Bad file, Good file
control.52 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Aux Playback Switch'
value true
Bad file, Good file
control.60 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name '3D Control - Switch'
value false
--
David Morrell
Web site: www.davidmorrell.ozeweb.net (when I get it on air again :)
<http://www.davidmorrell.ozeweb.net>
Email: dsmorrell56(a)dodo.com.au <mailto:dsmorrell56@dodo.com.au>
Ph: 0408 842 955 / 03 6343 5131
Hi all, my name is David, I'm new to the list. It was suggested that I try here by someone on the LAU list as they think I may have found a bug in the emu10k1 driver for Creative Audigy sound cards.
Sound works in Windows XP and worked in Ubuntu 8.04. It stopped after a
clean installation of Ubuntu Studio 9.04. It is not known if recording
worked or if it is now broken. Hopefully sorting out playback will
lead to a quick solution for recording, if one is needed.
Summary of Test Results
--------------------------------
Testing followed this understanding of the way sound playback is handled
in Linux. Sound;
- is generated by apps or test utilities such as Hydrogen or aplay
- may pass through a sound server such as PulseAudio or Jack
- goes to ALSA, which translates it for communication to sound cards
- is converted from digital to analogue, amplified and fed to speakers
by the sound card.
The system has a Creative Labs Audigy2 sound card.
It shares an IRQ with a video card and an onboard USB controller.
Video and USB work properly in Linux. Video, USB and sound work in
Windows.
However, while BIOS reports these items on IRQ10, Linux (using cat
/proc/interrupts) thinks they are on IRQ18. Is there any significance in
this? It seems unlikely as video and USB work properly.
ALSA appears to talk to the card – it is possible to set mixer controls
using one mixer interface and read their state using an unrelated
interface. Apps and test utilities appear able to send data to the
card. To back this up, the kernel modules required to form the driver
all appear to be loaded. When ALSA is forced to reload them, a pop
and brief low level white noise comes from the speaker.
This is similar to what can be heard during system boot.
Possibly ALSA is passing control data to the card but not PCM audio
data. I don't know if this is so or how to check.
Re-installing ALSA had no effect. A full uninstall – reinstall was not
done as many other packages would have been affected because of
dependencies.
Detailed information about the driver was reviewed, but it is beyond
my technical competence to understand if or how it applies to my card
and then to act on it (“Matrix:Module-emu10k1” at
http://www.alsa-project.org/main/index.php/Matrix:Module-emu10k1).
Now for the test results in detail.
Thanks to Dave Phillips for his excellent series "Troubleshooting Linux
Audio" at
http://www.linuxjournal.com and to many other sources.
Application & Test Utility Output
--------------------------------
the Hyrdogen drum machine can be seen producing output on its VU meters.
From the command line: aplay -vv ak4744.wav shows an apparently
successful result;
Playing WAVE 'ak4744.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo Plug PCM: Hardware PCM card 0 'Audigy 2 Value [SB0400]' device 0
subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
Test tone from Sound → Preferences → Test output appears to be
successful to most sound pipelines;
- Audigy 2 Multichannel Playback (ALSA) OK
- Audigy 2 Multichannel Capture / PT Playback (ALSA) Fails with
error message “gconfaudiosink: cound not open audio device for playback”
(also describes the audio sources as a 512 Hz tone and the pipeline as
“audioconvert ! Audioresample ! Gconfaudiosink”).
- Audigy 2 ADC Capture / Standard PCM Playback (ALSA) OK
- Audigy 2 ADC Capture / Standard PCM Playback (OSS) 2 are OK, the
third apparently identical one fails
- ALSA OK
- OSS OK
Sound Server
--------------------------------
PulseAudio and JACK were both on the sytesm. To simplify the problem;
JACK was not started;
PulseAudio was completely uninstalled, the system was restarted and it
was
verified that no persistent processes still existed for PulseAudio
(ps -e | grep “pulse”)
Drivers (ALSA)
--------------------------------
All volume controls were set to 100% and all mute controls were set to
un-mute in Alsamixer. These settings were verified by having another
mixer read and display them (Alsamixergui).
As can be seen from the preceding output of aplay, sound was routed
directly from its source to ALSA and ALSA recognised the Audigy 2 card
on this computer.
Output from the Sound → Preferences test also suggests that ALSA is
interrogating the card and recognising what it can and cannot do.
However, there is a strange indication from ALSCTL;
alsactl init
which shows;
Unknown hardware: "Audigy2" "SigmaTel STAC9750,51"
"AC97a:83847650" "" ""
What is this saying?
The ALSA soundcard matrix says an Audigy2 card should be using emu10k1
modules..
http://www.alsa-project.org/main/index.php/Matrix:Vendor-Creative_Labs
though I can't find an exact match there for my Audigy 2 SB0400 card.
I tried forcing ALSA to reload its kernel modules using;
sudo alsa reload
The speaker emitted a soft pop and about half a second of very low level
white
noise, similar to what can be heard during system boot.
Commmand output was;
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system
/home/dmorrell/.gvfs
Output information may be incomplete.
/sbin/alsa: Warning: Processes using sound devices: 3215(timidity).
Unloading ALSA sound driver modules: snd-emu10k1-synth snd-emux-synth
snd-seq-virmidi snd-seq-midi-emul snd-emu10k1 snd-ac97-codec snd-pcm-oss
snd-mixer-oss snd-pcm snd-page-alloc snd-util-mem snd-hwdep snd-seq-dummy
snd-seq-oss snd-seq-midi snd-rawmidi snd-seq-midi-event snd-seq snd-timer
snd-seq-device (failed: modules still loaded: snd-seq snd-timer
snd-seq-device).
Loading ALSA sound driver modules: snd-emu10k1-synth snd-emux-synth
snd-seq-virmidi snd-seq-midi-emul snd-emu10k1 snd-ac97-codec snd-pcm-oss
snd-mixer-oss snd-pcm snd-page-alloc snd-util-mem snd-hwdep
snd-seq-dummy
snd-seq-oss snd-seq-midi snd-rawmidi snd-seq-midi-event snd-seq
snd-timer
snd-seq-device.
Kernel module(s) the card is using were checked using
cat /proc/asound/modules
which shows;
0 snd_emu10k1
i.e. there is only card 0 and it is using module snd_emu10k1.
This was further confirmed using command lspci -v | grep “Audigy”, which
showed;
05:09.0 Multimedia audio controller: Creative Labs SB0400
Audigy2 Value Kernel driver in use: EMU10K1_Audigy
A test was done to confirm that the modules are actually loaded into
the kernel;
lsmod | grep "emu"
which showed a host of modules that seem as if they should be there,
though of course could not show any modules that aren't there and
should be;
snd_emu10k1_synth 14336 0
snd_emux_synth 40832 1 snd_emu10k1_synth
snd_seq_virmidi 13440 1 snd_emux_synth
snd_seq_midi_emul 14592 1 snd_emux_synth
snd_emu10k1 144288 1 snd_emu10k1_synth
snd_ac97_codec 112292 1 snd_emu10k1
snd_pcm 83076 3 snd_emu10k1,snd_ac97_codec,snd_pcm_oss
snd_page_alloc 16904 2 snd_emu10k1,snd_pcm
snd_util_mem 12288 2 snd_emux_synth,snd_emu10k1
snd_hwdep 15108 2 snd_emux_synth,snd_emu10k1
snd_rawmidi 29696 3 snd_seq_virmidi,snd_emu10k1,
snd_seq_midi
snd_seq 56880 10
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,
snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer 29704 3 snd_emu10k1,snd_pcm,snd_seq
snd_seq_device 14988 8
snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_seq_dummy,snd_seq_oss,
snd_seq_midi,snd_rawmidi,snd_seq
snd 62756 14
snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_ac97_codec,snd_pcm_oss,
snd_mixer_oss,snd_pcm,snd_hwdep,snd_seq_oss,snd_rawmidi,snd_seq,snd_
timer,snd_seq_device
Just for the hell of it, I had a look at information about the emu10k1
module using;
modinfo snd-emu10k1
which showed;
filename:
/lib/modules/2.6.28-15-generic/kernel/sound/pci/emu10k1/snd-emu10k1.ko
license: GPL
description: EMU10K1
author: Jaroslav Kysela <perex(a)perex.cz>
firmware: emu/emu1010_notebook.fw
firmware: emu/emu0404.fw
firmware: emu/micro_dock.fw
firmware: emu/emu1010b.fw
firmware: emu/audio_dock.fw
firmware: emu/hana.fw
srcversion: F52CF37385CBD708CAB4A2C
alias: pci:v00001102d00000008sv*sd*bc*sc*i*
alias: pci:v00001102d00000004sv*sd*bc*sc*i*
alias: pci:v00001102d00000002sv*sd*bc*sc*i*
depends:
snd-pcm,snd-util-mem,snd-page-alloc,snd,snd-rawmidi,snd-timer,
snd-hwdep,snd-ac97-codec,snd-seq-device
vermagic: 2.6.28-15-generic SMP mod_unload modversions 586
parm: index:Index value for the EMU10K1 soundcard.
(array of int)
parm: id:ID string for the EMU10K1 soundcard. (array of charp)
parm: enable:Enable the EMU10K1 soundcard. (array of bool)
parm: extin:Available external inputs for FX8010.
Zero=default. (array
of int)
parm: extout:Available external outputs for FX8010.
Zero=default.
(array of int)
parm: seq_ports:Allocated sequencer ports for internal
synthesizer.
(array of int)
parm: max_synth_voices:Maximum number of voices for
WaveTable. (array
of int)
parm: max_buffer_size:Maximum sample buffer size in MB.
(array of int)
parm: enable_ir:Enable IR. (array of bool)
parm: subsystem:Force card subsystem model. (array of uint)
Noticing the parameter 'enable' (ton enable a sound card) and feeling
desparate, I tried reloading the module with that parameter specified;
sudo modprobe -i snd_emu10k1 enable=true
Unsurprisingly, it made no difference as the card already appears to
be talking to its driver anyway.
The ALSA soundcard matrix mentions that some cards may need the
alsa-firmware package. That package is not on my system or in the
Ubuntu repositories. However, its headers are installed. I don't
know if this is significant.
Next, I tried reinstalling ALSA. The following packages were affected;
libsox-fmt-alsa
alsa-base
libasound2
libasound2-plugins
mcp-plugins
libesd-alsa0
This had no effect, so I considered completely uninstalling &
reinstalling. However, many other packages that depend on ALSA would
also have been removed. This looked like a short cut to a long
reconstruction.
Sound Card
--------------------------------
The card works under Windows XP and had worked under Ubuntu 8.04.
I have a Creative Labs Audigy 2 PCI card as card 0 on IRQ18 according
to cat /proc/asound/cards
0 [Audigy2 ]: Audigy2 - Audigy 2 Value [SB0400]
Audigy 2 Value [SB0400] (rev.0, serial:0x10011102) at 0x1040, irq 18
More information is given by
cat /proc/interrupts
which shows
18: 185146 IO-APIC-fasteoi uhci_hcd:usb4, EMU10K1,
radeon@pci:0000:01:00.0
There is a USB controller, the soundcard (EMU10K1) and the video card
(radeon) all using the same interrupt. The sound card does not appear
on any other interrupts.
BIOS reports all of these devices on IRQ10, not IRQ18. And yes, I have
checked carefully to be sure I am not confusing 8 with 0.
How could this discrepancy happen?
A hint may lie in the online book “The Linux Kernel” at
http://tldp.org/LDP/tlk/dd/pci.html.
“For Intel based systems the system BIOS, which ran at boot time, has
already fully configured the PCI system. This leaves Linux with little
to do other than map that configuration. For non-Intel based systems
further configuration needs to happen to:
- Allocate PCI I/O and PCI Memory space to each device,
- Configure the PCI I/O and PCI Memory address windows for each PCI-PCI
bridge in the system,
- Generate Interrupt Line values for the devices; these control
interrupt handling for the device. “
Possibly Linux has read the information set up by the BIOS, then the
PCI Fixup routine has remapped the Interrupt Line values even though.it
may not have needed to do so?
For a boots and all look at the PCI information about the sound card,
lspci -vvxxx
shows
05:09.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
Subsystem: Creative Labs Device 1001
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping-
SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort
- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at 1040 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,
D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: EMU10K1_Audigy
Kernel modules: snd-emu10k1
The card has the following devices shown by;
aplay -L
This shows abridged);
front:CARD=Audigy2,DEV=0
Audigy 2 Value [SB0400], ADC Capture/Standard PCM Playback
Front speakers
rear:CARD=Audigy2,DEV=0
Audigy 2 Value [SB0400], ADC Capture/Standard PCM Playback
Rear speakers
…
Audigy 2 Value [SB0400], ADC Capture/Standard PCM Playback
IEC958 (S/PDIF) Digital Audio Output
null
Discard all samples (playback) or generate zero samples (capture)
To see all input devices;
arecord -l
which shows;
arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Audigy2 [Audigy 2 Value [SB0400]], device 0: emu10k1 [ADC
Capture/Standard PCM Playback]
Subdevices: 1/1
card 0: Audigy2 [Audigy 2 Value [SB0400]], device 1: emu10k1
mic [Mic Capture]
card 0: Audigy2 [Audigy 2 Value [SB0400]], device 2: emu10k1
efx [Multichannel
Capture/PT Playback]
Subdevices: 1/1
-- David Morrell Web site: www.davidmorrell.ozeweb.net (when I get it on
air again :) <http://www.davidmorrell.ozeweb.net> Email:
dsmorrell56(a)dodo.com.au <mailto:dsmorrell56@dodo.com.au> Ph: 0408 842
955 / 03 6343 5131 _______________________________________________
Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
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/
