Re: [LAD] Programming LV2 plugin from scratch tutorial video series
On Wed, Oct 20, 2021 at 10:26:41AM -0400, David Robillard wrote: > > That C isn't trying to describe the entire world. > > This is a glaring straw man. I'm not sure what you're arguing against, > but it certainly isn't LV2. No, it isn't. Sorry if I gave that impression. It's more likely what you refer to writing > and the W3C and much of the semantic web community deserves a ton > of criticism Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Programming LV2 plugin from scratch tutorial video series
Am 20.10.21 um 16:26 schrieb David Robillard: Fair enough. "I just want to write C and only C" is a reasonable and understandable position, no need for any hand-wavey nonsense. For that case XUiDesigner may come handy, it will generate a complete working LV2 bundle from just stick a user interface per drag n' drop together. You only need to insert your dsp code to make it a real world plugin. https://github.com/brummer10/XUiDesigner ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Programming LV2 plugin from scratch tutorial video series
On 2021-10-20 14:26, David Robillard wrote: The main reason LV2 uses separate data files is so that hosts don't need to load and execute code only to discover what plugins are present. This has pros and cons, like most things. It has some merit to have all metadata in a text file separate from the binary plugin. The drawback is obviously that both need to be in-sync all the time. That however can be easily achieved by somehow automating the creation of metadata from the code (which otherwise a host would do from the binary). Whether or not the markup of text metadata is reasonable to be in turtle is mostly a style choice, it could have been XML or JSON, which have their own pros/cons, or st. else. The beauty of a single file to contain everything also has some merit. Going from a scenario, where the set of available plugins on a given systen won't change hourly, a way to tackle this would be to leave the process of finding plugins and creating a metadata (~ repository) from queryable binary files a totally separate and even optional and temporally fully user-controlled process. A host could still use that (speced-out) central repository through 'universe' or similar, but should also be able to get the info directly from a given single-file plugin path. Naively my imaginary plugin spec would eventually embed metadata as EBML at an offset to be queried by the host or the other way around, have a single EBML-encoded file with all metadata plus the binarie(s) inside. Eg. Matroska uses EBML for binary markup of video, also webp / webm is such dialect. Parsing seems very simple, it's a well-defined recursive form of where id and length are encoded as variable size integer (first byte is giving info about following data, not unlike a MIDI event in some aspect). It won't solve any semantic issues though. Without deep reasoning I mostly share Fons' views onto the surrounding topics. This of course includes also that LV2 has become a de facto standard with many 'compatible' plugins and hosts that work. This is totally separate from whining on tech / style choices :) Greetings Thomas ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Programming LV2 plugin from scratch tutorial video series
On Wed, 2021-10-20 at 10:10 +0200, Fons Adriaensen wrote: > On Tue, Oct 19, 2021 at 05:32:59PM -0400, David Robillard wrote: > > > life is hard. > > And complex, having real and imaginary parts. > > > The only reason you can understand a C header that defines a struct > > with filter coefficients or whatever is the same. > > True. > > > What's the difference? > > That C isn't trying to describe the entire world. This is a glaring straw man. I'm not sure what you're arguing against, but it certainly isn't LV2. > > If there's an impression here that somehow there is a machine- > > readable > > description of everything down to first principles that could be > > used > > to construct an implementation or whatever, that is /not at all/ > > the > > idea or intent. > > Nor would it work (IMHO). But the impression is given that it would, > in particular when discussing the alleged advantages. From who? Given how? > When some new plugin feature is defined, then in the end some human > programmer has to understand it using his/her domain-specific > knowledge. > And if that is the intent, things could be a bit simpler. Even the > very > restricted C vocabulary (and some common sense) would be enough. The main reason LV2 uses separate data files is so that hosts don't need to load and execute code only to discover what plugins are present. This has pros and cons, like most things. > A a programmer I like to avoid dependencies and keep things as simple > as possible, which probably explains why my brain goes in self- > defence > mode whenever I try to get any closer to LV2... Please don't take > that > personally, I'm very well aware of how useful LV2 has been to the > Linux Audio world. Fair enough. "I just want to write C and only C" is a reasonable and understandable position, no need for any hand-wavey nonsense. As it happens, we could do that, without even really breaking anything in a significant way, *specifically because everything is based on a simple abstract data model*. If someone makes a C API that can describe the same information, then it could be used to access the data instead. This could be used to generate static data files where that makes sense, or it could be used at runtime to dynamically discover plugins, or both. The same API could be used in either case. I would like to actually do this for various reasons, but it's not a high priority. This is the sort of thing you can easily do with a simple abstract data model (a set of triples), and that's the sort of thing that LV2 actually takes advantage of. What's going on here is really much more of a Scheme-like idea than some semantic pipe dream. So, concretely: we really could remove all of that Turtle stuff, and it would not be a very deep change, loosely analogous to just writing a different parser. Everything past that in the implementation would remain absolutely identical, not one character of code changed. That's not an accident, and this sort of thing is why people who *do* grok LV2 are not interested in throwing out all of the babies with the bathwater. The fact that we can change all of these superficialities and still retain everything that we have built so far is also a big reason why nobody cares that much. Work on new features and new/better ways of describing plugins/etc will be useful, even if LV2 evolves to become something that does not look at all like the current LV2 at first glance. We all have our gripes with Turtle, and with the idea of static metadata in separate files - but those can be addressed. > I just can't help having the impression that most of the 'semantic > web' stuff is just a load of hype. And that is something I try to > keep my distance from. As you should. It's very telling that this conversation, and most of the ones like it, are not actually about concrete technological issues. They're about people finding terms like "RDF" and "semantic web", googling them, falling down some rabbit hole or another, and ending up at very bizarre conclusions like some syntax being used makes the whole technology stupid and utopian (or whatever) because it's trying to define the entire world or... something. It's very understandable how people end up at such nonsense, and the W3C and much of the semantic web community deserves a ton of criticism for making that situation, but it's nonsense all the same. You'll certainly get no argument from me that that situation is a nightmare. I've been slowly expunging it from the documentation for years now, gently pushing third-party documentation efforts to do the same, and will continue to do so until absolutely none of it is left. Hopefully then we can spend more time talking about, and addressing, real problems... We can paint the shed whatever color we like, because the shed is built on a foundation of good ideas. The fact that some of those ideas are loosely associated with bad ones is irrelevant (except in PR terms). That's true of all ide
Re: [LAD] Programming LV2 plugin from scratch tutorial video series
On Tue, Oct 19, 2021 at 05:32:59PM -0400, David Robillard wrote: > life is hard. And complex, having real and imaginary parts. > The only reason you can understand a C header that defines a struct > with filter coefficients or whatever is the same. True. > What's the difference? That C isn't trying to describe the entire world. > If there's an impression here that somehow there is a machine-readable > description of everything down to first principles that could be used > to construct an implementation or whatever, that is /not at all/ the > idea or intent. Nor would it work (IMHO). But the impression is given that it would, in particular when discussing the alleged advantages. When some new plugin feature is defined, then in the end some human programmer has to understand it using his/her domain-specific knowledge. And if that is the intent, things could be a bit simpler. Even the very restricted C vocabulary (and some common sense) would be enough. A a programmer I like to avoid dependencies and keep things as simple as possible, which probably explains why my brain goes in self-defence mode whenever I try to get any closer to LV2... Please don't take that personally, I'm very well aware of how useful LV2 has been to the Linux Audio world. I just can't help having the impression that most of the 'semantic web' stuff is just a load of hype. And that is something I try to keep my distance from. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Programming LV2 plugin from scratch tutorial video series
On 20.10.21 00:39, David Robillard wrote: On Tue, 2021-10-19 at 22:51 +0100, Will Godfrey wrote: On Tue, 19 Oct 2021 16:58:39 -0400 David Robillard wrote: On Tue, 2021-10-19 at 19:17 +0100, Will Godfrey wrote: What is even worse, is when there is a problem of some sort with a plugin, and host reports that the (apparent) url doesn't exist! That's rather strange. Most hosts don't even do internet access whatsoever, and even if they did, I can't imagine why they'd be trying to fetch these ones. Which host? I must admit I can't find this now. I haven't checked for a long time, so I'll be the first to say I might have originally misinterpreted what I saw. Sounds like a bad error message to me. This may have shown up in a bug report with output from *lv2lint*. The latter can check for existence of license/homepage/plugin URLs. But there's no need to freak out for the average paranoid, it's a double opt-in: The feature *must* manually be enabled at compile- time and *must* manually be enabled at runtime ;-) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
