Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7520 discussions

by Nathanael Anderson

I'm trying to find a good solution for realtime upsampling and eq effects. So far it seems running jamin with jack enabled programs, and passing them through jamin for processing will be the best program for adjusting eq levels, and setting crossovers. In this area, information on other programs I have missed is appricated. I would then like to be able to take the sound and upsample it to dts for 5.1 or 7.1 surround sound, and being able to set delays for each speaker to be able to tune the audio to the acoustics of the area. A perfect setup would be able to to full eq/crossover/delay settings for each speaker while doing live encodes, but any additional information on open source projects related to these areas are appricated. Thanks in advance, Nathanael Anderson

18 years

[ANN] Traverso 0.42.0

by Remon

Traverso 0.42.0 Release Announcement The Traverso development team is pleased to announce the release of Traverso 0.42.0 About Traverso: Traverso is a GPL licensed, cross platform program for recording and mixing music, speech, and sounds on the computer Important changes in this release: * Read and write support for Ogg Vorbis, WavPack, FLAC and MP3 * On the fly sample rate conversion * A simple yet effective Project backup and restore system * Better use of available hard disk bandwidth * Encoding formats for recording added: W64 and WavPack * 3 new themes added, notably the medium-contrast and ubuntu theme * Fixed a number of bugs, added new ones and various improvements all over the place * User Manual translated into German and Portuguese Source tarball and installers for Mac OS X and Windows are available on the download page [1] Distribution packages are being created, with some (openSUSE, Gentoo) allready available for installation. We welcome any feedback in the forums [2], user mailing list [3] or internet relay chat, channel #traverso Enjoy! The Traverso team. [1] http://traverso-daw.org/ [2] http://traverso-daw.org/forum/ [3] http://savannah.nongnu.org/mail/?group=traverso

18 years

Rubber Band v1.0 - an audio time-stretching and pitch-shifting library and utility

by Chris Cannam

Rubber Band is an audio time-stretching and pitch-shifting library and utility designed for musical applications. http://www.breakfastquay.com/rubberband/ It includes a library that supports a sample-accurate multithreaded offline mode and a real-time lock-free streaming mode; a command-line utility program; and a LADSPA pitch-shifter plugin. Rubber Band is Free Software under the GNU GPL. Chris

18 years

Rubber Band v1.0.1 - an audio time-stretching and pitch-shifting library and utility

by Chris Cannam

18 years

[ANN] dssi-vst 0.5

by Chris Cannam

dssi-vst 0.5 released! ====================== The 0.5 release of dssi-vst is now available. dssi-vst is a DSSI plugin wrapper for Win32 VST effects and instruments with GUI support, allowing them to be loaded into any DSSI host. dssi-vst is available from the download page at http://dssi.sourceforge.net/ The 0.5 release now comes with Javier Serrano Polo's VST-compatibility header, as previously distributed in LMMS. (Actually, this header was already compatible with dssi-vst -- no modifications to dssi-vst were necessary -- it's just that the header is now included in the package.) This permits it to be compiled without the official VST SDK and distributed under pure GPL. No guarantees are made as to the reliability of the results; your feedback is welcome, but please bear in mind that I will not do any development work on the compatibility header myself for legal reasons. The 0.5 release is also (finally) compatible with version 2.4r2 of the official SDK, should you wish to use it. Chris

18 years

Re: [LAD] "enhanced event port" LV2 extension proposal

by Krzysztof Foltman

Dave Robillard wrote: > Why not make it satisfy most everyone by being extensible? It *is* extensible. Note that commands 0x00-0x6F and 0x73-0x7F are unused, so further extensions are free to define them (perhaps we need a scheme for binding extension URIs to command numbers, to make it more LV2-ey). And 0x72 command can be used for pretty much any data larger than 8+2 octets. While it's "efficient first" and not "generic first", so to speak, it should be fine for the intended uses. > The idea of a generic event port is not a bad one, I think it's not just "not a bad one". The other possibility (multiple event ports) is less efficient, and speed is crucial here. It's also more complex, looking from plugin author's perspective. So I had little choice. > idea at all (no matter what, someone is going to want to put something > in there you didn't think of. Please don't jump to conclusions, and take more time to read and analyse the proposal. Of course, it is possible to add new event types with arbitrary length data, and the limitation of 8 octets per extended block is not that bad, because you can always fit an interface pointer (32-bit or 64-bit) there. Just look how binary data extension is implemented. Notice that I just took the approach of optimizing for most common case (MIDI events), and tried to maximize functionality while keeping block size small and constant (to avoid pointer arithmetic that was complicating Lars' proposal a bit). > Trying to pre-define things from the top down like this is un-lv2-ey). Well, sometimes you need to find the right tradeoff between being efficient (memory- and speed-wise) and generic. I think I've found an acceptable tradeoff (definitely favouring speed, but not losing generality and not very memory-hungry). However, I had to make some assumptions about how it will be used (mostly implemented by inexperienced people, mostly used for MIDI and float parameters, seldom used for advanced stuff). Oh well, I'm repeating myself here :) I think those are correct assumptions, but you seem to have a different angle for looking at those things. Well, it took me years (and failed/inadequate designs) to grow out of the "everything should be as generic as possible" approach, so I understand why you're doing that, but I still prefer the priority-based optimization approach that I've used. I still think my proposal could be improved, and I don't like some decisions that I made (basically, I made them because the alternatives looked even more nasty), but stripping off optimizations is not the way to go, IMO. > Something more appropriate (IMO) might be like: > struct LV2_EVENT > { > ev_stamp_t time; ///< (ignoring the timestamp type issue) > ev_type_t type; ///< (again ignoring type issue) > size_t buf_size; ///< size of buf in bytes > char* buf; ///< raw event data > } You're suggesting a "classic" textbook chunked data approach, which works, no doubt. However, it has some problems with it, which might not be considered very major, but seem to make my approach slightly more favourable: - too much data to be accessed in the most common use case (in 32-bit environment, 16 bytes of header plus event data possibly in distant memory); we don't need to save every byte of RAM, but when you need to read and write twice as much RAM as you could, then maybe it's worth rethinking it - separation of event header and event data in the most common case; it would be better not to cause cache thrashing too much - it encourages memory fragmentation (experienced people will allocate event data for all events in the same buffer, wonder about inexperienced ones, one malloc per event data? :) ) - it doesn't deal with large data properly (because the plugin cannot start "owning" the raw event data instead of copying it from the buffer provided); imagine copying a video buffer in the process() function of a plugin! I'm not saying that approach is Really Bad - just that it's kind of a pre-optimization version of my proposal (I made MIDI data very efficient, float parameter data slightly less efficient, float parameter data with deltas even less efficient, and binary data are pretty inefficient :) ). The fact that event has to be handled is annoying enough on its own :) - I have to end the inner loop, store state information somewhere etc. - I don't want some additional, unnecessary memory accesses which may throw sample data and buffers out of the cache. > (Obviously just a quick generic knock-off to get the idea across). In > networkey terms, this is separating transport from contents, which is > pretty firmly established as a Good Idea. In network context, yes. However, _optimizing_ for uncommon case is not a preferable approach to me. The arbitrary binary data command (0x72) mentioned in my proposal can give you practically everything you need, and can be used in a network-transparent way, as long as data in the "binary data" chunks are self-contained (don't refer to other buffers). However, my proposal lacks any mechanism to be used for serializing arguments of future commands defined by extensions. Still, that problem was solved many times in history, by deriving extra interfaces for the new commands from an interface that provides reference counting and marshalling. IPersistStream type stuff, for the victims of Microsoft APIs. It is a bit complex (or at least not as trivial as plain MIDI), but it would be only used in hosts and complex plugins that use extension events, so I guess it'd be fine. > I very strongly feel that if 'more than MIDI' events are going to be > mixed with MIDI events in the same port (s/MIDI/whatever), then the > event transport mechanism needs to be 100% event type agnostic. On the other hand, "100% generic" means "almost 100% unoptimized". By throwing away extra information, you often throw away the chances for optimization, so to speak. Instead of thinking in terms of MIDI vs non-MIDI, try thinking of "my" event types as "short" (8 octets), "medium" (16 octets) and "large" (arbitrary-sized blobs). The fact that all short events are MIDI events is, I think, less important. It's also not set in stone. > It's the same approach LV2 takes with ports, and it works beautifully there. On the other hand, it deals with a trivial problem, and solves it in a complex way. That's not an engineer's dream :) Regards, Krzysztof

18 years

How to save and restore MIDI connexion (ALSA sequencer)

by Stéphane Brunner

Hello ! In my application (LiveMix - http://livemix.codingteam.net/) I just implement the MIDI support. To initialize the MIDI I do : snd_seq_open(&seq, "default", SND_SEQ_OPEN_DUPLEX, 0); snd_seq_set_client_name(seq, "LiveMix"); m_iPort = snd_seq_create_simple_port(seq, "control", 0, SND_SEQ_PORT_TYPE_MIDI_GENERIC | SND_SEQ_PORT_TYPE_SOFTWARE | SND_SEQ_PORT_TYPE_APPLICATION); m_iMidi = snd_seq_create_simple_port(seq, "control", SND_SEQ_PORT_CAP_READ | SND_SEQ_PORT_CAP_SUBS_READ | SND_SEQ_PORT_CAP_WRITE | SND_SEQ_PORT_CAP_SUBS_WRITE, SND_SEQ_PORT_TYPE_APPLICATION); Than with patchage I connect the midi port to others port... Than I want to know with port will be connected on witch other to reconnect it on other LiveMix run. I sea the function : int snd_seq_connect_from(snd_seq_t *seq, int my_port, int src_client, int src_port); int snd_seq_connect_to(snd_seq_t *seq, int my_port, int dest_client, int dest_port); To do the connexion but I don't found not the function to know where I'm actually connected. CU & thanks in advance. Stéphane -- Stéphane Brunner mail : stephane.brunner(a)gmail.com messageries instantanées : stephane.brunner(a)gmail.com ( http://talk.google.com) -------------------------------------- http://www.ubuntu-fr.org - Distribution Linux http://fr.wikipedia.org - Encyclopédie communautaire http://mozilla-europe.org - Navigateur internet / Client de messagerie http://framasoft.net - Annuaire de logiciel libre (gratuit) http://jeuxlibres.net - Jeux Libres (gratuit) -------------------------------------- Il existe 10 sortes de personnes : celles qui connaissent le binaire, et les autres. Si Microsoft inventait un truc qui plante pas, ce serait un clou. Si un jour on te reproche que ton travail n'est pas un travail de professionnel, dis toi que : Des amateurs ont construit l'arche de Noé, et des professionnels le Titanic.

18 years

miidi

by Giannis Gravezas

midi application for midi control and note playing with a twist ( of the wiimote ) here it is. <http://miidi.sourceforge.net> Yannis Gravezas, Athens, Greece

18 years

Re: [LAD] "enhanced event port" LV2 extension proposal

by Jeff McClintock

>> All of MIDI can be reduced to two messages: set-control (addressed by >> Channel, Voice and Controller ID) .. and SYSEX - for data-dumps. >What you say is of course a true statement, but it is ignoring what the >founding fathers of MIDI attempted to accomplish regarding efficiency on >a bandwith limited connection and the likelyhood of certain messages >appearing more often than others ,,, Hi Jens, Very true. MIDI was an excellent solution at the time and made good use of limited bandwidth. But I think as MIDI got extended it got too complicated, and now with software music systems we don't have such limited bandwith anymore. The 8-bit messages are looking dated as far as simplicity and especially resolution goes. The MMA are addressing the resolution aspect with "High definition MIDI", but it's implemented as SYSEX messages and therefore just adds more complexity to writing a comprehensive MIDI implementation. I hope in future we'll have a simplified system...instead of CCs and RPNs and NRPNs and SYSEX Controllers, have a single unified controller with a 32-bit Controller-Number range. Map all the existing MIDI messages into that range. NEW-MIDI would have only one message type, it would look like.. [Timestamp][Channel][Voice Number][Controller-Number][Value] Anyway, I got way off-topic. My intention was to say that LV2 may not need a per-note control extension because MIDI already has it via "Key Based Instrument Controllers", which is a SYSEX message for sending a CC to one specific note-number. Best Regards, Jeff

18 years

Re: [LAD] "enhanced event port" LV2 extension proposal

by Jeff McClintock

> However, it (MIDI) also has its own age. And limitations. In particular, the > amount of per-note control is pitiful. > .... In the meantime, maybe the MIDI guys will decide for us :D They did, "Key Based Instrument Controllers" provide for per-note controllers. Granted MIDI remains stupid. MIDI is 15 different ways of saying "set this control". All of MIDI can be reduced to two messages: set-control (addressed by Channel, Voice and Controller ID) .. and SYSEX - for data-dumps. Jeff McClintock Message: 13 Date: Fri, 30 Nov 2007 00:30:58 +0000 From: Krzysztof Foltman <wdev(a)foltman.com> Subject: Re: [LAD] "enhanced event port" LV2 extension proposal To: Dave Robillard <drobilla(a)connect.carleton.ca>, LAD <linux-audio-dev(a)lists.linuxaudio.org> Message-ID: <474F59C2.1050805(a)foltman.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Dave Robillard wrote: > I /really/ don't like screwing around with MIDI. Just make the events > pure, raw MIDI. Jack MIDI events are 'just n bytes of MIDI', Alsa has > functions to get at 'just n bytes of MIDI', and... well, it's just MIDI. > However, it also has its own age. And limitations. In particular, the amount of per-note control is pitiful. I can always use hacks to get around the limitations, or introduce a per-note control via separate "set note parameter" event type. But hacks are ... hacky, and the extended extension of extension for every single feature is a bit inelegant too. Anyway - so far, I have no code that would make use of this, so we might keep it as plain MIDI. And then we have next 5 years to decide the details of the feature. In the meantime, maybe the MIDI guys will decide for us :D Krzysztof

18 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