Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7448 discussions

by hermann

Hello I’m happy to announce a update release of gxtuner, a simple, small and lightweight guitar/bass tuner for jack. It's a break out of the guitarix tuner module, gxtuner-1.5 changes: * added reference pitch controller * added threshold controller * added command-line option (-i) to connect at start up gxtuner comes with a analogue like, full arbitrary scaling interface (scale), show the tune, the octave and the accumulated frequency in Hz, and it comes with full jack-session support. gxtuner use a equal-tempered scale based on A4 = 440 Hz (427Hz <-> 453Hz) gxtuner is licensed under the GPL. for more information please read the included README file. get it here: http://sourceforge.net/projects/guitarix/files/gxtuner/ direct link http://sourceforge.net/projects/guitarix/files/gxtuner/gxtuner-1.5.tar.bz2/… have fun Guitarix developers

12 years, 10 months

opinions wanted on a couple of architecture questions

by Iain Duncan

As I slowly figure out audio architecture, I've gotten to here: main() - sets up jack, instantiates and Engine class and a Controller class Engine - the engine is passed to the jack audio callback, and has a .tick() to calculate audio - engine will receive messages over ToEngineQueue ( with a ringbuffer ) - engine will send messages back to controller over a second queue, ToControllerQueue Controller - started in main thread - will handle all input and output and instantiate any guis - sends messages to engine over queue - receives messages from engine over the ToControllerQueue Message - struct for passing messages, holds simple numbers, keeping individual messages of known size for now I've seen a few ways now in tutorials of handling some things and would love opinions. - Should the ToEnqineQueue be a part of Engine? ie, do we pass messages to engine with engine->newMessage( msg ); - or should the queue's be instantiated in main and should Engine and Controller each get pointers to the queues? - I think the stk examples do the former and SuperCollider the second - is it a bad idea to have both engine and controller need pointers to each other? - is this an example of an undesired circular dependency? - is avoiding that by having them each only depend on Queue and Message a good plan? - or should I avoid it by using an ABC for MessageReceivingComponent and allow them each to have pointers of type MessageReceivingComponent? - how should one handle memory management of the messages? Is it ok for Engine to allocate memory for new messages and have them destroyed on receipt, - or should I have queue delete the memory and return by value when messages are fetched? - what is the crustimony proceedcake for allocated memory from an engine? thanks to anyone who feels like they have the time to answer these! iain

12 years, 10 months

Re: [LAD] "bleeding edge html5" has interesting Audio APIs

by Neil C Smith

David, With the greatest respect to you, and I have a lot of sympathy with your ideas of GUI's using browser / JS technology, your comments on Java are bordering on FUD. I also don't understand the general anti-Java diatribe - it's a library, and it has its uses - why treat it as somehow different to any other library. It's still the best performing VM out there. Once JavaScript allows me to write a single JIT'ed executable that runs cross-platform; links to JACK on Linux, Windows and Mac; allows sub-5ms latency; and lets me drop live-coded fragments into the audio graph - then it gets interesting, but until then JS is still playing catchup! :-) On 21 November 2011 01:15, David Robillard <d(a)drobilla.net> wrote: > * Most Windows computers do not have Java. Source??? Last stats I saw showed Java installs not far behind Flash. And if you take the "link your own VM" option (which is similar to the suggestion re. webkit) it's irrelevant anyway. > * Java is officially deprecated on Mac OS X. hmm .. Java on Mac is actually looking rosier than it has in a long time, now that development is taking place officially as part of OpenJDK. > * Java will never, ever be available by default on any Microsoft > platform That depends - lots of manufacturers install it by default. > * Java is not included in the default installation of the overwhelming > majority of free software operating systems Good! Too many distros install far too much by default. It's a library, it's a dependency, and it's there if it's needed. > * Java requires software installation of some variety (unless you're > seriously going to suggest using Java applets in 2011 with a straight > face...) Applets? God, no! :-) I've no problem with installation though. As I said before, I don't necessarily see web-apps as the ultimate way forward - I personally think the app-store model will hold out because a) app-stores allow certain companies to keep their walled gardens, and b) writing for the browser is always going to be writing to the lowest common denominator. > * Java recently has acquired a lot of legal questions making it not > exactly the wisest investment for new technology. Nothing that affects OpenJDK though. > * There are many cutting edge modern browser implementations, and > activity here is moving at an astonishing pace. Java is a dinosaur. > A dinosaur that the others are still trying to catch up with, mind you! > Regardless, if I may take the liberty of speaking for this community, > making people use Java for something is a sure-fire way of ensuring they > don't use it. And I'll take the liberty of saying I think that's a daft attitude to have! :-) If the application performs a function I need, then I'll consider using it, regardless of what technology underlies it. Best wishes, Neil -- Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net

12 years, 10 months

Re: [LAD] FFADO midi ports

by thijs van severen

Thanks guys! I actually tried j2a but now i realise that i forgot the -e option to expose the hw ports. Doh! I'll give it another try tonight. Thanks! Grtz Thijs On 9 Dec 2011 00:12, "Harry van Haaren" <harryhaaren(a)gmail.com> wrote: Hello Thijs, I think you might be under the impression that FFADO MIDI and ALSA MIDI are roughly the same, they're not... FFADO is a backend that you can run JACK on top of. If you run JACK with the FFADO as the "driver", then JACK will be able to send MIDI commands to your Saffire. ALSA MIDI is a totally different "MIDI". The upside: There's a program "a2jmidi" which will put all your ALSA MIDI ports into the JACK MIDI graph, then you can connect any ALSA MIDI out to JACK MIDI in, and vice versa. "a2jmidid" is the name of the package on debian based systems. Running is usually most benificial like so: a2jmidid -e & so that it keeps scanning the ALSA MIDI graph for changes, and will update the JACK MIDI ports available. Good luck! -Harry On Thu, Dec 8, 2011 at 9:57 PM, thijs van severen <thijsvanseveren(a)gmail.com> wrote: > > > > Hi all > > > > i'm trying to use 'amidi' to send a simple midi message to the midi out > port of my fi... > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > >

12 years, 10 months

FFADO midi ports

by thijs van severen

Hi all i'm trying to use 'amidi' to send a simple midi message to the midi out port of my firewire (FFADO backend) audio device. a Saffire LE. to do this i simply need to specify the port i want to send the data to, however i can only select one of the ALSA midi devices listed under /dev/snd/ and the firewire midi ports are all Jack midi ports and thus not listed here. but where are these listed ? or should i be doing things differently ? grtz Thijs -- follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

12 years, 10 months

New stuff: zita-dpl

by Fons Adriaensen

Hello all, First release of zita-dpl1. Look-ahead digital peak limiter. 1-16 channels (highest one determines gain reduction). More at <http://kokkinizita.linuxaudio.org/linuxaudio>. Enjoy ! -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

12 years, 10 months

AMS LV2 0.0.4

by Aurélien Leblond

> And ... > > Checking for 'g++' (c++ compiler) : /usr/bin/g++ > Checking for program pkg-config : /usr/bin/pkg-config > Checking for 'lv2-plugin' >= 1.0.4 : yes > Checking for 'lv2-gui' >= 1.0.4 : not found > The packages are installed and come from one package so if it finds one, it > should also find the other! Hmmm, that's a weird one! My only explanation is that you have the file /usr/lib/pkgconfig/lv2-plugin.pc but not /usr/lib/pkgconfig/lv2-gui.pc... Could you check on your system? Btw, what distribution do you use? >From my side, I'm not even sure I need to check for both libraries in my wscript... As you said, they come from the same lv2-c++-tools package. Thanks for the feedback anyway :) Aurélien

12 years, 10 months

Ardour3 - strange problem

by Fons Adriaensen

Hello all, Trying out Ardour3 but I'm blocked... I deep-copied an existing A2 session, paradiso-2, to /audio/ardour3-sessions. But A3 complains that it can't find the audio files in /audio/ardour3-sessions/paradiso-2/interchange/paradiso-2/audiofiles which is the right place, and the files are there. ??? -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

12 years, 10 months

NASPRO 0.3.0 released

by Stefano D'Angelo

Hi all, I'm glad to announce the release of NASPRO 0.3.0. NASPRO (http://naspro.atheme.org/) is meant to be a cross-platform sound processing software architecture built around the LV2 plugin standard (http://lv2plug.in/). The goal of the project is to develop a series of tools to make it easy and convenient to use LV2 for sound processing on any (relevant) platform and for everybody: end users, host developers, plugin developers, distributors and scientists/researchers. This release introduces a new simple command line effect processor using LV2 plugins called LV2proc, adds experimental translation of DSSI programs to LV2 presets, breaks the API of lower level libraries to make them slimmer and more efficient, and includes as usual bugfixing and improvements here and there. You can find detailed ChangeLogs in the tarballs. It includes: NASPRO core: the portable runtime library at the bottom of the architecture; NASPRO Bridge it: a little helper library to develop insert-your-API-here to LV2 bridges; NASPRO bridges: a collection of bridges to LV2 which, once installed, allow you to use plugins developed for other plugin standards in LV2 hosts; LV2proc: a simple command line effect processor using LV2 plugins. In particular, the NASPRO bridges collection includes two bridges: a LADSPA (http://www.ladspa.org/) 1.1 and a DSSI (http://dssi.sourceforge.net/) 1.0.0/1.1.0 bridge. NASPRO core, NASPRO Bridge it and NASPRO bridges are released under the LGPL 2.1, while LV2proc is released under the GPL 3. Enjoy!

12 years, 10 months

AMS LV2 0.0.4

by Aurélien Leblond

Hello everyone, I just posted a new version of the AMS LV2 plugins: https://sourceforge.net/projects/avwlv2/files/latest/download The main change from the version 0.0.3 is a embeded GUI for the VCO. As a reminder, these LV2 plugins are a porting of the AMS internal modules designed to be used in a modular synths (especially Ingen). At the moment, the Analog Driver, normal and Advanced Envelop, Amp, LFO, Mixer, Noise2, Slew Limiter, VCA (Exponential and Linear), VCF and VCO2 have been ported. This should be enough to be able to create basic patches, and two presets for Ingen are available in the package. Testers, comments, feedback....everything is more than welcome! For the ones who wants to create LV2 plugins, the code is written in C++, using Lv2-C++-Tools and GTKMM (the GUI designed with Glade). The code is quite simple, making them examples on how to mix all these things together and be able to design LV2 plugins quickly... Aurélien

12 years, 10 months

Jump to page:

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