Dear All,
The Linux Audio Conference submissions deadline has been extended! It is
now January 22nd, 2012.
So, if you were considering submitting a paper but couldn't make up your
mind yet, here is your chance to become active! Never forget that this
conference lives through the people participating in it.
January 22nd is the new deadline for all submission types: papers,
music, installations, workshop proposals.
Notifications of acceptance will still be sent out on February 6th, 2012.
Check out the link below more info:
http://lac.linuxaudio.org/2012/participation
Please spread this information to anyone who might be interested.
Questions? Drop us a line at lac(a)linuxaudio.org
We are looking forward to seeing you at Stanford in April!
Thanks,
The LAC 2012 organization team
HI Guys
happy new year.
Has anyone got the autofaders to work with Ardour and a DDX?
I believe this is possible but can find no info as yet.
Thanks for your time
Cheers
Bob
On Thursday 05 January 2012, Dave Stikkolorum wrote:
> On 05-01-12 15:31, Pedro Lopez-Cabanillas wrote:
> > The problem in loop.c is that you are using the function
snd_seq_ev_set_note()
> > that includes a duration as the 5th parameter. This function will create
two
> > MIDI events in a queue, the first one will be the noteon event, and the
second
> > one will be a noteoff event, scheduled adding the specified duration to
the
> > start time of the former noteon event. That requires a queue for event
> > scheduling.
> So in fact with a message that contains a duration for a note is always
> a queue involved?
Yes, but this macro snd_seq_ev_set_note() is the only one that includes a
duration parameter. It is not really a MIDI message, but the sequencer event
is converted into two MIDI messages (noteOn + noteOff). There aren't MIDI
messages containing durations.
OTOH any event using the macros snd_seq_ev_schedule_real() or
snd_seq_ev_schedule_tick() requires a queue as well, because the message
delivering time will be scheduled in the future.
Events using the macros snd_seq_ev_set_queue_control(),
snd_seq_ev_set_queue_start(), snd_seq_ev_set_queue_stop(),
snd_seq_ev_set_queue_continue() or snd_seq_ev_set_queue_tempo() also require a
queue, because all these macros have a queue parameter.
Regards,
Pedro
Hi all,
I try to write a c program that sends midi notes to the Hydrogen drum
sequencer.
I use the alsa library to create a client with an output port.
I attached two files.
loopqueue.c works but loop.c doesn't.
A base drum (note:28) is being send.
I am not succeeding to use direct delivery,
but it only works with the queue.
Any ideas why?
Regards,
Dave
> My question is, quite simply, since LMMS is FLOSS, would making
> Trippleoscilator + perhaps other instruments in LMMS into plugins
> (lv2/linuxVST) be a realistic possibility? Bear with me, I'm no developer
> but merely a musician, so I really don't know what I'm asking/talking
> about. But I have a firm belief that a plugin-version of these instruments,
> usable in for example Ardour3 when that arrives, would make a great
> addition to the Linux-musician community.
Technically it should be doable, but one would need to go in the code
of LMMS to check it out.
Sometime the code is almost usable directly in plugins.
I'm working on porting the internal modules from AlsaModularSynth into
LV2 plugins at the moment.
Once I'm finished with that, I could take a look into it.
(http://sourceforge.net/projects/avwlv2/)
> (ps. Is there anything similar already existing perhaps? ds.)
You should check AlsaModularSynth, coupled with Seq24... The
instrument you described look like a synth with 3 oscillators (duuuuh,
that would explain the name!). AMS comes with great examples, and
building a Synth with 3 VCO (Oscillators) should be "pretty" easy.
Yoshimi comes to mind as well (although it is way more complicated).
Oh, and if you have some courage, feel free to try my plugins with Ingen :D
P.S: I forwarded your mail to the LAU list. Some users there might
have other ideas for similar synths.
Hope that helps,
Aurélien
Hi all,
I have been looking into ye olde denormal problem a little, lately.
Particularly with respect to Ardour and plugins. I've assembled what I
believe to be a coherent statement of what is going on, but I'd very much
appreciate any corrections and clarifications that anyone can offer.
Here's how it seems to me:
If you compile your code (e.g. a plugin) without -msse and -mfpmath=sse on
the GCC command line you get *no* protection from denormals from the CPU.
If they occur in your code, they will be very much slower than normal
floating point numbers (~49 times slower on my Core 2 Duo, ~7 times slower
on a Core i3). As far as I can see, it does not matter that Ardour has
been built with those flags: if a plugin has not, you have no protection.
If you compile your code with -msse and -mfpmath=sse, you have Ardour's
protection from denormals. If the user's CPU supports it, you get
there is no significant slowdown with denormals using this mode. However
CPU support is "some later processors with SSE2", according to Intel.
The problem, I guess, is that we cannot really distribute plugins with SSE
instructions, otherwise we do not support people with older CPUs. In this
case, I think the plugin code must avoid denormals, otherwise there will
be a significant performance hit if they arise.
I've been testing behaviour using a very dumb program which you can get
from http://carlh.net/software/denormals.tar.gz
I've also been testing plugins using a primitive torture tester that you
can get from http://carlh.net/software/ or on github via
git@github.com:cth103/plugin-torture.git
Any comments?
Best
Carl
Hi everyone,
I was wondering if anyone managed to run a USB 2 soundcard on a USB3
(XHCI) port?
I'm running the kernel 3.2 rc7.
With the M-Audio Fast Track Ultra (USB 2):
The output of dmesg is this:
[ 475.094595] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[ 475.108605] usb 3-1: config 1 interface 3 altsetting 0 bulk
endpoint 0x7 has invalid maxpacket 8
[ 475.108615] usb 3-1: config 1 interface 3 altsetting 0 bulk
endpoint 0x87 has invalid maxpacket 8
[ 475.108958] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep
[ 475.109328] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep
[ 475.109879] xhci_hcd 0000:04:00.0: WARN: short transfer on control ep
[ 475.110564] xhci_hcd 0000:04:00.0: ERROR: unexpected command
completion code 0x11.
[ 475.110585] usb 3-1: can't set config #1, error -22
The snd-usb-audio module is not probed automatically, and if I
modprobe it manually, no sound card is detected.
The error message is described in this bug:
https://bugzilla.novell.com/show_bug.cgi?id=679944
but if I understand well, kernel wise, everything is "ok" and the
issue lies in Alsa
The output of lsusb is:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 050d:0307 Belkin Components
Bus 002 Device 003: ID 0408:1af1 Quanta Computer, Inc.
Bus 001 Device 004: ID 046d:c51b Logitech, Inc. V220 Cordless Optical
Mouse for Notebooks
Bus 003 Device 002: ID 0763:2080 Midiman M-Audio RunTime DFU
The Edirol UA-25Ex (USB 1) works fine, I get a few warnings in dmesg
but the sound card is detected and functional...
Let me know if I should provide any more info, or outputs, anything
that can help.
Kind Regards,
Aurélien
