Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Carlo Trimarchi

Hi, I need to build an application that can process sound from an external instrument (a midi keyboard, for example). I also need to create a graphic interface and I'd like to know which language maybe best to do this. Any suggestion? Thanks, bye.

18 years, 10 months

[linux-audio-dev] [completely OT] c++ and UTF-8 question

by Julien Claassen

Hi! I'm sorry to ask that here, but it seems I can't get an anser anywhere else. Does the libstdc++ support UTF-8 strings? Or is there some simple example code snippet somewhere to derive/modify something which would fullfill this need? Kindest regards and thanks! Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

18 years, 10 months

[linux-audio-dev] Re: processing plugin standard wrapper

by Stefano D'Angelo

> > > > you can think all you want. unless there a plugin->host callback that > > > > allows the plugin to determine its operating environment in huge detail, > > > > this kind of idea is pretty impossible to make use of. > > > > > > What? > > > Once again: misunderstood! These optimizations involve that the > > > "wrapper" (I should stop calling it this way) knows about the network > > > of processing objects (read: plugins) and that these last ones contain > > > "generic" information on their functionality (ex. STFT for LTI proc. > > > objects). > > > Then the wrapper takes care of optimizing the net. > > > > find me a host author who would want to use such a thing... managing > > plugins is a central task of a host, and handing that over to some > > "wrapper" that hides information from the host doesn't make the host's > > life easier, it makes it more complex. > > In fact you wouldn't have to. > You could just use it as a plugin wrapper, network representation and > optimizazion would be of some use only for some (experimental? > advanced? strange?) hosts. > Personally, I would use such thing for my project. > Then, who said that it has to hide such informations to the host?... > It is definitively not a plugin arch wrapper, but a kind of > "inter-application jack-like connectivity tool for processing objects > with already existing plugin archs wrapping and network optimization > capabilities". > As it goes when you build a GTK app, you don't have to use each > library function, and so it would become just a plugin wrapper. > Maybe the two things can be split, but maybe optimization could hardly > depend on each processing object interface (aka plugin format). Well, I thought about it last night, and maybe the whole thing could be split in three parts: 1. A modular processing object format wrapper (one module for each format) 2. A GUI generation and handling (and maybe embedding? XEMBED?) wrapper with format-specific modules and toolkit-specific modules 3. A library with network representation, optimizing and processing capabilities. What do you think about it? Stefano

18 years, 10 months

[linux-audio-dev] What does it mean for jack to be "rolling" (newby)

by Jonathan Ryshpan

I've been using jack and qjackctl with audacity under Linux (FC6). It seems to be working OK with 1 approx 1 msec xrun in a half hour recording session, when unfortunately my backup system kicked in. However there's something I don't understand about jack, even after reading a lot of the documentation. At the bottom of the qjackctl window is a set of arrows, like on an audio control device. When I click on the arrow pointing right, the green "Stopped" in the main window changes to "Rolling". What does this mean? What are the other arrows for? No useful info on the web. The above recording session was done while jack was "Stopped". Would jack work better if it were "Rolling"? Please excuse these elementary questions. Thanks - jon

18 years, 10 months

[linux-audio-dev] Re: processing plugin standard wrapper

by Jeff McClintock

>>>I actually don't know how many plugins are LTI, but, for example, a >>>lot of delays, reverbs, choruses, eq. filters, compressors, modulators >>>and "sound mixers" should be, and that's quite enough after all. Yeah, It's a good optimization. The SynthEdit plugin API supports inputs being flagged as 'linear', if several such plugins are used in parallel they are automatically collapsed into a single instance which is fed the summed signals of the original plugins. Plugin are collapsed only when their control inputs are the same. BEFORE optimation: [plugin]-->[delay1]------> [plugin]-->[delay2]-/ AFTER: [plugin]--->[delay1]---> [plugin]-/ e.g. two parallel 100ms delays are combined. Two different length delays aren't. This is most useful in synth patches where each voice is an identical parallel sub-patch. Jeff McClintock

18 years, 10 months

[linux-audio-dev] [ANN] Aqualung 0.9beta7.1 released

by Tom Szilagyi

Aqualung 0.9beta7.1 has been released. This is an update to our recent 0.9beta7 release, containing some important fixes to bugs that were found as a result of the greater user coverage after the release of 0.9beta7. Aqualung is a cross-platform music player with lots of features. Homepage: http://aqualung.sf.net (we are unable to update it ATM because of a several days long SF.net shell outage, but the SF.net project page has the latest downloadable files available). The ChangeLog is attached below. Tom 2007-02-18 Tom Szilagyi <tszilagyi at users dot sourceforge dot net> * Aqualung 0.9beta7.1 http://aqualung.sf.net This is a bugfix release, for some important fixes that were found due to the greater user coverage after the beta7 release. * Fixed drag and drop from external applications. * Remove selected tracks and invert selection in Playlist are now fast (optimized and improved). * Shortcut 'A' (show active song) in Playlist window doesn't interfere with CTRL+A (select all). * Added checks for NULL pointers as a workaround for a TagLib bug. * Added native WavPack decoder contributed by Maarten Maathuis.

18 years, 10 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 41, Issue 8

by oc2pus＠arcor.de

Am Dienstag, 13. Februar 2007 schrieb linux-audio-dev-request(a)music.columbia.edu: > 5. CLAM 0.98 released (David Garc?a Garz?n) > > > Message: 5 > Date: Tue, 13 Feb 2007 19:28:31 +0100 > From: David Garc?a Garz?n <dgarcia(a)iua.upf.edu> > Subject: [linux-audio-dev] CLAM 0.98 released > To: "The Linux Audio Developers' Mailing List" > <linux-audio-dev(a)music.columbia.edu> > Message-ID: <200702131928.31826.dgarcia(a)iua.upf.edu> > Content-Type: text/plain; charset="utf-8" > > We are glad to announce CLAM 0.98 a.k.a. âMac is here to stayâ. > > CLAM[1] is a free-software, C++ framework for doing research and > application development in audio and music. It also comes with a set of > applications ready to use for non technical users. > > This is the first release not developed within the MTG [2] since its main > developers now work at the GTI[3], also at the Universitat Pompeu Fabra. > Still, CLAM is very indebted to the MTG people. > > Most of the work in this release was focused on having stable building, > testing and packaging on Mac. Check out the MacOS download section[4] on > the web for applications DMGâs. > > We have received valuable and stimulating input for the MacOS build from > Christopher Tignor, Volker Schumacher, Eduard Aylon and StÃ©phane Letz. > Thank you all for your help. > > Apart from MacOS build, this release features KDE integration for > NetworkEditor and Prototyper (so you can open network files from > Konqueror), MFCCâs added to Annotatorâs extractor example, and several > fixes (thanks James). > > FLTK module has been dropped and it is not being compiled by default. It > will be completely removed on the next release. Check out the changelog [5] > for more details. > > Next release will consist mainly on bugfixing towards 1.0, so please, tests > and report as many bugs as possible. > > [1] http://clam.iua.upf.edu > [2] http://mtg.upf.edu/ > [3] http://gti.upf.edu/ > [4] http://clam.iua.upf.edu/download-osx.html > [5] https://iua-share.upf.es/svn/clam/trunk/CLAM/CHANGES > > The CLAM crew. hi, I packaged clam-0.97 for SuSE. http://packman.links2linux.de/package/clam for the 0.98 I cann't find the sources ? the src-download site is outdated (0.96) second question: in this directory http://clam.iua.upf.edu/download/linux-ubuntu-feisty/ I can find a 0.98 tar.gz, but just to be sure: clam_0.98.0-1.tar.gz 281.30 Mb really 281MB ? What is in that tarball ? have fun oc2pus

18 years, 10 months

[linux-audio-dev] processing plugin standard wrapper

by Stefano D'Angelo

Hi all, who would be interested in writing a processing plugin standard wrapper (LADSPA, DSSI, LV2, VST, etc.)?

18 years, 10 months

[linux-audio-dev] [ANN] Mammut V0.57

by Kjetil S. Matheussen

Homepage: http://www.notam02.no/arkiv/doc/mammut/ Screenshot: http://www.notam02.no/arkiv/doc/mammut/mammut.png Changes 0.22 -> 0.57 --------------------- -Ported from gtk1 to juce. -Various bells and whistles -Binaries for windows and mac -Various other things

18 years, 10 months

[linux-audio-dev] CLAM 0.98 released

by David García Garzón

We are glad to announce CLAM 0.98 a.k.a. ‘Mac is here to stay’. CLAM[1] is a free-software, C++ framework for doing research and application development in audio and music. It also comes with a set of applications ready to use for non technical users. This is the first release not developed within the MTG [2] since its main developers now work at the GTI[3], also at the Universitat Pompeu Fabra. Still, CLAM is very indebted to the MTG people. Most of the work in this release was focused on having stable building, testing and packaging on Mac. Check out the MacOS download section[4] on the web for applications DMG’s. We have received valuable and stimulating input for the MacOS build from Christopher Tignor, Volker Schumacher, Eduard Aylon and Stéphane Letz. Thank you all for your help. Apart from MacOS build, this release features KDE integration for NetworkEditor and Prototyper (so you can open network files from Konqueror), MFCC’s added to Annotator’s extractor example, and several fixes (thanks James). FLTK module has been dropped and it is not being compiled by default. It will be completely removed on the next release. Check out the changelog [5] for more details. Next release will consist mainly on bugfixing towards 1.0, so please, tests and report as many bugs as possible. [1] http://clam.iua.upf.edu [2] http://mtg.upf.edu/ [3] http://gti.upf.edu/ [4] http://clam.iua.upf.edu/download-osx.html [5] https://iua-share.upf.es/svn/clam/trunk/CLAM/CHANGES The CLAM crew.

18 years, 10 months

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