Linux-audio-dev October 2013

linux-audio-dev@lists.linuxaudio.org

36 participants
30 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)

11 years, 2 months

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

11 years, 7 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

11 years, 7 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<-----

11 years, 8 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 >

12 years

LV2: Communicate from the DSP to the UI

by Aurélien Leblond

>> In my lv2 plugin, I need to communicate information from the DSP to >> the UI, but I don't want to break the DSP/UI separation principle (no >> Instance or Data access). On top of that, I'm using LVTK. > he, he, yeah it can get a little confusing... maybe this will help. > // you're sending things in an atom sequence so get the size information > // from the port buffer > > LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify); > m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size); > > m_forge->sequence_head (m_notify_frame, 0); > > // sequences need a timestamp for each event added > m_forge->frame_time (0); > > // after forging a frame_time, just write a normal float (no blank object needed) > > m_forge->write_float (1604); > Your ttl file has atom:Float as the buffer type. I've never used > anything besides atom:Sequence. I imagine this buffer type doesn't need a > sequence head forged first. Maybe David will jump in on how atom:Float > bufferType'd ports are supposed to forged into and out of. Ok, so I changed my code the way you proposed (with switching in the ttl to Sequence), but still don't manage to make it work. I'm wondering if there isn't something wrong with the way I setup the Forge in the first place. I'm a bit confused with the way to interact wiith the map object in LVTK. Scope::Scope(double rate) : Plugin<Scope, URID<true>, Options<true>>(p_n_ports) { m_forge = new AtomForge(p_map); } void Scope::run(uint32_t nframes) { // you're sending things in an atom sequence so get the size information // from the port buffer LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify); m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size); m_forge->sequence_head(m_notify_frame, 0); // sequences need a timestamp for each event added m_forge->frame_time(0); m_forge->write_float(1604); } > I recommend, if you want to use LVTK to do atom forging, that you subclass > lvtk::AtomForge and add appropriate methods to it... > > Here's a snippet that shows how to write patch get/set messages with a > subclassed AtomForge. It also shows how to write raw midi. > > http://pastebin.com/C1LYtXpv -- the code in there uses small uses the > nullptr macro. just change those to "0" if you're not using c++11 Could you tell me the advantages of doing that? But I had a look at the code, I still need to understand how to work with LV2_URID_Map in LVTK (I cannot find any examples using it).

12 years, 1 month

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

12 years, 1 month

limiting email traffic

by Robin Gareus

Hi all, Due to excessive posts - in particular on the linux-audio-user email list, we are going to rate-limit the number of emails to 13 emails per user per 24 hours with direct follows-up replies to self counting twice. It is not unreasonable to assume that a single user posting more than 12 emails per day is either involved in a heated flame-war or otherwise disrupting reasonable discussion. Neither of which is acceptable on the LA email lists. We understand that some communication requires rapid exchange of many small snippets and recommend users who need to regularly post short messages many times per day to rather use services such as twitter, IRC or simply private email. The LA email lists are mainly intended for discussion, questions & answers, sharing and preservation of knowledge. Note that there are currently over 3000 persons subscribing to the LA lists, every single email sent to the list will result in 3000+ forwards and be archived in various places on the web. Offenders will be notified with a warning message with the 10th email within a day and after the 13th email temporarily banned for 6 hours from further posting to the given email list. Feel free to comment on this email here on this list, but official inquires should be addressed to members of the consortium. See http://linuxaudio.org/contact The system will be activated on 31/Oct/2013 if not vetoed. The actual rate-limit may also be adjusted over time to reflect list-behaviour. yours truly, robin

12 years, 1 month

LV2: Communicate from the DSP to the UI

by Aurélien Leblond

Hi everyone, In my lv2 plugin, I need to communicate information from the DSP to the UI, but I don't want to break the DSP/UI separation principle (no Instance or Data access). On top of that, I'm using LVTK. The type of data I'm trying to move is a Vector of Float (buffer type Sound in the ttl) - but even basic information on how to transfer a Float from the DSP to the UI would be valuable. What I have do so far in the DSP (run method) m_forge->set_buffer((uint8_t*)p(p_notify), sizeof(float)); //p_notify being the atom port m_forge->sequence_head(m_notify_frame, 0); ForgeFrame p_frame; Atom p_msg = m_forge->write_blank(p_frame, 1, urids.atom_Float); m_forge->property_head(urids.atom_value, 0); m_forge->write_float(1604); //test data i'm trying to move m_forge->pop(p_frame); In my UI, I just want to see if I receive this data In the port_event method, at the moment the only thing I'm doing is: std::cout << port << " - " << format << std::endl; The port is defined in the TTL as follows: a lv2:OutputPort, atom:AtomPort ; atom:bufferType atom:Float ; atom:supports <http://lv2plug.in/ns/ext/patch#Message> ; lv2:index 1 ; lv2:symbol "notify" ; lv2:name "Notify" ; At the moment, the code compiles and runs without crashing (yeah!), but nothing happens (boo!). Would you guys have any ideas? Thanks in advance, Aurélien

12 years, 1 month

linux-port of OpenMusic

by anders.vinjar＠bek.no

Hi all. Ive been working on a linux-port of IRCAMs OpenMusic lately, and think its approaching a useful state now. I would very much appreciate it if some of the brave ones out there did some testing and sent me feedback: http://forge.ircam.fr/p/OM6/downloads/label/421/ The tarball you'll find there includes the OM-6.7 image, source code, a README and the various resources it uses (.so's, libs, fonts, icons, help-files, tutorials, other). This beta is not prepared to be installed anywhere, only to be run from inside the directory where you unpack it (type ./OM_6.7_beta_4 ... ). Plan is to make an installable version once the dust settles some. Theres one thing which needs installing to work however, the music-fonts used in the various editors and factories etc. Theres an .rpm here: http://forge.ircam.fr/p/OM6/downloads/get/omfonts-1.0-1.noarch.rpm.zip - which hopefully takes care of the fonts (theyre also available for manual install in the tarball). The .rpm installs them (4 .ttf-files) inside its own folder /usr/share/fonts/omfonts/* The present version uses JACK for audio + midi I/O, and will try to start a JACK server if its not already running. To get any sound from the usual midi-ports, the linux-port uses libfluidsynth, and attempts to load one of the standard soundfonts into it. However you should be able to route midi-output to any client you prefer (with jack-midi support). Thanks for any feedback. Cheers, -anders

12 years, 1 month

2025

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 October 2013