Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

Looking for c/c++ library that for reading guitar pro files

by Nathanael Anderson

tuxguitar has java support for guitar pro files, so the format is understood, I'm wondering if anyone ever ran across a c/c++ library for reading them? I found ptparser for power tab, but most of my tab is in gp3/4/5 format, and I'd like to be able to write some code dealing with gp stuff, without having to write a whole lib to read them. Thanks, Nathanael

15 years

Please post this invitation to LAD - LAD NAMM 2011 Trinity Audio Group / Indamixx

by Ronald Stewart

Please post this invitation to LAD - LAD NAMM 2011 Trinity Audio Group / Indamixx Hi All, The Linux Audio community is a 6 year blessing to our existence. We would like to invite 5-7 at large attendees of Linux Audio Developers as our guest at NAMM 2011. Our 5-7 passes for NAMM are full vendor passes. Anyone in the area (Los Angeles) or who would like to attend globally and has the funds to buy airfare I will work with to get hotel accommodations at a super discounted rate as to not pinch the wallet. Deadline for emailing me you are interested in December 14th as the 15th is the day I must submit our final vendor attendee list. my email is ronaldjstewart(a)gmail.com here is the NAMM website: http://www.namm.org/thenammshow/2011 Thank you so much LAD! Ronald Stewart Creative Director Trinity Audio Group Inc. 9854 National Blvd. #322 Los Angeles CA 90034 310-733-9285 ronaldjstewart(a)gmail.com

15 years

recycle users wanted

by Alexandre Prokoudine

Hello lists :) First, an introduction. Within the context of this mail I'm representing re-lab -- a small project [1] that does a dirty job developers usually try to avoid -- reverse-engineering file formats that have no publicly available specs. Our primary goal is helping dev teams and therefore end-users to support legacy data. We started with Corel DRAW back in 2007 (supported by Inkscape, sK1 and UniConvertor now), continued with painting dynamics in Photoshop brushes (supported by Krita in SVN trunk) and Photoshop gradients (supported by SwatchBooker), and now we arrive to audio domain. A while ago we asked Ardour team if they wanted some file formats reverse-engineered. Paul named a couple of such file formats, including REX2 audio loops [2]. Since we are (at least pretend to be) nice guys, we started with mailing Propellerhead, but they never replied (only to be expected, given their track record re open source teams). Well, something had to be done about that, eh? So we started looking into things. Initial version of Python scripts that parse .rx2 files and dump stuff to stdout is already available [3]. This is exactly what deliver in the end: Python scripts for parsing and a specification that explains what every chunk does. Now here is what we need. All we have right now is a bunch of .rx2 files that I got with my Focusrite Saffire Pro24 and bundled software. It's good for a start, but for proper r-e we need introducing small changes to files and seeing what's changed. So we need someone with a licensed copy of ReCycle and some spare time on his/her hands to help us figuring things out. Demo version of ReCycle works fine in WINE, but saving and loading arbitrary files is impossible. We really do not want dealing with pirated copies, because, again, we do our best to be nice guys. And since we do it not just for fun, but for actual results, we'd be glad if developers of other applications (FreeCycle and Smasher are the first I can think of) implemented support for REX2. Coincidentally we are also interested in people who are good at audio compression algorithms. *cough* Monty *cough* :) By the way, usually I don't read both l-a-u and l-a-d lists, so after a while (a week maybe) I'll turn off delivery of mails, which means you probably want using Reply to All button in your mail client of choice. [1] http://gitorious.org/re-lab/ [2] http://en.wikipedia.org/wiki/REX2 [3] http://gitorious.org/re-lab/audio Alexandre Prokoudine http://libregraphicsworld.org

15 years

Re: [LAD] [LAA] Denemo 0.8.22 Release - Free and Open Source Music Notation Editor (Lilypond Frontend & Midi)

by Niels Mayer

On Wed, Dec 8, 2010 at 9:38 AM, Nils <nils(a)hammerfeste.com> wrote: > Denemo 0.8.22 release! > Get it on http://www.denemo.org After a successful "configure" "make" fails with: Making all in doc ./make: line 1: html:: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl ./make: line 4: chunk:: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/chunk.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/chunk.xsl ./make: line 7: pdf:: command not found compilation error: file denemomanual.xml line 3 element article xsltParseStylesheetProcess : document is not a stylesheet ./make: line 9: fop.sh: command not found ./make: line 10: acroread: command not found ./make: line 11: 075: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl ./make: line 14: 076: command not found warning: failed to load external entity "/usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl" cannot parse /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/profile-docbook.xsl make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/npm/denemo-git' make: *** [all] Error 2 The issue seems to be hard paths to /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl which are files that aren't owned by any package on the Fedora platform: gnulem-335-~/denemo-git> yum whatprovides /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl ... No Matches found -- Niels http://nielsmayer.com

15 years

Re: [LAD] Project proposition: llvm based dsp engine

by Stéphane Letz

> > > Message: 3 > Date: Mon, 06 Dec 2010 14:11:07 +0100 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] Project proposition: llvm based dsp engine > To: Paul Davis <paul(a)linuxaudiosystems.com> > Cc: The Linux Audio Developers' Mailing List > <linux-audio-dev(a)lists.linuxaudio.org>, llvmdev(a)cs.uiuc.edu > Message-ID: <1291641067-065c11f3c738513db43420e758ad7e5d(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, and thanks for the feedback. > >> My own gut feeling on this is that you'd be better off figuring out >> how to do this in the context of Faust, which already does a important >> subset of what you are describing, though notably without (I think) >> the LLVM part. > > Surely a contribution to the discussion by the Faust people would > be welcome; and even more than to the discussion :->. By the way, they > do something with LLVM, but i do not know exactly what (Faust is included > in the list of projects using LLVM). > > I think the interest, if any, would be in having a *low* level > library generic enough to be used by multiple applications, so > to factor the work. It may be that an existing project have internally > a large part of the needed code, though. > >> Note also that hosts which run plugins at the level of LADSPA/LV2, >> VST, AU, DSSI etc are unlikely to be easy candidates for any >> cross-plugin optimization. > > I was actually talking about two different context, reusing existing > binaries, and having cross plugin optimisations for native plugins. > > But, if the plugins are compiled with a different compilation chain > (using the LLVM compiler producing LLVM byte code, so introducing a different > binary format for them), than cross plugin optimisation is possible also for > existing plugins like a LADSPA plugin. > > Would that be worthwhile ? Difficult to know for sure, but it is an interesting > subject to explore. > > Maurizio > I'm quite dubious of any real optimization you would achieve with this kind of approach, using LLVM. AFAIKS LLVM link time optimization allows some kind of inter module inlining or possibly constant propagation (see http://llvm.org/docs/LinkTimeOptimization.html) but I am not sure it would help a lot in our domain. Again staying in the imperative world makes things much more complicated... go functional! Stéphane PS: BTW LLVM is a really nice tool and very interesting things can be done with it, like using LLVM bitcode format as an interchange format for different architectures and using the JIT for dynamic compilation. We can already do that with Faust LLVM backend where we can generate a bitcode binary, then load it and JIT with a generic "LLVM faust plug-in" loader. This would allow the same bitcode object to be produced by the Faust online compiler for instance and be executed on any target machine.

15 years

L2Ork seeking additional performance opportunities in Berlin and Paris

by Ivica Ico Bukvic

Apologies for cross-posting. Linux Laptop Orchestra or (L2Ork) is currently in the final stages of planning its debut European tour. While most venues have been already arranged for we are currently in the process of seeking additional performance opportunities in Paris, France as well as Berlin, Germany. Our target dates are May 17-31, 2011 with anticipated stops in Ljubljana, Budapest, Linz, Berlin, Hamburg, Utrecht, Amsterdam, Paris, and Birmingham. If anyone is aware of potential venues in Paris and Berlin and/or contacts that may be able to point us in the right direction, I would greatly appreciate it if you would please email me at your earliest convenience. For additional info on L2Ork please visit http://l2ork.music.vt.edu/main/ Thank you very much! Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra 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/

15 years

Project proposition: llvm based dsp engine

by Maurizio De Cecco

I have been looking for a while to LLVM as a possible technology to build a DSP execution engine, providing the runtime flexibility needed by real-time interactive DSP applications (like patcher languages), or by plug-in based processors, and in the same moment the powerful link time optimizations that such a system can provide. Such a task is daunting for a single developer project like mine, but it may become feasible if such engine could be useful for multiple projects, so to become a community initiative (i am sending this mail to the Linux Audio Developers mailing list and to the LLVM mailing list, feel free to send it elsewhere if you find it useful). So, I'll explain in a few lines exactly what i thinking of, and i propose that if anybody is interested in such initiative she/he can contact me directly, and we will see if there is enough interest for actually start something. Of course, i may also miss an existing project on the same field, in this case, let me know :->. The idea is the following: build a tool kit, based on LLVM, to dynamically build the execution chain of DSP applications; almost all DSP applications using plug-ins have something of this kind. This toolkit will be based on code generation and JIT, and should have a flexible architecture so to accomodate multiple plugin API/ABI, to be able to call, from the same execution chain, DSP operation written for different contexts (for example, LADSPA plug-ins, PD objects, and so on). The code generation would allow this integration for a very low run time cost. But the most interesting part is actually providing a definition of native, LLVM compiled, plug-ins, and to use the LLVM link time optimizations for doing things like inlining, loop fusions etc, between different DSP operation; this can provide quite a speed improvement for those chains composed of simple operators. The execution chain should be flexible enough to provide support for multi-rate synchronous data flows, and should include support for multiple threads execution (probably different chains for different threads). To complete the project, let's add a library of DSP operators, a reasonable high level API to use it, and documentation to help the DSP application designer (i find the LLVM learning curve quite steep :). Contact maurizio(a)dececco.name if you are interest in setting up such a project; if enough developers with the right skills and enough interest are found I'll set up a project mailing list to further discuss the subject. Cordially, Maurizio __________ Maurizio De Cecco - Music: http://www.myspace.com/mauriziodececco Blog: http://maurizio.dececco.name/ Software: http://www.jmax-phoenix.org/

15 years

Re: [LAD] Project proposition: llvm based dsp engine

by Stéphane Letz

Le 7 déc. 2010 à 13:00, linux-audio-dev-request(a)lists.linuxaudio.org a écrit : > > Message: 6 > Date: Tue, 07 Dec 2010 11:40:08 +0100 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] Project proposition: llvm based dsp engine > To: linux-audio-dev(a)lists.linuxaudio.org > Message-ID: <1291718408-fa0519db02fe30b9a7fa6ef94f6d44d6(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1" > > I realised that my yesterday answer miss the point a little, > so here it is a few linse of complement. > > Going back to the Paul comment: > >> I can say for sure that, for example, >> Ardour3 has an object called a Processor whose ::run() method >> encapsulates all DSP done within Ardour, but nevertheless it would be >> more or less impossible to do any kind of optimization that looked >> "across" all the Processors in a signal chain (eg. gain, pan, plugins, >> etc, etc). > > This is exactly the point: what about having a way to build the 'run' methods > for a class of applications (PD have such a method, jMax have such a method, > many others application have such a methods) that *would* allow cross plugin > optimisations for a certain class of plugins (those written or compiled according > to the engine 'native' rules) and being able to use the other plugins keeping the > glue code run time cost very low thanks to dynamic code generation. > > Essentially a generic basic infrastructure using LLVM code generation and optimisation > capabilities. > > And by the way, i am not sure to understand the reference to Faust, that is one of the > language/system used to define and assemble DSP algorithms, and to generate plugins, > but it is not a generic container for DSP executions, AFAIK. > > Maurizio > Doing "cross plugin optimisations" is something that can be done at the Faust source code level, where sophisticated optimization and code reorganisation can be done because we stay at a pure functional signal level, thus avoiding all the complex issues related to state management. If you want to combine plug-ins coded in any kind of imperative language, then some really hairy issues are coming quite rapidly. Stéphane

15 years

Harmonic generator and transfer function

by Andrew Gaydenko

How does Steve Harris' Harmonic generator LADSPA plugin work? I mean relation between controls (concrete harmonics levels) and transfer function Vout = Vin(1 + a*Vin + b*Vin^2 + ...)

15 years

Is there a Linux Software Mixer?

by Rory Filer

Hi All I think I know the answer to this, but I was wondering if it's possible to mix two separate audio sources in software. I'd like to be able to play announcement-type audio atop the currently playing main track. An example might be when driving down the Autobahn and a traffic report temporarily pre-empts whatever it is you are listening to. In my case, though, I'd prefer to keep the main audio playing, but at a very low volume level compared to the short announcement.. My setup is a roll-your-own embedded Linux distro with kernel 2.6.28. I'm using Alsa SoC audio driving an I2S output on my Marvell processor (which is now working just fine, BTW). The I2S signals feed an FM transmitter chip which is broadcasting audio to a nearby FM receiver. The FM chip only has the one input so no mixing possible within that part. Anyhow, considering I only have a single I2S output, seems to me that I'd need to do the mixing somewhere upstream of that serial port within the Linux machine. But there is no special hardware for this and I think the answer is "no, there is no way to mix two separate audio tracks without a DSP and another device driver". But I thought I'd ask just the same. Regards, Rory

15 years

Jump to page:

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