On Thu, 2011-02-24 at 10:48 +0000, Chris Cannam wrote: I could perhaps be convinced to make it BSD since it's intended to be as widely usable as possible... the goal is to provide an enabling technology to promote Turtle/RDF, not the software itself, so that's appropriate. I'm making a single-file "amalgamation" ala SQlite as well, public domain / unlicense like they do might be a good choice too. I always wanted a programmatic query interface in Redland... having actual textual queries that need to be parsed every time is a bit silly in something like SLV2. Maybe one day I'll try my hand at a (simple than SPARQL) query engine, but it's a bit hard, and it turns out that doing triple queries and just iterating over those (possibly nested) actually makes much more clear code from a C coding perspective. Nested foreach style loops is much more natural than tabular query results for the type of code that uses LV2 (not that SPARQL style querying doesn't have it's uses, of course). -dr

On 02/25/2011 07:33 PM, David Robillard wrote: I am not a lawyer and all that but on mobile devices it can be very complicated (or impossible) to satisfy the ability-to-relink LGPL requirement. LV2 plugins on mobile devices? Yes, I'm investigating that :) -- Olivier

On 02/25/2011 08:14 PM, Stefano D'Angelo wrote: Yep :)

On 02/25/2011 08:15 PM, Stefano D'Angelo wrote: Oh, well, I've only done some research so far. I have a closed source Android audio app which could act as a plugin host. It's a few months ago now that I investigated LV2. IIRC, at that time I concluded that this wasn't an option because SLV2 was GPL'ed. But things are changing IIUC :) The thing about Android is that third-party plugins should be rather feasible. There are simple mechanisms which could easily allow a host to discover which plugins are installed on the system. Such plugins could be distributed as standalone packages (APK) on the Android Market. There are a couple of security issues with linking about a third-party .so though. -- Olivier

On 02/25/2011 08:57 PM, David Robillard wrote: It's not always easy to discuss about religious matters, such as licenses ;) That said there is another big problem. This glib dependency, it's way too heavy for mobile deployment. Yes, and tablets opens many perspectives for audio. -- Olivier

On 02/25/2011 09:13 PM, Stefano D'Angelo wrote: Size. There are two bottlenecks related to size when deploying on Android: - the space it takes on the device. In the past apps could only be installed in the device internal memory, and it is often quite small, like about 150Mb. People tend to install a lot of apps so this gets filled quickly. So, a mechanism, app2sd, has been added to allow installing apps on the sdcard, which is usually more than 8Gb. But this doesn't work for native libraries, because the sdcard is mounted noexec. You can use app2sd, but the native libraries provided by the app are copied to internal memory. - the download time. It is common for users to download apps when they're on the go, and thus possibly using a bad internet link. My app is currently a little less than 1Mb, and I actually don't really want to make it bigger. Some games can get big, but my app isn't a game, it's intended to be lightweight. For example, I needed to add a little magic, to detect file formats. So I grabbed libmagic, compiled that, linked statically, and IIRC it resulted in a size increase of about 200Kb. That was quite unacceptable for such a simple functionality. So, I read the code and libmagic metadata files, and I implemented my own magic (OGG, WAV, FLAC, AIFF, MP3) in about 30 lines of C. I had a couple of bugs, but it now works flawlessly. That said, I would need to test what kind of size it takes when linking statically against SLV2. But I will need to support glib as a shared library or something like that because of the LGPL. That's a lot of complication. This RDF turtle format is surely a beautiful thing when you write or read it, but it requires such a parsing machinery... What about an alternative format intended for lightweight packaging and parsing? It would take the turtle metadata and convert it into a text file which could be parsed with about 100 lines of C. It may not work for all plugins, but maybe for the vast majority of them? At least I'm thinking about that kind of solution for packaging for Android. Some kind of pre-parsing/metadata-simplification at packaging stage to avoid the need for bundling a full-fledged parser. -- Olivier

On 02/26/2011 05:47 PM, Stefano D'Angelo wrote: I was unsure librdf. It's good to know that it's not needed anymore Yes, ARM, 32bit. But, with the Android NDK, "By default, ARM target binaries will be generated in 'thumb' mode, where each instruction are 16-bit wide.". This is intended to save space. The only way to know what size it will really take is to compile with the Android NDK. Also, linking statically when using a reasonable set of SLV2 functions would give a more realistic figure. This should also avoid extra ELF stuff when creating an .so. I haven't played so much with flags such as -Os because there's like a very very careful mood about portability when compiling native libraries for Android. The NDK already sets various optimization flags. But this could be worked around. Something like 100k-200K could be fine in my case, at the condition that adding LV2 support provides a real benefit in terms of functionality. I don't want to wake up old trolls, but last fall, when I had a sound engineer intern working on the topic, we ended up thinking that integrating LADSPA would really be straightforward. No such overhead, great portability, and plenty of plugins. So most logically, when time comes to add plugin support, I will start with LADSPA. LV2 will maybe come afterwards. But this could change if there suddenly is a enthusiastic mood about LV2 on Android, and that LV2 plugin packages arrive on the Android Market. -- Olivier

On 02/26/2011 06:45 PM, Stefano D'Angelo wrote: Heh :) Well, right now, I'm more wondering about what ui:AndroidUi could be. Aside, in the ui ext docs there's this example which contains ui:binary, but I can't find any reference documentation about this binary property on the page: http://lv2plug.in/ns/extensions/ui/ Effects are not the top priority. I've done quite a lot of research on it because it was a good topic for my intern to work on. I have other basic features to add first. And the schedule that you mention makes sense to me. Hmm, I've been wandering in google yesterday about such LV2-LADSPA bridge. I am discovering the NASPRO project. That's interesting. It seems like it may consume a lot of brain-time diving into all this when compared to LADSPA. But I'm nevertheless a bit worried about adding support for LADSPA, as it's getting old and somehow obsolete. But IIUC correctly you are about to add some sort of LADSPA backward compatibility, which in any case, sounds very good and was clearly missing. What kind of help would you need? Also, are you/is there anyone on the list who is interested in releasing audio plugins for Android? Feel free to write me personally if needed. -- Olivier

On 02/26/2011 07:28 PM, David Robillard wrote: Browser UI is too much overhead IMO. I've had many Android devices in my hands. Some of them are fast, some of them lag terribly. You need to optimize as much as you can, and thus avoid extra layers such as a browser, javascript, and all that. Also, for really nice Android plugin UIs, the use of OpenGL could be great. It provides a great frame rate, suitable for fancy realtime frequency curves, waveforms, etc.. But all this need some careful research. I am really glad to read that this gap between LADSPA and LV2 is about to disappear. I completely agree with that. Especially when you also mention 20k ;) -- Olivier

(split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb) On 02/26/2011 11:35 PM, David Robillard wrote: I tend to believe that, generally, what is supposed to work in all cases doesn't work well in specific cases. It may do the job somehow, but it's not really adapted. And if this results in poor acceptance, then your investment is lost. Portability is good, but if you go too far with it, you lose a lot of API and/or platform specific features and optimizations. Also, I don't see what's so easy with browsers. I've done web development for years, and compatibility problems are the rule. I don't see why this is so crucial for plugins. It's true that browsers are evolving fast, but right now you can't even get a VU-meter to update fast enough in a portable manner. Browsers are not adapted to such things as live frequency curves and other powerful audio UIs. I don't think it's a matter of priorities here. We have different opinions on what plugin UIs could be on mobile devices. Actually, on current mobile platforms, when one wants a portable UI, there is an alternative to Web UIs: OpenGL. This runs everywhere, and as smoothly as can be. All you need is the plugin to expose draw() and mouse motion functions. Using such functions glScissor(), it would even be possible to embed a plugin UI in a host UI while making sure that it doesn't draw out of its bounds. A toolkit on top of OpenGL may often be useful especially for drawing texts and widgets. For example, there is Clutter: http://www.clutter-project.org/ But this is no constraint, every plugin would be free to use the toolkit of its choice internally when rendering within its draw() function. There are subtleties though. For example on Android, there are so-called screen densities, theoretically ranging from 120dpi to 320dpi according to the device. But that's easily solved with OpenGL, the host can scale the displayed plugins if needed. The plugins do not need to know what the ratio between a point and a pixel is. And if there existed some specialized toolkit for audio UI development, and even a UI builder in the lines of JUCE's Jucer, then creating portable and high-performance plugin UIs would become very easy. That said, I have also investigated other solutions for simple portable plugin UIs, but I think that OpenGL is worth considering. Hmm.. Does the current bridge rely on LADSPA rdf files to be present? If so then I would say that it doesn't really provide backward compatibility from LV2 to LADSPA. AFAIK, ladspa.h is the specification, and I would hope that the bridge is able to detect and load any plugin which follow this specification. In the Android case, this is entirely possible yes, during the APK packaging phase. -- Olivier

On Mon, 2011-02-28 at 22:37 +0100, Stefano D'Angelo wrote: [...] You could avoid having to do this whatsoever by just translating the lrdf data to LV2-style Turtle, if you want to consider LADSPA deprecated (i.e. you don't expect a bunch of new plugins with lrdf data to keep arriving). Then you don't have to deal with XML at all, yay. -dr

2011/3/1 Olivier Guilyardi <list(a)samalyse.com>om>: Mmm, one more reason to avoid supporting LRDF...

On Tue, 2011-03-01 at 19:01 +0100, Stefano D'Angelo wrote: I would just ram all this through rapper and get Turtle and call it a day, but I'm probably more inclined to consider LADSPA/LRDF deprecated than most. Why on earth would anyone write a new LADSPA + LRDF plugin now? Fixed in svn, thanks. -dr P.S. Serd parses N3 too

2011/3/1 David Robillard <d(a)drobilla.net>et>: If we exclude older IE releases it all gets a lot better :-) True for live usage, not really for offline processing, recording sessions, etc. At least not in the long run. Think spatialization, EQs, physics-related stuff, scientific usage and, somewhere in the future, sound analysis (spectrograms, etc.), highly interactive stuff. WebGL FTW??? I actually am quite impressed with YUI, it seems very fast in doing non trivial stuff. However, I couldn't imagine a waveform editor, to say, in browsers yet. /me thinks, at this point, about a possible WebUI decorator plugin with interactive design possibilities... (then my mind pushes it too far: let's integrate with Firebug or something. :-P) Uhm, GL is actually embeddable in most semi-serious toolkits (even SDL should allow that IIRC). Should we go for a GL/WebUI approach? /me: GUI decorator plugin #2 - give it a bunch of metadata (and maybe fonts image), it will create the GUI on the fly for you. Agreed. Stefano

On 03/01/2011 12:58 AM, David Robillard wrote: Hmm, what platform specific native code? In my idea, the host would handle setting up the GL viewport and such. The plugin would expose a draw() callback in which it would only perform standard OpenGL calls. I'm not an expert about GL portability, but AFAIK this might allow the UI provided by a plugin to run unchanged on Linux, iOS, Android, Mac, Windows, etc.. I'm confused now. You are talking about UIs automatically built by the host from the plugin parameters, ports, metadata, etc.. To me, this is not a plugin UI, this is the absence of plugin specific UI, and the kind of thing which you can already do with LADSPA plugins, etc.. So, automatically generated web UIs from plugin metadata is of course possible, but I wasn't talking about that. I'm talking about those cases where the plugin needs to provide a specific UI, as it's currently being done with LV2 using GTK, for example in Calf plugins, etc.. But here you mention a mix of automatically generated UIs and "special web UI fragments" provided by the plugin. This sounds like abstract maths to me ;) Sorry, I can't follow you, it's not my field. Regarding remote controllers.. Well this is already in the wild, tablets included, with OSC and MIDI. For example, there is TouchOSC (sorry, not free, but a great project) which even has a UI editor. I think that I understand you idea of doing this with a browser. No need to setup OSC, ports, map URIs, etc.. But this sounds like a web-based controller project. It's application level IMO, not sure it belongs to LV2, apart from the UI fragments idea, but this all sounds like fundamental research to me. That said, I don't think that I can help some more here. I'm more into simple user needs and every day music/audio tasks. -- Olivier

On 03/02/2011 12:22 AM, David Robillard wrote: No, not really. Apart from mobile web apps, a way to build cross-platform apps is using a lightweight toolkit, with OpenGL for all graphics, and a couple of other entry points such as an audio I/O callback, etc.. With this method, notably used by game devs, there's one code base, with thin platform drivers. So, with such portable hosts, the platform specific native code goes into the toolkit. And both the host and plugin would be rather platform-agnostic. Okay, I see. But we are talking about plugins, are we? To me a plugin is a small module which embeds in a host UI or appears as a small window on top of it. What you're talking about makes sense if the host itself runs in the browser... But switching from a native UI to a browser repeatedly is going to look rather odd IMO. And if your idea is mainly intended for browser-based hosts then it will not integrate properly with a large range of existing software. That said, for instance on Android, you can embed a small WebView into the UI of a host. So it could make sense. But (http) network operations are going to bring some more overhead. All of this really isn't going to be smooth. In order to avoid network operations, on Android, you could expose some of your Java classes as Javascript objects into the WebView, this is entirely possible. But now that's going to be a lot of native code for binding say a slider to javascript and then to java and then down to the native plugin... The UI would draw into a rectangular area which could: - either be embedded in a larger GL scene, if the host UI is GL based, - or be displayed by QGLWidget, rendered into a GdkGLWindow, etc.. Also, what's rather funny is that there would be some kind of symmetry between the run() and draw() functions exposed by a plugin. One for audio, the other for graphics/video... And both called in a cyclic manner by the host. Yes, I've developed a long time for the desktop, and I never used OpenGL before I got myself into mobile development. Now that I'm familiar with it, I quite enjoy it, and am amazed by the perspectives in terms of portability. Sounds good. This is where LV2 extensibility shows some of its strengths I guess. Hmm, own web server, I don't know really.. This sounds a bit bloated to me. And how does one draws a frequency curve, even one which doesn't update in realtime? With SVG? Do you see how heavy this is all going to be? Slicker for who? The whole point of controllers is that the user can choose the one he/she likes. Hardware controller, tablet-based controller with knobs, or sliders, or pad, or even one which uses the device sensors such as the accelerator, the compass, etc.. Not sure what you mean here, but I'm a big No Silver Bullet fan, and generally I don't believe in no-need-to-code-anymore claims. Now, first, I'll repeat what I said earlier: "I tend to believe that, generally, what is supposed to work in all cases doesn't work well in specific cases. It may do the job somehow, but it's not really adapted. And if this results in poor acceptance, then your investment is lost." Also, I'm into music too. The greatest reward (apart from money ;) I currently get when working on my product is enthusiastic feedback from musicians. Now, think of a music instrument. Do you mean that a grey guitar with unpersonalized design is what musicians need? I strongly disagree. And that's why I think that powerful UIs with their own style can be a good thing. It can stimulate creativity. And each user can choose the one which best fits his mood. Okay, well, this Web UI idea would certainly be good in certain cases. And the truth is that I'm not really convinced about the OpenGL idea, because it may result in inconsistent appearance, with widgets style which do not match each other. But this later problem could be solved with a simple audio-oriented UI toolkit, which would render using OpenGL. A such toolkit could actually be very lightweight. For instance you do not necessarily need to embed entire charsets. A couple of characters (digits, "dB", etc..) could be sufficient in many cases. -- Olivier

On 03/02/2011 02:27 PM, Paul Davis wrote: Okay, well, I'm not into game development. I just mentioned that because there are a few game devs who actually rely on that kind of portable toolkit on Android. But I have no clue of what's really involved in highly complex games. Now, this discussion is more about audio and music apps. What I meant is to have the portable code base expose: process(*input, *output) And now, yes of course, you need thin drivers which calls this function. And if you want to support 4 platforms, you may need a dozen of drivers, yeah, but it sounds ok to me, as long as all the logic resides in the portable code base. At least in my very case, this should allow me to perform audio I/O on any mobile and non-mobile platform I can think of. First 5 years is a real lot of time when it comes to computing. I think that it's very risky to predict what will happen. Maybe you're right about technical limits evaporating, or maybe that technical approaches will take entirely new directions. Also, if you are talking about the browser limits, well, browsers are getting more and more advanced, web UIs are used in a variety of cases, yes. But the more powerful the machines become, the more audio applications will need to be powerful as well. And there always will be a gap between native optimized code and high level interpreted stuff. At least in the foreseeable future. Also, my OpenGL idea, although merely brainstorming so far, is not only applicable right now. It could also allow to build innovative 3D audio UIs. You could even embed 2D plugins UIs into a 3D scene. My point about OpenGL wasn't only about optimization. It just appears to be very portable, and yes also suitable for high-performance UIs today. And it seems to me like it can only get better in the future. -- Olivier

On 03/02/2011 03:30 PM, Stefano D'Angelo wrote: Pretty amazing. You are focusing on the GUI technology but you are leaving aside the question of the communication between UI and audio processing. Choosing a GUI technology will have consequences on that. With native OpenGL, both the draw() and run() method would reside in the same .so, and the plugin could perform high-performance IPC internally, within a single process. Just an example: a compressor plugin which shows the input and the output waveform in realtime, for visual feedback of the applied compression. I think that what I'm saying about OpenGL about internal IPC also applies to the other technologies that you mention, apart from the web UI. So, with a web UI and even with WebGL, what are your ideas for communicating between the UI and the audio processing thread/process? -- Olivier

On Wed, 2011-03-02 at 15:30 +0100, Stefano D'Angelo wrote: [...] Sounds to me like people already have chosen their targets ;) -dr

On Wed, Mar 2, 2011 at 12:25 PM, Olivier Guilyardi <list(a)samalyse.com> wrote: from the depths of time: http://lalists.stanford.edu/lad/2000/Nov/0344.html it basically turned out to be useless. the host can put together a pretty good GUI by itself. it could do an almost perfect job with port grouping hints.

(resending this since my previous mail with attachments didn't go through) On 03/02/2011 06:29 PM, Paul Davis wrote: Here are a few of the abstract UIs that I asked my intern to build for various LADSPA plugins: http://testing.samalyse.com/lad/plugin_ui/ He worked with the TouchOSC Editor, which was rather handy for this, although the goal is not using such interfaces in TouchOSC. Colors can help to group parameters which relate to each other. A certain visual coherence can be given to the UI by simple widget placement. A certain degree of compactness can also be achieved, especially for toggles. But all this is highly experimental. -- Olivier

On Wed, 2011-03-02 at 14:20 +0100, Olivier Guilyardi wrote: Thin platform drivers, i.e... platform specific native code. Can we PLEASE stop beating this dead horse? My point is that NO SOFTWARE NEEDS TO BE INSTALLED AT ALL WHATSOEVER AT ALL PERIOD AT ALL. Get it? Good. Let's move on. The idea is to put the entire performance/control/et UI in the browser, so it can be remote. You've missed the remote idea. Remotes good, even on a desktop. People go out and spend money on special purpose devices for this all the time. Tablets can give you a completely generic reconfigurable... that. The "host", as in the plugin host that does audio things, is obviously not in the browser, that's on the machine doing audio things, C, Jack, etc. Yep. It's not a network operation if it's local. Local socket communication is very fast... and something that's arriving in the browser. http://en.wikipedia.org/wiki/WebSockets As far as I'm concerned a non-crap app design should be capable of doing engine <=> UI communication over a <whatever, e.g. socket> anyway, even if you only intend to use it on a local machine. You WANT a huge meaningful wall between those two things. For one thing, if your UI stuff crashes, your audio doesn't, and your set doesn't trainwreck. The other win of UI<=>audio separation is that not all of our DSP code runs on a computer with a monitor at all. Little embedded boxes that do DSP stuff don't have big screens... but they usually have USB ports (or network, or MIDI, or something). That UI <=> Plugin separation is necessary is, IMO, a given, and not up for debate. You could throw it all out the window and gain virtually nothing in return, but... well, doesn't sound wise, does it? Plugin and UI are not the same thing, nor should they be. OK, well, do you have any active plans to do OpenGL plugin UIs any time soon? In one sense. The problem it's solving also shows some of its weaknesses. ... Yeah, that would be the obvious reason. ;) Yep. I see how heavy it is, and I also see that it is the only technology stack you have, if you want to do this kind of thing. I also see it's getting a whole lot less heavy extremely rapidly. Anyway, go look at some modern canvas experiments. Drawing a curve quickly is well within what works fine right now. Drawing and animating a whole ton of them smoothly is current reality. Why you are trying to pick apart web UIs in the same email as you're arguing where one size does not fit all I don't know... I want a remote control that works on any device out of the box. It's about as blatantly obvious as anything can be that web is literally the only way to go for that, because the browser is actually on those devices. QED. Do I think /all/ desktop PC hosts and plugin should use it? No. It's for "remote control" things (even if not remote). Is GL good? Yes. I sure wish I used it for the Ingen canvas. Has anyone actually showed up yet who wanted to write a GL UI? No. Unless you're one, talking about it is a waste of time. You just mentioned controller apps where users build their own UIs (touchOSC etc), sooo... I guess you don't believe in reality? ;) This is audio. Give people the ability to pixmap at all and they're going to make some big retarded quasi hardware photo thing, each entirely different, and usually horrific screen real-estate wasters. Consistency between UIs ain't going to happen. GL would probably be even more consistent than the toolkits, ironically, because it tends to push you towards vectorey things. Aaaand now we're entered the realm of many years of work that nobody is going to do. Unless JUCE counts. Speaking of doing tons of work, GL gives you an open-ended way to draw things... and that's it. One you actually need to make those things interactive, you need something else. Something else that isn't just GL, and probably isn't portable, and is a ton of more work regardless. The DOM inherently makes it trivial to deal with events, and that's all built-in. A mess of little toolkits, all alike, is not a fun situation, and plopping it on a GL backend doesn't make it go away. -dr

On Wed, 2011-03-02 at 19:31 +0100, Olivier Guilyardi wrote: Yep. I would much rather all the UIs be based on GL than a bunch of different toolkits, but toolkits solve all the problems required (e.g. input), and GL solves a tiny part of it, and people in this community know the toolkits. So here we are. UI types aren't pressing decisions (a point that this list in general loves to miss lately...). The UI extension is toolkit agnostic for this reason. Maybe some day someone will make GL plugin UIs. Maybe not. Whatever. -dr

On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo &lt;zanga.mail(a)gmail.com&gt; wrote: no different than any other plugin API, except that the concept is a bit more unified than "data" and "parameters" as found in, say, VST or AU. AU, which is the only other plugin API to explicitly support plugin<->GUI separation (even across processes) works in exactly the same way as LV2. there are many AU plugins which do precisely what you describe, yet still use a host-mediated parameter accessor API to both control and represent current plugin state. this conceptual issue has been thrashed out many times on the coreaudio mailing list as far back as 1994, and nobody ever convinced the coreaudio guys (who are a smart bunch of guys) that they had done it wrong. the principle remains: access to plugin parameters is mediated via the host to facilitate several things that would be impossible to do properly, if at all, if they instead happened directly. meta-parameters are used to provide the kind of thing you're describing, and the "real" parameters are marked as "not for display" in the (unlikely) event that the host creates the GUI for the plugin.

On Wed, Mar 2, 2011 at 3:44 PM, Chris Cannam &lt;cannam(a)all-day-breakfast.com&gt; wrote: sorry. "AU, which the only other <mumble> plugin API to ..." :) There's an extension for that!

Personally, I like the idea of plugin interfaces having some form of visualization. The compressor example is obvious. So is the graphical equalizer. I can imagine other cases as well: waveform of a sampler. Perhaps a synth that let's the user scribble their own waveform. There are all sorts of things that would provide better user interfaces if the control is richer. This web UI stuff might be the best new interface we've never used. But, I want a studio configuration, not some "I can change plugin parameters using an html text input while I'm at the office." David seems to think anything with a pretty interface is stupid and just eye candy. But try convincing Apple's human interface team of that argument. If the solution to visualization in lv2 is "ur doing it wrong", then perhaps we are using the wrong plugin tech.

I suppose I don't mean to attack lv2. It is a good extensible format, and is the product of much dedication, especially on Dave's part. I could write my own extension and be done with it. But then we end up with a situation like the external UI is today. My concern is if we would ever have a standard extension for this kind of thing when the primary maintainer considers the idea stupid, dumb, or broken.

2011/3/3 Paul Giblock &lt;pgiblox(a)gmail.com&gt;om>: Yet I can guarantee the maintainer in question is not stupid, dumb or broken, and after possibly a long discussion it's usual to find some common ground with him.

On 03/03/2011 01:25 AM, David Robillard wrote: Do you have a practical example of a plugin with a GL UI that would work nicely in Ingen? -- Olivier

On 03/04/2011 01:04 AM, David Robillard wrote: No, I meant a new plugin, or a new UI for an existing plugin. What do you think it would be nice for, in the context of Ingen? What would it do and how would it look like in the canvas? -- Olivier

2011/3/2 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt;om>: Since I'm not just complaining or posing hypotetical questions, but want the understand the issue at its deepest, I want to ask you to please better point out what is exactly this host-mediate parameter accessor API (a link to docs is more than enough). So I'm not totally dumb. :-) Stefano

2011/3/2 Paul Davis &lt;paul(a)linuxaudiosystems.com&gt;om>: Ok, now I know what we're talking about. This kind of stuff looks to me as stuff that is generally specified in the RDF data in the LV2 model (at least the basic standard properties), or am I missing something? May I ask you what does it allow to you to do that you like, specifically?

On 03/02/2011 08:55 PM, Stefano D'Angelo wrote: Visualization can allow realtime feedback of the applied effect as well as improved interaction. About my previous compressor example: imagine a single area where you have both the input and the output waveform. It allows you to see the applied compression but not only. The threshold above which the compression is applied can be represented as an horizontal line which could be moved up and down. Another example is a visual EQ as the one found in Jamin, where you both see the live spectrum and can adjust frequency bands level. -- Olivier

2011/3/2 David Robillard &lt;d(a)drobilla.net&gt;et>: But you can't pretend everybody has the same "workflow" and understanding as yours. I'm, for example, more a visual kind of person.

2011/3/2 Fons Adriaensen &lt;fons(a)linuxaudio.org&gt;rg>: I do particullarly appreciate this kind of feedback from people actually using our crap :-) (and even more since you also do this stuff too). Does point #1 mean we basically may want visualization that expresses only a few properties of a certain waveform?

On Wednesday, March 02, 2011 09:15:32 pm Fons Adriaensen did opine: I beg to disagree with the premise that the waveform is useless. I have had a scope probe in one hand for 60 years now, and there is nothing that comes close to finding that slightly edgy sound that just isn't quite right like a good look at the waveform when you have a known test signal. Clipping is easier to see, crossover distortion is easily seen by the trained eye, and even slew rate limits can be made to stand out plain as day. Note however that I am not referring to a digitized waveform which has its own set of problems unless the sampling frequency is 100's of times faster than the signal being sampled, I am referring to the raw analog signal itself. Digitize crap,and you still have crap even if the digital sample is quite high and the A-D is totally monotonic. Consumer stuff rarely is either wide range linear, nor monotonic beyond 13 or 14 bits in a 16 bit system. Even 24 bit stuff probably falls face first in its oatmeal at 20 good bits. Yes, you can see the results of all those distortions by doing an FFT on the digital signal, but unless one is intimately familiar with the FFT display, it can't tell you the real problem is crossover related so you only guess, or find someone who can tell you whats wrong, and chances are, he will use an analog scope to find and point it out. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) <http://tinyurl.com/ddg5bz> 667: The neighbor of the beast.

On Thursday, March 03, 2011 10:01:22 pm Fons Adriaensen did opine: Some of the best sounding commercials we ever did, were done during a time when our production guru started asking if he could watch the levels on a scope so I rigged one on the output of the production audio board. Then he got the itch to goto Alaska & no one else seemed to care, despite my stated willingness to teach them. Now, we are all digital, and the levels are all over the map. Sucks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) <http://tinyurl.com/ddg5bz> Ogden's Law: The sooner you fall behind, the more time you have to catch up.

On Wed, Mar 02, 2011 at 07:37:37PM -0500, David Robillard wrote: I guess the situation could be somewhat different for an audio engineer controlling a 'standard' app such as mixer, and a musician using a GUI as an interface to his instrument. Also, even in the first case visual quality *does* matter, but it depends on subtle things rather than on flashy features - just perceptible shadows, gentle colour gradients or textures for backgrounds, small differences in the size of controls, small deviations from grid positions to suggest functional groups, etc. all help to provide an interface that is easy to use. Ciao, -- FA

On Fri, Mar 04, 2011 at 01:53:55PM +0100, Stefano D'Angelo wrote: A simple bargraph showing the gain change will provide the same info. Also note that a compressor curve shows the _static_ response only. If you'd plot a point corresponding to actual input and output level for real musical signals it would most of the time *not* be on that curve. Ciao, -- FA

On 03/04/2011 01:53 PM, Stefano D'Angelo wrote: There is one thing which stays on my mind. I am familiar with developing JACK clients, not plugins. However, there has been quite a few discussions in the past where JACK was advocated as a way to create modules, DSP units dedicated to a specific task. In other terms: some kind of plugins. And what is absolutely nice about this is how it is non-intrusive. When working on a JACK client, there are only audio input and output ports, a thin transport layer, done. From these primitives, upon this bare but solid ground, a developer creativity enjoys a lot of freedom. However, there's been this critical and long-lasting session handling problem. Fortunately, this problem doesn't occur for LADSPA and LV2 plugins, since saving and restoring state is performed by the host. But, with this UI/engine separation, whenever a developer comes out with an innovative idea that he really likes, he's very likely to hit a wall because of a specific LV2 technical constraint. And at the same time it takes an incredible (if only possible) coordination effort to maintain LV2 to fulfill and *anticipate* all needs. But LV2 is extensible. So what I think is that in addition to the extensions which imply UI/engine separation (and I understand that it's important in many cases), there should be a DoWhatTheFuckYouWantInYourPlugin extension ;) With such plugins, restoring/saving state would rely on passing a blob in addition to restoring/saving the control ports values. There would be no such thing as UI/engine separation. The plugin would be self contained. And hopefully it would integrate nicely with other extensions such as midi. I think that this extension, since it would only imply simple but powerful primitives, would give a lot of freedom to developers who want that, and at the same time be rather easy to maintain. -- Olivier

On 03/04/2011 03:40 PM, Stefano D'Angelo wrote: Thanks for clarifying that.. But does this mean that LV2 already support what I explain /with/ existing extensions? I'm sure he wouldn't. Otherwise, my patch to remove this glib dependency may never be submitted ;) -- Olivier

On 03/04/2011 08:51 PM, David Robillard wrote: About graceful degradation, indeed, in my compressor example, you would certainly have regular controls aside of the interactive visualization area. Setting the threshold could be done graphically but also with say a knob. So it would still work if direct access to waveform data is not available, the visualization would be deactivated. This sounds nice and solves the rich-visualization issue IMO. -- Olivier

On Friday 04 March 2011 19:38:28, David Robillard wrote: Why widget type/toolkit at all? If you want to abstract, why not abstract at a lower level? Make the plugin claim its written for a GL context or X or Win32 or Cocoa (or whatever is used on MacOS), and return the relevant context id. Make the host do the same thing. Make the library mix and match at that level (or libraries: it's not like a host is changing between X and Win32 at runtime), and gain toolkit independence. -- Pedro Alves

On Friday 04 March 2011 22:00:47, Paul Davis wrote: Of course. I was implying always Xembed'ding when host and plugin are both X11 based, with the ugliness all tucked away in the library. But it seems I can infer then that one of the design choices of libsuil is to allow trusting plugins into the address space party. I wonder how long it will take until there's a cry for a way to force plugins to be loaded out-of-process . ;-) Thanks for the explanations. -- Pedro Alves

On Fri, 2011-03-04 at 21:45 +0000, Pedro Alves wrote: That is exactly what I am describing (and have implemented). The toolkit choice has always been entirely open-ended in the UI extension. -dr

On 03/02/2011 10:58 PM, David Robillard wrote: Ears are not separated from the body. Not only am I interested into the convergence of audio and graphics but also touch. This basically is what my Android app is about. Aside of that I've worked with a painter on an artistic project which consists in a dialog between painting and music. That affects my point of view. Also, the feelings I get when I touch and see my guitar have a great influence on what I play. And I'm certainly not the only one. -- Olivier

2011/3/2 Olivier Guilyardi &lt;list(a)samalyse.com&gt;om>: Mmm, this answer goes straight to the heart of the problem: what does the UI actually represent? Your examples show quite clearly that the visualization part might be of great help, and I honestly won't support the idea that the host should do that, since there are thousands of ways you could represent data. Yet a problem remains... is data visualization really indivisible from a plugin state and/or its input parameters? Or, in more practical terms, should we consider visualization belonging to the plugin GUI or not? I suspect that in theory it is not, but in real world it is... since it would really be madness to ask a plugin how it treats data, how could it ever be represented in the most meaningful way w.r.t. its processing algorithm and asking it, optionally, for a self representation in either a form of data that is directly comparable to the input/output representation (compressor and EQ example) or whatever else... (I'm scared of myself at times)

2011/3/2 David Robillard &lt;d(a)drobilla.net&gt;et>: This is because tonight I decided not to do any coding. :-)

On 02/26/2011 07:37 PM, Stefano D'Angelo wrote: Hmm, I will first try and learn more about NASPRO, compile it on Android, and see if I can get it to work with SLV2 for LADSPA plugins. There are many musicians using my app, and amongst them many guitarists. I think they're mainly the ones who requested effects. You could provide your plugins as standalone packages on the android market. My app could be the first host, but there could be many other hosts in the future, if it's documented and easy. I'll be happy to discuss more about this next week. Now, I need to go. Thanks for the great discussion! Cheers -- Olivier

2011/2/26 Stefano D'Angelo &lt;zanga.mail(a)gmail.com&gt;om>: Ciao Stefano, With a small impedance matching device connected to the mic-in of the phone, the way IK Multimedia's guitar amp sims work on iPhone? http://www.ikmultimedia.com/Main.html?iphone/index.php&fenderiphone -Giuseppe

2011/2/27 Stefano D'Angelo &lt;zanga.mail(a)gmail.com&gt;om>: Ciao Stefano, I was merely pointing it out as I don't think there is currently any other way to do it. Connecting the guitar directly to the phone with a simple plug adapter would probably sound meh. Unless Google wants to add support for external USB sound cards to Android? ;) Sounds cool, I recently bought one of those beasts ( http://www.fractalaudio.com/products-fa-axefx.html ), and I think it's amazing, hands down the best amp modeling I've ever heard (and amazing effects too!) demos are here http://www.fractalaudio.com/experience.html It also does model the power stage section (power tubes->output transformer<->cabinet interaction) and exposes many parameters to the user, like tubes bias, negative feedback amount (if any), sag, B+ filtering/capacitance, even speaker distortion etc. I'd be happy to compare your plug-ins to the Axe-FX ;) I would personally prefer desktop LV2 versions of your plug-ins, they could always be ported later to Android if it's going to be worth the effort. And I would prefer GPL'ed plug-ins and be willing to donate, I don't think there are many options right now on Linux, I dislike rakarrack and guitar_ix, and find CAPS* so so. Can't help you there, sorry. I have a cheap entry level HTC Tattoo and it's slow as molasses. Haven't even attempted to install any audio related apps. It might be feasible on higher end droid phones though provided the audio API allows it, I just don't know. I think there has been a recent discussion about realtime audio apps on Android on LAU if I am not mistaken, you might want to search for it. Sorry for the OT. Ciao, -Giuseppe

(split from: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb) On 02/27/2011 02:13 PM, Stefano D'Angelo wrote: I've had several users report success in using various microphones plugged into their Android device, with these adapters: https://www.kvconnection.com/Articles.asp?ID=165 I haven't tested that, but I think that it should work with a guitar. There's no plan for this AFAIK. This is entirely up to you of course, but I think that there are some compromises. I am not sure that it would work in this case, but for example, one could consider releasing an LV2 plugin under the GPL, and make a paid version for Android which includes a nice UI. Fancy UIs can involve costs, such as working with a professional designer, etc.. Some app developers accept donations. It's even the case of some of the most popular Android music apps. They usually release the app freely, and they have another paid "app" which actually provides nothing but a way to donate. So far, I've had my intern select more "generic" effects, such as reverb, compression, delays, etc.. It needs some more work on the guitar side. Latency is terrible. Expect about 100ms for input and for output as well. This situation is one the main reasons why we created the Andraudio mailing list [1], dedicated to audio development on Android, but also possible audio stack patching/improvement. In the current situation, applying effects in realtime isn't possible on Android because of such latencies. But it's of course possible for post-processing, and that's what I'm working on. The quality can be rather good. It's nothing like desktop gear, but it's ok for composing on the go, to catch ideas whenever/wherever they come from, record a piece of guitar, add some effect, and send it right away to your band... [1] http://music.columbia.edu/mailman/listinfo/andraudio -- Olivier

On 03/01/2011 01:53 PM, Stefano D'Angelo wrote: Hey ;) No I don't have that much money to spend right now. Small company here. I'm more thinking in terms of informal partnerships. Selling plugins, a developer can benefit from the popularity of certain hosts apps, and having a choice of quality plugins is good for hosts too. Yes, you are welcome, it's quite low traffic, but there's already been a few useful threads. We also have setup a google code project to share code experiments and work on the wiki: http://code.google.com/p/andraudio/ What I explain above is very relevant to my case. But you can also think about advanced sequencers and other innovative music making apps, especially on tablets. In such cases, the user is likely to load pre-existing samples or use synths, and is therefore not affected by the recording quality. You know, the most advanced music apps currently run on iOS, and there is no such things as plugins AFAIK. I think that's it's not legally/technically feasible to support third-party plugins on iOS. But on desktops, users are very familiar with the plugin concept. So to me there's something to do in the mobile world, which hasn't been done yet, and which should be possible on Android. -- Olivier

On Sat, 2011-02-26 at 17:47 +0100, Stefano D'Angelo wrote: [...] PCRE is a dependency of glib. I don't use regular expressions in these projects. I could probably make slv2 itself smaller by using a single non-type-safe collection type rather than the different collection type for each element type which is the current situation (stupid neanderthal type primitive type systems). This would reduce the number of functions quite a bit. Other 'function compression' could also happen, but this all would break the API thoroughly. Type safety (i.e. lack of dirty casts and confusing API to use) here is more important than code size, which I don't think is unreasonable anyway. I'm more in to shrinking the actual runtime memory overhead to the absolute bare minimum than shrinking the code. I have roughly infinity more useful things to do than pretending <100k libraries are bloated :) Replacing glib, it seems, is the main and by far most significant thing that needs doing to get a very small embedded appropriate limitation. The code size of my new libraries, IMO, is well within reasonable limits for anything that would use LV2 plugins. -dr

On Sat, 2011-02-26 at 19:32 +0100, Olivier Guilyardi wrote: Fair enough. The sum of all installed LV2 data loaded into a data structure can be large, though. My new implementation is still not quite optimal, though: The per-statement overhead in Sord can be reduced from 4 * sizeof(void*)) * n_triples * n_indices to 4 * sizeof(void*)) * n_triples relatively easily, but it already seems to be much smaller than the old librdf version (judging by my last unscientific experiment and feedback from others, at least). n_indices is typically in [1..4], and IIRC 2 for slv2. There's also, from SLV2's perspective, 2 copies made of every parsed node (from disk to serd, then from serd to sord). This can be reduced to 1, the optimum[1], at a slight cost in processing overhead (reading a character gets one function call more expensive). Everything else is pretty tight; with these two improvements serd => sord will be roughly as space efficient as it is possible for an implementation of "reading Turtle in to a searchable model" can be. On Android it's probably not an issue though, as you say. For other embedded situations it would be nice to have absolutely minimal space overhead on top of the actual data itself... plus it's fun :) Fair enough. It seems the libraries involved can be built to be well under 100k with -Os and such, but I have no idea how 64-bit shared library code compares to static android code in terms of size. I'm all for contributions that shave a bit of space, but everything seems pretty good to me now (glib aside). -dr [1] In a basic model where reading from "disk" is considered a copy. To make the implementation literally as lightweight as possible in reality, it could mmap everything, so in the case where the data is already cached it would not be copied at all thanks to virtual memory. I will probably try this eventually for fun, but it's probably more of a high-performance computing CS nerd wank than something that needs to happen...

On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote: I will need to make a "load all LV2 data and do nothing" program to benchmark how much space is used by loading all LV2 stuff. I suspect it will be a figure workable within 288MB of RAM, but ideally should be smaller since apps have other things to store, especially when audio is involved. I would guess it will be at the very least a month before this happens, unless somebody steps up to do it. The relevant SLV2 release announcement will mention the glib removal. -dr

On Tue, 2011-03-01 at 14:00 +0100, Stefano D'Angelo wrote: [...] Nope. The next release will be very soon. It is not a short-term priority for me at all. If a solid replacement for all the necessary things shows up that I don't have to work on whatsoever, then I'll switch to it. I very much need to start releasing /plugins/ and /programs/ - things users actually /use/ directly. At first I only care about doing so on this platform, and glib is not a problem whatsoever on this platform. There's still a ton of LV2 core/extension work that needs doing before I get to do that. Pissing time away replacing glib? No thanks. :) -dr

On Mon, 2011-02-28 at 17:24 +0100, Olivier Guilyardi wrote: [...] I just released serd-0.5.0[1], sord-0.5.0[2], and lilv-0.5.0[3] which all have zero dependencies except each other and the C standard library. All work on at least GNU/Linux (Debian Testing), Mac OS X (10.6), and Windows 7 (under MingW), but I havn't tried any cross compiling yet. You should be able to easily get less than 100Kb. Compiling static libraries for 32-bit i386 with -Os I get: 16K ./sord/build/libsord-0.a 36K ./lilv/build/liblilv-0.a 28K ./serd/build/libserd-0.a Which is 80k total. It compresses well: 8.0K ./sord/build/libsord-0.a.zip 12K ./lilv/build/liblilv-0.a.zip 16K ./serd/build/libserd-0.a.zip Which is 36k total. The code is not really optimized for binary size (e.g. there are many more functions than there could be), but this seems good enough for any reasonable application (certainly a dramatic improvement over the several megs of Redland or GLib, anyway). Quite a bit of this code is unused in a typical LV2 host (e.g. SerdWriter), so if you're building a static app you can probably coax GCC into culling it down even further[4]... if not, I could add a --read-only compile option to omit the writing stuff which should save a bit more. Let me know how it goes with the Android NDK, I havn't tried. -dr [1] http://drobilla.net/2011/09/29/serd-0-5-0/ [2] http://drobilla.net/2011/09/29/sord-0-5-0/ [3] http://drobilla.net/2011/09/29/lilv-0-5-0/ [4] http://gcc.gnu.org/ml/gcc-help/2003-08/msg00128.html

On 02/26/2011 07:07 PM, David Robillard wrote: Sounds good. I don't get it. Do you mean that libserd is the only thing that I would need in the host? 20K? Now we're talking :) But I don't understand exactly what's required in the host and also during packaging to achieve such a tiny requirement. -- Olivier

2011/2/25 David Robillard &lt;d(a)drobilla.net&gt;et>: Given the discussions we had already, NASPRO core could be a viable alternative. Pros: - no dependencies apart from libc and libm - size (181K without stripping on Arch Linux x86-64, -O2) - high portability, little and confined platform-specific code, compiler-specific (symbol visibility, etc.) code confined to a small header - gracefully handles platform-specific conventions (i.e., ':' vs ';' in path variables, zero-length prefixes in path variables under *nix, directory separators, etc.) - total amount of code is circa 7.5k lines, including comments and public headers - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme counting is supported - thread safety (e.g., data types are synchronized at a very granular level, but allow you to have more coarse synchronization if you want) - extremely low memory footprint - locale-independent asprintf() and vasprintf(), C99 level (except "%lc" and "%ls" conversions, possibly they are not even needed if using UTF-8) - semi-serious, integrated and as-lightweight-as-it-can-be error/message reporting mechanism - precise and well defined error checking and error codes - includes directory traversal, dynamic loading - well documented Cons: - not yet released - no real test suite and not extensively tested - currently implemented data types: doubly linked lists and AVL trees only - not yet ported to non POSIX platforms (i.e., Windows) - API/ABI are "stable enough", but can't guarantee for total stability in the next future (i.e., no big changes will happen, yet something might change) - no locale-independent sscanf() or similar - no UTF16-BE support/conversion - till now, a one man effort That is, it is certainly possible to make it become viable to replace SLV2, but this is not high priority for me at the moment. Once the new NASPRO release is out I can consider whether to do the work, since I want to port SLV2 to Windows right after. The decision, however, depends on whether Dave would like that or not. Stefano

On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote: Sure. Sounds good, probably a good choice, and it would be nice if your work - originally intended to escape slv2 - could be used by it to make a better general solution instead :) Like you, I think releasing the current state of things is a higher priority though. Plenty enough improvement and new libraries lately as it is, time to kick it out the door and get it on users machines. We can look into this.. y'know.. later. -dr

On 02/25/2011 10:00 PM, David Robillard wrote: I will try and submit a patch to remove glib. It'll take some time because I have dozens of other things to do, but I will work on this. I had a quick look at sord, it seems it only needs glib's sequence and hash table. Is this correct, or will you need some more utilities? -- Olivier

On 03/11/2011 07:22 PM, David Robillard wrote: also care about HP-UX. So, a small abstraction layer around dlopen() and LoadLibrary() should suffice, no? No rush here as well. I can work on a patch, but on the other side I don't want to interfere if you're in the middle of your work. -- Olivier

Hi! On 03/11/2011 07:22 PM, David Robillard wrote: Alright, attached is a minimal radix tree implementation. I just wrote it from scratch. Would that work for sord? If so, I'll try and benchmark it and do some more tests. Cheers, -- Olivier

Hi Olivier, 2011/3/19 Olivier Guilyardi &lt;list(a)samalyse.com&gt;om>: I see nobody answered yet... but don't despair, it's probably because the long-awaited LV2r4 release made David want to run away for a while. :-) However, I have no idea why he needs such a thing and I have to admit my ignorance in this regard (the only thing I ever read about radix trees is the Wikipedia article, I'm afraid). In any case, I have to ping him for a number of related things w.r.t. SLV2 (Windows port, mostly), so I will try to remember him about this. Best regards, Stefano

On 24/03/11 06:10 PM, Olivier Guilyardi wrote: Sorry. I still have plenty of releases left on the table before I have time to get around to this stuff... and yes, I took a little break for a change ;) I also should have mentioned I found an old radix tree implementation of mine that should be pretty solid. I will contrast/compare these when I get the chance. The radix tree is for interning URIs. You could also use a hash table, but hash tables are ugly and clunky IMO, I prefer more elegant structures that grow organically (and radix trees are simple to implement), and as mentioned we have many common prefixes here which makes it a suitable choice. Interning URIs is used to get a number to represent a URI string. This is necessary for even remotely appropriate performance because it means statement lookup is a series of integer comparisons, and not a series of vastly more expensive (and redundant) string comparisons. For a store of n statements with URIs of length k, a search will thus be O(lg(n) + k). Without interning it would be O(k*lg(n)), and have more fragmented memory access as well. Thanks, -dr

On Fri, Feb 25, 2011 at 3:09 PM, Olivier Guilyardi &lt;list(a)samalyse.com&gt;wrote;wrote: Perhaps one of these alternatives could work as a stand-in replacement? https://secure.wikimedia.org/wikipedia/en/wiki/GNU_C_Library#Use_in_small_d… Jeremy

2011/2/25 Olivier Guilyardi &lt;list(a)samalyse.com&gt;om>: Yep. :-) Yes, I don't know the details of those mechanisms, but after seeing how Flash is distributed as an APK and integrates into the browser, I was thinking something along those lines too. True. However, my question about this Android/LV2 possibility is: what for? Any ideas? Stefano

2011/2/25 Olivier Guilyardi &lt;list(a)samalyse.com&gt;om>: The app looks very cool, having LV2 there would be awesome! Agreed. Stefano

On 25 Feb 2011 18:34, "David Robillard" &lt;d(a)drobilla.net&gt; wrote: Thanks! I hope to. I've always rather liked the look of the BSD boilerplate. For me that's OK, an LV2 implementation would be of rather different purpose from a general store implementation. Though I can imagine others finding it difficult -- I've noticed some confusion about what exactly the LGPL means for use of the LADSPA header in the past. I can see many cases for GPL libraries and BSD libraries, but I've not so often been convinced by the use of the LGPL. Chris

On Fri, Feb 25, 2011 at 7:52 PM, David Robillard &lt;d(a)drobilla.net&gt; wrote: as long as they can meet the relink requirements. not always a trivial matter.

On Fri, Feb 25, 2011 at 9:27 PM, David Robillard &lt;d(a)drobilla.net&gt; wrote: BSD is fine with me. his company in london is active and in the audio software business (ambisonics for the masses, IIRC). i can't remember its name right now, but i bumped into by accident a month or two ago. --p

On Fri, 2011-02-25 at 23:12 -0500, Paul Davis wrote: On Tue, 2011-03-01 at 08:45 +0000, Richard Furse wrote: That leaves Stefan and Steve. -dr