Linux-audio-dev August 2009

linux-audio-dev@lists.linuxaudio.org

94 participants
75 discussions

Re: [LAD] [ANN] Invada Studio LV2 Plugins 1.2.0

by Ralf Mardorf

Dan Mills wrote: > On Sun, 2009-08-23 at 19:24 +0200, Ralf Mardorf wrote: > >> The only useful thing is to >> have a pre-adjusted meter, that can't be readjusted by the audio >> engineer. >> > > How do you deal with the annoying detail that there are at least 3 > standard alignments between 0Vu and 0dbFs (EBU, SMPTE and US Radio)? You > need a calibration tweak to allow you to set the meters to whatever > standard the rest of your system is aligned to. > > Regards, Dan. I'm very sceptic that meters for studios in the box are in sync with external equipment. I'm also very sceptic about the quality of measure accurately for external equipment in any home recording studio, any semi-pro studio and even some pro studios, were the equipment isn't checked on a daily basis. Absolute accuracy becomes important especially if tapes are sent from one studio to the other. The effective value is sine wave +3dB = 0 and nothing else. Am I wrong?

16 years, 5 months

[LAD] [Fwd: Re: [Zynaddsubfx-user] more on improved jack io]

by cal

A short while back I floated some experimental notions involving ZynAddSubFX on LAU. That was useful, especially Paul D's comments (they always are). I subsequently posted a patch on the project's Tracker on sourceforge, which naturally caught the attention of Mark McCurry, currently running the ZynAddSubFX project. As far as Zyn is concerned, I do so wish for good things to happen to it in the future. I suspect there's both lurkers and devs on this list with some interest in zyn, so with the indulgence of everyone concerned I'm presenting a thread from Zynaddsubfx-user. I hope Mark doesn't mind, but airing this here might somehow prove helpful. Hope so. -------- Original Message -------- Subject: Re: [Zynaddsubfx-user] more on improved jack io Date: Thu, 13 Aug 2009 19:09:41 +1000 From: cal <cal(a)graggrag.com> To: Mark McCurry <mark.d.mccurry(a)gmail.com> CC: zynaddsubfx-user <zynaddsubfx-user(a)lists.sourceforge.net> References: <4A7E48B3.2030401(a)graggrag.com> <278139b70908121642p78b4a0caw7543afd87e4d8db8(a)mail.gmail.com> Mark McCurry wrote: > Cal, > > I would like to integrate in your patch into the main branch, as better > jack and alsa audio are something that is desired, but it does look like > it currently needs some extra work. > For the previous patches, they did get out of date before I had too much > of a chance to integrate them. > For the previous iteration of this patch, I do believe that I asked > Harald Hvaal to attempt to integrate some of your work after contacting you. > He told me that he did email you, but he did not get a response. > > In the diff, it looks like you took the changes that you made to an > earlier version and just diffed it with current code. > This generates an unreasonable amount of noise to hide the signal. > There are also a good number of stylistic/superficial differences > (REALTYPE -> zynsample_t , whitespace differences, Master -> zynMaster , > etc) (in my opinion). > > If the diff was readable, then it would have a good chance to get into > the main git branch, but for now it is illegible. > I apologize for letting it balloon to this size and I am still > interested in integrating parts into the git code, but it needs to have > the fat trimmed before that can happen. > > --Mark McCurry > (If you prefer that this discussion occurs on the mailing list, then > that is fine with me) > hi Mark, As patch reviews go, that one's probably about as naive and shallow as they come. I do appreciate your mail though, and I've cc'd the user list as suggested - perhaps a wider audience might help the discussion. In dismissing "stylistic/superficial differences", I suspect you have no clue as to why I considered those changes desirable and/or necessary from a software engineering perspective, as distinct from merely stylistic. From your review, I also suspect there's been little or no analysis of what it might take to improve the structure of the audio and midi drivers, and to have zyn use jack's reported samplerate and buffer size. And no comment whatsoever on how well or badly I've achieved those goals. Naive in the extreme. On the subject of whitespace - the complete absence of whitespace and rational indentation in the official code is one of the main reasons (but not the only one) why zyn is in danger of bit-rotting its way to oblivion. Code like that was normal in 2002, but you'd be hard pressed to get any serious coder to even look at it today. In my humble opinion, the whole codebase needs the whitespace issue addressed if the code's to have any future. I started looking into the zyn code because I needed it to work well and reliably, which the official codebase does not do. What I've actually attempted is to take what I consider the latest interesting version of the code (2.4.0, released by paulnasca) and fix those broken elements that were causing me grief. I needed jack audio/midi to work well, so I fixed it. I saw alsa audio out as potentially useful for simple performance, so I added it. My patch is clearly labeled "experimental", so if anyone else finds it interesting or useful, then that's cool too. I'm pretty comfortable with what I've achieved so far. Jack audio is better, jack midi works well although the structure is far from ideal, or even good practice. I'm surprised you didn't notice that in your review of the patch. I know how to resolve that, but it's going to take even more serious restructuring to accommodate it properly. If and when I manage to get that together, I predict that that too will be summarily dismissed as just more fat to be trimmed. I'm also quite comfortable with the fact that my personal goals are way out of alignment with those of the "official" project. Over some months I've watched the changes going into git, and I'm less than enamoured with the changes since paulnasca's active involvement. In moments of melancholy, I do fear the official codebase is devolving ever so slowly toward becoming just a sad undergraduate fantasy. Naively sprinkling esoteric abstractions through the code while blissfully ignoring significant shortcomings in the code isn't likely to produce anything of value. Merging my audio/midi driver changes into git wouldn't be a trivial exercise, but really not all that hard. No offense, but I suspect neither you or Harald have the necessary skills (yet) to achieve that effectively. I don't see the current direction of the "official" development effort as interesting, hence I'm reluctant to engage in any serious fashion. cheers, Cal ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Zynaddsubfx-user mailing list Zynaddsubfx-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/zynaddsubfx-user

16 years, 5 months

Re: [LAD] LV2 port groups

by David Robillard

On Tue, 2009-08-18 at 07:53 +0000, Michael Chapman wrote: > On Sunday 16 August 2009 7:17 pm, Jörn Nettingsmeier wrote: > > michael, there are plans to implement the ACN/SN3D scheme in the LV2 > > plugin standard. > Excellent news! > > since it's based on rdf, the question is whether it might feasible to > > use the URLs for each ACN on ambisonics.ch as unique identifiers (which > > would be quite elegant and point users right to the relevant > > documentation). > Sounds good. > > however, that would depend on whether you could guarantee stability of > > said URL space. > Don't see any practical problem. > Legalistically the Association will undoubtedly go through > other officers over the years, but I cannot see any restraint on the > present Council giving an irrevocable commitment for something that is > manifestly in the interests of ambisonics. > I am also (I hope we all are) committed to Tim Berners-Lee > philosophy of not chopping and changing URLS (his great example is that > info.cern.ch --to his regret-- became w3.org, without even a redirect ... > and so the oldest web address in the universe disappeared). > > a short excerpt of the preceding discussion is quoted > > below. please maintain the cc: list when replying. Sounds good. It's probably a mistake on my part to use your /documentation/ URIs as the URIs for the concepts themselves anyway. Stable URIs are still good for all the usual reasons though. > > The stream descriptions could use them as well if there were URIs such > > as: > > > > http://ambisonics.ch/standards/filetypes/h1v1 > > > > instead of: > > > > http://ambisonics.ch/standards/filetypes/f > > > > None of my business, but if you are going HV, rather than HVP (which I > don't think I would ...) then Malham Notation (e.gg: "f", "fh") seems to > me a lot easier ... Sorry, I meant h1p1. Point being the current scheme doesn't really tie in with the use of (H,V) notation elsewhere on the site, and doesn't extend to higher orders very nicely. Nitpicks, anyway. > A redirect from http://.../h1v1 to http://.../f would not be impossible. > Would that be anyuse? > > > or better, http://ambisonics.ch/standards/streams/f if I can nitpick :) > > > > Likewise a redirect from http://.../filetypes/... to > http://.../streams/.... though if we are nitpicking I prefer > http://.../signal_sets/... ;-)> > > Not sure about the 'ethics' of littering the name space with redirects and > welcome comments from anyone who has thought more about this than I have. > Not least how does one redirect: presumably a 303 ("see other") is > preferable to a 301 ("moved permanently")? But I've not done that many / > thought that much about redirects in my life .... ;-)> Probably not worth changing. Also, hyphens in URIs are prettier :) > Please accept the gratuitous comments above as that. Seems silly not to > throw in my bits of experience at this early stage. > The bottom line is though, that this is your project and we are willing to > help as much as we can with whatever _you_ want. I'm just acting as RDF scribe, really. I defer to you folks who actually know a lot about ambisonics completely. Aside from a very helpful ambisonics for dummies sort of intro from Fons, I'm clueless :) Thanks, -dr

16 years, 5 months

[LAD] Multi-Channel channel order

by David Robillard

Is there any existing 'standard' for the order of channels for higher-than-stereo multi-channel streams? I'd assume this would be defined for interleaving or something, though that's not what it's needed for: I think the port groups extension should specify an order for all the channels of the various types of group. Though this isn't necessary useful in the normal case (ports are separate ala LADSPA), with this replication stuff and presumably other things the host and plugin are going to have to deal with sets of buffers, and having a predefined standard order for them seems like it would make life a lot simpler and faster (and not having one seems to have no benefit). For example, for discrete non-interleaved 5.1 (using a full channel for the .1) we have 6 channels: left, center, right, rear left, rear right, LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup) What order should these be passed in? Any existing practices? Thanks, -dr

16 years, 5 months

[LAD] [ANN] TAP-plugins 0.7.1

by Tom Szilagyi

Hi all, A bugfix version of TAP-plugins has been released. It aims to fix: * problems on 64-bit (silence in EQ, etc) * denormal problems * GCC compiler warnings * uninitialised variables (detected via Valgrind) Thanks to Damon Chaplin for spotting the issues, working on the solution and preparing a patch. TAP-plugins is hosted on SourceForge, please visit: http://tap-plugins.sf.net http://sourceforge.net/projects/tap-plugins/ There is no new functionality in this release. If 0.7.0 works perfectly for you, there is no need to upgrade. Enjoy, Tom

16 years, 5 months

[LAD] LADSPA plugins in ardour

by Fons Adriaensen

Hello all, I have an ardour mixer strip with 4 input and 2 outputs, and insert (post-fader) a plugin which has 4 inputs (A,B,C,D) and two outputs (X,Y). The signals at the output of the strip seem to be X + C + D and Y + C + D instead of X and Y. Is this 'documented behaviour', and if yes what purpose does it serve ? Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

16 years, 5 months

Re: [LAD] the role of lv2 extensions

by Jeff McClintock

> David Robillard - > Anyway, ...replication in basic form is pretty straightforward: the host > needs a way to pass a 'replication factor' to the plugin. This raises > a > few obvious questions: > > - Should changing this at run-time be possible? This is more useful > with polyphony than with replication for multi-channel purposes. This > raises nasty realtime issues, but since buffer allocation is the host's > problem and a clever host could possibly do it, I think the spec should > make this possible. Maybe there are problems with internal plugin data > that needs to replicate as well but in a non-realtime way though? I have written plugins that support port replication. In my case they *appear* to do so in realtime, but don't actually. The host re-instantiates a replacement (with the extra ports), and the same parameter settings, then inserts the replacement in the graph 'swapping out' the old instance (and destroying it). This happens pretty darn fast - milliseconds. The advantage is a minimal, simple API - when a plugin in created it queries it's 'replication factor' and adjusts itself accordingly. I don't need to support changes 'on the fly' while the plugin is processing audio (which could be difficult to perform within the constraints of realtime operation (without memory allocation etc). So you can avoid the nasty realtime issues, yet easily support run-time flexibility. Jeff McClintock

16 years, 5 months

[LAD] [somewhat OT] Dataquay -- a C++ wrapper for the Redland RDF data store using Qt4

by Chris Cannam

This is rather off-topic for this list, but I know that some developers here have a warped interest in this sort of thing. Dataquay is a free open source library that provides a friendly C++ API for the popular Redland RDF data store using Qt4 classes and containers. http://breakfastquay.com/dataquay/ Dataquay is intended to be simple to use and easy to integrate. It is principally intended for use in Qt-based applications that would like to use an RDF datastore as backing for in-memory project data -- that is, data being edited by the user, such as points and their properties in a graphical editor -- to avoid having to provide application data-specific file I/O and to make it easy to augment the data with descriptive metadata pulled in from external sources. Dataquay is also intended to be useful for applications whose primary purpose is not related to RDF but that have ad-hoc RDF needs for metadata management. Dataquay is similar in concept to the Soprano library (http://soprano.sourceforge.net/), but smaller, less sophisticated, and with BSD rather than LGPL licensing. Please see the website for more information, downloads, and caveats. Chris

16 years, 5 months

[LAD] control your Mackie C4 via OSC with contrOSC

by Malte Steiner

Hello, I released a new free open source application under GPL3: contrOSC is a middleware to bridge hardware DAW midicontrollers to OSC (Open Sound Control) enabled software like PD, CSound or SuperCollider, so you can easily create patches which communicates with the devices. The first one is the C4 by MACKIE (tm). Demopatches for PD and CSound are included, the OSC commands are documented in the manual PDF. http://controsc.sourceforge.net Dependencies are - QT 4.x - liblo for OSC - alsaseq for Midi So far only sourcecode release. Cheers, Malte -- ---- media art + development http://www.block4.com

16 years, 5 months

[LAD] rtirq script is broken with 2.6.31

by Robin Gareus

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rui et al, I just found that recent kernel development (merging IRQ threads into mainline) breaks the "rtirq" setup script. Basically rtirq does nothing. The command to get the PID PIDS=`ps -eo pid,comm | egrep "IRQ.${IRQ}\$" | awk '{print $1}'` (rtirq line 120) does no longer work since the IRQ process names have changed. I've quickly changed it to PIDS=`ps -eo pid,comm | egrep "irq\/${IRQ}-" | awk '{print $1}'` and it sets the priorities again, but that's not correct since it also raises priority of other drivers on the same IRQ.. Similarly `rtirq status` returns nothing. I've checked with: `ps -ewo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio` instead. It looks like a new set of regexps for rtirq is in order ;) This is Linux soyuz 2.6.31-rc5-rt1.1 #1 SMP PREEMPT RT Wed Aug 5 23:06:21 CEST 2009 i686 GNU/Linux # ps -eo pid,comm | grep -i irq 4 sirq-high/0 5 sirq-timer/0 6 sirq-net-tx/0 7 sirq-net-rx/0 8 sirq-block/0 9 sirq-tasklet/0 10 sirq-sched/0 11 sirq-hrtimer/0 12 sirq-rcu/0 149 irq/9-acpi 495 irq/14-ata_piix 496 irq/15-ata_piix 506 irq/16-yenta 526 irq/12-i8042 527 irq/1-i8042 1418 irq/8-rtc0 1428 irq/19-ehci_hcd 1446 irq/16-uhci_hcd 1447 irq/17-uhci_hcd 1450 irq/18-uhci_hcd 1452 irq/19-uhci_hcd 1544 irq/29-iwl3945 22591 sirq-high/1 22592 sirq-timer/1 22593 sirq-net-tx/1 22594 sirq-net-rx/1 22595 sirq-block/1 22596 sirq-tasklet/1 22597 sirq-sched/1 22598 sirq-hrtimer/1 22599 sirq-rcu/1 22609 irq/17-HDA Inte 22610 irq/17-ohci1394 22952 irq/16-i915@pci 22968 irq/28-eth1 Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that those are a result of a suspend/resume cycle; and I'll check later if the chrt settings do persist after a suspend/resume. so long, robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp7AfMACgkQeVUk8U+VK0LBZACfUeRxyGBf5rpmMvlurTFxKRis zk0An2QFd07wyg5wHRZXY0MJjD9dESnv =JLI3 -----END PGP SIGNATURE-----

16 years, 5 months

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 August 2009