Linux-audio-dev September 2010

linux-audio-dev@lists.linuxaudio.org

52 participants
35 discussions

Start a nNew thread

Faust MIDI?

by Carlo Capocasa

Hi, is it possible to send and receive MIDI with a FAUST program? Carlo

12 years, 2 months

envy24control, resp. it's successor

by Ralf Mardorf

Pardon, I didn't follow the progress of envy24control. Did you finish the recently development and if so, where can we/I get the latest source code? Cheers! Ralf

13 years, 7 months

Port Argotlunar VST to LV2!

by Louigi Verona

Hey guys! Will anyone be interested in porting this GPLed VST to LV2? http://argotlunar.info/ Louigi Verona.

13 years, 8 months

Re: [LAD] FOSS Ethernet Soundcard - IETF Ethernet AVB

by errordeveloper＠gmail.com

Hi everybody, Fallowing up the long discussion i'm trying to sort of give the information you all seem to be missing. there was a meantion of this, but not too many of you have paid any attention: here you can find an article about the current status of the protocol mess: http://prosoundnewseurope.com/pdf/PSNLive/PSNLive_2009.pdf (page 28) obviously eas50 is good to go, but Ethernet AVB is right thing really. the only thing that it's still work in progress, but many of the proprietary vendors, which already have their own networking solution (like Harman with HiQ-net, the one i can name of top of my head) are involved in AVB stadard deveelopment. The idea of AVB is to bypass the IP layer, which is right thing really. you don't need to assign IPs to your audio nodes, really! in avb you'd just have to select channels that nodes whant to listen to. there is a fair bit of documentation on the ietf.org AVB group's page. but XMOS is looking to be the best point of refference: http://www.xmos.com/news/15-jun-2009/xmos-simplifies-ethernet-avb-implement… is think we should forget everything else and crack on with the XS1 AVB implementation! their XS1 chips seem to be really great, their are basically every innovative and open-source minded. the official toolchain is LLVM-GCC based. you can use C, C++ or their own XC. XC is basically C with some stuff omited (like goto and floats) and XMOS IO stuff added, don't just say WTF, look at it first! you should also watch the videos here: http://www.xmoslinkers.org/conference-online-wf especialy the two about the "XMOS Architecture" and the AVB presentation. some dev-kits are quite expencive, but that's due to low-volume really ;) there is alos a nice USB Audio kit! plus there is alittle board that is cheap and has two RJ45's on it already :) I'm myself studying the XC book at the moment. And geting familiar with the tool set :)~~ looks very exciting, cause these are the invovative chips! ok, may be an FPU is really missing on XCore, but how many DSPs have it anyway? well quite a few, but there was no FPU on dsps for ages! :)) also XC or C/C++ are so much more obvious then the bloody "menthal american military engeneers non-sense" called HDL-whatever! Cheers Everyone, Hope you will appreciate my excitment :)~ (l0l) -- ilya .d

13 years, 8 months

[ANN] QmidiCtl, QmidiNet 0.1.0 Out Now!

by Rui Nuno Capela

Howdy! It's been a long summer hasn't it? Bad news is that laudable 'spring cleaning' has slipped a bunch and in fact, is still on going with no end on sight, exactly as the 'uber-procrastinator' predicted! ;) Nevertheless, QmidiCtl, QmidiNet 0.1.0 are out now! This release marks the fact that QmidiCtl [1] is now made available from the official Maemo 5 repository [3]. So that you can download and install it directly from your N900 [4]. You'll find it on the Multimedia section. Second, QmidiCtl [1] is now fully configurable with regard to which MIDI events are sent and/or recognized. It's not MMC-exclusive anymore. Third, QmidiNet [2] also talks JACK-MIDI now. Although (very) experimentally. And you don't have to opt out on ALSA-MIDI. You can have both MIDI interfaces running as long as you please. Finally, Paul de Vries shows us a magnificent video re. How To: Setup QmidiCtl on The Nokia N900 with Renoise [5]. Alas, it's on Windows and using ipMIDI [8] as the gateway back-end. No sweat :) If Renoise [6] is to run on Linux he would use QmidiNet [2] or multimidicast [7]. Take note that the latter only does ALSA MIDI and doesn't handle MIDI SysEx messages as certain as MMC is. Kudos to Paul. See also: http://www.rncbc.org/drupal/node/233 Websites: http://qmidictl.sourceforge.net http://qmidinet.sourceforge.net Project pages: http://sourceforge.net/projects/qmidictl http://sourceforge.net/projects/qmidinet Downloads: - source tarballs: http://downloads.sourceforge.net/qmidictl/qmidictl-0.1.0.tar.gz http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.0.tar.gz - source package (openSUSE 11.3): http://downloads.sourceforge.net/qmidictl/qmidictl-0.1.0-1.rncbc.suse113.sr… http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.0-1.rncbc.suse113.sr… - binary packages (openSUSE 11.3): http://downloads.sourceforge.net/qmidictl/qmidictl-0.1.0-1.rncbc.suse113.i5… http://downloads.sourceforge.net/qmidictl/qmidictl-0.1.0-1.rncbc.suse113.x8… http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.0-1.rncbc.suse113.i5… http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.0-1.rncbc.suse113.x8… - binary packages (Maemo 5): http://maemo.org/downloads/product/Maemo5/qmidictl Weblog (upstream support): http://www.rncbc.org License: QmidiNet and QmidiCtl are both free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. References: [1] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast http://qmidictl.sourceforge.net [2] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast http://qmidinet.sourceforge.net [3] Maemo.org - Home of the Maemo community http://www.maemo.org [4] Maemo.org - Downloads: QmidiCtl http://maemo.org/downloads/product/Maemo5/qmidictl [5] How To: Setup QmidiCtl on The Nokia N900 with Renoise http://www.youtube.com/watch?v=z0hnZwnAdsk [6] Renoise http://www.renoise.com [7] multimidicast - sends and receives MIDI from ALSA sequencers over network http://llg.cubic.org/tools/multimidicast [8] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN http://nerds.de Cheers && Enjoy -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

13 years, 9 months

[ANN] Qtractor 0.4.7 - The Furious Desertrix is out!

by Rui Nuno Capela

It's TYOQA (The Year Of Qtractor Automation:) what else? But wait, there's three months to go yet. Meanwhile, the foundations have already been laid and one can now tell that a rocky milestone is ready to get bumped. Ouch! Qtractor 0.4.7 (furious desertrix) is out! Release highlights: - MIDI learn/controller mapping for all plugin parameters (NEW) - Extended Clip fade-in/out WYSIWYG curves (NEW) - MIDI resolution overflow (FIX) - MIDI tempo standard base on quarter-note (FIX) - Extended MIDI controller mapping for mixer/tracks (NEW) - Audio metronome gain control (NEW) - Mute/solo tracks while looping (FIX) - MIDI Clock support (NEW) - Audio clip import while looping (FIX) - MIDI track bank-select/program-change transparency (FIX) - VeSTige headers included for native VST plugin support (NEW) - JACK transport sync support (FIX) - Clip tempo-adjust tool (NEW) - Audio tracks auto-monitoring (FIX) - Transport back/forward stops on loop points (NEW) - MIDI tracks redundant mute/solo (FIX) See also: http://www.rncbc.org/drupal/node/235 Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.4.7.tar.gz - source package (openSUSE 11.3): http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.sr… - binary packages (openSUSE 11.3): http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.4.7-1.rncbc.suse113.x8… - user manual (nevermind 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: - While moving multi-selected MIDI events around the clip editor (aka piano-roll), with help of keyboard arrow keys, that is, was not clear which one was the so-called "anchor" event, the one which positioning gets honored for snap-to-beat business. Not anymore: the anchor event now defaults to the earliest in time or the one the user's last point(-click)ed. - MIDI control observer pattern implementation has sneaked in, making it ready for the so-called and long-awaited "MIDI Learn" feature and arbitrary MIDI controller assignment, for plugin parameters in particular. - MMC DEFERRED PLAY doesn't cause transport state to stop if currently rolling (mitigating bug #3067264). - Audio clip merge processing might have been skipping a few initial frame blocks, now fixed. - Clip selection and plugin parameter hash optimization. - Anti-glitch audio clip macro fade-in/out fixed again. - New clip fade-in/out slopes (curves) are introduced, partially adapted and refactored from those easing equations of Robert Penner's fame. - Clip fade-in/out non-linear slopes are now shown as actual WYSIWYG curves. - Escape key now closes generic plugin widgets as ever found usual elsewhere. - Picking nits: unselect current track when clicking on any gray empty area, also accessible from a new menu item: Track/Navigate/None. - A nasty and deadly MIDI resolution overflow has been finally fixed, allowing for long MIDI sequences (1h+) to load correctly on 32bit machines from now on (was perfectly fine on 64bit though). - MIDI editor selection hash optimization in face of reasonably huge event sequences. - MIDI controller mapping finally refactored to support some other MIDI event types than just CC (0xBn) ones. - Nitpicking fix: corrected main track-list (left pane) display when no track is currently selected. - libX11 is now being added explicitly to the build link phase, as seen necessary on some bleeding-edge distros eg. Fedora 13, Debian 6. (fixing bug #3050944). - New audio metronome bar and beat sample gain options. - Progressively, the observer pattern is being finally introduced, targeting all potentially automation controls and widgets as plain ground-zero for the (ultra-)long overdue automation feature. - MIDI controller mapping of still non-existing tracks were being implicitly assigned to the last, highly numbered, existing track. Now fixed. - Moving from old deprecated Qt3'ish custom event post handling into regular asynchronous signal/slot strategy. - Muting/soloing tracks while playback is looping was leaving current audio clip out-of-sync whenever that same track is later un-muted on any other preceding clip. Now hopefully fixed. - MIDI Clock support makes its first appearance. - All tempo (BPM) calculations are now compliant to the MIDI conventional equivalence between beat and quarter note (1/4, crotchet) as common standard time division. - Automatic audio time-stretch option is not enabled by default anymore. - Standard warning Apply button is now only shown when dismissing dialog changes are actually valid. - Make sure non-dedicated metronome and player buses are properly reset and reopen when changing regular audio buses (hopefully fixing bug item #3021645 - Crash after changing audio bus). - Hopefully, an outrageously old bug got squashed away, which was causing random impromptu crashes, most often when importing audio clips while looping and play-head is any near the loop end point. - General standard dialog buttons layout is now in place. - Fixed main track view off-limits play-head positioning. - Main tool-bar Time and Tempo spin-boxes, may now have their colors correct, as for most non-Qt based theme engines (ie. Gnome). Green text on black background has been and still is the the intended aspect design ;) - MIDI file import and internal sequence representation has been changed to be inclusive on all bank-select (CC#0,32) and program-change events which were previously discarded while honoring MIDI track properties. Interleaved SysEx events are now also preserved on their original sequence positions instead of squashing a duplicate into the MIDI bus SysEx setup. - Attempt to include the VeSTige header by default, as for minimal VST plugin support. - JACK transport support has been slightly rewritten, in fact the sync callback is now in effect for repositioning. - The MIDI clip editor (piano roll) widget won't be flagged as a tool window anymore. - A tempo adjustment tool is making inroads from the menu, as Edit/Clip/Tempo... (factory shortcut: F7). - Audio tracks auto-monitoring is now effective on playback. - Make sure to ask whether a dirty MIDI clip should be saved, upon resizing or stretching its edges (fixes bug #3017723). - Backward and Forward transport commands are now taking additional stops on loop points. - Attempt to optimize track solo/mute redundant transactions, in special regard to MIDI track events which were being duplicated on soloing and temporarily muted on unsoloing. Cheers && Enjoy (be happy!) -- rncbc aka Rui Nuno capela rncbc(a)rncbc.org

13 years, 9 months

Roger Linn should open source Linnstrument & release on meego :-)

by Niels Mayer

http://www.youtube.com/watch?v=AoAOx97G8ew http://www.gizmag.com/roger-linn-linnstrument-digital-music-interface/15155/ ........ Sadly, that's unlikely to happen anytime soon - because the TouchCo multitouch pad that Linn used in the production of his prototype has been withdrawn from production. Apparently Amazon bought up the technology earlier this year ( http://www.nytimes.com/2010/02/04/technology/04amazon.html?_r=1 ) with a view to using it in the Kindle eBook reader, but has completely shelved it and shut down the TouchCo operation, presumably due to the ongoing Intellectual Property chest-beating, suing and counter-suing going on in the multitouch arena right now. So the TouchCo website has nothing but a sad placeholder to offer ( http://touchco.com/ ), and Linn has nothing but his pre-production prototype to work with, ruling out the possibility of a LinnStrument hitting the market in the immediate future. ........ Could the meego touch API support the features needed by the instrument used in the above Youtube Video of Roger Linn? Some of the swipes and other gestures demonstrated in the video are available in http://apidocs.meego.com/mtf/gestures.html but an important one isn't: multitouch pressure sensitivity that is equivalent to "polyphonic aftertouch" on a MIDI keyboard -- allowing analog pressure readings to be taken continuously and simultaneously per touch. Is there interest in making such devices part of the "use case" for meego touch? And are there any such displays&touchsensors available for use with Meego capable hardware such as the beagleboard? I imagine one could extrapolate touch pressure by looking at how much area each touch consumes, dynamically -- (assuming a normal human finger whose tip would deform and cover more surface area with application of more pressure). Niels http://nielsmayer.com

13 years, 9 months

Paul's Extreme Sound Stretch

by Louigi Verona

Hey guys! I have two questions. 1. How does Sound Stretch work? It is incredible the way it can produce a tone which has no noticeable vibrations, just a wall of sound. How is that accomplished, in layman terms if possible :) 2. Can this program be jackified and is that a lot of work? -- Louigi Verona http://www.louigiverona.ru/

13 years, 9 months

a treasure trove of information on "Physical Audio Signal Processing"

by Niels Mayer

Following a wikipedia link on karplus-strong synthesis posted recently, I found this, which appears to be the online fount of all knowledge for physical modelling and sound synthesis: https://ccrma.stanford.edu/~jos/pasp/ (with links to examples, code, etc). > PHYSICAL AUDIO SIGNAL PROCESSING > FOR VIRTUAL MUSICAL INSTRUMENTS AND AUDIO EFFECTS > JULIUS O. SMITH III > Center for Computer Research in Music and Acoustics (CCRMA) > Department of Music, Stanford University, Stanford, California 94305 USA I figure someone will find this interesting. Plus it's cheaper than buying the book: ``Physical Audio Signal Processing'', by Julius O. Smith III, W3K Publishing, 2010, ISBN 978-0-9745607-2-4. Copyright © 2010-09-08 by Julius O. Smith III Center for Computer Research in Music and Acoustics (CCRMA), Stanford University Niels http://nielsmayer.com PS: Speaking of CCRMA. as seen recently in Linux Journal ( http://www.linuxjournal.com/article/10725 ): "Systems designed for power users tend to be both slick and decadent, armed to the teeth with the kind of tools that would make most end users crawl into a straitjacket and whine for their mommies. The studio distributions, such as PlanetCCRMA and 64 Studio, tend to be this variety." (i think that's a geek's way of making a compliment).

13 years, 9 months

a case for a knob control standard?

by pete shorthose

if there was a standard that described the expected behavior of commonly used (or just useful) knob control methods, perhaps in the form of a short draft specification on freedesktop.org, would people (ie developers) use it? expectations and requirements clearly differ so we would probably need to gather together and discuss those in use with a mind to removing or combining similar methods, explicitly naming them and defining their behavior in the abstract. if we required that applications implement a set few methods as configurable options (as a minimum) in order to comply then we might eventually see the back of the unpredictable mess we have now. it wouldn't matter how they are configured, be it gconf, dotfile, command line, prefs dialog, env variable.. as long as it could be done. worth thinking about or is it just too niche? are the actual real world applications too varied and specific to make it useful? for example it would certainly be nice to crack open a library config or application prefs window and assign VLMC (vertical linear motion control*) to the left mouse button and RMC (radial motion control*) to shift + left mouse button, and have those conform to the expected standards. or even just to set KNOB_CONTROL_METHOD=RMC in your global environment and have all the adherent applications just do what you expect. it seems to me that standards (of the mutually agreed rather than officially sanctioned variety, since the latter is impractical) provide the best means to bring about common behavior in sovereign systems. naturally it would be completely platform independent. just having named control methods with explicitly defined behavior may help matters too. cheers, pete. *crappy names i'm sure, but you get the idea.

13 years, 10 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 September 2010