Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7509 discussions

by Fons Adriaensen

hi all, In between smashing flies that came sitting on my hands while typing, and taking cold showers (we have some heath wave here) I wrote an auto-wah LADSPA plugin. It's available from the usual place: <http://www.kokkinizita.net/linuxaudio/downloads/WAH-plugins-0.0.1.tar.bz2> Since I'm not a guitarist I'll need user feedback to improve it. Enjoy ! -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

15 years, 10 months

[PD-announce] smeck (6ch guitar processing patch) released]

by Frank Barknecht

Hi, something for the guitarists around. This is the patch, that Miller Puckette explained during the workshop at LAC2008. Ciao -- Frank ----- Forwarded message from Miller Puckette <mpuckett(a)imusic1.ucsd.edu> ----- Date: Mon, 24 Aug 2009 20:52:33 -0700 From: Miller Puckette <mpuckett(a)imusic1.ucsd.edu> To: pd-announce(a)iem.at Subject: [PD] [PD-announce] smeck (6ch guitar processing patch) released Hi all, I've finally done a good enough job of cleaning up the 'smeck' patch (seen at Pd conventions 2007 and 2009) to consider it releasable. This patch takes a 6-channel signal from a separated guitar pickup (such as the Roland GK series) and does a variety of cool things to it. Smeck is available from: http://crca.ucsd.edu/~msp/ cheers Miller _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce _______________________________________________ Pd-list(a)iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ----- End forwarded message -----

15 years, 10 months

Selectable limit for polyphony of virtual synth

by Ralf Mardorf

Hi programmers of virtual synthesizers :) more than an hour ago I wiped of the dust of my old Oberheim to make soundfonts of some basses, but some pad sounds captivated me. The Oberheim is limited by 6-voice polyphony, resp. this isn't a limitation for those sounds. Virtual synth often tend to make the mix muddy, when playing pad sounds, because the polyphony isn't limited, every released note is able to end the complete release decay. For the Oberheim some notes are cut, while the wanted notes still can play the release decay. A selectable limit for polyphony might be a feature, that should become more common again, not only for virtual analog synthesizers. I know that e.g. fluidsynth-dssi has a global setting for polyphony, but the problem with this is, that it has impact to all used fluidsynth-dssi plugins. Cheers, Ralf

15 years, 10 months

[ANN] Invada Studio LV2 Plugins 1.2.0

by Fraser

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Everyone, There is an updated version of the Invada LV2 plugins available. This release contains a new plugin, 'Meters', which features Peak, VU, Phase & Spectrograph meters. Screenshot is here: http://www.invadarecords.com/images/downloads/Screenshot-Invada_Meters.png The amount of headroom between 0dB on the VU to digital 0dB is selectable from - -15dB to -3 dB. There is no right value for this, it really depends on the music, so just pick whatever value that causes the VU to spend most of it's time between +/- 3dB. (this stems from the fact that 0dB in the analogue world is the optimal level whereas 0dB in the digital world is the maximum level) Other Notable Changes: * Envelope attack & decay for meters now consistent across sample rates. * Improved font selection and sizing for widgets. * Initialised uninitialised variables in the delay plugin (thx Damon). * Added LV2 'Portgroups' extension to RDF's (thx Dave). * 'DESTDIR' make option to help packagers (thx Philipp). * Various GUI tweaks. Download from here: http://www.invadarecords.com/Downloads.php?ID=00000264 Ubuntu packages from here: https://launchpad.net/~invada/+archive/ppa Post bugs here: https://bugs.launchpad.net/invada-studio Send comments here :) Also packagers for distros may be interested on the 'nopkg' version of the tarball that contains no debian folder: https://launchpad.net/invada-studio/lv2/1.2 Final note: Please be aware that the 'External UI' extension the plugins use is due for a revision to make in fully compliant with LV2 spec V3 and above. When this occurs there shouldn't be any issues as I'll provide version of the GUI's compatible with both revisions. regards, Fraser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKkQSLNZroiEh4erwRAqM/AKDZ3+UWGtZuncD7URuAbuS/s1jpdgCfZQRW p7Pf1XIBpdgBIzhcIveu5ZM= =GHHe -----END PGP SIGNATURE-----

15 years, 10 months

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

by Ralf Mardorf

PS: The effective value is sine wave +3dB = 0 and nothing else. Am I wrong? *Just for dBFS*

15 years, 10 months

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?

15 years, 10 months

[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

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

15 years, 10 months

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

15 years, 10 months

[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

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