Linux-audio-dev September 2013

linux-audio-dev@lists.linuxaudio.org

46 participants
37 discussions

by Frank Kober

Hi, QMidiArp 0.5.2 has just seen the light of the day. It brings mainly two improvements. One is a comeback, that of tempo changes on the fly, and that now includes also tempo changes of a potential Jack Transport master. Also the Jack Transport starting position is finally taken into account, so that QMidiArp should be in sync also when starting the transport master not at zero. The second one is Non Session Manager support, mainly thanks to the work done by Roy Vegard Ovesen! Note that for compiling in NSM support you will now need liblo as dependency. Enjoy, and enjoy LAC in Graz this year Frank ________________________________ QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO. Everything is on http://qmidiarp.sourceforge.net qmidiarp-0.5.2 (2013-05-09) New Features o Tempo changes are again possible while running, both manually or by a Jack Transport Master o Jack Transport position is now taken into account when starting, QMidiArp used to start always at zero o Muting and sequencer parameter changes can be deferred to pattern end using a new toolbutton o Modules in the Global Storage window have mute/defer buttons o Global Storage location switches can be set to affect only the pattern o Non Session Manager support with "switch" capability (thanks to Roy Vegard Ovesen) General Changes o NSM support requires liblo development headers (liblo-dev package)

10 years

OpenAV Productions : Sorcer

by Harry van Haaren

Hey Everybody, I'm happy to announce OpenAV productions: http://openavproductions.com OpenAV productions is a label under which I intend to release my linux-audio software projects. The focus of the software is on the workflow of creating live-electronic music and video. The release system for OpenAV productions is one based on donations and time, details are available on http://openavproductions.com/support Sorcer is a wavetable synth, and is ready for release. Check out the interface and demo reel on http://openavproductions.com/sorcer Greetings from the LAC, -Harry

10 years, 5 months

itop

by elboulangero

Hello everyone, lately I had to fight big XRUN troubles, and thanks to this forum I finally solved that. This excellent thread saved me: http://linuxaudio.org/mailarchive/lau/2012/9/5/192706 On my long quest, I tried to see a little bit more what happened with the IRQs on my system. I searched for a kind of 'top' utility to monitor the interrupts, but the only apps I found were either deprecated, or missed some cool features. So, I ended up writing my own tool to monitor the file /proc/interrupts. It's available a this address: https://gitorious.org/elboulangero/itop As its name indicates, it behaves pretty much like top, but for interrupts. It's quite a simple thing, that I tried to enhance a bit with some cool features: + refresh period can be specified. + two display modes: display interrupts for every CPU, or only a sum of all CPU. + display every interrupt (sorted like /proc/interrupts), or only active interrupts (sorted by activity). + in case the number of interrupts changes during the execution of itop (due to a rmmod/modprobe), it's handled without any fuss. + command-line options are also available as hotkeys for convenience. + at last, the program display a summary on exit. The idea is that this summary could be copied/pasted in emails to help debugging. If anyone is interested, feel free to try and comment ! Cheers

10 years, 5 months

Support for Steinberg UR22 (Yamaha USB chipset 0499:1509)?

by cullinan＠rocketmail.com

Hi, there! I just got a Steinberg UR22 USB<->Audio / MIDI interface for my semi-prof. DJ work. I am working on Linux (only), but wanted to give this new product a chance. Well, it's basically a nice device but with an Yamaha chipset in it which seem unfortunately not supported from the latest (3.7.9) linux kernel(s). My questions are: - How likely is it to get this device fully supported on linux? - What needs to be done to get this device fully supported? I am an electrical engineer and did some linux device driver development in the past on some DMA stuff, but I am quite new to linux audio. But I am willing to help somewhere... I could try to reverse-engineer the USB stuff on Windows with the usbmon/usbsnoop/libusb things... But if it's too much work, to get it working, I could also just decide to send it back to Steinberg and thank them for not supporting Linux with their products. The USB information I could get is: $ aplay -l doesn't list that device $ lsusb ... Bus 002 Device 016: ID 0499:1509 Yamaha Corp. ... (See the more comprehensive $ lsusb -v below...) Related USB devices are: 0499:1501 Yamaha 0499:1507 Yamaha THR10 0499:1509 Yamaha Steinberg UR22 (what I am talking about) 0499:150c Yamaha THR10C Related search resuls are: Getting a Steinberg CI1 USB audio interface to work http://ubuntuforums.org/showthread.php?t=1696336 Yamaha THR10 amp / USB2.0 audio interface http://linux-audio.4202.n7.nabble.com/Yamaha-THR10-amp-USB2-0-audio-interfa… Thank you, Clemens (different one as in last link) -----8<----- $ lsusb -v -d 0499:1509 Bus 002 Device 014: ID 0499:1509 Yamaha Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0499 Yamaha Corp. idProduct 0x1509 bcdDevice 1.00 iManufacturer 1 Yamaha Corporation iProduct 2 Steinberg UR22 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 442 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 0a 24 01 00 01 34 00 02 01 02 ** UNRECOGNIZED: 0c 24 02 01 01 01 00 02 03 00 00 00 ** UNRECOGNIZED: 09 24 03 02 01 03 00 01 00 ** UNRECOGNIZED: 0c 24 02 03 03 06 00 02 03 00 00 00 ** UNRECOGNIZED: 09 24 03 04 01 01 00 03 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 44 ac 00 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x002a 1x 42 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 10 b1 02 00 ee 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0096 1x 150 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 44 ac 00 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x002a 1x 42 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 10 b1 02 00 ee 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0096 1x 150 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 255 iInterface 0 ** UNRECOGNIZED: 07 24 01 00 01 24 00 ** UNRECOGNIZED: 06 24 02 02 01 00 ** UNRECOGNIZED: 09 24 03 02 01 01 01 01 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 ** UNRECOGNIZED: 07 24 01 00 01 24 00 ** UNRECOGNIZED: 06 24 02 02 01 00 ** UNRECOGNIZED: 09 24 03 02 01 01 01 01 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) -----8<-----

10 years, 5 months

Re: [LAD] Community Interaction and Working Together

by michel dominique

On ven. 20/09/13 13:11 , Harry van Haaren <harryhaaren(a)gmail.com> wrote: > Hello all Users & Devs of linux-audio-land, > > Moving forward from the topic on Aeolus and forking projects, perhaps it is > wise to look at how the community as a whole can grow from this situation: > > 1) It seems the frustration of forks is mainly due to lack of > communication. > 2) Had appropriate communication been in place, patches could have been > merged. > 3) If 1) and 2), then the community flourishes as a whole. > > In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its > relevant here): > "That imply we must communicate more with each other" > "I think this is a big problem, and not only related to Fons work, or the > LAD, but to the whole community." One think I have done is to add in the About box a few buttons to launch things like the mail list subscription page, mailto and irc. The function look for $BROWSER, if it doesn't exist, the user get the opportunity to set it, and the browser will do the rest. It is too early now for me to know if it make a big difference. This will not replace an email list, but can be a good complement, and make life easier for someone that want to get in touch with the development, or have an issue, a comment or whatever to ask or report. And well, this is oriented first to users. Developers must be able to find my email on the website or the source code... > > The mailing list you're reading from now is one of the central hubs for the > community: > The -developers list is the perfect place to announce projects, forks, > patches etc. +1 > The -users list is good for asking users and interested parties questions. +1 Dominique > > I will try to announce more patches / code, to contribute upstream, and > hopefully benefit the community. > Cheers, -Harry > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev [1] > > > > Links: > ------ > [1] > http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi > nfo/linux-audio-dev >

10 years, 9 months

Community Interaction and Working Together

by Harry van Haaren

Hello all Users & Devs of linux-audio-land, Moving forward from the topic on Aeolus and forking projects, perhaps it is wise to look at how the community as a whole can grow from this situation: 1) It seems the frustration of forks is mainly due to lack of communication. 2) Had appropriate communication been in place, patches could have been merged. 3) If 1) and 2), then the community flourishes as a whole. In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its relevant here): "That imply we must communicate more with each other" "I think this is a big problem, and not only related to Fons work, or the LAD, but to the whole community." The mailing list you're reading from now is one of the central hubs for the community: The -developers list is the perfect place to announce projects, forks, patches etc. The -users list is good for asking users and interested parties questions. I will try to announce more patches / code, to contribute upstream, and hopefully benefit the community. Cheers, -Harry

10 years, 11 months

MIDI Running Status and ALSA, was: [LAU] Launchpad S and Linux

by Kaspar Bumke

On 28 September 2013 22:01, Fons Adriaensen <fons(a)linuxaudio.org> wrote: > If the problem is the same as with the original LP, then > the ALSA driver can't do anything about it, unless it would > contain LP-specific code. > But isn't the problem a general running-status problem if multiple programs are receiving from the same device? Is it a problem with the way the ALSA sequencer works (this seems to ring a bell somehow) as you said in the older thread that using Jack-MIDI would solve it?

11 years

JACK + PA Latency

by Patrick Shirkey

Hi, Moving this to the LAD list as it seems to be getting to a more technical and challenging stage now. This may be a simple answer and if so that is great but suspect it is a bit more complex than that so might require the brain power of the LAD list rather than just my capabilities. To recap I am trying to get hard data on the best case latency while running a combination of JACK + PA. There are various reasons for and against doing this but discussing them is not the purpose of this thread. - I am using jack_delay to measure the round trip latency between jack -> PA -> JACK - I also have been testing a complete loop including system i/o but for the purposes of this thread we can ignore those results. - I have seen some interesting numbers come up today. If I run the following command: pactl list sink-inputs I get numbers similar to this: Buffer Latency: 8000 usec Sink Latency: 3166 usec The combination of the two shows the actual PA Stream Buffer latency (approx 10 - 11ms). This number stays approximately static while polling with this command. To be clear there is also the additional latency that occurs as the data is transferred from PA to the output but I am told it is negligible although it might turn out to be a key player. The results from jack_delay are somewhat different. I have included a snapshot below*. For reference sake it was also suggested that I open /dev/cpu_dma_latency and give it a value of 0. /dev/cpu_dma_latency allows to write the latency you can tolerate (in ms). The kernel will translate this to the deepest C-state the processor can enter. I have been running my tests with this value at zero in case it helps. I have checked with powertop and turbostat but it doesn't appear to make any difference on this machine. Possibly because it is an older cpu. Armed with that preliminary information there are a couple of issues that I am interested in at this juncture. 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. --------- RESULTS --------- jack_delay -> pa -> ecasound -> pa -> jack_delay hda_intel driver dual core Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz jack is run at 64/48000/2 ecasound has a period size of 64 PA is configured to run at 48khz too [*] Here's the snapshot from jack_delay: 62784.000 frames 1308.000 ms total roundtrip latency extra loopback latency: 62784 frames use 31392 for the backend arguments -I and -O 62784.000 frames 1308.000 ms total roundtrip latency extra loopback latency: 62784 frames use 31392 for the backend arguments -I and -O ?? Inv 63168.000 frames 1316.000 ms total roundtrip latency extra loopback latency: 63168 frames use 31584 for the backend arguments -I and -O 63743.999 frames 1328.000 ms total roundtrip latency extra loopback latency: 63743 frames use 31871 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64639.999 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 64640.000 frames 1346.667 ms total roundtrip latency extra loopback latency: 64639 frames use 32319 for the backend arguments -I and -O 65088.000 frames 1356.000 ms total roundtrip latency extra loopback latency: 65088 frames use 32544 for the backend arguments -I and -O 65088.000 frames 1356.000 ms total roundtrip latency extra loopback latency: 65088 frames use 32544 for the backend arguments -I and -O 65087.999 frames 1356.000 ms total roundtrip latency extra loopback latency: 65087 frames use 32543 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65152 frames use 32576 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65216.000 frames 1358.667 ms total roundtrip latency extra loopback latency: 65216 frames use 32608 for the backend arguments -I and -O 64.000 frames 1.333 ms total roundtrip latency extra loopback latency: 63 frames use 31 for the backend arguments -I and -O 64.000 frames 1.333 ms total roundtrip latency extra loopback latency: 63 frames use 31 for the backend arguments -I and -O ?? Inv 256.000 frames 5.333 ms total roundtrip latency extra loopback latency: 256 frames use 128 for the backend arguments -I and -O 256.000 frames 5.333 ms total roundtrip latency extra loopback latency: 256 frames use 128 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 768.001 frames 16.000 ms total roundtrip latency extra loopback latency: 768 frames use 384 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 831 frames use 415 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1024 frames use 512 for the backend arguments -I and -O ?? 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1024 frames use 512 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1023 frames use 511 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1023 frames use 511 for the backend arguments -I and -O 1344.000 frames 28.000 ms total roundtrip latency extra loopback latency: 1344 frames use 672 for the backend arguments -I and -O -- Patrick Shirkey Boost Hardware Ltd

11 years

Build error in Guitarix

by Gianfranco Ceccolini

Hi Hermann I've been trying to build the latest versions of Guitarix - both the git latest version (29 I believe) as the 28-2 - and both yield the same error when I try to use the -optimization flag package libcloog-ppl0 not found : optimization is disabled I'm using an Arch Linux on an Intel Atom N2800 and I have the AUR cloog-ppl 0.16.1-1 package installed. Is there something else to be done in order to get the optimization flag to work? Iǘe browsed the LAD archives and noticed there is already a tread with this error in topic for version 27. Can I discard the optimization flag and add the "march=native" instead? If yes, how should I do it? Can't wait to try the gx-fuzz on the MOD! Kind regards and congratulations for the effort on Guitarix. Here at the MOD Team we have it as on of our favourite plugins pack. Gianfranco

11 years

[ANN] Vee One Suite 0.3.5 - Fall greetings released!

by Rui Nuno Capela

yet again, a new batch the Vee One Suite of old-school software instruments is out: synthv1 [1] polyphonic synthesizer, samplv1 [2] polyphonic sampler and drumkv1 [3] drum-kit sampler. as usual, all three are made available in dual form: - a pure stand-alone JACK client with JACK-session, NSM (Non Session management) and both JACK MIDI and ALSA MIDI input support; - a LV2 instrument plugin. as for this release changes: - First attempt on separating the DSP code from UI as runtime objects, effective for the LV2 plugin deploy. - MIDI channel filter switch is now introduced. - Fixed uninstall target make rule. - Mono(phonic) mode switch is now being introduced. - Another minor fix to note-off fast-release. all free and open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. so, here they go again: [1] synthv1 - an old-school polyphonic synthesizer synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx. LV2 URI: http://synthv1.sourceforge.net/lv2 website: http://synthv1.sourceforge.net downloads: http://sourceforge.net/projects/synthv1/files - source tarball: http://download.sourceforge.net/synthv1/synthv1-0.3.5.tar.gz - source package: http://download.sourceforge.net/synthv1/synthv1-0.3.5-12.rncbc.suse123.src.… - binary packages: http://download.sourceforge.net/synthv1/synthv1-0.3.5-12.rncbc.suse123.i586… http://download.sourceforge.net/synthv1/synthv1-0.3.5-12.rncbc.suse123.x86_… [2] samplv1 - an old-school polyphonic sampler samplv1 is an(other) old-school all-digital polyphonic sampler synthesizer with stereo fx. LV2 URI: http://samplv1.sourceforge.net/lv2 website: http://samplv1.sourceforge.net downloads: http://sourceforge.net/projects/samplv1/files - source tarball: http://download.sourceforge.net/samplv1/samplv1-0.3.5.tar.gz - source package: http://download.sourceforge.net/samplv1/samplv1-0.3.5-12.rncbc.suse123.src.… - binary packages: http://download.sourceforge.net/samplv1/samplv1-0.3.5-12.rncbc.suse123.i586… http://download.sourceforge.net/samplv1/samplv1-0.3.5-12.rncbc.suse123.x86_… [3] drumkv1 - an old-school drum-kit sampler drumkv1 is (yet) an(other) old-school all-digital drum-kit sampler synthesizer with stereo fx. LV2 URI: http://drumkv1.sourceforge.net/lv2 website: http://drumkv1.sourceforge.net downloads: http://sourceforge.net/projects/drumkv1/files - source tarball: http://download.sourceforge.net/drumkv1/drumkv1-0.3.5.tar.gz - source package: http://download.sourceforge.net/drumkv1/drumkv1-0.3.5-8.rncbc.suse123.src.r… - binary packages: http://download.sourceforge.net/drumkv1/drumkv1-0.3.5-8.rncbc.suse123.i586.… http://download.sourceforge.net/drumkv1/drumkv1-0.3.5-8.rncbc.suse123.x86_8… see also: http://www.rncbc.org/drupal/node/709 enjoy && have fun! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

11 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev September 2013