Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

1 participants
7445 discussions

aqualung player request: multichannel playback

by Jörn Nettingsmeier

hi aqualung people! your player has been discussed as an interesting way to pave the path of ambisonics towards world dominance, because it's cross-platform, hooks up to jack and allows for easy integration of ladspa plugins (where we could slip in an ambi decoder to make an easy-to-use ambi player for the rest of us). problem is: it won't load files with more than 2 channels. initially, we'd need four channels for first-order b-format, and later 9 and 16 channels could be interesting. the dolby crowd might appreciate six. how difficult would it be to implement the following?: * make the number of jack output ports N configurable (because obviously jack ports can't show up and go away while the program and any playlist runs, because that makes for messy routing) * output the channels of each soundfile in the playlist to those N channels, padding with silence or omitting channels as needed. this would make a spiffy .amb file player and instantly increase your user base by at least 20 :-D corner cases such as automatic resampling will not be important, at least initially. if desired, different formats could be dealt with based on number of channels and/or additional metadata and file format guesses, and played out to different sets of jack ports for appropriate handling. like so: configure 2 ports for stereo: aqualung:stereo.[L|R] configure 4 ports for ambisonics: aqualung:ambi.[W|X|Y|Z] configure 6 ports for dolby 5.1: aqualung:5-1.[L|C|R|LS|RS|LFE] in this simple case, aqualung could guess the correct routing based on channel number alone. later, it would be cool to be able to configure rule sets for routing rather than hardcoding them, such as: suffix .amb > route to ambi no of channels 4 > route to ambi WAVEX flag enterprise > route to holodeck (you get the idea)... wdyt? btw, please remove the cc: to sursound, since it's a moderated list - i will summarize your replies accordingly. best, jörn

14 years, 8 months

Time & How to approach it

by harryhaaren＠gmail.com

Hey all, I've been dev-ing MIDI/audio programs in C++ & Python for a while, but I'm struggling with one concept: How to approach time. If i want to "schedule" events for the future, what is the "correct" way to do this? I've read some docs about Jack's timebase & transport system, ideally I want to support that, but I dont seem to grasp the "whole". I could write a class that has a "MIDI clip" inside it, and then play back multiple of these clips from thier classes. Or should I approach more along the lines of each MIDI clip being inside a std::vector<MidiClip>? How does eg: Seq24, Ardour, RoseGarden etc approach the time management? I've attempted to read docs/sources, but the projects are too big for me to understand how the "time-system" works. Hope somebody could shed some light on this, -Harry PS: If there's a tutorial or simple example I could read, please say, I've googled but not found any tutorial on the subject.

14 years, 8 months

Re: [LAD] Time & How to approach it

by Mark Vitek

In writing arpage, I find that qtractor and seq24 provide good BBT data. Ardour was ok, but Hydrogen didn't do so well. -- sent from mobile On Jan 22, 2010 1:40 PM, "Olivier Guilyardi" <list(a)samalyse.com> wrote: On 01/21/2010 03:28 PM, torbenh wrote: > On Thu, Jan 21, 2010 at 07:48:20AM -0500, Paul Coccoli wrot... I think that Harry's question was more about time as he rephrased it in his 2nd post, than about event queuing, although this is of course linked. But in regard to time, what about Beat-Bar-Tick which seems to be important to him? How many applications support (set or handle) the Beat-Bar-Tick related jack transport position fields? In general, how reliable are these fields? -- Olivier _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists...

14 years, 8 months

RDF MIDI vocabulary

by Dave Robillard

Anyone know of an existing RDF vocabulary for MIDI (to describe the various controllers, event types, etc.)? Thanks, -dr

14 years, 8 months

Search: Free, Crossplatform Soundlib for a game

by Nils Hammerfest

Hi, I search for a free and open source sound/music lib to integrate sound and music in a game. The game runs on Lin/Win32/OSX so it has to be crossplatform. I know openAL, but this is too big and tons of people have problems with it. Anything slimmer around? Nils

14 years, 8 months

Re: [LAD] Hydrogen and jackmidi

by Christopher Cherrett

-------- Original Message -------- Subject: Re: [LAD] Hydrogen and jackmidi From: m.wolkstein(a)gmx.de <m.wolkstein(a)gmx.de> To: Christopher Cherrett <ccherrett(a)openoctave.org> Date: 01/17/10 07:01 > Am Sun, 17 Jan 2010 05:30:38 -0700 > schrieb Christopher Cherrett <ccherrett(a)openoctave.org>: > > >>> hi all, >>> i am one of two/three active hydrogen developers. >>> if you want new features or support for newer and of course great linux-audio >>> technologies. so IMO, please create WORKING patches and submit them to our >>> dev-mailing-list. than we can check them in. >>> >>> >> Are you saying you are not interested in seeing jack-midi make it into >> hydrogen with your help? >> >> > no, i am interested on all. also on jack midi. > please don't misunderstand me. in moment jack midi is not my personal priority. what not mean that jack midi is bad ore what ever. > i have a normal job, children and as most people, few spare time. > after 2 years developing on h2 and create a lot of code i found out that many people in the whole world have good ideas and are very interested on everything. > e.g.to write functions or make new technologies working. but after 2-3 weeks mostly they lost their intention and leave a unfinished working place. mostly break up other function and > all is unusable. this is why i say -make working patches-. i personally like talking about something. but i like it more, if people make tings working what they talk about. > > in an open source community we need constructive work. and not destructive discussions > about thinks which are not possible if nobody work on them. > > :) > greetings wolke > >> Is it only developers that get a say by coding something? >> >> I code for open source and for a living, I see great value in the needs >> of the users. It is the only thing that allows an application to grow to >> a professional level. >> >> IMO >> >> I find it very valuable to find out who users are and what they are doing with the app. I ignore certain users. After all, who likes to waste time on things that do not get used. So I understand. Speaking of jack-midi. It is the oly thing that keeps my setup running. When using alsa midi the slows down and speeds up very bad. I find the timing in jack midi to be far superior for professional work. When I run jack midi it would be synced with jack transport running alongside of 900+ midi and audio connections. things get nasty with alsa midi :) -- Christopher Cherrett ccherrett(a)openoctave.org http://www.openoctave.org

14 years, 8 months

Hydrogen and jackmidi

by alex stone

A quick question. Is Hydrogen now a jackmidi app? I've been searching the interlink, and did see some discussion about it, and i wondered if this was an impending reality, or a false dawn. I've downloaded the latest stable but no jackmidi present as yet. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

14 years, 8 months

[ANN] Qtractor 0.4.4 - The Frisky Demivierge's in the wild!

by Rui Nuno Capela

What? No automation, yet? Yes I failed the promise once again. So what? What would you expect from this self-called über-procrastinator? As sure is one to say that this is the Year of Linux Desktop (YOLD:), I'll give you the shivers and command this one will be the year of Qtractor Automation. No kiddin' ;) Meanwhile, this new dot-release brings you several niceties, a couple of them have been waaay longer and dustier on the all-mighty-overdue TODO list than automation is. Rejoice! or else... Qtractor 0.4.4 (frisky demivierge) is in the wild! Release highlights: * LV2 plug-in support (NEW) * MIDI event list view (NEW) * Expedite audio/MIDI clip import (NEW) * DSSI plug-in output control ports feedback/update (NEW) * JACK transport, MMC, SPP control options (NEW) * Self-bounce/recording (FIX) * Audio/MIDI drift correction (FIX) * Anti-glitch audio micro-fade-in/out ramp smoothing (FIX) Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.4.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.sr… - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.4.4-2.rncbc.suse112.x8… - binary packages (Ubuntu 8.04 LTS; no LV2 support): http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_… http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu804_… - binary packages (Ubuntu 9.10): http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_… http://downloads.sourceforge.net/qtractor/qtractor_0.4.4-1.rncbc.ubuntu910_… - user manual (ever still outdated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - For all the DSSI plugins that have output control ports, a host feedback/update process cycle is now being finally provided: all output control ports are now marshaled to their respective GUI process, rather often and when found open/visible. - MIDI clip editor (aka piano-roll) snap-to-beat behavior on edit mode is now kind of more like 'filling-in-the-blanks' (as Frank Neumann et al. wishes ;) - Fixed MIDI clip editor mistake when reverting to initial clip length, before closing and discard changes (thanks to Frank Neumann, for spotting this one). - LADISH Level 1 support has been added: SIGUSR1 signal trap just makes it a shortcut to File/Save. - Avoid parameter value flickering, due to duplicate command invocation, most evident when changing values massively on native Linux VSTi plugin editor GUIs (thanks to a detailed report on this odd behavior, from Mike of linuxDSP.co.uk). - Another TODO item bites the dust: MIDI event list editor, now accessible from the MIDI clip editor menu (View/Events) - Last used session directory is now made current on startup only when no filename is given on the command line (solving bug #2920244). - Current snap-to-beat setting (time quantization) now affects the anchor event only, while dragging, moving and/or pasting multiple events over the MIDI clip editor (aka piano-roll). - Make anti-glitch audio clip micro fade-in/outs independent from current buffer size as much as possible. - Audio/MIDI engine drift correction gets really sophisticated, with the help of (now old) ALSA MIDI tempo skew facility. - Edit/Clip/Import... menu option is now available for expedite clip insertion from audio and MIDI file requesters. - Set default session directory effective to file's location. - Audio track/clip recording process has been target to special re-factorization across the internal audio engine process cycle, in a late attempt to get self-bounce/recording effective and working consistently for all track layouts. - All session related dialogs are now set to window modality, (were set to default application modality before) allowing for continued input focus and interaction on all plugin/tool windows. - An off-by-one nasty old bug fixed in audio clip drawing, was causing instant crashes on certain zoom levels of the main track view. - Graphical MIDI clip representation regarding note/pitch range is now kept as much as possible across clip edits (cut, copy, paste, drag, move, delete, etc.) - LV2 plug-in hosting has finally come into actual implementation; only some and the most basic LV2 plug-in features are supported at the moment; probably there's no big advantage against the old LADSPA ones; there's some support for external UIs though; also, LV2 MIDI/Event bare-bones support is included but chances are it won't build nor work right on most of the setups out there. It's a WIP host implementation anyways, as is the whole LV2 spec. for that matter ;) - Connections filter is now reset when widget is shown through the View/Connections main menu or toolbar button. - Audio bus auto-connection option is now applied when creating or updating, newer or existing buses, respectively. - Global configuration state is now explicitly saved/committed to disk whenever View/Options... dialog changes are applied or when a session is loaded or saved. - Audio ramping spin-locking makes its smooth stuff, in an attempt to reduce glitching and crackling when editing (due to its own pseudo spin-locking) and toggling playback states. - JACK Transport, MMC Device, and MIDI Song Position pointer (SPP) control modes are now made optional (View/Options...), allowing for discretionary configuration: None/Disabled, Slave/Input, Master/Output or Full/Duplex (default). - Session files may now be dragged and dropped over the main track view and get loaded for business as usual (once quietly ignored). - In an attempt to mitigate potential stack corruption and sudden crashes, old commented out session pseudo-locks are now back in business while executing clip editing commands (cut, paste, drag, move, insert, delete) and playback is currently rolling. - Adjusted first-time application window size to fit into 800x600 screen size and with reasonable initial dock-ables layout. - Avoid duplicate snap-to-grid effect when changing the length of MIDI clip editor events across non-zero clip offsets (after a glitch reported by Ralf Mardorf). - Late audio track processing optimization, suppressing all plugin, mixer and monitor pass-through activity when given track is muted, either explicitly or implicitly (ie. other track is in solo state). - Entering System Exclusive events (SysEx) on the MIDI clip editor (aka matrix/piano-roll widget), yet something not fully supported anyway, even though allowed in edit mode, doesn't crash the whole damn thing anymore, while saving the clip to a file. - Strict aliasing avoidance, with plain and demanded use of 'union', as much as to stop nagging warnings from gcc >= 4.4.1 (last seen on src/qtractorMidiEvent.h hackery). - Visual correct play-head position while changing zoom levels, applicable to both main track and MIDI clip editor views. Cheers && Enjoy. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

14 years, 8 months

Re: [LAD] Hydrogen and jackmidi

by Maitland Vaughan-Turner

dave phillips sez: > alex stone sez: > >This really surprises me. I would have thought you'd be inundated with > >jackmidi requests. > > > >Another assumption on my part bites the dust....... > > > > Add my droplet to the inundation. > > Vote++. > > Best, > > dp I'd like in on this torrent of votes, as well! hydrogen jack-midi will be SO GREAT!! I love hydrogen's interface; it is both intuitive and unique! It will be very useful for controlling external hardware as well as other software applications!! thanks!! ~Maitland

14 years, 8 months

[OT] Has anyone managed to compile this?

by Victor Lazzarini

Dear all, Torben's new project brought back to my mind this mind-bending C++ template example (see attached), which I could not yet get to compile, I have been told it has been compiled, but g++ will have none of it. So I still have doubts on whether it includes legal C++ code or not. But it is an interesting example (even if it does not build) of what (possibly) can be done with templates. My question to the list is: has anyone managed to compile this code? Regards Victor

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