Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

[LAD] Upcoming ICMC L2Ork workshop at NYC Resistor

by Ivica Ico Bukvic

Apologies for cross-posting... Dear Colleagues and fellow computer music enthusiasts, On May 30th 1pm-7pm EST @ NYC Resistor L2Ork will hold a one-day workshop on building Linux-based laptop orchestra and unique opportunities such an ensemble brings about. Synopsis: L2Ork is an ultra-affordable tool for handling administrative logistics associated with starting a new Linux-based laptop orchestra using exclusively free software and cost-efficient hardware. The workshop will cover general issues in regards to starting a Linux-based laptop orchestra, as well as provide an opportunity for the workshop participants to engage in writing for L2Ork. The workshop will also cover L2Ork's latest initiative to bridge STEM (Science, Technology, Engineering and Math) and Arts in K-12 education and funding opportunities such a project may bring about. Participants will learn about: * administrative and logistical prerequisites for starting a Linux-based laptop orchestra * design considerations in designing and building adequate infrastructure (speakers, soundcard, system configuration and optimization) * streamlining Linux platform * optimizing Pure-Data software for GUI-based networked performances * ensuing creative opportunities of a networked laptop orchestra * design strategies and standards developed for writing pieces for the L2Ork ensemble * education-based opportunities attained through L2Ork's ultra-affordable infrastructure * logistical considerations in building GUIs for a diverse group of performers with widely varying amount of musical training and experience * wiimote strategies for an ensemble-oriented performance * strategies for incorporating soloists into the L2Ork ensemble Participants will be given access to: * all L2Ork's resources, including custom code and Pure-Data abstractions designed specifically for the orchestra and its input devices * customized Pure-Data software platform with performance, editor, and GUI enhancements * access to software repository containing optimized Linux kernel and supporting software as well as turnkey Linux setup containing an entire hard-drive image of the L2Ork Linux system * detailed list of parts necessary to build L2Ork-compatible ~$250 hemispherical speakers and a ~$750/seat turnkey setup including a laptop, external soundcard, wiimote & nunchuk, headset, cables and accessories, and a custom hemispherical speaker. All participants will be also given an opportunity to interact with L2Ork members (performers and researchers alike) as well as submit their own works for programming consideration by the L2Ork ensemble. For a more detailed overview and registration info please visit: http://icmc-workshop-l2ork.eventbrite.com/ NB: please note that the times listed on the aforesaid site are in Pacific Time. For additional info on L2Ork, please visit http://l2ork.music.vt.edu. Should you happen to have any questions, suggestions or concerns, please do not hesitate to contact me. 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, 9 months

[LAD] LAC2010 - tune in..

by Robin Gareus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, For all those who could not make it to Utrecht: LAC2010 is just about to start here. Live A/V streams are already online - thanks to Joern -at http://streamer.stackingdwarves.net/ Remote participants are invited to join #lac2010 on irc.freenode.net, to be able to take part in the discussions, ask questions, and get technical assistance in case of stream problems... The Conference Schedule in online at: http://lac.linuxaudio.org/2010/?page=program ciao, robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvb2a4ACgkQeVUk8U+VK0JDcACaArfwzRM34VgBpEAqK/DjY/S8 oRYAoIu2HfLRoVAibfkw97/wn0j1Ukui =qDnY -----END PGP SIGNATURE-----

15 years, 9 months

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

by James Morris

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, 9 months

[LAD] Bug in FST: can't find/load plugin, specified with full path

by Mike Cookson

When I give relative path, it works. I found a workaround: begin full path with dos-device name.

15 years, 9 months

[LAD] Novation launchpad midi driver

by Christian

Although my provider's spam filter still blocks linux audio mails, I'm happy to announce my novation launchpad midi driver. It is not a driver in the common sense, but a user space usb application which offers a midi out and in to write and receive launchpad midi messages. On my distribution(gentoo) I needed to add myself to the usb group to run this application. Download it from: http://krampenschiesser.de/launchpadd-0.1.tar.bz2 Dependencies: I know the dependencies are quite fat(boost) but this driver is part of my sequencer application, and I just want to give launchpad owners the possibility to use their pad. boost >= 1.41 (need threads, signals2, foreach) libusb-1.0 alsa pthreads To build the whole stuff you need cmake(>=2.6). Installation: $ tar -xjf launchpadd-0.1.tar.bz2 $ cmake $ make $ sudo make install $ launchpadmidid To uninstall use : $ xargs rm < install_manifest.txt I would be very happy to get some feedback from the users and developers. Coming from the Java world this is my first(finished) project in c++ and c. And I didn't know anything about USB before... So if there is a developer who has got a good knowledge of c/c++ or usb interrupt transfers it would be great if he could have a look at the code, especially the method handleWriteTransfer in LaunchpadImpl(.cpp) is a point where I'm not that sure about the interrupt handling(although it works as it is right now). If there's anyone using this application on a kernel <=2.6.27 please inform me(as the polling changed with this version).

15 years, 9 months

[LAD] Kernel Opinions: .31-rt or .33-rt?

by Gabriel M. Beddingfield

Does anyone out there have an opinion on linux kernel 2.6.31-rt vs. 2.6.33-rt for audio? Thanks, Gabriel

15 years, 9 months

[LAD] EURASIP JASP CfP

by Victor Lazzarini

Hi everyone, I think this CfP might interest some of the people on this list: http://www.hindawi.com/journals/asp/si/mart.html We welcome contributions from various related audio development areas, as you will be able to see from the call, there is a wide scope in it. all the best Victor

15 years, 9 months

[LAD] JACK Graph Internal Latency? (was Re: A small article ...)

by michael noble

hi all, On Thu, Apr 29, 2010 at 7:05 AM, Tim E. Real <termtech(a)rogers.com> wrote: > > > Just a request: Would be awesome as a DSSI plugin so that we > don't have to use rakarrack in a 'send and return' loop within our apps, > which causes latency due to the round trip... > Tim. > > This raises a question that I've had for a while regarding latency in the JACK graph. I may have even asked it in the past, but if I did I either wasn't satisfied with the answer or have forgotten it completely. Either way, I'm unable to find it in the archives. My understanding is that connections between applications in the JACK graph should add absolutely no additional latency to the signal path. Latency is of course introduced at the A/D and D/A conversion stage of the graph, which is to be expected. This is the latency figure that jack reports - the latency introduced at every A/D or D/A stage. The only additional latency introduced is by processing internal to any applications, for example by the use of sample blocks as in the case of convolution. Am I correct in this? If so, then I don't understand Tim's statement above, as there should be no difference, in terms of latency, between using Rakarrack as a plugin (if it were possible) within an application, or placing it in an external send/return loop in the JACK graph. If my assumption is not correct, then I'm actually highly confused as to what the value of JACK is at all. If latency were introduced at every additional JACK signal routing, then even a simple routing like the following: A/D -> Rakarrack -> Jackrack -> Ardour -> D/A would have no less than four multiples of the internal JACK latency. This would quickly become unworkable in more complex JACK graphs (for example asymmetrical graphs would have signal chains running with different internal latencies). This would make having application interconnects a pointless exercise in frustration for the most part. And actually, from experience, this is not what seems to happen at all. Feel free to correct my admittedly limited technical understand of how latency is handled internally to the JACK graph... -michael

15 years, 9 months

[LAD] Ladspa run lengths and control latency

by Tim E. Real

I wrote: >> Maybe I made a mistake there, confusing a plugin chain with analog >> latencies. Ah but then, isn't a plugin chain like a 'bucket brigade'? >> Each stage can't know what the previous stage does to the signal until >> that previous stage has processed a whole buffer. >> ("He said, waiting to be clobbered by the responses.") >Oops, yeah that happens, but all within one process cycle. >Each plugin in the chain is run in succession on the data, right? >My mistake. Must be tired, the ol' brain wanders... I have a question, sort of related to that latency discussion: Plugin 'run' length need not be related to audio buffer size, right? I'm thinking of breaking up my 'single-run-per-process' into multiple 'run-lengths-between-control-or-program-changes-or-midi-events', per process. I know dssi docs mention doing this in regards to program changes 'between notes', but don't specifically mention handling control changes or midi events that way, but it seems reasonable. So not only will I get more or less 'sample accurate' control and program changes and midi events, but processing each control's successive changes won't take so long from waiting for the next process cycle in order to set each change (I found when processing a string of dssi-vst osc control change notifications for one control, the vst expects *all* of the changes to be sent back to it via the ladspa control port, so the quicker the port value can be changed, the better, that's why I want to break up the runs). Is this a good method? I'm also asking because... If I carry this logic to an extreme, what might be wrong with using say 128 'single sample' runs, for an audio buffer size of 128? Can plugins handle 'single sample' (or even dynamically varying runs)? My proposed method implies this would actually happen, if control or program changes or midi events needed to occur very close together. Thanks. Tim.

15 years, 9 months

[LAD] [ANN] Qsynth 0.3.5 - Spring Cleaning Pt.2

by Rui Nuno Capela

Hello, Ashes to ashes, dust to dust, funk to funky. Yawn. Cut the non-sense, there's no burial service nor Bowie's song here. Just blowing some aging stuff, maybe giving the patine that it deserves ;) Almost one long year has gone by and sadly enough, there's no big new and flashy features to show off. But, nevertheless, Qsynth 0.3.5 is out from the closet! Hope you enjoy the (not so big) news :) Have fun. Description: Qsynth is a FluidSynth GUI front-end application written in C++ around the Qt4 toolkit using Qt Designer. FluidSynth is an excellent command line software synthsizer based on the Soundfont specification. Website: http://qsynth.sourceforge.net Project page: http://sourceforge.net/projects/qsynth Downloads: - source tarball: http://downloads.sourceforge.net/qsynth/qsynth-0.3.5.tar.gz - source package (openSUSE 11.2): http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.src.rpm - binary packages (openSUSE 11.2): http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.i586.r… http://downloads.sourceforge.net/qsynth/qsynth-0.3.5-2.rncbc.suse112.x86_64… - binary packages (Ubuntu 9.10): http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_i386… http://downloads.sourceforge.net/qsynth/qsynth_0.3.5-2.rncbc.ubuntu910_amd6… Change-log: - Initial widget geometry and visibility persistence logic has been slightly revised as much to avoid crash failures due to wrong main widget hidden state. - General source tree layout and build configuration change. - Most modal message dialog boxes (eg. critical errors) are now replaced by system tray icon bubble messages where available. - Reverb and Chorus parameter ranges have been revised to match and comply with fluidsynth back-end (libfluidsynth). - Fluidsynth channel info and unset program interfaces are now in use where available (libfluidsynth >= 1.1.1, EXPERIMENTAL). - Global configuration state is now explicitly saved/committed to disk when Options dialog changes are accepted and applied. - Output peak level meters get their long deserved gradient look. - Automatic crash-dump reports, debugger stack-traces (gdb), back-traces, whatever, are being introduced as a brand new configure option (--enable-stacktrace) and default enabled on debug build targets (--enable-debug). - Added Czech (cs) translation, contributed by Pavel Fric. - The channel preset selector (Channels/Edit...) has been seriously crippled for ages, only showing the presets of the last loaded soundfont, now fixed. - Minimum number of MIDI channels allowed on engine setup has been dropped from the old value 16 to as low as 1 (one), not that it makes a difference, as (lib)fluidsynth internals just rounds it to the nearest multiple of 16 anyway. - Cleanup to knobs source, simplified from redundant stuff. Weblog (upstream support, yours truly): http://www.rncbc.org License: Qsynth is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Cheers && Enjoy. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

15 years, 9 months

Jump to page:

2026

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