Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

by Mike Cookson

Hello. I have installed jackdbus to have working ladish. If I start jackdbus (by "jack_control start" or ladish), legacy jack applications works. But if starting call produced by libjack applications, dbus apps don't see server. If server already started, it should be right for dbus to check first, wether server already runing via libjack and connect to them instead to try start own server to no end. Otherwise (IMHO, should be even more simple), also possible for libjack client functions to work always through dbus. The source of problem is PulseAudio, which I hoped to work only with JACK. I am trying to solve problem with startup script, which kills jackd and starts jackdbus before pulse restarts.

15 years, 5 months

Reminder: upcoming L2Ork workshop at NYC Resistor as part of ICMC 2010

by Ivica Ico Bukvic

(apologies for cross-posting) Dear Colleagues and FOSS enthusiasts, A friendly reminder that we have a Linux Laptop Orchestra (L2Ork) workshop at the NYC Resistor scheduled for May 30th, 2010 as part of the ICMC2010 workshop sessions. Please note the change in time which is 10am-4pm (ET). For additional information and registration info, please consult the website at: http://icmc-workshop-l2ork.eventbrite.com/ I would greatly appreciate it if you would please disseminate this as far and as wide as possible. For more info on L2Ork and its software/hardware resources, please visit: http://l2ork.music.vt.edu Many thanks! 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, 5 months

precision resampling to correct clock differences - no luck with libsamplerate and zita-resampler...

by Jörn Nettingsmeier

hi *! i need to re-synchronize two recordings of the same event that for technical reasons had to be done with unsynchronized clocks. i'm assuming for the sake of sanity that both clocks were perfectly stable. my approach is this: in ardour, align some unique feature (a click in this case) at the very beginning of the recordings to within a few samples. set a mark1. then, identify another unique feature close to the end, set mark2 to its position in the reference clock file and mark3 in the file that needs to be resampled. read the frame positions or the markers from session.ardour. sample rate ratio is then (mark2 - mark1) / (mark3 - mark1). i compute a value of precisely 1.00020678091, and i'm now looking for a resampler that will do the right thing here. unfortunately, both zita-resampler and libsamplerate seem to represent the sample rate ratio internally as a fraction of two integers, which means that in my case, it will be rounded to 44100/44107. this is not acceptable for the usecase at hand, as the offset after 4 hours of recording would be too large. due to the massive amount of data to be processed, slicing the material into smaller chunks to reduce the error is not an option. is there a hard technical reason for the behaviour of the resamplers? would it make sense for this bear of very little brain to dig into the code and try to convince them to perform resampling at ratios with full double precision, or is such an undertaking bound to fail? thanks, jörn

15 years, 5 months

Is there any hope for ReZound?

by Louigi Verona

Hey guys! ReZound to me seems like one of the best sound editors on Linux. Yet, it appears to have been forgotten. Any hope its development and maintenance will be resumed? Louigi.

15 years, 5 months

[ANN] Qtractor 0.4.6 - The Funky Deviless is here!

by Rui Nuno Capela

So much to tell, even more to do... then one could hardly shake, this long overdue. Lousy rhymes and no miserly times. And there it is: a bug-fix release, I'll mean to ease. Oh crap! Let's get it through once and for all. With huge compliments to all who got the nerve and report as many too much idiosyncrasies (nee bugs). Don't, never look back. There's plenty more ahead, no matter where you look, or hear, whether is up or down hill :) Qtractor 0.4.6 (funky deviless) is here! Release highlights: - MIDI Editor draw mode (aka paint mode) (NEW) - MIDI Swing-quantize (NEW) - LV2 UI Instance & Data-access extension support (NEW) - JACK Session support (EXPERIMENTAL) (NEW) - LV2 Save/Restore extension support (NEW) - MIDI Editor event list in-line editing (NEW) - MIDI Clip time-stretching (FIX) - MIDI Clip editor file salvage quietness (NEW) - MIDI Control bus switching crash (FIX) - MIDI Bank-selection backout (FIX) - Initial widget geometry extents (FIX) - Input-only bus playback crash (FIX) - Bus connection persistence crash (FIX) - Drag-and-drop cloning plugins (FIX) - MIDI Editor floating-selection persistence (NEW) - Audio inserts garbage signal (FIX) A bit more or not so detailed change-log is found below. Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.6.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.sr… - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.4.6-4.rncbc.suse112.x8… - binary packages (Ubuntu 10.04): http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004… http://downloads.sourceforge.net/qtractor/qtractor_0.4.6-4.rncbc.ubuntu1004… - user manual (outrageously outdated): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License (no kiddin'): Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - Introducing a non-painting edit sub-mode on the MIDI clip editor's piano-roll (see Edit/Select Mode/Edit Draw menu). - The MIDI clip editor (aka piano-roll) is now a lot more quiet about saving its own dirty content, delegating all salvage questions to main session control. - Don't show session restart message box when changing JACK transport mode option anymore. - Dedicated MIDI control bus switching fixed. Was closing the wrong bus eventually and crashing the whole show with it (fixes bug #2989590). - MIDI bank/program backout has been corrected on MIDI track properties dialog rejection (ie. user cancellation). - MIDI bank select method has been corrected for tracks with no instrument defined (probably fixing bug #2987071). - LV2 UI Instance and Data Access extension support added; reduce LV2 external UI parameter value update flickering. - JACK session infrastructure support. (EXPERIMENTAL) - Initial widget geometry and visibility persistence logic has been slightly revised as much to avoid crash failures due to wrong main widget hidden state. - Initial mixer widget extents are now set reasonably larger. - General source tree layout and build configuration change. - Ever since smooth-ramping introduction that having at least one input-only buses were causing immediate playback crashes, now hopefully fixed. - Refactored for common engine client nomenclature, primarily provided by JACK, then secondarily passed to ALSA Sequencer, getting rid of the JackUseExactName requirement and lifting the unique/single instance restriction in the process. - Current JACK Transport, MMC Device, and MIDI Song Position pointer (SPP) control modes are now saved/loaded as part of session option properties. - MIDI clip editor's context menu crash on Qt >= 4.6 has been fixed (resolving bug #2972603). - An ancient double-free corruption has been finally fixed at the audio/MIDI bus connection persistence logic. - Improved visibility of track state buttons text (R, M, S) when turned on dark colored themes. - LV2 Save/Restore extension support kicks off. - MIDI engine read-ahead period has been shortened to half than it was since inception--now it's a 500msec cycle. - MIDI clip editor event list gets its due inline editing, for time, note, value/velocity and duration columns, just one double-click away over the target cell ;) - Add-plugin selection dialog position and extent are now remembered across invocations and application sessions (tipping by Frank Neumann). - MIDI clip time-stretching is now made available through the same gestures as audio ones, by just shift+dragging either of the clip edges. - Drag-and-copying plug-in instances (cloning) is now fixed with regard to parameter value replication. - MIDI clip editor snap-per-beat setting is now independent from main multi-track view; File/Save As... dialog fixed; the current event selection is now kept floating as long as it's possible after editing command actions; finally, edit mode has been extended to free-hand event drawing, chalking off (piano roll) draw mode from the TODO list. - Swing-quantize has finally made its overdue debut as an additional MIDI clip editor tool (see Tools/Quantize...). - Almost since its inception, audio inserts were injecting garbage random noise when not being activated, now fixed. - Dedicated audio output ports for MIDI track plugins, now have their connection persistence back in business due on session load. Cheers && Enjoy (what else?) -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

15 years, 5 months

Re: [LAD] update: OT-ish: realtime 2d placement algorithms :-/

by James Morris

On Fri, May 21, 2010 11:30, James Morris wrote: > Just a quick update. I eventually settled on a 64bit 2D array, with each > 64bit element in the array representing 64 spaces in the grid merely for > tracking the state of space being used or unused. Turns out much faster > this way. There will still be a list of blocks (or windows if it was a > window manager) placed but this is an entirely separate issue. For example > in the test code I keep track of the coordinates (returned by the > algorithm) and dimensions of placed blocks in an array. > > code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2 not very portable: uses GCC builtins ctzl, and clzl, and probably other stuff not so portable. > > video/demo here: http://jwm-art.net/art/freespace_grid.ogv > > > > running 'make' in the src, builds a demo/test program which produces > similar output to the video - this is where the good old xterm wins - set > font to 'tiny' and maximize vertically and widen it to atleast 128 chars > and xterm displays fast enough it looks like an animation. > > > I'm hoping this will work well enough for real-time placement, though the > worst case scenario has changed from just being 255 windows placed, to > something like.... placing a 1x1 block in a non-empty grid full of (any > dimensioned window... it's difficult to work out the worst case here. > > james. > > > On Fri, April 30, 2010 23:10, James Morris wrote: >> Hello, >> >> I'm still trying to develop my boxy-sequencer idea. Basically, I've >> tried >> out a couple of algorithms for window-manager-like box placement within >> a >> grid and run into big problems. >> >> Because I need help/advice/ideas, I'm posting here as it has some >> relevance, and I've also posted to >> >> http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-a… >> >> A quick run down of what's happened so far, the two algorithms: >> >> The first I directly based on Fluxbox's Row Smart placement algorithm. >> Testing only the data structures, (and with gcc -O0) jack kicked out my >> client after around 200 boxes were placed in a 128x128 grid. I then >> counted how many times the algorithm looped through the entire list of >> boxes and discovered (not in RT for this) that the 256th box placement >> required around 14000 scans through the list of 255 previously placed >> boxes (i've decided 256 boxes will be the worst-case-scenario). >> >> The second algorithm consists of a freebox data structure which >> represents >> a rectangular area of free unused space. It also forms a node in a >> doubly >> linked list, as well as four directional links to other freeboxes >> touching >> it (with a maximum of one freebox touching each side of a freebox)... >> turns out rather complex to implement fully: 700+ loc for a partial >> implementation of row-smart left-to-right top-to-bottom placement - >> theres >> also col-smart, r-to-l, b-to-t and all combinations. >> >> Through stackoverflow, I've come across spatial hashing. >> >> I wondered if anyone here uses this technique for the display of data >> (would scrollable window views use such a thing?). worth it for a >> 128x128 >> grid etc? >> >> I'm just after any general thoughts/insights you might have as to what >> might or might not work. Anything worth pursuing. >> >> I'm afraid there's all sorts of little things to be considered so if you >> do have something to suggest, please read the stackoverflow post first. >> >> Cheers for any help, if possible, >> James. >> >> >> > > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev >

15 years, 5 months

update: OT-ish: realtime 2d placement algorithms :-/

by James Morris

Just a quick update. I eventually settled on a 64bit 2D array, with each 64bit element in the array representing 64 spaces in the grid merely for tracking the state of space being used or unused. Turns out much faster this way. There will still be a list of blocks (or windows if it was a window manager) placed but this is an entirely separate issue. For example in the test code I keep track of the coordinates (returned by the algorithm) and dimensions of placed blocks in an array. code/demo here: http://jwm-art.net/boxyseq/freespace_grid.tar.bz2 video/demo here: http://jwm-art.net/art/freespace_grid.ogv running 'make' in the src, builds a demo/test program which produces similar output to the video - this is where the good old xterm wins - set font to 'tiny' and maximize vertically and widen it to atleast 128 chars and xterm displays fast enough it looks like an animation. I'm hoping this will work well enough for real-time placement, though the worst case scenario has changed from just being 255 windows placed, to something like.... placing a 1x1 block in a non-empty grid full of (any dimensioned window... it's difficult to work out the worst case here. james. On Fri, April 30, 2010 23:10, James Morris wrote: > Hello, > > I'm still trying to develop my boxy-sequencer idea. Basically, I've tried > out a couple of algorithms for window-manager-like box placement within a > grid and run into big problems. > > Because I need help/advice/ideas, I'm posting here as it has some > relevance, and I've also posted to > > http://stackoverflow.com/questions/2746590/fast-block-placement-algorithm-a… > > A quick run down of what's happened so far, the two algorithms: > > The first I directly based on Fluxbox's Row Smart placement algorithm. > Testing only the data structures, (and with gcc -O0) jack kicked out my > client after around 200 boxes were placed in a 128x128 grid. I then > counted how many times the algorithm looped through the entire list of > boxes and discovered (not in RT for this) that the 256th box placement > required around 14000 scans through the list of 255 previously placed > boxes (i've decided 256 boxes will be the worst-case-scenario). > > The second algorithm consists of a freebox data structure which represents > a rectangular area of free unused space. It also forms a node in a doubly > linked list, as well as four directional links to other freeboxes touching > it (with a maximum of one freebox touching each side of a freebox)... > turns out rather complex to implement fully: 700+ loc for a partial > implementation of row-smart left-to-right top-to-bottom placement - theres > also col-smart, r-to-l, b-to-t and all combinations. > > Through stackoverflow, I've come across spatial hashing. > > I wondered if anyone here uses this technique for the display of data > (would scrollable window views use such a thing?). worth it for a 128x128 > grid etc? > > I'm just after any general thoughts/insights you might have as to what > might or might not work. Anything worth pursuing. > > I'm afraid there's all sorts of little things to be considered so if you > do have something to suggest, please read the stackoverflow post first. > > Cheers for any help, if possible, > James. > > >

15 years, 5 months

Re: [LAD] interesting TSC coverage on lwn.net

by lieven moors

On 05/20/2010 09:08 AM, Jörn Nettingsmeier-6 wrote: > hi *! > > in the light of recent timer discussions (was it here or on > jack-devel?), lwn.net has interesting coverage about the time stamp > counter and its oddities in the recent weekly edition: > http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ > (free link, the rest of the issue will become available to > non-subscribers in 14 days or so.) > > best, > > jörn > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev@... > http://lists.linuxaudio.org/listinfo/linux-audio-dev Thanks for the link! Interesting read. So this is the monster that's being used when you start jack with -c cycle... Greetings, lieven

15 years, 5 months

interesting TSC coverage on lwn.net

by Jörn Nettingsmeier

hi *! in the light of recent timer discussions (was it here or on jack-devel?), lwn.net has interesting coverage about the time stamp counter and its oddities in the recent weekly edition: http://lwn.net/SubscriberLink/388188/62e8027425e224f6/ (free link, the rest of the issue will become available to non-subscribers in 14 days or so.) best, jörn

15 years, 5 months

A vocoder with built-in Modulator

by Louigi Verona

Hey guys! In many DAWs it is not possible to use a vocoder, because it requires two inputs - a modulator and a carrier. So in order for this to work you either have to allow routing in the mixer (which none of the linux daws are capable of, as far as I know) or else use vocoder as an external programm. While the latter is a partial solution, it is not always desirable. Having Vocoder as just a plugin inside a DAW is something that I personally always needed. I wanted to suggest a Vocoder with built-in Modulator. This can be accomplished in two methods: a. The user loads a wave file from the plugin's GUI, a wave file that would act as a modulator. b. The plugin has a set of predefined waves and/or a set of oscillators with basic waveforms (like the famous Orange Vocoder VST). There are two Vocoders on Linux that I know of - the LADSPA Vocoder (and its LV2 port, done by a different programmer) and the Vocoder, created by the guys of the Rakarrack team. Both vocoders are definetely very capable tools. I wanted to ask whether 1. modifying them in a manner I specified above is a difficult task 2. and whether someone would want to take it up. Additionally, how difficult is it to include several features that would make this vocoder more like an instrument rather than just a plugin that does only one job, namely filter, fine tune for the modulator and LFO. Louigi Verona.

15 years, 5 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