Re: [linux-audio-dev] promoting LAC 2007
On 27 Mar 2007, at 16:01, Fons Adriaensen wrote: On Tue, Mar 27, 2007 at 04:17:16PM +0200, Frank Barknecht wrote: Maybe one day there will be a Linux version of Live, but it's not something I particularily look forward to, as I wouldn't use it anyways unless it gets opensource'd. There are probably many of us thinking the same way. But the sad fact is that if all Linux users do this, then Linux will forever be an 'amateur' platform. From the PoV of a professional audio user (i.e. one who makes his/her living by providing services in that area), if a product does the job and has the right price, there is no good reason for not using it. I mostly agree, but in some ways the acceptable quality of the linux audio offerings makes proprietary software less necessary. OTOH, for processing photos I mainly use proprietary software (Lightroom, Bibble [on Linux] and Capture NX), as the free software options are simply not up to the job. For comparison the only proprietary music software I use is to control some dedicated synth hardware. Obviously I'd prefer to use 100% free software, but I'm more pragmatic than ideological. - Steve
Re: [linux-audio-dev] 2-channel stereo compatible ambisonics...
On 14 Mar 2007, at 10:10, Joern Nettingsmeier wrote: Steve Harris wrote: On 13 Mar 2007, at 09:15, Valent Turkovic wrote: Hi, is it possible to record multi channel speech audio and down sample it 2 stereo channels BUT with horizontal audio positioning of each audio channel ie. like dolby surround effect. Sure, but you might be disappointed by the results, Pro Logic is not very sophisticated (eg. there's no separate rear left and right channel, and the bandwidth is limited). Also the only free software implementation that I know of is not state of the art, partly due to patent problems, and partly due to lack of interest. There's a LADSPA plugin: http://plugin.org.uk/ladspa-swh/docs/ ladspa-swh.html#id1401 which does Pro Logic matrix encoding, you will need some other software to mix your independent streams into LCR channels (you can do it by ear with a 3+ variable send bus mixer), but once you have that you can feed it to the plugin and get a pro logic compatible stream out. PS ignore the documentation, it has been tested, and it does work, just not brilliantly. You will get better results if you EQ the mics a bit to cut the level of the highs and lows a bit, especially in the rear channel. You would get much better results with an ambisonic stream, but I don't /think/ you can make stereo-compatible ambisonic streams, and not many people have ambisonic decoders. Other people on this list know a lot more about ambisonics though. i'm very new to ambisonics, so i may be wrong, but i think there are indeed stereo compatible first-order ambisonics streams. iirc, the format is called UHJ, and it matrixes WXY (lossily) into L/R (i.e. no height information). i've changed the subject to bait fons :-D if we're lucky he knows an implementation of 2-channel UHJ. i found this article: http://www.ambisonic.net/ambi_AM91.html but it does not give details as to how the matrix encoding is accomplished. Hi Joern, Hmm, interesting, though it sounds like you'd need a specialised UHJ ambisonic decoder to play it back. That probably narrows the audience even further. - Steve
Re: [linux-audio-dev] Getting out of the software game
On 14 Mar 2007, at 15:34, Lee Revell wrote: My other response would be to point to all the successful vendors who *do* provide open Linux drivers. Creative released a GPL emu10k1 driver and went on to sell gazillions of those devices to Linux users, and the competition never cloned their hardware, because they patented their hardware innovations. And because their hardware is weird and terrible, but that's another story. I agree, FWIW, I'm just not sure that's a compelling example. - Steve
[linux-audio-dev] Hi, is it possible to record multi channel speech audio and down sample it 2 stereo channels BUT with horizontal audio positioning of each audio channel ie. like dolby surround effec
On 13 Mar 2007, at 09:15, Valent Turkovic wrote: Hi, is it possible to record multi channel speech audio and down sample it 2 stereo channels BUT with horizontal audio positioning of each audio channel ie. like dolby surround effect. Sure, but you might be disappointed by the results, Pro Logic is not very sophisticated (eg. there's no separate rear left and right channel, and the bandwidth is limited). Also the only free software implementation that I know of is not state of the art, partly due to patent problems, and partly due to lack of interest. There's a LADSPA plugin: http://plugin.org.uk/ladspa-swh/docs/ladspa- swh.html#id1401 which does Pro Logic matrix encoding, you will need some other software to mix your independent streams into LCR channels (you can do it by ear with a 3+ variable send bus mixer), but once you have that you can feed it to the plugin and get a pro logic compatible stream out. PS ignore the documentation, it has been tested, and it does work, just not brilliantly. You will get better results if you EQ the mics a bit to cut the level of the highs and lows a bit, especially in the rear channel. You would get much better results with an ambisonic stream, but I don't /think/ you can make stereo-compatible ambisonic streams, and not many people have ambisonic decoders. Other people on this list know a lot more about ambisonics though. - Steve
Re: [linux-audio-dev] denormals or ... ?
Hi Dave, To be getting problems from denormals you really need a stretch of silence going into some effects processing. From your description it doesn't seem like that's very likely. If you do have a stretch of silence, add a small amount of noise to the track, and if it goes away you have a denormal bug, and you can shoot the plugin developer :) It could also be a NaN problem, which have similar symptoms but can happen at any time. Their uncommon, but much nastier to find and fix. If you skip forward to near the point where it jams and play from there, does it still jam? Have you tried muting some tracks to see if it still happens? - Steve On 13 Mar 2007, at 15:08, Dave Phillips wrote: Greetings: I have a problem with a piece I'm working on in Rosegarden 1.5. I've appended the text I sent to Chris Cannam, along with his response (I hope he doesn't mind). Btw, the machine is based on an AMD64 3200+, with 2G RAM and an 80G hard drive. Sound runs through an M-Audio Delta 66. Distro is 64Studio 2.0. My questions lead, Chris's replies follow : 2) I've written a piece consisting of six tracks with these specs: Tr.1 (audio) drum loop, repeated, 1 plugin (CAPS plate reverb 2x2) Tr.2 (MIDI) bass part, repeated, uses patch from 8mbgmsfx.sf2 soundfont, no fx (part is rendered via QSynth which does have its reverb active) Tr.3 (audio) rhythm guitar loop, repeated, 3 fx (dj EQ mono, CAPS compress, CAPS plate 2x2) Tr.4 (audio) lead guitar, no repeats or copy, 4 fx (CAPS plate 2x2, AmpIV, AM pitch shifter, multiband EQ) Tr.5 (audio) riff loop, copied, 3 fx (dj EQ mono, CAPS compress, CAPS plate 2x2) Tr.6 (audio) another percussion loop, copied, no fx At 120 BPM the piece is 200+ measures long. It plays along swimmingly, but at m. 74 (about two minutes into the piece) the sound cuts out entirely. RG continues to run, but it pops up a message telling me that there's not enough CPU for realtime processing. Up to that point JACK reports approximately 33% CPU usage and no errors, but then it reports 0(1024) for xruns. I don't know what the second number (1024) means to JACK, but it keeps rising (with no sound) until I halt RG. That sounds a bit like a plugin denormal problem. Although denormals are usually less of a problem on AMD64. The 0(1024) in qjackctl I think means that JACK has reported 1024 xruns via the reporting API but they haven't been mentioned in the message log. I don't actually know what causes that. Does CPU usage (as reported by a plain old CPU usage reporting program) actually peak at that point? So my question is: Given my machine, should my CPU be topping out in this scenario ? Probably not, or at least I wouldn't expect it to suddenly peak if usage has previously been on the low side. The only thing RG does that may affect CPU usage drastically during playback is that it doesn't start running plugins until they actually have something to work on, and it stops running them if they've fallen silent for a certain period and have no more input coming up (this is in contrast to e.g. Ardour which runs plugins all the time during playback, taking a more strictly correct view). So, if anyone has anything to add to Chris's assessment, I'd like to know about it. If the problem is indeed related to denormals, is there a way to fix it ? Comments and suggestions are most welcome. Best, dp
Re: [linux-audio-dev] audiogui
On 28 Feb 2007, at 17:29, Stephen Sinclair wrote: PS: does anyone know where I can 'GPL' an decent OSC server implementation in C++? The LibLo implementation is GPL, very easy to use, and available in many distros including Ubuntu. http://liblo.sourceforge.net/ I'm using it for a project and it seems very good. I think having an OSC-controlled audio back-end is a Good Thing. It is C, not C++ though, but I think a few people have used it in their C++ programs without too much trouble. There are some native C++ implementations, but I don't remember the names offhand. - Steve
Re: [linux-audio-dev] processing plugin standard wrapper
On 17 Feb 2007, at 10:47, Thorsten Wilms wrote: On Sat, Feb 17, 2007 at 12:45:37AM -0300, Camilo Polyméris wrote: Or if two consecutive plugins do FFT, the first could pass the information to the second in the frequency domain. Neither of these would work with current plugin architectures, though. Well, there has been that idea floating around, about having converter plugins to and from frequency domain and other plugins that work in frequency domain exclusively. Using LV2 with whatever extension(s) would be necessary. Yeah, I still plan to do this if I ever get the time. - Steve
Re: [linux-audio-dev] processing plugin standard wrapper
On 14 Feb 2007, at 04:18, Leonard Ritter wrote: On Mon, 2007-02-12 at 13:23 +0100, Stefano D'Angelo wrote: Hi all, who would be interested in writing a processing plugin standard wrapper (LADSPA, DSSI, LV2, VST, etc.)? ... so you have now 4+1 = 5 interfaces. theoretically, the issue should be solved, since you have now one central interface to talk to the other 4. however you disregard that in the process of writing your own interface, you learned all other 4 interfaces (so you could translate between them), which is exactly what you wanted to avoid. of course other people would profit from your work, ideally. the second issue is that your 5th interface accumulates all features of the other 4, which means that it will be the hardest to comprehend. ... the route i took for aldrin was to support none of these (since they didn't match the problem that i had), and, if the need for a certain piece of dsp code arises, port that code over to my private interface. So... you're inviting him to learn from your mistake? ;) I agree with the bulk of what you wrote, the solution to the problem of too many APIs is not to add another, but I don't think your own code is a good example of that. I am also not in a position to throw any stones. - Steve
Re: [linux-audio-dev] Old hat - comparison against windows
On 31 Jan 2007, at 11:27, Bob Ham wrote: On Tue, 2007-01-30 at 23:30 +0100, [EMAIL PROTECTED] wrote: On Tue, Jan 30, 2007 at 09:18:06PM +, Bob Ham wrote: On Tue, 2007-01-30 at 21:05 +, Bob Ham wrote: On Tue, 2007-01-30 at 09:03 -0800, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that ... make Linux compare favorably? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. The word FUD comes to mind. No idea why. Further to that, something constructive: perhaps you could try telling your customers why *you* chose linux, rather than trying to find reasons to tell them *they* should. the customers dont notice. they still use windows or no computers at all. it looks rather like a question from the management. You are correct there. From the modern business perspective, though, management are Michael's personal customers. I think the argument still applies. If your goal is to convince someone that your choice of linux is correct, telling them why you chose linux in the first place seems, to me at least, to be the best method, rather than seeking out reasons which you yourself haven't been concerned with previously. I don't think that's necessarily the case, just because Linux had better RT performance in 2000 doesn't mean it still does today, with Vista and general improvements. I think it's reasonable for management to question if it's still the best choice. - Steve
Re: [linux-audio-dev] Old hat - comparison against windows
On 31 Jan 2007, at 14:06, Robin Gareus wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Luthman wrote: On Wed, 2007-01-31 at 13:54 +0100, Robin Gareus wrote: Cons; If windows wants it can perform better than a fully fledged rt-unix-kernel. - but that remains to be proven for Vista! Are you saying that this is true for XP? Are there any references for that? maybe not for audio-apps. I once read some books about subverting the windows kernel - one can do marvelous stuff and get great performance out of it!! - only half kiddingly. - luckily I have not booted into XP for years and this Con might just be crap... however some instinct tells me that a UNIX - no matter how pre-emptive or tweaked - will always have more overhead than some DirectX-app. - but IMO this is irrelevant for normal audio apps on modern machines.. - memory management and -locking are more crucial.. I don't know if it's still the case, but a few years ago the NT kernel was very heavyweight compared to the UNIX kernel, and too a long time to do things like context switches. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 30 Jan 2007, at 01:25, Fraser wrote: Hi Steve, Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. In practice not all hosts do that, some just pick a suitably small block size, eg. 32 frames and quantise the changes to that rate. I didn't realise that - perhaps I glossed over that bit of the spec. A block size of 32 frames would really exagerate unnecessary paramter conversion... Sure, which is why people do tend to do the if (oldval != newval) thing on expensive parameter calculations. 32 is really the extreme end, I would think that typically its higher than that. JACK systems do run down to the 32 frame buffer level, so you have to be able to handle it anyway. It's quite inefficient as the cost of calling the run() function of every plugin for every block is significant. - Steve
Re: [linux-audio-dev] Old hat - comparison against windows
On 30 Jan 2007, at 17:03, Michael Ost wrote: Can anyone suggest ways to compare audio/midi performance between Linux and Windows that (1) are relevant to non-technical musicians and (2) make Linux compare favorably? Not things like I just don't like Windows or software feature comparisons or the politics of open vs. closed source, but rather things like responsiveness to audio interrupts, RAM footprint of the OS and ...? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. We spend alot of time on compatibility, especially on getting the plugins to work with Wine. I often get asked about switching to Windows and I don't have a good answer. My sense is that the main benefit of Linux is that audio interrupts are serviced faster and more predictably than in Windows because of SCHED_FIFO and Linux's low overhead. And clearly musicians could feel that, especially at lower buffer size settings so that's the kind of thing that could matter. I would have thought that the best way to measure scheduler performance is to write a simple VST plugin that writes the precise time at which it was called into a ram buffer, and writes the buffer out to disk after a few tens of thousands of calls. You can the measure the times between adjacent runs and work out if there's any significant difference in jitter. I would think that the RAM footprint is essentially impossible to measure, as you can't tell what proportion of the kernel space is buffers etc. From a commercial point of view, your are at the very least saving licence fees for each piece of hardware, that would surely eat into your profit margin. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 02:18, Fraser wrote:
Hi Steve,
Hi Fraser,
Sure. This was an issue in LADSPA, though not a significant enough
one that anyone wanted it changed. I would suspect you're
overestimating the burden compared to the function call overhead and
cache thrashing. I'd be interested to see figures indicating
otherwise though. There will obviously be cases where it's faster to
set values using callbacks, but I'll bet it's not universal.
I had a thought last night about this - if I am worried about the load
from converting parameters I can always do something like:
if(current_control_value1 != last_control_value1)
{
recalculate internal_value1
}
in the run loop
Yes, exactly. It's slightly more expensive as you have a conditional,
but you save the function call overhead, which is something like
1000-1500 cycles IIRC.
3) changes to parameters can be presented to the run() function
immediately
I don't see how it makes any difference in this area?
in the example code this line:
const float gain = *(plugin_data-gain);
is outside the for loop in the run() function
so changes to the gain are not picked up till the next run() call.
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably small block size, eg. 32 frames and
quantise the changes to that rate.
- Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 14:41, Lars Luthman wrote: On Mon, 2007-01-29 at 13:49 +, Chris Cannam wrote: On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: Chris Cannam [EMAIL PROTECTED] writes: What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Elven is not really meant to be used. It's an experimental host and a perpetual work-in-progress that I'm writing to test new extensions and to see how hard it is to write a basic LV2 host from scratch, including Turtle parsing and RDF subgraph querying (conclusion: not very hard). I would hope that there aren't many more than this, as it's still a draft spec, and it's not all nailed down. I'd hate for too many people to implement a draft before it's finalised. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 15:23, Paul Winkler wrote: On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote: Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. /delurk What does chop the run block mean? /relurk Imagine you have a block of 1024 samples, and at sample 24 a control value changes from 1 to 2, you could do: plugin-port = 2.0; plugin-run(1024); which puts the control value change in slightly the wrong place, or you could do: (chopping) plugin-port = 1.0; plugin-run(24); plugin-port = 2.0; plugin-run(1000); It's not a technical term or anything, I just needed a word :) - Steve
Re: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...)
On 29 Jan 2007, at 16:51, Florian Schmidt wrote: On Monday 29 January 2007 09:08, Steve Harris wrote: Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. In practice not all hosts do that, some just pick a suitably small block size, eg. 32 frames and quantise the changes to that rate. Hi, let me chime in because it kidna fits into the subject. I have defined two (very very simple LV2 extensions): The extension’s URI is http://tapas.affenbande.org/lv2/ext/fixed-buffersize All that a plugin needs to check is whether a host feature with this URI exists and the data will be a uint32 containing the buffersize. The host is only allowed to call the plugin’s run function with a buffersize equal to the one specified by the host feature. There’s a second extension: http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize which is identical to above but with the additional requirement that the fixed buffersize has to be a power of two. Great idea. I've got some plugins that will benefit a lot by this. We should link to known extensions on the http://lv2plug.in/ site. FWIW, my provisional plan was to wait until it seemed like time for a LV2 1.1 (hopefully not too soon :), then roll all the popular extensions into that. It doesn't make a huge amount of difference whether their included or not though. Before you ask, no I don't have a definition for popular. - Steve
Re: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...)
On 29 Jan 2007, at 17:57, Florian Schmidt wrote: On Monday 29 January 2007 18:22, Steve Harris wrote: http://tapas.affenbande.org/lv2/ext/fixed-buffersize http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize Great idea. I've got some plugins that will benefit a lot by this. We should link to known extensions on the http://lv2plug.in/ site. FWIW, my provisional plan was to wait until it seemed like time for a LV2 1.1 (hopefully not too soon :), then roll all the popular extensions into that. Ah, i don't mean this extension has to become part of the core LV2 spec. Nonono. I was just wondering whether it makes sense that i maintain this seperately and keep the extension URI to my site. Is there a plan to host some very common extensions on the lv2 site (URI having lv2plug.in in it and docs on the lv2 site), too? If so i would like to see these extensions included. Ah, I see. In principle that's fine, but in practice I suspect it's easier for you to edit the content on your own site. OTOH if people are happy to maintain the content via WebDAV then I'm happy to host extensions at http://lv2plugin.in/extension/foo or similar. There should definitely be links to the extensions from the spec site either way. It doesn't make a huge amount of difference whether their included or not though. Well, just a visibility thing. By having some extensions documented and hosted on lv2plug.in they probably get more visibility than others. For certain almost core functionality this would make sense i think. Well, for any really. URIs are free and we're not going to run out ;) - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 28 Jan 2007, at 05:07, Fraser wrote: however, it and i think all the other issues you raise are all solved by LV2 (LADSPA Version 2), which has come about in part from other people's difficulties with the same range of problems as you. ahh, so there is a V2 coming, not too much info about it yet out there (unless you know where to look) Which is deliberate, as it's not quite finished yet. There was quite a lot of discussion here though. On the natural parameter values, I really rather like it that way. Sure, it costs a bit of CPU to do the conversion, but it means that different plugins of the same type are more likely to be compatible, and it makes wiring up things in a modular synth style easier. It also means that things like preset files contain the same values as the live display, which is helpful. When it comes to burning a bit of extra CPU power to make the users life easier, I'm all for it. From my quick look at the LV2 spec there's something I'd like to see (this is just my 2c): The plugin doesn't know when a parameter has changed, so it must calculate it's internal values from the displayed parameter 'as often as possible' - once per run() call (doing it in the for loop itself is just too extreme). Sure. This was an issue in LADSPA, though not a significant enough one that anyone wanted it changed. I would suspect you're overestimating the burden compared to the function call overhead and cache thrashing. I'd be interested to see figures indicating otherwise though. There will obviously be cases where it's faster to set values using callbacks, but I'll bet it's not universal. It's also quite convenient for both the plugin and host not to have to provide/call callbacks for every parameter. ... This has the following advantages 1) run() just runs (saved a bit of cpu) But costs you some extra function calls, and makes the CPU load dependent on the frequency of changes, which makes predictably hitting RT deadlines harder. 2) internal values are only calculated when the parameter they are associated with changes True. 3) changes to parameters can be presented to the run() function immediately I don't see how it makes any difference in this area? 4) the plugin knows when a parameter changed and so can smooth jumps in values itself (rather then hoping to host is doing it) Either way the plugin is free to do parameter smoothing. Typically I just do a linear interpolation and/or a 1st order LP filter. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 24 Jan 2007, at 18:04, Stefano D'Angelo wrote: 2007/1/24, Steve Harris [EMAIL PROTECTED]: The way to help, IMHO, would be to make the existing systems compatible, using bridges/reflectors/wrappers, rather than creating more specs. - Steve Honestly I don't know about PluginCore, however that's not necessairly true. Although it is a completely different thing, take as an example GStreamer. If you compare a processing plugin to a media file and plugin development APIs to encodings... in the end they're quite similar! As I stated before, while in most cases bridges/reflectors/wrappers can be made quicker and safer, it must be ensured that there's logical equivalence beetween the two standards (or that the one you're writing the plugin for is logically a subset of the one you're going to use). Not necessarily. In my opinion, often a 90% solution that reuses existing technology is better than a 100% one that involves reinventing the wheel. Even if the new wheel is a bit more round :) It's all somewhat a matter of taste though. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 24 Jan 2007, at 15:06, Jay Vaughan wrote: At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: What I'd like to work on is a sound processing architecture (LADSPA, VST, DSSI, etc.) wrapper, which hides the details of a particular implementation to audio program developers. Nice idea. Already done: http://teragon.org/products/PluginCore/ What do you think about it? Would be nice if there were a GPL effort in the same way .. Hum. I'm reminded of the often used thought process: hmmm, there are way to many standards in this area, what we can do to improve things is add another, that would be great!. The way to help, IMHO, would be to make the existing systems compatible, using bridges/reflectors/wrappers, rather than creating more specs. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 24 Jan 2007, at 15:52, Stefano D'Angelo wrote: 2007/1/24, Jay Vaughan [EMAIL PROTECTED]: At 20:08 +0100 22/1/07, Stefano D'Angelo wrote: What I'd like to work on is a sound processing architecture (LADSPA, VST, DSSI, etc.) wrapper, which hides the details of a particular implementation to audio program developers. Nice idea. Already done: http://teragon.org/products/PluginCore/ What do you think about it? Would be nice if there were a GPL effort in the same way .. -- ; Jay Vaughan Well, it seems like LV2 can do (at least theorically) all of these already, altough some things might be a bit tricky (read the rest of the conversation). Now I'm seeking whether this approach (LV2 bridges plugins) can present practical problems and, in such case, I think it's better to solve them in LV2 than restart from scratch. To be true, there are two things I'm concerned about: one (less relevant, maybe) is RDF files... a bridge plugin should generate them for all installed plugins when it is loaded, and so it has to contain (or link to) code that can handle such syntax (I really don't understand why LV2 developers choose such language instead of XML, which is much more known and supported). For one thing XML has no guarantee of extensibility, making it unsuitable. The other one is more serious (but should have been also faced by vstserver, fst and dssi-vst): I'm talking about logical compatibility beetween LV2 and other standards (VST in this case) in handling some tasks (settings and session storing, banks/effects/programs metaphor, etc.). Does anyone know about these matters? That was outside the remit, LV2 1.0 was just intended to replace LADSPA, and LADSPA doesn't have those features. However, LV2 is designed to be easy to extend to include such things. Then I think that it would be nice if some GUI programs could take advantage of trapping Xlib (or whatever) functions (LD_PRELOAD?) in order to embed plugin GUIs inside the app and/or have a library that autogenerates GUIs for non GUI-plugins (well... the XML GUI specification for LADSPA has been dropped in LV2 in favour of extensions?). ... it's such a complex matter :-P The tripping point is the X event loop. Allegedly GTK and Qt have compatible event loops, but that's still quite limiting, and I don't think anyone's built a proof of concept. - Steve
Fwd: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 22 Jan 2007, at 22:15, Stefano D'Angelo wrote: 2007/1/22, Dmitry Baikov [EMAIL PROTECTED]: On 1/23/07, Stefano D'Angelo [EMAIL PROTECTED] wrote: Good point! This is true, but there are lots of sound processing plugins around, so maybe instead of creating a new API and then apply some compatibility layer, it should be better to create a wrapping tool natively. I think it should be also easier to expand. Then, embrase LV2 and create LV2 plugins that will load VSTs, LADSPA and anything you want. Or if you want something not possible with LV2, write an extension proposal. I think LV2 was designed as a very extendable API. If it is not, in your opinion, then help the guys to improve it. That could be a very wise solution, but there's one big problem with it: when you load a LV2 plugin, you load only one plugin! To be clearer I make an example: I have 10 VST plugin, and I want to write a LV2 plugin which loads VST plugins. When the LV2-aware application asks me which plugin I want to load I should specify the VST plugin loader... but then? There's no way for my LV2 plugin to determine which VST plugin it should load. This works fine, and was in the design brief for LV2. When asked what effects your LV2 plugin supports, you can return a list. But also if this is an overcomeable problem, for each VST plugin I load I have to waste memory space with a new instance of the LV2 VST loader plugin. No you don't. A LV2 VST loader would be a single shared object, so the OS would only load one instance of it. Then, it is quite absurde from the user point of view to open a plugin which lets you open other plugins... it's just illogical! It doesn't look like that to the user, they will just see a list of plugins, some of which will be VST and some will not be. Have you tried the DSSI VST reflector? It would work the same as that. Don't misunderstand me, LV2 is great, I think that it's the best processing architecture out there, but it's designed with a 1:1 relationship in mind (one plugin = one effect). That's absolutely not an LV2 weakness, it just does its job and nothing else (as it should be). You need to read the spec again. The terminology is confused, not least in the spec documents, but a single .lv2 plugin can host multiple effects with different ports and so on. - Steve
[linux-audio-dev] Back in the land of the connected
Just a quick heads-up. As some of you may know, I recently left my old job and the University of Southampton. But, I forgot to fill in the paperwork to keep my old accounts, machines etc. Consequently my @ecs.soton.ac.uk and @plugin.org.uk addresses stopped working, and the server that was running plugin.org.uk went offline. I now have my email accounts back. I'm still fishing through the backlog, so if you sent anything and I haven't replied, give it a week or so then try again. Some stuff will have been lost. Plugin.org.uk is back online at a new server, but judging by my inbox some things aren't working right. I'll look at it over the next day or so. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: You need to read the spec again. The terminology is confused, not least in the spec documents, but a single .lv2 plugin can host multiple effects with different ports and so on. - Steve Oops... seems like I'm a bit confused! Well, I'm going to reread the LV2 spec and try to figure out how to manage this kind of situations. Sorry for wasting your time! Not at all, at the very least it points out that the LV2 spec needs to be clearer, and probably needs better examples. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 13:19, Stefano D'Angelo wrote: 2007/1/23, Steve Harris [EMAIL PROTECTED]: On 23 Jan 2007, at 12:17, Stefano D'Angelo wrote: You need to read the spec again. The terminology is confused, not least in the spec documents, but a single .lv2 plugin can host multiple effects with different ports and so on. - Steve Oops... seems like I'm a bit confused! Well, I'm going to reread the LV2 spec and try to figure out how to manage this kind of situations. Sorry for wasting your time! Not at all, at the very least it points out that the LV2 spec needs to be clearer, and probably needs better examples. - Steve Well, maybe it's because I'm not very good at English :-) However I have another question: how would a LV2 VST loader plugin could communicate to the host a VST plugin info? This could be done only via an extension? That's the slightly tricky part, the VST reflector would have to generate an RDF file describing all the VST plugins it knows about. That will work fine, and is not particularly difficult, but it could be made slicker with an extension that allowed the VST reflector to generate that file dynamically. Then, if I understood correctly, such LV2 VST loader plugin, when asked for effects, should return a list of all effects of all VST plugins it knows about? Yes, it can just return the URIs of all the installed VST effects as return values of the lv2_descriptor() calls. The host calls it repeatedly until it's found all the effects. - Steve
Re: [linux-audio-dev] Sample Rate Converter Comparison
On 23 Jan 2007, at 14:43, Paul Davis wrote: On Tue, 2007-01-23 at 14:31 +, John Rigg wrote: On Tue, Jan 23, 2007 at 08:53:13AM +1100, Erik de Castro Lopo wrote: Hi all, SecretRabbitCode was recently included in a test of a number of commercially available sample rate converters and while it wasn't the best, it certainly didn't disgrace itself either. The results are here: http://src.infinitewave.ca/ Don't know if it's just me, but I can't get the images to change on the web page (using Firefox 1.0.4 with javascript turned on). The only way I can look at the results is to get the URLs for individual images from the page source and type them in manually. its just you :) or rather, an early version of firefox perhaps. i have 1.5.X and it works fine here. Works fine with my 2.0.0.1 too. - Steve
Re: [linux-audio-dev] Sound processing objects architecture, is it possible?
On 23 Jan 2007, at 16:14, Stefano D'Angelo wrote: Just some last questions and I'll stop shouting and fooling around :-) This issue should also have been faced with vstserver, fst and so, but I never used them, so I'm just asking (I'm doing all of these because I'm working on a DSP program): how would a LV2 VST loader handle VST plugins with various effects, banks and programs, expecially in the case (if any and/or possible) where such plugin makes some fades when changing while playing (real-time processing)? I've no idea, you'd have to ask the authors of those other converters. Then... I see in VST docs that a getInputLatency and getOutputLatency functions are defined. I think that these could be used as extensions on a LV2 host, but such values are to be trusted under wine? LADSPA has _latency ports, I don't remember what we said for LV2. The latency should only be algorithmic, so wine should not be relevant. And what about the combination of LASH and VST storing system? Sorry, I don't know anything about the VST storing system. - Steve
Re: [linux-audio-dev] plugin loaders
On Wed, Dec 20, 2006 at 09:11:06 -0500, Paul Davis wrote: 2. We build binaries for the lowest common denominator, so the plugins you'll find in Fedora, for instance, don't take advantage of SSE hardware or instruction scheduling for different processors. This can make a huge difference. What would be nice is if we could distribute an RPM containing a plurality of plugin builds, and then have the application load the plugin matching the capabilities the execution platform. that's hard. but then again seems like its the job of a package manager to identify the correct build to install on processor foo, right? Perhaps, perhaps not. LV2 has the potential to make that easier, as plugins are in directories, which can have multiple .so files, and they can be annotated so the host can pick out the right one. They could even be cross platform that way. c.f. http://lv2plug.in/ - though the full docs for the directory format are not yet uploaded. - Steve
Re: [linux-audio-dev] Anyone else ever run a THD test on Jamin?
On Sun, Nov 05, 2006 at 06:07:33 -0500, Paul Winkler wrote: On Sun, Nov 05, 2006 at 09:44:14PM +, Dan Mills wrote: Hi all, While hacking around with aliasing effects in digital compressors (Yes it is real, yes you can hear it!), I happened to run a 10Khz sine wave into jamin with an instance of Jaaa hooked up to the output. The results were 'interesting' as it appears that jamin introduces easily measurable harmonic distortion even with all compressors and eq bypassed! Switching the master bypass in jamin however does make the effect go away. That probably an effect from the compressors, someone pointed out that there is a distortion on the falling edge of sinewaves, I've not had time to look at it. I did do THD tests on the EQ etc., but not the compressors. I haven't tried anything like that, but I did notice that listening to the low band soloed (no mids, no highs) there was some easily audible distortion that I couldn't get rid of. When turning off the solo switch, it either went away or was masked by the mids and highs. Not sure which version of JAMIN, this was early 2006 and I haven't used it lately. That's not too surprising, the solos dont really do the right thing, and you will end up with some distortion around the band changoever points. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Tue, Oct 17, 2006 at 04:43:39 +0200, Fons Adriaensen wrote: On Tue, Oct 17, 2006 at 09:59:10AM -0400, Paul Davis wrote: On Tue, 2006-10-17 at 11:56 +0200, Fons Adriaensen wrote: 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a signal when converted to the analog domain can be several dB above that of the highest sample. indeed. there are people who are coming to believe that this error is responsible for a significant part of the audible difference between digital and analog playback when the levels in the source material are high. It could be. OTOH, most DACs today would upsample and filter before the real conversion takes place, and could allow for this. But maybe they don't, and just clip at that point. I've actually measured this with an oscilloscope (because I'm that sad, and to settle an argument), and at least the DA converters I tested did respect the fact that the peak voltage was obove the INT_MAX voltage level. It was a few years ago, so I cant remember what I tested, but one thing was a yamaha digital desk. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Wed, Oct 18, 2006 at 12:48:59 +0100, Dan Mills wrote: --- John Rigg [EMAIL PROTECTED] wrote: If the control signal is derived from the upsampled input to the compressor, that is taken care of. But that puts potentially expensive gain calculations into the fast sr code, also I was rather planning on using the impulse used for the upsampler to provide the band limiting for free. the gain calculations are relativly cheap, its converting those gain levels back into a gain coefficient on the output that's expensive (from what I remember). the gain tracking is done per sample, but the cofficient calcualtion is done every 4. BEAST was the project that had the SSE 2* up/down sampler code that seems to be reasonably quick. But what interpolation function? If you something obvious and cheap you may as well not bother, as you wont get accurate peak interpolation. The API is likely to be 'interesting' as most dynamics plugs don't generate an array of gain values then apply them, and a single sample streaming resampler doesn't bear thinking about. I dont think a streaming resampler is more challenging than a correct one that runs on buffers. You just have to preserve state with every call, rather than at the buffer boundaries. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Wed, Oct 18, 2006 at 11:02:26 +0100, Dan Mills wrote: --- Steve Harris [EMAIL PROTECTED] wrote: These are aliasing artifacts in the sidechain though, right? So they will show up as modulations in the output, rather than directly audible aliasing. The last thing almost all software compressors do is something of the form output = gain * sample; It's not quite that simple. But broadly, yes, that's why I said it would be modulated by the product of the alising. Gain is in the range (0,1] so it will be amplitude modulated. The alising is present in the sidechain, right? So a filterted version of the alising will be present in the output of the gain stage. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Tue, Oct 17, 2006 at 11:56:20 +0200, Fons Adriaensen wrote: On Mon, Oct 16, 2006 at 07:48:35PM +0100, Dan Mills wrote: The gain control signal has energy right the way out to the band limit (and probably aliased around it), never mind what happens when that hits the multiplier! The question is: how much of this HF energy is there ? There shouldn't be much in a compressor with controlled attack / release times. In that case it is always possible to filter the control signal. In fact the obvious way to set attack / release times is by such filtering ! Right, the RMS envelope follower in SC* is a lowpass filter, though its only a one pole IIRC, so it wont be steep enough to kill off everything in the top end. A fast limiter needs a higher sample rate or interpolation anyway, just to detect the correct peak level. Remember that 'THE SAMPLES ARE NOT THE SIGNAL'. The real peak level of a signal when converted to the analog domain can be several dB above that of the highest sample. True enough, and infact the SWH lookahead limiter doesn't upsample. It probably should do, but it's quite expensive. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Thu, Oct 05, 2006 at 08:14:35 +0200, David Olofson wrote: On Thursday 05 October 2006 19:59, Paul Winkler wrote: On Thu, Oct 05, 2006 at 07:07:34PM +0200, Fons Adriaensen wrote: On Thu, Oct 05, 2006 at 05:12:20PM +0100, Steve Harris wrote: The SC* plugins do the same as TAP (calculate the gain every 4 samples), but I interpolate the gain values between each computation. The attch/deacay times were slow enough in my testing that it was OK to do that. It should be OK for all practical attack/release times. The only penalty is 3 samples of delay on the gain change and maybe that's to be avoided for a hard limiter. For a normal compressor it should not matter. That is what, 90 microseconds at 44.1 kHz? I don't think there are any analog compressors that react anywhere near that fast. Don't worry about it :-) I don't know how fast it *actually* is, but FWIW, my old Behringer compressor/limiter has a lowest attack setting of 0.1 ms, and a lowest release setting of 50 ms. So that would be a little iffy. SC4 only advertises that it goes down to 1.5ms, which gives something like 90 segments in the attack segment. Looking at the code, the compressors use a pretty expensive linear - dB conversion routine (cubicly interpolated lookup table) to work out the gain changes, maybe I could substitute a cheap approximation function. I'll bet that analogue compressors didn't use accurace logarithmic approximations. I'm not sure It'd be worth dropping the calcualtion period below 2 though. - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Thu, Oct 05, 2006 at 10:48:07 -0500, Andres Cabrera wrote: Hi, Here they are: www.geminiflux.com/SC1-Processed.jpg www.geminiflux.com/SC4-Processed.jpg What's that glitch near the cursor? Is that a bug, or was it in the input waveform? What immediatly strikes me as wierd is that you don't get that rippling effect in the attack, or at least it's not as pronounced. Without delving into the code too deeply, I think theres a bug, theres some interpolation factor that's calculated from the attack coefficient (ef_a), but then its later applied whether were in the attack segment or the decay segment. So actually it's not linearly interpolated, I think I was attempting to process the gain response with the envelope function. But I'm not really sure, as theres no comments in the code (bad Steve, no biscuit). - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Thu, Oct 05, 2006 at 05:29:20 +0200, Alfons Adriaensen wrote: On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote: Just to clarify the problem I'm encountering, here's a zoom in on the processed wave, exactly at the point where gain reduction starts occuring. This screenshot doesn't apply any of the methods proposed in the paper, it shows the output of the plugin. This behavior occurs for the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All processed files were saved at 32-bit floating point. www.geminiflux.com/Tap-processed.jpg [I miseed the orignal posting, but went back i the archives and found it] This is kinda interesting, but it's slightly peverse as some ofthe results can be got by looking at the source! Though it's good to confirm what the results actually are. Like Fons I'm a bit concerned about the tests, 0dB square wave in particular is worrying. The point about latency is interesting. I did consider delaying the input in the SC* plugins, but I guess that analogue compressors likly didn't have it, and they're often considered to be the best so it can't be too important. Have you measureued the systemic delay of the waves compressor to verify that it does have a delay line? - Steve
Re: [linux-audio-dev] Paper on dynamic range compression
On Thu, Oct 05, 2006 at 05:04:07 +0100, Steve Harris wrote: On Thu, Oct 05, 2006 at 05:29:20 +0200, Alfons Adriaensen wrote: On Thu, Oct 05, 2006 at 09:14:26AM -0500, Andres Cabrera wrote: Just to clarify the problem I'm encountering, here's a zoom in on the processed wave, exactly at the point where gain reduction starts occuring. This screenshot doesn't apply any of the methods proposed in the paper, it shows the output of the plugin. This behavior occurs for the Tap, SC1 and SC4 plugins in Ardour, Audacity and Rezound. All processed files were saved at 32-bit floating point. www.geminiflux.com/Tap-processed.jpg The SC* plugins do the same as TAP (calculate the gain every 4 samples), but I interpolate the gain values between each computation. The attch/deacay times were slow enough in my testing that it was OK to do that. It would be trivial to change the plugins to caclulate every sample, but at the time they were first released it made the plugin too expensive to run many at once. Things may be better on current CPUs. - Steve
Re: [linux-audio-dev] pink noise generation
On Thu, Sep 28, 2006 at 02:06:50 +0400, Andrew Gaydenko wrote: Hi! Can anybody point me to theoretical and algorithmic fundamentals of real-time (JACK-oriented) (pseudo)pink noise generation at given frequency range? Have a look at Fons Adriaensen's Jnoise: http://users.skynet.be/solaris/linuxaudio/ - Steve
Re: [linux-audio-dev] How to test resampling quality?
On Wed, Sep 27, 2006 at 11:16:27 +0100, James Courtier-Dutton wrote: Hi, I was wondering if there are any tools out there to test audio resampling quality. I am particularly interested in 44.1kHz to 48kHz resampling due to the fact that most sound cards prefer 48kHz. At least with up sampling (low rate to higher rate) one does not get aliasing. I really just want to find some algorithm that I can use to compare 44.1kHz audio signal with an 48kHz audio signal, and to see if there has been any lose of quality during the up sample. I'm not sure if it's a good technique, but to test my dithering algorithms I took high precision FFTs of the input (sine wave IIRC) and output signals and looked for extranous peaks. You can see the test code in the tarball: http://plugin.org.uk/libgdither/libgdither-0.6.tar.gz c.f. http://plugin.org.uk/libgdither/TESTING - Steve
Re: [linux-audio-dev] LADSPA preset musings
On Sun, Sep 17, 2006 at 11:22:29 +0200, Luis Garrido wrote: I have also thought of RDF/turtle as per the new LV2 spec but, if I am not mistaken, raptor doesn't write turtle and, to be honest, all this subject/predicate/object/ontology stuff seems like a bit of overkill just to store groups of (int, float) pairs, although this may change in LV2 if float is not the only type supported anymore. Raptor writes NTriples, which is a subset of Turtle. - Steve
Re: [linux-audio-dev] job offer... [Fwd: Algorithm Development Manager (Full-Time)]
On Fri, Aug 25, 2006 at 01:11:53PM -0400, Paul Davis wrote: On Fri, 2006-08-25 at 17:02 +, carmen wrote: i guess everyone has to pay the rent somehow...but do a indeed/simplyhired search for linux audio, or similar. and check out the names of the top 10 entriesSony, Avid, Qualcomm. id rather work at starbucks than give them more intellectual property :) thats pretty much what they did, in addition to sending to linux-audio- announce. i know at least 6 people who got this (and related) emails. 7. I'm not opposed to companies posting to l-a-a or l-a-d when they have relevent job openings, but this recruitment firm is spamming in my opinion. - Steve
Re: [linux-audio-dev] scaling jackinput to dbSPL
On Tue, Aug 15, 2006 at 03:30:47 +0200, conrad berhörster wrote: Hello all, Does anybody know, how i can scale the incoming jack signals to dbSPL, which is in the range of 0 to 120. An is it possible to calculate from dbFS (which is used in normal soundapp in range -inf to 12db) into dbSPL. dB SPL is a measurement of physical sound energy, so in general software was no control over it. It depends on the efficientcy of your monitors, gain of your amps, desk etc. The only way you can relate dB SPL to dB FS is by calibrating your particular setup using a sound level meter. There's a SMPTE standard for the relationship between dB SPL and dBu or dBv (I forget which), which gets you half way there, but noone uses it anyway. I had my home system calibrated to SMPTE for a while, and it was just anoying. Bob Katz advocates the K-system calibration, which is different again, and also not very common. http://www.digido.com/portal/pmodule_id=11/pmdmode=fullscreen/pageadder_page_id=59 - Steve
Re: [linux-audio-dev] LV2 and Linuxaudio.org
On Thu, Aug 10, 2006 at 12:47:11 -0400, Ivica Ico Bukvic wrote: To all involved in the LV2 project, I would greatly appreciate your feedback regarding LV2 project becoming a member of Linuxaudio.org. Provided that you decide this is a step they wish to take, it would be a good idea to nominate someone as the representative of the project within the consortium. FWIW, I think it would be a good idea. However, it's not clear that there exists an LV2 thing to be a member of anything. Perhaps the LV2 specifcation site (http://lv2plug.in/) could be a member? If there was a consensus that it was a good idea, I'd be happy to state that. Or something. Also, there could actually be a LV2 project, mailing list etc. created, theres a DAV repository at lv2plug.in, and people hack on the contents, so it does kinda make sense. - Steve
[linux-audio-dev] LV2 draft spec update
http://lv2plug.in/spec/ Some more work has been done recently, but I think I forgot to tell this mailing list. The most notable change is the inclusion of a port hint to indiciate that connections to that port are optional. This has never been a part of LADSPA, though it was discussed. It's included because it makes it possible to have plugin that can use certain port type extension, but dont require them. Eg. a plugin that can use MIDI data, but doesn't require it. If the plugin marks the MIDI port as lv2:optionalConnection then hosts can tell by inspection that it can still load and use the plugin, even if it doesn't support/want to use the MIDI extension. The LV2 spec is approaching finalisation now. We have two independent host impletmentions, and several that share some code, there are lots of plugins, some using extensions and some using vanialla LV2. If people want to comment opn the late drafts now would be a good time, as I imagine that the final spec will look a lot like whats there unless people find problems. - Steve
Re: [linux-audio-dev] LV2 draft spec update
On Wed, Aug 09, 2006 at 11:10:07AM +0100, Jono Bacon wrote: On 8/9/06, Steve Harris [EMAIL PROTECTED] wrote: The LV2 spec is approaching finalisation now. We have two independent host impletmentions, and several that share some code, there are lots of plugins, some using extensions and some using vanialla LV2. If people want to comment opn the late drafts now would be a good time, as I imagine that the final spec will look a lot like whats there unless people find problems. Is there a way to categorise LV2 plug-ins? The problem with LADSPA is that there is one huge list and it should really be divided into sections. Maybe have the equivilent of a .desktop file for each plug-in? Yes, but that feature was also in a LADSPA extension called LRDF, some hosts make use of use it, eg. jack-rack. If you look in /usr/share/ladspa/rdf/ and /usr/local/share/ladspa/rdf/ you should see the category data. - Steve
Re: [linux-audio-dev] LV2 draft spec update
On Wed, Aug 09, 2006 at 12:57:24 -0400, Ivica Ico Bukvic wrote: The LV2 spec is approaching finalisation now. We have two independent host impletmentions, and several that share some code, there are lots of plugins, some using extensions and some using vanialla LV2. If people want to comment opn the late drafts now would be a good time, as I imagine that the final spec will look a lot like whats there unless people find problems. Excellent work! FWIW, I think it would be really nice if we got LV2 also as a member of the consortium. Sure, no problem. It's not relly a project in the normal sense, but I guess it makes sense. - Steve
Re: [linux-audio-dev] Are people still writing LADSPA plug-ins?
It might be better to have a planet for linux audio in general, Dave Phillip's blog is allready in my RSS reader. LV2 is in the last 10% stage, I meant to mail out an update after the ast batch of work Dave Robillard and I did, but I think I forgot, and I can't remember what we did now... There are now 3 hosts (2 built on libslv2, and 1 independent), and many plugins that more-or-less work, the plugins dont work on Mac OSX (at least I couldn't get them to work), but mostly do on linux. - Steve On Tue, Aug 08, 2006 at 10:15:28 +0100, Jono Bacon wrote: Hi all, Thanks for the responses. It seems that the public face of LADSPA is maybe a little different to the reality - I remember first reading about LADSPA and thinking that there was not all that much going on with it, but I am pleased to see people are working on plugins. I think it could be useful to improve the face of LADSPA and spread the word of LV2. Would any LADSPA plug-in authors be interested in writing blogs about their work with LADSPA? If this was the case, maybe there could be a Planet LADSPA that would bring together such bog entries? Planets have been really useful in spreading the word about certain technologies, and they are a great way to get more people reading your blog. I don't know how many times I have asked a question on my blog and got 15 responses as it is on Planet GNOME, Planet Advocacy and a few others. Maybe then we would have more and more people writing plugins. :) Thoughts? Jono
Re: [linux-audio-dev] light C++ set for WAV
On Wed, Jul 26, 2006 at 09:02:31 +1000, Erik de Castro Lopo wrote: Mmm. For what it's worth, I write mostly C++ but have no problem with using the libsndfile C API. Most people who really know C++ know enough to be comfortable with pure C. I'm pretty sure you fall into this category. However, I do get emails from some of the more clueless Windiots complaining that libsndfile is written in old-fashioned C instead of nice shiny modern C++. IMNSHO these people should not be allowed anywhere near a language as complex, subtle, and unforgiving as C++ (or for that matter as unforgiving as C). Heh, I get that from UNIX people too though, I always assumed they were trying to wind me up... - Steve
Re: [linux-audio-dev] Popular LADSPA plug-ins to depend on?
On Wed, Jul 26, 2006 at 03:41:24PM +0200, Richard Spindler wrote: 2006/7/26, Thorsten Wilms [EMAIL PROTECTED]: You should not depend on particular plugins, if the app could work without just fine. Hasn't Debian a 'Recommends' thing going for things like this? Doesn't JAMin need the SWH Plugins for it's equalizer and stuff? Therefore it seems as if it's dependent on these plugins. Yes, it does. So it shouldn't be a problem for Jokosher to take the same approach. Sure. It's better than code duplication in my opinion. - Steve
Re: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Fri, Jul 21, 2006 at 01:13:43 +0100, [EMAIL PROTECTED] wrote: On Fri, 21 Jul, 2006 at 09:39AM +1000, Loki Davison spake thus: On 7/21/06, Stephen Sinclair [EMAIL PROTECTED] wrote: ... For music/audio stuff you can do the dsp stuff with c and then communicate with another process written in a higher level language, i.e python over OSC. The LAD irc crew have been discussing using this idea for a new sequencer/daw thing. And I've been doing it with a small sample player. It works nicely and means I don't have to deal with UI crud in C (nightmare!). SooperLooper (http://essej.net/sooperlooper/) works that way and has done for some time. Some added bonuses are that your backend is inherantly scriptable from other environments, and it pretty much forces you to adopt a MVC UI coding model. - Steve
Re: [linux-audio-dev] Re: Language fanboys [was Re: light C++ set for WAV]
On Thu, Jul 20, 2006 at 09:51:05 -0700, Thomas Vecchione wrote: ??? Non realtime style? How can you have a gui written in a real time style? Doesn't that kind of break the basic rules of realtime? Well that is my question, sorry I should have clarified I am just now getting into realtime programming so this might be a really stupid question anyways. If you dont have the GUI thread(s) running at a high priority, would that affect the overall response of the program? Primarily I am looking at for triggering sound effects samples(Of varying size) for live performance, thus I would need to make sure response to the gui is also quick and that latency is not added in from the time of hitting a go on screen. The extent of that kind of latency is not quite so critical as processing latency. What is important however is that the latency is constant, jitter is quite obvious. Humans are able to correct for reasonably high constant latency between actions and the sound happening. MIDI latency is typically 1ms or so, and that's generally not a issue. Getting lower than that in a UI + OSC connection is no problem. In any case, it's not a good idea to run GUI theads at high priority as they often have to do actions which require a significant ammount of wall-clock time. If your thinking of using a UDPish protocol, please use OSC. The packet format is a bit of a pig, but there are plenty of libraries that make it easy (eg. http://liblo.sourceforge.net/) it means other peoples software can interoperate with yours. It will also save you a lot of time in debugging annoying network I/O issues and platform dependencies. - Steve
Re: [linux-audio-dev] LV2 Turtle requirement
On Sun, Jul 16, 2006 at 05:38:15PM +, carmen wrote: On Sun Jul 16, 2006 at 07:35:19PM +0200, Lars Luthman wrote: On Sun, 2006-07-16 at 17:28 +, carmen wrote: i notice this file: http://lv2plug.in/spec/lv2.ttl is in the nicely readable turtle format. my main question is, whether this will be transformed to RDF-XML during 'make install' or perhaps by the developer themselves (Eg, similar to leaving a configure script around for those who dont have autoconf). I hope not - I've already written a host that parses Turtle and only Turtle. you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. I've never heard of Fresnel, but Protege can read N3, which is a superset of Turtle. There's some pretty strong anti-XML feeling in this community, and Turtle was less contraversial all round. Personally I prefer reading and writing Turtle to RDF/XML, which is pretty hideous. If your tool of choice can't read Turtle directly, just use something like rapper to turn it into RDF/XML first. - Steve
Re: [linux-audio-dev] LV2 Turtle requirement
On Sun, Jul 16, 2006 at 05:52:15PM +, carmen wrote: you hope not what? it just seems like Turtle should be developers choice, and the format in the .bundle should be more standard - even Firefox can parse RDF/XML out of the box. the vast majority of the cool tools like Fresnel/Protoge that some develoeprs might want to edit their schemas in, don't support Turtle as well, AFAIK.. my main issue is the only RDF toolkit in Portage didnt properly include Turtle parsing. which means theres an even slimmer chance of such things existing in Debian, Fedora, etc. now i must investigate why this is the case.. on top of that, a lot of the ideas wrt interactive documentation (eg wiki-style annotations of what ports actually do, user presets, etc) on the web would be easier since RDF/XML is readily embeddable into XHTML. throwing a 'raptor blahblah.ttl blahblah.xml' in a SConstruct is praobly easier than having to continually think about it on the server side (eg in PHP) or in JavaScript.. You can't easily embed RDF/XML into XHTML, you can use RDF/A or GRDDL, but that's different. You can apply the same conversion argument just as well the other way round. I have some PHP scripts that conneg LV2 turtle files into HTML (still very primitive) or RDF/XML as required, it's not exactly hard. - Steve
Re: [linux-audio-dev] Re: Hello and Python bindings for LADSPA
On Sun, Jul 16, 2006 at 03:38:59PM +0100, Jono Bacon wrote: Hi Lars, It does just work, you just get generic GUIs instead of plugin-specific ones. But surely the GUI is bound to a certain list of plugins. So, when we get LADSPA support in Jokosher, because we need to make the GUI for the plugins, we need to basically decide on a list of included plugins and create the GUIs. Surely this limits the ability for the user to just install a plugin pack as we won't have GUI for those plugins? Correct me if I am wrong on this, I am still very new around here. :P Oh, and I read that someone was working on an XML DTD for plugin GUIs - what is the current progress on this? I could not find anything out about it on the LADSPA site. It has been proposed several times, but it's not a particularly good idea IMHO. I was in favour of it for a bit. - Steve
Re: [linux-audio-dev] light C++ set for WAV
On Thu, Jul 13, 2006 at 05:16:01 -0400, Paul Davis wrote: On Fri, 2006-07-14 at 06:48 +1000, Erik de Castro Lopo wrote: but I am not a fan nor a great user of C++. The wrapper should really be written by someone with a love for the language. LOL! that's pretty great. not a fan translates in real world terms into one of LAD's most persistent critics of almost every aspect of C+ + :)) rock on erik, we love you anyway! Dammit, I feel insulted ;) Though, having just part-written a huge database engine in C I am feeling warm thoughts about ObjectiveC, which maybe makes me a traitor to the cause. Go Ocaml though. - Steve
Re: [linux-audio-dev] memory-mapped wav files
On Fri, Jul 14, 2006 at 12:06:23 +0100, [EMAIL PROTECTED] wrote: On Thu, 13 Jul, 2006 at 04:45PM -0400, Stephen Sinclair spake thus: A thought occured to me recently... If I am writing an application which needs to stream a large wav file, I am having to write something which reserves some memory, and loads pieces of the wav file from disk on request. Say I need to be able to jump around the file a bit, I would have to detect when the piece is not available and load it in as appropriate. ... which I realized is exactly what the OS VM paging system does. So, has anyone tried using memory-mapped files for streaming audio data? (obviously, I mean, in a non-realtime thread, using a buffer). Or would this be totally inefficient? I was thinking it could really simplify programming, just directly accessing parts of the wav file as needed, and letting the OS load it up into physical memory when it wants to. It's perfectly sensible. I do it a lot, because it's easy. The problem is having to load the whole thing into memory before you start, which makes things alow to start. If you're playing linearly, to solve this, you need can load it in chunks and start playing the first chunk straight away. mmap-ing doesn't epxlicitly load the whole file, just bits as you request them. I wrote an app on linux that accesses large files (1-4 GB) this way recently, and the performance was certainly no worse than buffered read()s. It is very convienient, but there are some gotchas, especailly on 32bit machines where you will run out of address space really quickly. Also, my feeling is that linux is a bit conservative about how much ram it will use to map the file, though there is a hinting mechanism you can use to say what you want that mmaped region for. It's madvise(2) on Linux and BSD. I'd second what Erik said though, for audio file i/o, use a library. The ammount of i/o is really tiny, so overoptimising it is silly. - Steve
Re: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 04:21:20 -0400, Dave Robillard wrote: It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff modulation input then I want it to modulate up and down by N octaves, not N Hz, frequency-linearly symmetric modulations sound wrong. My favourite (digital) modular filters have a centre frequnecy (shown in Hz, expoentialy scaled control) and a modulation input that modulates in octaves. You want the modulation to be musically relevent, and the most musically useful unit for pitch is octaves :) Humans aren't SI sadly. I agree that describing it as volts is a bit odd, but it instantly makes people like me feel at home. There's not reason why a digital modular neds units for its modulation sources. It's just real numbers. This is true, but there are other cases when you want a real, meaningful frequency to do something with (using the same plugin). Eg lowpass all frequencies above 800Hz. Someone working on a DAW definitely doesn't want to deal with this meaningless V/Oct unit. That's why I said you have a centre frequency control, that's set in Hz. Of course, in a modular you can convert Hz frequencies to VOct frequencies, and in a DAW you can convert VOct frequencies to Hz, but in both cases it's a user nuisance, so it needs to be automatic. My gripe isn't with the unit itself, so much as in the current situation with LADSPA it's a really, really huge PITA to have a mess of twisty little units, all alike. Yes, but neccesary, unless your hosts all understand the semantics of pitch/frequency and are willing to do lots of pow() based conversions. Of course LV2 will let us solve this, and the frequency unit can in both cases be kept entirely transparent by the host (if you want), making the actual unit used by a plugin just an optimization as it should be (skipping the conversion step). s/will/could/, I'm not yet convinced that it's appropriate. My preference would still be for a Hz centre control and a (high rate) modulation input. If there's a sane representation in RDF for a single port to do both things well, then I'm all for it, but I'm scpetical. - Steve
Re: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 11:40:53 +0200, Fons Adriaensen wrote: On Sun, Jun 25, 2006 at 06:57:47PM +0100, Steve Harris wrote: I agree that describing it as volts is a bit odd, but it instantly makes people like me feel at home. There's not reason why a digital modular neds units for its modulation sources. It's just real numbers. I never mentioned 'volts'. Sorry, that was Dave then. I still feel at home with v/octave though :) - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: Basically all you've added is port grouping. Sure, there's no binary breakage now - no kidding, you havn't had to change anything yet. All you've done is added a bunch of metadata that has no reason to be in binary code at all, but you've done it in a way that's going to break horribly as soon as you try to add something. No, it also adds rendering of port values. Though that is somewhat limited. Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. - Steve
Re: [Freebob-devel] [linux-audio-dev] ieee1394 deadlock on RT kernels
On Mon, Jun 26, 2006 at 10:11:30 +0200, Pieter Palmers wrote: Can we see the kernel panic message? ;-) no :p. I'm sorry for being a jerk, but I'm not going to type over that message just so that you can confirm that it indeed is a 'soft lockup' (or whatever it is called exactly) and that it occurs in the ohci1394_iso_unregister_tasklet. You'll have to take my word on it. If you need some specific part of the kernel message, you can get it. Tell me what you wqant and why, that way I can learn something from it. Was it not written to /var/log/messages? - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote: On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). True enough, but with POL if the frontend and backend mahcines are different architectures or operating systems then you have a problem. - Steve
Re: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 02:01:48 -0400, Dave Robillard wrote: On Tue, 2006-06-20 at 08:35 +0100, Steve Harris wrote: On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: Because people actually use them in Om, because people actually use Om unlike certain other modulars. volt per octave is pretty damn obscure in a computer program If i wanted to have a cutoff at concert A what the hell is that in volts per octave?S Zero typically. I have to take issue with this, 1.0f per octave is the natural way to preresent things like filter cutoff in a modular. It's what makes the great modular systems so easy to work with. Nonsense. As a numerical unit it has no meaning whatsoever, and the unit actually used has no bearing on the user interface provided (which should of course be exponential). It has a very specific meaning, +1.0 is +1.0 octaves. The only sane unit for frequency is Hz. As Loki said, if I want a cutoff at concert A, I (like any musician) know that's 440Hz. Whatever arbitrary ugly real number it is in V/Oct As Defined By AMS is not something I or anyone else cares to know. Any table of frequencies, or math app, or damn near _anything_ that deals with frequencies will present it in Hz. If you can come up with a real reason why this arbitrary AMS V/Oct makes any sense in a _digital_ modular, I'd like to hear it. It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff modulation input then I want it to modulate up and down by N octaves, not N Hz, frequency-linearly symmetric modulations sound wrong. My favourite (digital) modular filters have a centre frequnecy (shown in Hz, expoentialy scaled control) and a modulation input that modulates in octaves. You want the modulation to be musically relevent, and the most musically useful unit for pitch is octaves :) Humans aren't SI sadly. I agree that describing it as volts is a bit odd, but it instantly makes people like me feel at home. There's not reason why a digital modular neds units for its modulation sources. It's just real numbers. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Tue, Jun 20, 2006 at 12:57:43 +0200, Fons Adriaensen wrote: :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. I hope you dont have that impression, LV2 is not finalised, I tried to make sure I had draft and provisional in the text, but I guess I wasn't sufficiently clear, it is very much still up for discussion. My feeling is that it is somewhere around the Last Call stage in W3C speak. l-a-d fortunatly not having a formal standards process ;) Also, the units stuff I alluded to obove is not, and will not be part of the LV2 1.0 spec, it will come soon after and live as an extension. My plan was to crib from the scientific communities work on representing unit values in RDF, write an early draft and post it here. It is somewhat orthogonal to LV2 itsself, so if someone else with more time feels motivated to work on it, please do. The situation with LV2 is that I have ported most of my LADSPA plugins (to verify there were no blatant problems) to a version of the draft, and we now have 2-3 partial host implementations of the current draft. That doesn't cover the requirements of reference implementations to my satisfaction. So, just to be clear, nothing has been decided. The purpose of the website it to encourage discussion. - Steve
Re: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote: Because people actually use them in Om, because people actually use Om unlike certain other modulars. volt per octave is pretty damn obscure in a computer program If i wanted to have a cutoff at concert A what the hell is that in volts per octave?S Zero typically. I have to take issue with this, 1.0f per octave is the natural way to preresent things like filter cutoff in a modular. It's what makes the great modular systems so easy to work with. - Steve
[linux-audio-dev] LV2 update
There's been little news on the LV2 front here recently, all the disucssion seems to have taken place on IRC, so a quick update: Theres now a website: http://lv2plug.in/ as of a couple od days ago, thanks to Thorsten Wilms which has links to drafts of the C header file and RDF/Turtle schema. Please read the formal specs and comment. Following discussion on the l-a-u list and hard work by a lot of people there's a logo. Please don't discuss the logo except to praise it ;) choosing one was quite involved. Various generic forms (black on white etc.) will be availble on the website in due course. TODO list: * Finalise the technical aspect of the spec, get interested parties to confirm that it meets thier needs (or at least doesn't prevent them). * Write human language specification to go with .h and .ttl explaining how to use the spec, conventions etc. * Make sure there's a reasonable set of reference implementations and examples. * Test the extension mechanisms. * Publish final spec, have tea and cakes etc. - Steve
[linux-audio-dev] LV2 plugin porting experience
I thought it might be of interest to other plugin developers to learn what my experiences were of porting my LADSPA plugins to the LV2 draft. As some of you may know the primary source for my plugins is a wierd XML format, so porting that was fiddly, but didn't involve much manual effort, just coding a handful of XSLT sheets. However I ported a couple by hand to get a feel for it, and basically it comes down to deleting the constants and runAdding method from the ladspa .c file, sedding some struct names and replacing occurances of LADSPA_Data with float (except the last argument to connectPort, which is a void *). It may be possible to do it automatically with a cpp/m4 hack, or a perl script or something, but I doubt its worth the effort. Writing the turtle is a little more involved, but I'm sure some enterprising person can write a program to generate .ttl from existing LADSPA .so's, then it will be a case of adding any additional data you want to express by hand. Writing the Makefile was pretty tricky, as the plugin data and code all ends up in a plugin directory, but it wasn't too bad once I figured out how best to layout the source. I decided not to use automake/autoonf/ ibtool as I felt it caused more probems than it solved with LADSPA. The Makefile would have been less critical if I didn't have quite so many plugins; I didn't want to recurse into every plugin directory, which is the obvious thing to do. - Steve
Re: [linux-audio-dev] LV2 update
On Tue, Jun 20, 2006 at 09:39:30 -0400, Dave Robillard wrote: I can make the plugin validating host check the latency primitively (eg run a single sample through the buffer) and fail if it isn't reported correctly, so we're sure the LADSPA latency woes are gone. What if it's a delay line? I think you have to reply on the concience of plugin programmers to get it right. - Steve
Re: [linux-audio-dev] LV2 update
On Tue, Jun 20, 2006 at 02:46:37 -0400, Dave Robillard wrote: Let's just standardize an extension for latency ports after the release of LV2. And let's do it FAST, so that most plugin writers will be porting their plugins with the extension in place. I think this should be included in the spec, since it's devastating when plugins don't adhere. I believe Steve agrees with me (Steve?) It doesnt need to be an extension really, as it was common practice in LADSPA, just pick a URI for the hint and put it in the schema. lv2:latencySamples anyone? - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 06:03:43 +1000, [EMAIL PROTECTED] wrote: Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a describe_value function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return SAW, SIN, SQR etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return -4 semitones This is handled in LADSPA+RDF and LV2 (aka LADSPA2) using scalePoints, eg. http://lv2plug.in/plugins/Amp-example.lv2/amp.ttl, search for lv2:scalePoint. That one's a silly example, but it makes the point. Things like -4 semitones will be handled by a units extensions, which will also allow hosts to use things like native gain control sliders for decibel ports, and BBT controls for time inputs. This idea is better in some ways, though though overall I prefer doing it though description, rather than programatically. - Steve
Re: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 08:44:25 +0200, Fons Adriaensen wrote: All this doesn't change the fact that the rationale I commented on *is* fake, whatever the qualities of LV2 (which I do not even deny). I dont agree that it's fake per se, but I do think it was overstated. It can be /difficult/ to maintain binary compatibility, but it is rarely impossible, unless a really bad design decisision was taken.. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 01:55:27PM -0400, Dave Robillard wrote: API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. The provisional LV2 spec is at http://lv2pluig.in/ it could do with some human language text explaining the technical parts, not just C and RDFS, but I think theres enough there to make sense of it. FWIW, I think the not changing any code thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to understand the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote: On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote: FWIW, I think the not changing any code thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to understand the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. What worries me is that LV2 is *not* going to solve the problem that DR raised w.r.t. my Moog filter plugins. This particualr one I'm not worried about, as it's a know one, its all the subtle things noones realised yet, something like a plugin that does its delay in 24ths of a beat or something. IIRC the control law is : f = pow (2, v) * frequency_of_middle_C or some such, where v is the parameter value. So the relation v-f is *exponential* (not logarithmic). Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. So how are we going to tell this to the host ? I'm sure LV2 can _represent_ all of this, but representation is not the same as meaning. For the host to understand it, either - it has a degree in music science and DSP, - the meaning of the tags used is predefined by some standard. Or both if you really mess up :) The latter is missing, and once it is defined the need for an 'open' representation format no longer exists. That's more-or-less true, but you can apply that argument repeatedly forever. I have many plugins that I would prefer to work this way, but LADSPA makes it tricky if you want to interoperate with most hosts. Consequenctly, I have given it some though. The representation I was thinking of was something like: :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. Some organic chemists use an RDF schema that expresses conversions bewteen crazy chemical units, but I think its overkill for crazy DSP units. We only really care about frequency[/time] and ampltiude anyway ;) - Steve
Re: [linux-audio-dev] Writing a winner takes it all gain filter.
On Fri, Jun 16, 2006 at 11:44:57 -0700, Kjetil S. Matheussen wrote: I suggest that you rewrite the comment about snd. Writing lispish, yuck doesn't give you much credit as someone worth listening to. Hum. It's maybe not tactfuly expressed, but the s-expression syntax has a number of objectors with informed positions. It is near one end of a broad spectrum of languages so inevitably not to everyones taste. - Steve
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Thu, Jun 15, 2006 at 09:19:35 -0400, Paul Winkler wrote: On Wed, Jun 14, 2006 at 10:26:15AM -0700, lazzaro wrote: There are, of course, languages like SuperCollider and CSound, which ARE made for expressing audio algorithms. However, again they are generally interpreted. Sfront compiles a high-level music language (Structured Audio) to C, and there's no reason in theory that audio drivers couldn't be written for LADSPA. I remember asking you about this a couple years ago and you said it could be done, but you could only run one plugin instance at a time... .is that still the case? or am I misremembering? And, is all the sfront / saol action happening somewhere that I'm not aware of? I was always disappointed that there didn't seem to be a lively community around saol. Yes, me too, I wrote some code in sfront and liked it, I even went as far as figuring out what needed to be done to remove the globals that prevented you from running more that one plugin at once, but never did the coding. - Steve
Re: [linux-audio-dev] Writing LADSPA plugins in high level language?
On Wed, Jun 14, 2006 at 04:20:42PM +0200, stefan kersten wrote: On Wed, Jun 14, 2006 at 02:09:33AM -0400, Lee Revell wrote: How do you do realtime in an interpreted language? How can you guarantee the interpreter won't do something that's not RT safe during a critical section? by properly designing the interpreter? You sped a lot of your time when your writing plugins shaving a few cycles of work here and there to make things more efficient, introducing an intepreter into the mix just makes that a lot harder. When people think they want a VM or interpreter they often want garbage collection, generally garbage collection is not relatime safe. There are relatime garbage collectors, but they're not common and they're extremly complicated. Given that (Objective) C(++) has the best math libraries, debugging tools and is very efficient I dont see any reason for using any other general purpose language. Faust is another matter however. FWIW, you can compile Matlab into C, but actually Matlab/Octave is not that appropriate for writing plugins as it's designed and optimised for complete matricies, not rolling buffers. - Steve
Re: [linux-audio-dev] LV2 library API
On Tue, May 30, 2006 at 03:09:33 -0400, Dave Robillard wrote:
I'm a bit unhappy that it makes code longer and more messy though. The
primary design goal here is to make host code as terse and simple as
possible. strcmp'ing a string and then freeing it is quite a bit uglier
than just testing an enum val :/
This is maybe a PITA, but what about a runtime provided enum list, like:
foo_enum = { { FOO_FLOAT, LV2_FLOAT_URI },
{ FOO_MIDI, http://example.org/datatypes/midi; },
{ 0, NULL } };
lv2_set_urilist(foo_enum);
the library can contain an builtin enum list that is set implictly, ie. it
does lv2_set_urilist(lv2_internal_enum); when it starts.
that way simple hosts can just use it as is, and more complex ones can
specify the types they support, and everyone gets to use ints.
- Steve
Re: [linux-audio-dev] LV2 library API
On Tue, May 30, 2006 at 11:43:57AM -0400, Dave Robillard wrote: The problem with returning strings is namespace prefixes. It's all fine if the type is in the lv2: namespace so it can return something nice like lv2:float, but if it's something else it will have to return the fully qualified URI. For consistency's sake I'll have to return the full URI for everything. Returning QNames is bad mojo. I think what I'll do is have the type function return a full URI, but #define symbols for the builtin port types (which is easily extensible without breaking anything). Something like: char* type = lv2_port_get_type(someplug, 0); if (!strcmp(type, LV2_DATATYPE_FLOAT)) /* ... */ free(type); Makes sense to me. You could make the API (optionally?) take a char * to write the result into to avoid a lot of malloc() and free()s, but I doublt it's a worthwhile saving. - Steve
Re: [linux-audio-dev] This weeks changes to LV2 (née LADSPA2) strawman examples
On Wed, May 10, 2006 at 01:46:38 -0400, Dave Robillard wrote: On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: http://plugin.org.uk/ladspa2/ Changed name of the port shortname property to symbol, which hopefully implies more the right thing. Added Rate before Control and Audio port names to hopefully make thier menaing clearer for people who may not come from a LADSPA background. This is just fiddling really, so I think it's starting to settle down. To say this is a nitpick is an understatement, but I like ladspa:ControlRateInputPort over ladspa:InputControlRatePort. More normal and englishey. If you send me a patch to the schema I'l apply it and fix the amp. Youre right, it looks better. - Steve
Re: [linux-audio-dev] This weeks changes to LV2 (née LADSPA2) strawman examples
On Thu, May 11, 2006 at 01:59:12 -0400, Dave Robillard wrote: On Wed, 2006-05-10 at 10:12 +0100, Steve Harris wrote: http://plugin.org.uk/ladspa2/ Changed name of the port shortname property to symbol, which hopefully implies more the right thing. Added Rate before Control and Audio port names to hopefully make thier menaing clearer for people who may not come from a LADSPA background. This is just fiddling really, so I think it's starting to settle down. (I've got a working Jack host that successfully runs the example Amp plugin on Jack audio) Couple of things that need fixing: - Typo in amp.ttl line 61: ladspa:OuputAudioRatePort - ladspa:OutputAudioRatePortX Thanks, done. - I think ladspa:scalePoint (while a good idea) shouldn't be in the spec as it's a new feature. It belongs in the (discussed) units extension. It's not actually a new feature, it was present in LADSPA RDF descriptions: http://plugin.org.uk/ladspa-swh/metadata/swh-scales.rdf and liblrdf. I don't think it's related to units as it deals in numerical port values, rather than real-world values. But that's splitting semantic hairs. The same goes for the classification stuff, which was the main reason users wanted RDF support from hosts for LADSPA, AFAICT. - Steve
[linux-audio-dev] This weeks changes to LV2 (née LADSPA2) strawman examples
http://plugin.org.uk/ladspa2/ Changed name of the port shortname property to symbol, which hopefully implies more the right thing. Added Rate before Control and Audio port names to hopefully make thier menaing clearer for people who may not come from a LADSPA background. This is just fiddling really, so I think it's starting to settle down. - Steve
Re: [linux-audio-dev] LADSPA 2 name
On Wed, May 10, 2006 at 07:12:33 +0200, Esben Stien wrote: Steve Harris [EMAIL PROTECTED] writes: LV2 What happened to the funny recursive acronyms?;). That they don't show up in a google search don't hold water; f.ex a search for JACK get you.. our beloved, sacred one. They seem to be too much a matter of taste, and/or have negative connotations in various languages. Trying to get everyone to agree on one is just too much effort. Feel free to try and get consensus on a word-like name, but I've lost all enthusiasm for it. I think it's telling that the hardest part of this whole process has been choosing a name, classic colour of the bikeshed problem. You can argue that the name is important, but we've been happily using LADSPA for years, and that's terrible by alomost any metric. I've started using the name LV2 myself, if it doesn't annoy me within a week or so, and no-one comes up with a sensible objection it will probably become permenant. So, if you really hate it speak up now. Nothing beats daves' PEEP in any case..;) Someone was allready using it for a free software project, and it's visually too close to BEEP which is a widely used protocol library. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote: On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote: Is there some equivalent mechanism that lets dlloaded plugins dig function pointers out of the the host? Thier public symbol linking system is backward too from what I remember. one portable way is to pass a struct of function pointers filled by the host to the plugin initialization function, as done in the SuperCollider server plugin API. That doesn't really help for extensions. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Wed, May 10, 2006 at 03:15:25PM +0200, Lars Luthman wrote:
On Wed, 2006-05-10 at 13:22 +0100, Steve Harris wrote:
On Wed, May 10, 2006 at 01:42:16PM +0200, stefan kersten wrote:
On Mon, May 08, 2006 at 09:07:48AM +0100, Steve Harris wrote:
Is there some equivalent mechanism that lets dlloaded
plugins dig function pointers out of the the host? Thier
public symbol linking system is backward too from what I
remember.
one portable way is to pass a struct of function pointers
filled by the host to the plugin initialization function, as
done in the SuperCollider server plugin API.
That doesn't really help for extensions.
It does if the struct looks like this:
struct ExtensionFunctions {
struct {
const char* extension_uri;
void* function_pointer;
}* null_terminated_function_array;
};
OK, true, but anyway I want to avoid anything that complex until we have a
real need for it. To avoid specing anything that's not quite fit for
purpose.
- Steve
Re: [linux-audio-dev] LADSPA 2 name
On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote: LAMA - Linux(Libre) Audio Modules Architecture I hope The Dalai Lama will not object. Good name, but theres a well known VST plugin called Delay Lama. - Steve
Re: [linux-audio-dev] LADSPA2 naming redux
On Sun, May 07, 2006 at 09:26:00AM +0200, Jens M Andreasen wrote: On Fri, 2006-05-05 at 21:04 +0200, Leonard paniq Ritter wrote: On Thu, 2006-05-04 at 09:11 +0100, Steve Harris wrote: Before anyone suggests it, FreePod is a piece of windows malware amongst other things :) following this thread for quite a while i conclude that it is impossible to find a name that sounds good and does _not_ mean anything. do something irrational please. :) Something new that is still very much like the old, but with only 3 or 4 letters? By dropping the 'A' in LADSPA it could become LDSP (ell-dis-pea) There was a yamaha preverb processor called an LDSP, I dont know if its still current though. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Mon, May 08, 2006 at 07:32:06 +0200, [EMAIL PROTECTED] wrote: I mean the linker should do it. If you dynamically build the plugin against a stub library and the host exports something with the same ABI, I /think/ the plugin should have the host's version of the function in its namespace. this is not TRUE on windows. otherwise yes. Ah, well thats kind of important. I understand that Windows is quite popular in some places? ;) Is there some equivalent mechanism that lets dlloaded plugins dig function pointers out of the the host? Thier public symbol linking system is backward too from what I remember. I don't think theres any reason to stop Windows users being able to share the love, should they so choose. I used to get a lot of mail asking for advice on how to compile my plugins on Windows until I put a note on the website saying I couldn't help. - Steve
Re: [linux-audio-dev] LADSPA2 naming redux
On Wed, May 03, 2006 at 09:38:28 -0400, Dave Robillard wrote: Before further discussing the name Pod, please have a look at www.line6.com/products/pods/ . There is a whole family of FX processors for guitar and bass under the registered trademark POD, and these devices are well known and widely used. So it´s probably not a good idea to name a software effects collection Pod. This is a good point. The POD line is _VERY_ well known, and given that plugins can be effects or guitar amp models etc (ie the domain is similar) I wouldn't be surprised if Line6's lawyers had something to say about it once they find out. Indeed. When I first googled it if didn't seem that close (amp sim hardware v's a software bundle format), but after sleeping on it I think it's much too close in function. - Steve
Re: [linux-audio-dev] LADSPA2 naming redux
On Thu, May 04, 2006 at 08:57:54 +0700, Patrick Shirkey wrote: Dave Robillard wrote: This is a good point. The POD line is _VERY_ well known, and given that plugins can be effects or guitar amp models etc (ie the domain is similar) I wouldn't be surprised if Line6's lawyers had something to say about it once they find out. -DR- OPOD - Open POD The file extensions could be .opd I had a very very similar idea: OpenPOD, OPOD being a non-cannonical abbreviation, extension .opod. By my own metric is level 3/0 crapness :) There are a bunch of openpod/oped things, none of them are relevant though (I expexted a bunch of mp3 player related stuff, but no). Openpod.org is a free software news site. Because it's $word$word we'd have to go for a slightly crap TLD. I think I like it, but it's not ultra-stellar-fantastic. Before anyone suggests it, FreePod is a piece of windows malware amongst other things :) - Steve
[linux-audio-dev] LADSPA2 naming redux
Richard's preferred name of PEA (AKA anything that's not LADSPA2) got me to thinking. What about abstracting it up one level and calling the directory + .so files + manifest thing a POD (Plugin Object and Description). Theres nothing particularly audio specific about the high level construct, its just that we don't have a concrete ABI for dealing with sills, video etc. This means that what we think of as a LADSPA2 plugin would be a LADSPA POD. The directory would have a .pod extension. POD seems like a nice word to me, plenty of scope for puns, short and pod plugin on google doesn't come up with anything much. The only audio related things for pod I could see are: a guitar effects processor called a PODxt (there was a POD historically), an audio I/O device called a Firepod, and the documentation for the LADSPA Perl module. Perl docs are the only non-coincidental hits for LADSPA POD. I could juggle the description stuff around the seperate pod-ness from ladspa-ness, it's not hard, but also not neccesary. There is a small name clash with Perl, which uses .pod for it's documentation format, but I dont think that's really an issue, our .pods will be found in POD_PATH (eg. /usr/lib/pod/, ~/.pod/) and be will be directories. Thoughts? - Steve
Re: [linux-audio-dev] LADSPA2: logarithmic hint
On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis wrote: On Tue, 2006-05-02 at 17:57 +0200, Alfons Adriaensen wrote: I can't imagine any sane interface standard for audio controls without a way to say that the natural way to represent a port's range is exponential. saying that the port range is exponential doesn't pin it down very much. it still requires the host to make decisions about precisely what kind of exponential curve to use for the range, and it may get it wrong. The type is irrelevant, the problem is that what I generally want to say is this goes from 0Hz to fs/2Hz, and I want it to be logarithmic, but you can't say that literally, so you have to say this goes from fs/1Hz to fs/2Hz, which tends to make the bottom value a bit random. I don't know what the correct solution is, possibly just providing a rule for the host to caluculate what it should use instead of log(0) is enough, but I'm not sure what the rule should be. The reason why it gets them wrong is probably because the code handling defaults is something like 10 times more complicated than it need be. care to suggest a simpler approach? LADSPA defaults are broken, and hopefully not relevant. - Steve
Re: [linux-audio-dev] LADSPA2: logarithmic hint
On Tue, May 02, 2006 at 07:21:31 +0200, fons adriaensen wrote: On Tue, May 02, 2006 at 05:21:44PM +0100, Steve Harris wrote: this goes from 0Hz to fs/2Hz, and I want it to be logarithmic, That's a contradiction. Yes, quite, but the only other option is to express it as a fraction of the sample rate, or an absolute value at both ends, neither of which is right. The plugin can handle 0, and the host should be free to choose any value in that range, but I have to set some arbitrary positive limit which is ineviatably unhelpful, and the host has no real choice but to take it literally. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Tue, May 02, 2006 at 02:34:20 -0400, Phil Frost wrote: On Mon, May 01, 2006 at 10:27:56PM +0100, Steve Harris wrote: On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: Do you mean that the plugin should dlopen the host? Wouldn't that require some way to pass the path to the host program to the plugin (in which case you might as well pass a function pointer directly)? I mean the linker should do it. If you dynamically build the plugin against a stub library and the host exports something with the same ABI, I /think/ the plugin should have the host's version of the function in its namespace. From what I glean from this you are talking about having the plugin .so access symbols that are defined in the host. I know this is possible, and you don't even have to link against any stub library. Check out the -E or --export-dynamic option to gnu ld. OK, great. Do you know if OSX and Windows have equivalents? I don't know if this is a good idea, though. It feels kinda freaky. Perhaps, it was just one suggestion for how to achieve that. It's not needed by all plugins, so it doesnt have to be glaringly obvious, it just has to work. And this disucssion is purely hypothetical at this stage anyway. - Steve
Re: [linux-audio-dev] LADSPA 2
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote: Further, you can't really remove all of this data. Most of it will be required by the plugin code itself, and you can't expect it to go and read it from the RDF. Since the plugin author writes both and they are strongly associated with (and depend on) each other, the plugin can 'assume' eg. the type of it's ports. Plugin code definitely won't be reading the RDF file.S I've not yet seen a plugin that introspects its own port hints either, but don't take that as a challenge ;) - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Sun, Apr 30, 2006 at 06:39:05 -0400, Dave Robillard wrote: Dave, you complain about people talking down about modular synths, then yourself discount things that are only useful in non-modular designs? How about a little reciprocity here? [snip] ... a simple I need it would have been fine. ;) On the contrary, some people have said I need it to the LOG hint, but it's still not the right thing ;) That doesn't change the fact that we need it... There's a difference between needing the feature, and needing that part of the spec, which was the point I was trying to make. Logarithmic input values are very important, I couldn't agree more, but the LOG hint doesn't give you that. Since you took it away, Steve, you'll be the one to define that nice extension for us, right? :] Sure. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Mon, May 01, 2006 at 02:13:00AM +0200, Lars Luthman wrote: 2) the dynamic program lists and midi mappings (static definitions could be written in the RDF file, but that's no fun) That's a tougher one. Control port :| Not really - plugins only get to write to the control ports in the run() callback (or select_program() for DSSIs), and it's entirely possible and plausible that a program would want to list the available programs for a plugin before it starts running it's audio callback. I as thinking the host could call run(0), but I guess it might not want to activate either. Would it be possible to change the instantiation function from LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned longSampleRate, const char* BundlePath, const char** HostFeatures); to something like this: LADSPA_Handle (*instantiate)(const LADSPA_Descriptor* Descriptor, unsigned longSampleRate, const char* BundlePath, const char** HostFeatures, void** HostFeatureData); where HostFeatureData is a NULL-terminated array of the same size as HostFeatures, containing feature-specific data that the plugin can read and/or write. Then, if HostFeatures[3] is PROGRAM_LIST_CALLBACK, HostFeatureData[3] can point to a 'const DSSI_Program_Descriptor *(*)(LADSPA_Handle, unsigned long)', i.e. a DSSI program list callback pointer, and the plugin can set it to point to its program list callback. Or you could define a DSSI host feature and a struct similar to the current DSSI_Descriptor with configure(), get_programs(), get_midi_controller_for_port() etc and pass a pointer to that instead. It's possible, but it looks a bit ugly to me, and theres no way to update it without calling instantiate again. I don't see any other obvious way to let future extensions add their own callbacks (except for specifying a function name in the RDF file and then dlsym()ing that symbol name in the host). Or passing function poionters over control outs, but thats even nastier. But if its a required host feature, then the mini-spec for the feature can just say what the callback must be called. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: IMHO, thats not the way to do any of those things: mono/stereo is best done with dosconnected ports IMHO. That way you can change the connected state and have the plugin react. mono/stereo isn't the best example. I'm thinking of things like an n-1 mixer plugin. I'd like to not even think about cases like that, it's conceptually quite complex, and there aren't many examples of when it's needed. Like you said below it can be done with complex control ports for example. That's not great either, but for the small number of cases it's needed it doesn't bother me personally. Adding complex features to make certain corner cases easier is what ruins most APIs IMHO. I guess the port things aren't a good justification for the creation parameters, you're right. The question, then, is what is the recommended way for the host to provide functions to the plugin? That's what Lars was originally seeking (and solves the above allocation problem as well) I think that if it's provided as part of a HostFeature (so the plugin knows it exists and what it's called) it can be obtained using the OS's normal dynamic linking functions. I've not tried though. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Mon, May 01, 2006 at 11:24:03PM +0200, Lars Luthman wrote: On Mon, 2006-05-01 at 22:13 +0100, Steve Harris wrote: On Mon, May 01, 2006 at 04:50:13 -0400, Dave Robillard wrote: I guess the port things aren't a good justification for the creation parameters, you're right. The question, then, is what is the recommended way for the host to provide functions to the plugin? That's what Lars was originally seeking (and solves the above allocation problem as well) I think that if it's provided as part of a HostFeature (so the plugin knows it exists and what it's called) it can be obtained using the OS's normal dynamic linking functions. I've not tried though. Do you mean that the plugin should dlopen the host? Wouldn't that require some way to pass the path to the host program to the plugin (in which case you might as well pass a function pointer directly)? I mean the linker should do it. If you dynamically build the plugin against a stub library and the host exports something with the same ABI, I /think/ the plugin should have the host's version of the function in its namespace. - Steve
Re: [linux-audio-dev] Todays changes to LADSPA2 strawman
On Sun, Apr 30, 2006 at 11:37:28 +0100, Chris Cannam wrote:
On Sunday 30 Apr 2006 00:01, Dave Robillard wrote:
We need a better API with which to build good, useful things.
So what are those things, and how will LADSPA2 get us to them? I'm not
looking for perfect foresight here, just some inspiring examples.
So, examples:
Making disconnected ports have sensible behvaiour, eg. making stereo
plugins work as mono ones, if only left in and out are connected.
Port groups that are identified, eg. marking left and right ins as a pair.
So hosts can offer sensible connection options, and distinguish from
sidechain inputs.
Randomisable control ports (Taybin has been after this for ages). It's a
nice way to experiemnt with complex plugins.
FFT data inputs, using a struct like { int num_bins; float data[num_bins]; }
much more efficient the constant moving in and out of PCM, and makes
plugins less complex.
Just because one API is easier to extend than another, doesn't mean that
it will necessarily happen easily or in a useful way (i.e. with
consistent enough coverage from hosts or plugins to be really useful).
The logarithmic hint discussion here is an example of that -- it's just
about the most trivial thing that can be imagined as an application of
an extensible API, yet it's ended up in a lengthy discussion with no
consensus so far.
Well, actually the LOG hint is just an example of something that LADSPA1
(arguably) got wrong, and theres no eaasy way to fix it in LADSPA1. The
reason it can't be fixed easily is that its far from trivial. Especially
seen as noone knows what it means ;)
You're right though, just building an extention mechanism is no guarantee
that people will use, but if you dont then they don't have the choice.
- Steve
Re: [linux-audio-dev] LADSPA2: logarithmic hint
On Sat, Apr 29, 2006 at 01:00:04 +, carmen wrote: It's not possible for a host to know how to scale a port from just the unit labeling. Unit labeling and input value scaling are independent, in fact are completely orthogonal except in certain conventional cases like IEC for some (not all!) dB ranges. ++. there definitely needs to be a 'logarithmic' hint. maybe even log(10) vs log(2). Errm, you you really need to think about that harder. The hint that this should be scaled logarithmically isn't enough information to do anything useful - try it. If you try to define an operation that hosts can apply generally then you will find there are lots of cases where it can't be applied. Either because it can't be computed, or because it does something unhelpful. im sure this RDF/JSON/YAML thing can make a case for it Possibly, but I doubt the field of mathematics can ;) if a is the users parameter UI control value in [0,1], u is the lower bound, v is the upper bound, and b is the log base, then: port val = ( (1-a) log(u) + a log(v) )^b = ( -a log(u) + log(u) + a log(v) )^b = log( ( u+v^a ) / u^a )^b = (u + v^a) / u^a so the log base cancels out. - Steve
Re: [linux-audio-dev] LADSPA2 name early consensus
On Fri, Apr 28, 2006 at 02:29:42 -0400, Dave Robillard wrote: On Fri, 2006-04-28 at 08:57 +0100, Steve Harris wrote: OK, it seems like the consensus is clear to me. So far, most people want to use/keep LADSPA2. I ran it through a condorcet program, just to make sure, but it't not in doubt. FWIW, by my count the pure acceptable numbers came out as: Most people who suggested we keed LADSPA said LADSPA, not LADSPA2. If we keep the name LADSPA, everything is going to have to say LADSPA2, directory names, API calls... LADSPA2 looks like an ugly working name to me. --votes Richard Furse also agrees, he said: [talking about the PEA name, which he likes, but I don't] Really not sure about LADSPA2 - happy with just about anything else! We could always bill it as LADSPA PEA or suchlike if folk really care about the Trademark. I don't think that's strong enough to count as a veto, and he's away at the moment, so I can't ask him. It's enough to want me to hope we can reach a consensus on something other than LADSPA2 though. For the record, I was initally in favour of just using LADSPA2 (I'm really lazy), but he talked me out of it, hence the mail to the list asking for votes. - Steve
