On Sat, Jun 12, 2010 at 05:40:09PM -0500, Gabriel M. Beddingfield wrote: Regarding the example, what is the function of each of amp-full.ttl amp.ttl manifest.ttl and why are these separate files ? Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Sat, Jun 12, 2010 at 05:40:09PM -0500, Gabriel M. Beddingfield wrote: Half of the URLs quoted above refer to inexistent pages. What is the purpose of 'http://' in that case ? Anyway I'd expect a plugin to work without any network or web access. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Sun, Jun 13, 2010 at 12:09:12AM +0100, Steve Harris wrote: OK, let me rephrase the question: why are such ambiguous or misleading 'symbols' being used ? And since I'm now talking to one of the experts: Can an LV2 extension redefine everything except the mimimum required for discovery ? This includes the way ports are described, the way the host is supposed to call the plugin etc. ? Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Sun, 13 Jun 2010, fons(a)kokkinizita.net wrote: Pretty much, yes. Here's how: When you instantiate the plugin (LV2_Descriptor::instantiate) you pass an array of LV2_Feature structs. This struct is very simple: typedef struct _LV2_Feature { const char * URI; void * data; } LV2_Feature; The `data` pointer can be a pointer to /anything/... but it should be clearly defined, according to the URI. Also, there is the function LV2_Descriptor::extension_data that allows the Host to query the plugin for additional 'extension data.' It doesn't take a lot of imagination to see that this could be used to define a whole different class of plugin API's that would fit within this... and that these mechanisms themselves are not too different from the basic LV2 discovery fuction: lv2_descriptor(). Port descriptions are also done by extensions, seeing as how the port parameter for LV2_Descriptor::connect_port is simply a void* pointer (i.e. anything). However, I don't see many options for redefining how LV2_Descriptor::run is called. About the only way to redefine this would be to create an empty run() method and have your subversive sub-plugin API define an alternate one. hth, gabriel

On Sun, Jun 13, 2010 at 8:59 AM, <fons(a)kokkinizita.net> wrote: supporting touch specifically requires 2 things: a) a user interface that has a distinct gesture for both the start of a touch and its end b) an explicit way to convey the use of this gesture to a control object when using the mouse, we get button press and release events, which satisfy both (a) and (b). when using external hardware controllers, many lack anything that can satisfy (a). those that do make things quite complex - for example there is a tascam controller which sends 2 different MIDI CC's when you move a fader, one to indicate the onset+end of a touch, and another to signal actual fader moves. this works well if you have a design that takes this sort of thing into account, but is horrible otherwise. i have seen quite a few reports recently that involve the Calf plugins, most of them not so great (i..e crashes etc). i have some suspicions that they do GUI operations from an illegal thread. --p

On Sun, Jun 13, 2010 at 5:38 PM, <fons(a)kokkinizita.net> wrote: Did someone mention CV as an interapp/plugin global standard, both internal as a plugin/host communication protocol and as standalone intercommunication protocol? 1 protocol language to rule them all, one protocol language to bind....never mind. Just a thought, and an ironic moment of dejavu....... -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On 2010-06-13, at 00:20, fons(a)kokkinizita.net wrote: Well, their hardly ambiguous. I would imagine that misleading-ness is somewhat dependent on your context. If you don't feel comfortable with dereferencable symbols you could use schemes such as URN (http://en.wikipedia.org/wiki/Uniform_Resource_Name) which cannot be resolved, but it's missing some of the potential advantage. http://www.w3.org/Addressing/ There are times when having the namespace be dereferencable is an advantage. If someone discovers a LV2 turtle file in the wild, but has no idea what LV2 is (this has happened) they can paste a URI into their web browser and discover more about it. I guess it's little different to googling the fingerprint of a binary data file you find, but it's much more reliable. The remaining advantage is really just namespacing, but using an existing globally deployed, cheap, and well understood allocation scheme - the DNS system and HTTP paths. You have to provide the minimum that is specified in the C header file, but you can step a long way outside it if you chose to. For example the dynamic ports extension adds a completely new type of port. I cannot be understood by hosts that do not support it of course, but they can tell that it's a plugin that they cannot make use of. There are also extensions that are back-compatibe, and the host can identify them too. - Steve

On Sun, Jun 13, 2010 at 12:58:11PM -0400, Jeremy wrote: Glad to know I'm not the only one. I've been wondering what is the purpose of things like: @prefix : <http://lv2plug.in/ns/lv2core#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema> . @prefix doap: <http://usefulinc.com/ns/doap#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . where 'doap' stands for 'Description Of A Project', and 'foaf' for 'Friend Of A Friend'. If this has to be part of an LV2 plugin somehow (and it's not clear if it has to be or not), AND whatever software that is reading this is *not* supposed to follow these links and find some information there, what is the purpose ? If these things are not a required part of any LV2 file, what are they doing in the documentation (except confusing people) ? I'm more and more convinced that people creating these sort of thing entertain the illusion that they somehow create meaning while there is none. It looks more like an extreme form of illiteracy, a complete failure to convey meaning in a form that makes sense to a human. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On 2010-06-13, at 21:50, James Morris wrote: My LV2 plugins are generated from XML. Someone else has a system that builds them from C++ classes. - Steve

On Sun, Jun 13, 2010 at 05:08:55PM -0400, Paul Davis wrote: As a mathematician I'm familiar with formalisms and abstractions hat are some orders of magnitude more complex than the one at hand. But at least in that field they do have a meaning and a purpose. You say these things 'are not there to convey meaning to a human'. OK. Before it was stated that the software reading them is not supposed to follow these links and get any information from them. I and assume that the same software is not capable of 'understanding' them spontaneously either, or with some help of the Holy Spirit. So what purpose do these things have if they are not meant for a human reader and irrelevant to any software ? If in the end something that is described in this convoluted way as e.g. a 'port label' ends up to be displayed in the right place, probably as some text besides a visual representation of a port, then that is possible *only* because of one reason: *** the programmer who wrote the software doing this did *** understand the meaning of the English word 'label', *** and wrote his code based on that understanding. All the rest is, IMHO, pure BS. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On 06/14/2010 12:02 AM, Paul Davis wrote: than identification and categorization: "LV2 offers identification of plugins and ports not (necessarily) by obscure ID numbers, but human readable URIs and port symbols. The URI can be a web address (optionally, any URI is fine). This allows the use of HTTP content negotiation to ask for the RDF of a plugin originally only the URI is known of. The RDF could include machine readable information about where to get the plugin. Thus sharing files that reference plugins such as sequencer sessions or modular synthesizer patches would become more comfortable, as missing plugins could be fetched automatically (or finding them would be easier, at least)." This last sentence seems to clarify the idea behind URIs. -- Olivier

Hi drew, On Mon, 14 Jun 2010, drew Roberts wrote: These are globally unique names (identifiers). They have a standard syntax that is easily parsed by a machine. They also have a syntax that allows you to have any manner of strange versioning scheme without stepping on the toes of my plugin. Alternatives to this system are UUID/GUID's like: {C51D1AA2-DEE3-48D5-B5F0-E90F530F701D} {C7FFBB63-24B6-47D3-BB37-771B61A642F8} {E2BD858E-B848-4618-9FD6-54281B9B1ADB} {B17F7836-C46E-4477-B688-55A76073EF3D} Or a rigidly-enforced naming scheme that everyone must follow when making their LV2 plugin. Something like: foomatic-eq_1.0.0-5_i386 Where everyone has to be careful about dashes, underscores, dots, and how version numbers are handled. Using URI's is preferred because they're both machine and human readable... and it's /possible/ that the plugin author will throw up a page at the end of the URL with some kind of documentation. For example: XML namespace URI's are exactly the same. The XHTML 1.0 namespace is 'http://www.w3.org/1999/xhtml'. It identifies the rules about how the document may be structured. When parsing an XHTML doc, the application has to already have support for that... becuase it won't get any help by following the URL. However, if a human follows the URL, they'll get some pointer regarding XML namespaces from the W3C. They are names for identifying a published component (be it a plugin, host, RDF schema, etc.). The host application has to already have support for it. Meanwhile, if a human stumbles on it, it can /possibly/ give them a few clues about where to look for help or to find out who published it. -gabriel

On Mon, 14 Jun 2010, fons(a)kokkinizita.net wrote: Ha! No. :-) But they do have better syntax-creep resistance. I was thinking along the lines of Debian's rules for how binary package (.deb) files are named.[1] The underscore becomes a field separator, and in some contexts the dash '-' becomes a micro-separator. But maybe that example doesn't apply so well. But it's a similar battle: trying to avoid naming collisions. Glad I could help! -gabriel [1] I'm not picking on Debian. I think all distros have some kind of scheme like this.

On 06/14/2010 10:23 AM, Jeremy wrote: ...and in that one line you have explained the entire basis of this discussion. well done you ;) will it change anything?? who knows, but it's a good starting point from a laymans' point of view. as an enthusiastic LV2 user I wonder how many other devs have balked at this and just walked away from LV2... Hey Fons, does all this discussion mean you're thinking about whipping up a few plugs then?? (please please please..) best, g.

On Mon, Jun 14, 2010 at 7:34 AM, Patrick Shirkey &lt;pshirkey(a)boosthardware.com&gt; wrote: Patrick, great read. And the challenge you've expressed so well here is also applicable to the relationship between devs and users too, with expectations on both sides that regularly fail to connect. If talented chaps like yourself and Fons find the coding side of documentation for LV2 confusing, then a user wanting to get involved in assisting devs with their projects, with the altruistic intent of making a contribution, is almost certainly doomed to be bewildered at the first hurdle. This is more common than devs might think, and there's several projects i've looked at and tried, that could seriously do with dumbed down examples of .conf, .rc, .xml, .something, files to at least give users a start, so they then in turn can give something back, as they grow to understand the app they're trying to use. An example of how this works well is jconvolver, with easy to follow examples, and a chance for stubborn/foolish/brave/pick one chaps like me then able to, in turn. offer help to new users, and so the process continues. A poor example of this is jackmixdesk, with a vital disconnect at the important stage of trying to use the app, as the "dumb user" walkthrough of the actual process of using the app is missing, and the dev seems to have since moved on. The result is a significant, if modest, critical mass of users getting enthusiastic about jconv (and i confess to telling everyone i can about this very powerful app), and the opposite for jackmixdesk. No offence to the JMD dev, as i'm sure it's a clever and ultimately usuable app, but not in it's current state, (unless the dev has expressly intended the app for personal use, or an academic exercise), for lack of that walkthrough at the simplest level. I don't doubt the intent of LV2 is to unify a format, nor do i doubt the massive potential, and frankly, plain common sense in doing this. But like the lack of user critical mass for many LA apps for the reason i gave (and this view is not just mine, as a browse through related fora will demonstrate), there is a disconnect of intent from the community to come together (putting aside differences) in a concentrated effort to bring such a potential winner for all, to a reality that enables the less talented, or new on the block contributors, to take this concept, and fly with it, as seems to be the intent. Dangerous Dave R continues to get my admiration and respect for taking this on, along with the team of contributors who see the potential for growth and success in a unified format. From the perspective of a user who's had to face a multitude of bewildering options when using linux audio apps, and the missing bits in the learning chain through the assumption that we're all coders, or programming language aware, i understand the confusion. We're not all coders, and not all coders are as talented as many of you chaps, at least not yet. Making it as easy as possible to get them involved, and encouraging and supporting them to getting further involved, seems to make sense, and unless i have this wrong, would increase the core numbers of devs in the LA community, with the result of more hands on deck to share some of the donkey work. LV2 isn't just a viable plugin format, at least for me, as a user. It's more important than that, as it represents part of the fundamental fabric of LA, like jack. If there's a perception of confusion at the dev level, then users are likely to be thoroughly bewildered. Contrary to what seems a common perception, the CALF standalone host and plugins work well for me, and i defer to them more often than not, if i need an effect of some sort. Why? Because although some discussion might be viable as to their construction, or how "tidy" they are code wise, they're USER friendly, to the point i don't have to think about it. Well done the CALF team, for presenting the "product" in a user friendly environment. If there's one thing devs can do to get more users involved, it's to present dumbed down examples of use/workflow for their apps, for users who know nothing about coding, and are unlikely to want to learn. The modest time taken to do this will, imho, greatly increase the potential for many more users and modest coders getting involved in our little community, and create a larger group of users who can in turn assist new users, and so on. Some of those users may be good graphics artists, or competent at building websites, skilled at marketing, good at fundraising etc... I assume, in the above comments, growth and progress is the intent of our community and it's core of extremely talented people, coder and user alike. 2 roubles worth. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On Mon, Jun 14, 2010 at 11:49 AM, &lt;fons(a)kokkinizita.net&gt; wrote: Now i'm enthusiastic again, and struggling to be patient... Fons, a question. In the framework you've described, would it feasible or possible to run the host and plugins as a "backend" on a headless rig, and run the gui on the main daw box, in an attempt to offload some of the grunt work? Alex. p.s. If you want a dumb 64bit user tester who's likely to try and break this, using a big orchestral project session, call me..... :) -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On Mon, Jun 14, 2010 at 12:47 PM, &lt;fons(a)kokkinizita.net&gt; wrote: Aah, riight. I misunderstood the structure of what you're doing. Alex. -- www.openoctave.org midi-subscribe(a)openoctave.org development-subscribe(a)openoctave.org

On Mon, Jun 14, 2010 at 08:04:06AM +0100, Steve Harris wrote: To whom or what ? If the destination is a human, something like # Author: Steve Harris # License: GLPv2 would seem a bit more user friendly. I've never seen one. And certainly when I'd see one it wouldn't look very inviting to read it. Is this meant for humans ? If not *which software is reading this, and what is it doing with the information provided* ? After reading that for the N-th time, it's not clear at all if the lines quoted above (from that very file) are required or not, and *if* they are required, for what purpose - how this information is used. If the links are not followed, they are little more than magic incantations. Does the software that reads someplugin.ttl depend on these things or not (AFAICS it doesn't) ? It's not an attack but an opinion, and certainly not directed at you (Steve) personally. If I wanted to attack you 'ad hominem' I would not choose a subject in which you are 1000 time more expert than I am - it would be very easy to select one where the roles would be reversed. Such a mass hysteria wouldn't be the first one - we've seem some bubbles bursting before. And whatever problem these companies are solving seem to be quite remote from audio plugins. The essential point in my comment is that it is foolish to confuse the 'semantic web' with reality. Are your 13857 Facebook friends real friends ? Are those 200e6 'FOAFs' what they claim to be ? Back to the technical side, it all seems as futile as including a complete BNF of the C language (or a reference to it) at the top of each *.c source file. It's useless to the compiler (which is not going to modify itself), and it's useless for the human reading or editing the file. And again, if in the end information such as e.g. port min, max, default, etc. has its intended effect, that does not happen magically because of the RDF. It happens only because some human at some point understands the meaning of these terms and their intended use. If the RDF form would really convey meaning by itself, you should be able to replace e.g. 'min, max, default' by 'sdf45xef, j73dfhshf, sdclkle82), and they would still have the intended effect. This is clearly *not* the case, it all depends on a human understanding those words, and a human can perfectly (and even much more easily) understand these without all the semantic gobbledegook. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

Steve Harris wrote: Correct. People I know and I, we never take care of this data. I read this by random, after I stopped reading this thread. You are all gifted coders and you do waste your time with a discussion about this issue. I'm watching this from the sidelines. It doesn't matter who is "right" or who is "wrong". As a Linux user I beg, give us users more LADSPAs, DSSIs and LV2s and if there are bugs for existing ones, cancel those bugs. If you would talk about technical issues, I hopefully would shout my mouth ... but AFAIU you are talking about minor stuff. You waste your talents. It isn't something pretty to watch.

On Mon, 14 Jun 2010, fons(a)kokkinizita.net wrote: [snip] These are macro declarations. When a computer reads and processes the .ttl file, it will expand rdf:foo Into <http://www.w3.org/1999/02/22-rdf-syntax-ns#foo> (Or something like that.) The intention with the plugins is that all metadata is able to be parsed by the computer and presented to the end-user in the host application. You DO NOT need these macros unless you want to use them to save on typing (and human-readability). They are globally unique ID's that refer to a published (RDF) metadata schema. -gabriel