Linux-audio-dev May 2010

linux-audio-dev@lists.linuxaudio.org

74 participants
59 discussions

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 >

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

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

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

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

14 years, 7 months

[ANN] Faust 0.9.24

by Orlarey Yann

================ | FAUST 0.9.24 | ================ GRAME - Centre National de Creation Musicale - is happy to announce the release of FAUST 0.9.24. This version fixes several bugs, and introduces some new possibilities in the language. ------------- About FAUST : ------------- FAUST (Functional Audio Stream) is a functional programming language specifically designed for real-time signal processing and synthesis. A distinctive characteristic of FAUST is to be fully compiled. The FAUST compiler translates DSP specifications into very efficient C++ code that works at sample level. It targets high-performance signal processing applications, libraries and audio plug-ins for a variety of audio platforms and standards. A same FAUST specification can be used to easily generate native JACK or ALSA applications, as well as CSOUND, LADSPA, MAX/MSP, PD, Q, SC and VST plugins. The Faust distribution can be downloaded at: http://sourceforge.net/projects/faudiostream Two mailing lists are available: https://lists.sourceforge.net/lists/listinfo/faudiostream-devel https://lists.sourceforge.net/lists/listinfo/faudiostream-users In order to test FAUST without installing it, please refer to the Online Faust Compiler: http://faust.grame.fr ------------ What's new : ------------ - Explicit substitutions. The language has been extended with new expressions type : exp[x1=def1; x2=def2; ...] allowing explicit substitutions in the lexical environment of an expression. This extension allows for instance, to customize an existing component by replacing some of its internal definitions without having to modify its source code. This extension is particularly useful to promote better code reuse. - Improved mathematical description (--mathdoc option) and support for two new languages : German (-mdlang de) and Italian (-mdlang it) - Support for floating point numbers in scientific notation and better precision for floating point constants. The precision used to print a floating point constant in the generated C++ code is no more limited to 6 digits. It is now dynamically adjusted to find the minimal number of digits that will produce the same internal representation when read back. This approach guarantees accuracy without sacrificing for readability. - All expressions are now systematically represented in polynomial forms. For example x*x will be replaced by x^2. If x is a complex expression the later form has several advantages, in particular to limit CSE. - Lazy semantics to select2 and select3 : the code generated for select2 and select3 is now based on conditional expressions ((cond)?exp1:exp0 ) instead of tables. The resulting code is more efficient as the stateless parts of the branches are not computed every time but only when really needed. - new --task-graph option. It produces a graphical representation of the internal DAG of task in dot format (Graphviz http://www.graphviz.org/). This DAG is useful for example to understand the potential parallelism of a program as analyzed by the Faust compiler - Two new tools : faust2graph and faust2graphviewer. These tools make use of the --task-graph option in order to produce the graphical representation, as a PDF file, of the internal DAG of tasks of a Faust program (require Graphviz). - new reduce.lib library. It provides various operations on block of samples based on a high order 'reduce(op, n)' fold-like function. Moreover the music.lib library has been extended with break-point functions and multiple decorrelated random and noise generators. New flanger and stereowidth control have been added to the effect.lib library. - new iPhone architecture. It consists in a iphone-cocoa.cpp architecture file and an Xcode template project to be used to produce the applications. Use "make iphone" in the example folder to build the examples for the iPhone. - improved cross plateform compatibility and brand new visual studio 2008 project to build Faust on windows machines. ---------- Bug Fixes: ---------- - Report error when non-integer table size is detected during compilation - Corrected partial application of power operator. Now ^(n) is equivalent to \(x).(x^n) and not anymore to \(x).(n^x) - Added missing faustpower definition when power function is used only in table content. - Fixed lock-free implementations of PopHead and PopTail functions on work stealing queues in --scheduler mode - Corrected missing dependencies in the internal DAG of tasks - Added missing cache code to slow shared expressions used delayed - Added missing cache code to foreign functions ---------------- Acknowledgments: ---------------- Many persons have been contributing to the FAUST project by providing code for the compiler, architecture files, libraries, examples, documentation, scripts, bug reports, ideas, etc. I would like to thank them and especially: Fons Adriaensen, Tiziano Bole, Baktery Chanka, Thomas Charbonnel, Damien Cramet, Etienne Gaudrin, Albert Graef, Stefan Kersten, Victor Lazzarini, Matthieu Leberre, Mathieu Leroi, Kjetil Matheussen, Remy Muller, Sampo Savolainen, Nicolas Scaringella, Stephen Sinclair, Travis Skare, Julius Smith, as well as my colleagues at GRAME, in particular : Dominique Fober, Stephane Letz and Karim Barkati, and from the ASTREE project : Jerome Barthelemy (IRCAM), Alain Bonardi (IRCAM), Raffaele Ciavarella (IRCAM), Pierre Jouvelot (Ecole des Mines/ParisTech), Laurent Pottier (U. Saint-Etienne) Yann Orlarey GRAME

14 years, 7 months

LAC "Tools" round-table wrapup

by Robin Gareus

Hi LADs, Following up on the LAC Tools round-table, I've started a wiki page: http://wiki.linuxaudio.org/wiki/tools_comparison Since I've not taken part in the discussion, I'm missing a few footnotes and explanation for keys in the context (eg. batch, sync). Could you please enlighten me, or just fill in the missing content there. IMHO it'd also make sense to do a 2nd table with orthogonal practical information, for instance: audio: JACK,ALSA,.. midi: JACK,ALSA,ALSA-seq audio-file-formats: pcm,mp3,gig,mid,.. control: OSC,TCP,pipe,MMC,.. interop/sync: jack-transport,MTC plugins (if applicable): LV2,LADSPA,VST,AU,.. Come to think of it, those could be integrated in the apps-database as tags for each tool, similar to: http://wiki.linuxaudio.org/apps/categories/jack_transport but let's get the categories/tags straightened out before starting on an implementation and posting it to LAU. What do you think? Cheers! robin

14 years, 7 months

Need to unsub, but server is down.

by Gene Heskett

Greetings; Can someone go look at lists.linuxaudio.org? The bottom line of the message is timing out. Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Live or die, I'll make a million." -- Reebus Kneebus, before his jump to the center of the earth, Firesign Theater

14 years, 7 months

[OT] lectureship in composition, music dept. NUIM Ireland

by Victor Lazzarini

Hi everyone, We have a new post in our department, which might interest some of you. http://www.publicjobs.ie/publicjobs/en/star/goToJobDetails.do?id=419 Unfortunately, given my involvement in the selection process, I can't answer any queries related to this post, but my colleague Gordon Delap will be most happy to do so. Maynooth is an interesting place to be at the moment, so I hope some of you will find this worth a go. All the best Victor

14 years, 7 months

guitarix-0.08.0 release 'Rockers'

by hermann

guitarix is a simple Linux Rock Guitar amplifier and is designed to achieve nice thrash/metal/rock/blues guitar sounds. guitarix uses the Jack Audio Connection Kit as its audio backend and brings in one input and two output ports to the jack audio graph. guitarix provide a jack midi input port to connect a midi controller (midi learn) and a (3 channel) jack midi output port, feed by a (scalable) mix of the tuner and a beat-detector. Release 0.08.0 comes with a bunch of major changes : * new portmap window * new BiQuad Filter * new Moog Filter * new Flanger * new post processing tube3 * new two 10 band parametric EQ's * new oversample mode selector(1x -8x) * fix some bugs in midi out * reworked tuner interface (show frequency(hz)) * new configure options (see ./waf --help for more info) have fun ________________________________________________________________________ guitarix is licensed under the GPL. Project page with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ please report bugs and suggestions in our forum here: http://sourceforge.net/apps/phpbb/guitarix/ ________________________________________________________________________ For capture, guitarix uses the great 'jack_capture' (version >= 0.9.30) written by Kjetil S. Matheussen. If you don't have it installed, you can look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Responses, guitarix uses the zita-convolver library, and, for up/down sampling we use zita-resampler, both written by Fons Adriaensen. If you don't have it installed, get it here: http://www.kokkinizita.net/linuxaudio/index.html We use the marvellous faust compiler to build the amp and effects and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ ________________________________________________________________________ For faust users : All used Faust dsp files are included in /guitarix/src/faust, the resulting cc files are in /guitarix/src/faust-cc The tools we use to convert (post-processing and plot) the resulting faust cpp files to the needed include format, stay in the /guitarix/tools directory. ________________________________________________________________________ regards Hermann Meyer, James Warden, Andreas Degert

14 years, 7 months

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 May 2010