| drobilla | Blah, well, that was way more work than expected | 00:16 |
|---|---|---|
| drobilla | I guess we'll see what the fallout is. Since we have so little cross-project communication based on atoms other than MIDI at present, there shouldn't be much if any | 00:16 |
| * drobilla checks in The Great LV2 Object Simplification | 00:55 | |
| drobilla | Apologies in advance for all the deprecation noise :) | 00:56 |
| drobilla | falktx_: Good grief, -Wconversion is noisy | 00:59 |
| falktx_ | hehe, welcome | 01:00 |
| falktx_ | you feel the pain now | 01:00 |
| drobilla | I dunno, bit much. Ultimately the "fix" is just stick a massive amount of explicit casts everywhere there's a warning | 01:01 |
| falktx_ | atom* and event-helpers are the noisiest ones | 01:02 |
| drobilla | ev->time.frames being 64-bit is a bit odd and causes them, too | 01:15 |
| * drobilla shrugs | 01:15 | |
| drobilla | 64-bits were available, I figured Sequence wasn't necessarily limited to a single process cycle | 01:16 |
| * drobilla wonders exactly how this will bite him in the ass | 01:28 | |
| * drobilla does not wonder if | 01:28 | |
| falktx_ | blame me afterwards :) | 01:29 |
| drobilla | Oh, I will :) | 01:30 |
| drobilla | apparently uint16_t + uint16_t => int | 01:32 |
| falktx_ | yes | 01:32 |
| falktx_ | same with chars | 01:32 |
| falktx_ | char('a') + char('b') => int | 01:32 |
| falktx_ | it seems gcc temporarily converts vars to int when doing calcs | 01:33 |
| drobilla | Not so annoying with atom's uint32_t | 01:33 |
| drobilla | Pretty annoying with event's uint16_t | 01:33 |
| drobilla | I sometimes go the other way from the whole "SDK with everything in it" thing and wonder if utility headers should really be in the spec distribution at all | 01:37 |
| drobilla | Anything else would make distribution more tedious, though | 01:37 |
| drobilla | falktx_: http://lv2plug.in/changeset/903 | 01:49 |
| drobilla | I haven't touched event-helpers in ages, nor have I tested it. You may want to do so. | 01:50 |
| falktx_ | btw, I think this: | 01:50 |
| falktx_ | return (uint32_t)sizeof(LV2_Atom) + atom->size; | 01:50 |
| falktx_ | can become this: | 01:50 |
| falktx_ | return atom->size + sizeof(LV2_Atom); | 01:50 |
| falktx_ | the first is uin32_t, so size will adapt. not 100% sure though | 01:51 |
| falktx_ | *sizeof will adapt | 01:51 |
| drobilla | nope | 01:52 |
| *** kaspar_e has quit IRC | 01:54 | |
| * drobilla runs it on drobillad for kicks | 01:54 | |
| drobilla | hah, yeah, not a chance | 01:55 |
| drobilla | I am really dismayed that serd isn't -Wcast-qual (and I suppose -Wconversion) clean, though | 01:55 |
| * drobilla returns to something that actually needs doing | 01:55 | |
| *** HarryHaaren has quit IRC | 01:55 | |
| *** unclechu has quit IRC | 01:56 | |
| drobilla | Atom type hierarchy without Blank and Resource: http://drobilla.net/files/lv2_atom_class_hierarchy.pdf | 01:58 |
| drobilla | Speaking of which, if anyone happens to have the time to proof-read a probably ~5 page paper on atoms this weekend, I'd appreciate it | 02:02 |
| *** bazz has quit IRC | 02:04 | |
| *** bazz has joined #lv2 | 02:04 | |
| *** falktx_ has quit IRC | 02:49 | |
| *** falktx has joined #lv2 | 02:49 | |
| *** NickSB2 has quit IRC | 02:54 | |
| *** speps has quit IRC | 04:43 | |
| *** falktx has quit IRC | 05:36 | |
| *** rncbc is now known as rncbc|AFK | 07:00 | |
| *** edogawa has joined #lv2 | 07:08 | |
| *** abique has joined #lv2 | 07:55 | |
| *** kaspar_e has joined #lv2 | 09:40 | |
| *** NickSB2 has joined #lv2 | 09:43 | |
| *** kaspar_e has quit IRC | 11:07 | |
| *** kaspar_e has joined #lv2 | 11:43 | |
| *** unclechu has joined #lv2 | 11:49 | |
| *** kaspar_e has quit IRC | 12:30 | |
| *** kaspar_e has joined #lv2 | 12:30 | |
| *** sigma6 has joined #lv2 | 13:15 | |
| *** unclechu has quit IRC | 13:18 | |
| *** bgola has quit IRC | 13:43 | |
| *** edogawa has quit IRC | 13:43 | |
| *** edogawa has joined #lv2 | 13:43 | |
| *** awilliams has quit IRC | 13:43 | |
| *** bgola has joined #lv2 | 13:45 | |
| *** awilliams has joined #lv2 | 13:45 | |
| *** wrl has quit IRC | 14:21 | |
| *** falktx has joined #lv2 | 15:49 | |
| *** rncbc|AFK has quit IRC | 15:49 | |
| *** rncbc|AFK has joined #lv2 | 15:50 | |
| *** kaspar_e has quit IRC | 15:54 | |
| *** abique has quit IRC | 16:12 | |
| *** HarryHaaren has joined #lv2 | 16:13 | |
| *** kaspar_e has joined #lv2 | 16:47 | |
| *** rncbc|AFK is now known as rncbc | 17:37 | |
| drobilla | I think it might be time to add an lv2:MIDIPlugin class | 17:45 |
| drobilla | Perhaps a slightly more generic event or music or something... | 17:46 |
| drobilla | 'Filter' is now full of rgareus's midifilters stuff, which really doesn't fit in with the lowpass and friends intention of that one | 17:47 |
| *** sigma6 has quit IRC | 17:48 | |
| *** falktx has quit IRC | 18:34 | |
| *** rncbc is now known as rncbc|AFK | 19:00 | |
| *** HarryHaaren has quit IRC | 19:47 | |
| *** HarryHaaren has joined #lv2 | 19:48 | |
| *** mlpug has joined #lv2 | 19:51 | |
| drobilla | rgareus: So my general plan for this paper was 1) what's an atom / data model / binary format 2) serialisation 3) communication via ports 4) forge 5) property-based state 6) a general protocol for manipulating that state | 20:03 |
| drobilla | I am wondering if 5 and 6 is really the right thing to work towards, though. Maybe there's a better "point" to build up to? | 20:04 |
| drobilla | s/rgareus/whoever/ | 20:04 |
| rgareus | 5,6 could be a separate paper | 20:04 |
| drobilla | Could be, but leaves it a little bare, and also raises the question "so... what's a use of all these fancy datatypes anyway?" | 20:05 |
| drobilla | A simple example would be setting the sample filename property as in eg:sampler, a thing you can not do with MIDI | 20:05 |
| *** falktx has joined #lv2 | 20:05 | |
| drobilla | It surely needs *some* compelling example | 20:08 |
| drobilla | I'm just not sure setting property-based state is the right one. That may be a 'Future Work' thing | 20:08 |
| Anchakor | the paper definitely should explain the motivation and the vision - why it is the way it is | 20:09 |
| drobilla | Well, ultimately it's "you can represent whatever and serialize it, yay" but more tangible audio-related examples are nice | 20:11 |
| drobilla | The patch extension might be too much, I don't know, but that e.g. Ingen does *everything* it does via a couple of such message types is a nice example of what this does that MIDI and OSC can't really | 20:12 |
| drobilla | Maybe really affirm the point that these are just types and you don't have to use them, then present as an example loading a sample as eg:sampler does | 20:14 |
| rgareus | drobilla: eg:sampler is probably as simple as it gets. | 20:14 |
| drobilla | It's hard to target this at such a diverse audience | 20:14 |
| rgareus | drobilla: as for 'real world' examples, I can supply many :) | 20:14 |
| drobilla | Half tempted to try to realize that C++ forge API so I can show prettier code :) | 20:15 |
| rgareus | drobilla: could be waveform visualization ( not only sampler but IR) --fixed data transfer | 20:15 |
| Anchakor | for me the concept of plugins changing non-stream data and events, such as mathematically defined curves is appealing | 20:15 |
| rgareus | drobilla: or realtime visualization.. which requires 'objects with state'. eg histogram view in Ebur-128 meters.lv2 | 20:16 |
| drobilla | This would be that message: http://pastebin.com/VDBnPQGV | 20:16 |
| drobilla | More matheyness would probably be good for this crowd I suppose | 20:17 |
| drobilla | (this=LAC) | 20:17 |
| drobilla | patch:Put is a little less obvious than patch:Set though | 20:18 |
| drobilla | Actually, envelope points, I'm not sure. This vocab is based around subjects, but you probably don't want to deal with that here | 20:20 |
| drobilla | rgareus: Where can I find the messages you use in that one? | 20:21 |
| rgareus | they're just arrays for the most part | 20:22 |
| drobilla | probably not so good as examples | 20:22 |
| drobilla | I figured sticking to only talking about one container (object) would keep things more easily digestable | 20:23 |
| rgareus | drobilla: one example is https://github.com/x42/meters.lv2/blob/master/src/ebulv2.cc#L369 | 20:23 |
| drobilla | Hm, that's not bad | 20:24 |
| drobilla | Bit big. | 20:25 |
| drobilla | P.S. I added forge_key which will save you 13 characters on those lines | 20:26 |
| drobilla | Well, I guess I can just send objects like this, and not do the whole property-based patch extension thing at all | 20:32 |
| drobilla | It is nice that the filename property from sampler directly corresponds to what's saved in state, though | 20:32 |
| rgareus | drobilla: forge_key is new in lv2 1.8.0? | 20:35 |
| drobilla | rgareus: no, just svn, so actually switching wouldn't be wise. just saying. | 20:38 |
| drobilla | I deprecated atom:Blank and atom:Resource an added forge_key thus far. Not so conservative changes in svn right now. | 20:39 |
| drobilla | Anchakor: ... thinking about those envelope points has me considering if I really want to ditch blank node IDs | 20:39 |
| drobilla | I wonder if/when we'll run in to 'too many mapped URIs' bloat | 20:40 |
| drobilla | Perhaps I should relax patch:subject so it can be whatever, say, a number | 20:41 |
| Anchakor | for the things you want to use blank nodes, do you really need a RDF identifier at all? | 20:43 |
| drobilla | s/RDF // then yes | 20:43 |
| drobilla | kind of inherently | 20:44 |
| drobilla | Well, I guess not, there's identity-via-value, like lv2:symbol for ports | 20:44 |
| drobilla | Basically I'm just confronting that the patch vocabulary doesn't seem like it would be able to do something like arbitrary envelope points well | 20:45 |
| drobilla | Which isn't really a big deal, but in general I think it's good to try and minimize message type bloat | 20:45 |
| Anchakor | I mean in a waveform you don't need an unique identifier for each point, you just need a way to get its value | 20:45 |
| Anchakor | aka the unique identifier is a combination of another unique identifer (that of the waveform) and an offset number | 20:46 |
| Anchakor | (maybe bad example) | 20:46 |
| drobilla | I guess to be a truly general 'RDF manipulation' vocab it needs to be able to do such things | 20:46 |
| drobilla | patch:identity [ eg:someidprop "me!" ] or something, if patch:subject won't do | 20:47 |
| rgareus | drobilla: it's a nice additiion; but as you say: I'll postpone the update until... it moved from your SVN to debian/stable :) | 20:47 |
| drobilla | (this is very well into the territory of shit I would never mention in this paper, but it's interesting) | 20:47 |
| drobilla | Anchakor: You know what would be nice? If the damned RDF community had a clue about metacircularity and I could just use SPARQL for this :) | 20:48 |
| drobilla | But it'll be a cold day in hell before I involve SQL in any of this, so here we are, inventing that wheel. Anyway. | 20:49 |
| Anchakor | I probably wouldn't go further with the RDFization then "save this data as object of triple with this property' | 20:53 |
| drobilla | Projects that have more cohesion so you can just change the world if you figure out better thigns are so nice. APIs are the bane of my existence. | 20:53 |
| drobilla | Anchakor: I only barely mention it, mainly due to the serialization to Turtle part | 20:53 |
| Anchakor | as in not involve some envelope ontology | 20:53 |
| drobilla | Anchakor: With atom stuff I talk about dictionaries, and generally try to pitch a JSONey flavour | 20:53 |
| Anchakor | just focus on the point that atoms are for transferring arbitrary structured data | 20:54 |
| drobilla | Maybe the eg:sample thing and an arbitrary object, like a point | 20:54 |
| drobilla | http://pastebin.com/e7jHBvpF | 20:54 |
| drobilla | Better more audioey example instead of point welcome | 20:55 |
| drobilla | Especially if it would appeal to LAC review committee people :) | 20:55 |
| Anchakor | what about the sample waveform? | 20:55 |
| drobilla | Problem with that is the code to forge such a thing is pretty hairy | 20:55 |
| drobilla | and the serialization isn't so obvious to the uninitiated. I did show a nested object (property with blank node value), but that's probably as far as that should go | 20:56 |
| drobilla | It's unfortunate that vectors and tuples have to be distinct for optimization reasons. The RT audio domain makes this model messier than it could be | 20:57 |
| Anchakor | ADSR envelope is another good example | 20:57 |
| Anchakor | it's just 4 values | 20:57 |
| drobilla | It would be good to avoid "why wouldn't you just use control ports for that?" | 20:57 |
| drobilla | i.e. things you might want to have an arbitrary number of | 20:58 |
| Anchakor | that's true | 20:58 |
| Anchakor | so scrape that :0 | 20:58 |
| Anchakor | :) | 20:58 |
| Anchakor | like I said I like the math definition of a curve/function | 20:58 |
| drobilla | more concrete example? | 20:59 |
| drobilla | ramped controls are another one, but I think I might leave that for "future work" since expressing control is something lots of people have lots of strong opinions about | 21:00 |
| Anchakor | like a plugin for defining such a curve and then other plugins modifying copies of the curve to apply it as envelope/automation curve | 21:00 |
| drobilla | Heh, on that, I just noticed that http://lv2plug.in/gmpi.html is now Google hit #2 for "GMPI recommendations" :) | 21:00 |
| Anchakor | then you only modify the original curve and the derived curves change accordingly | 21:01 |
| drobilla | You just lept like 5 light years away | 21:01 |
| Anchakor | yeah, but that is the VISION ;) | 21:01 |
| drobilla | Shared cross-plugin mutable data and oh my | 21:01 |
| drobilla | I'm not even sure that is the vision (I think we discussed this earlier) | 21:01 |
| drobilla | More in the "HTF should Ingen work?" domain, anyway | 21:01 |
| drobilla | Multi-touch gestures is one something like points, if going the UI direction is good | 21:03 |
| Anchakor | well I hope we won't need to make lv3 to make it possible | 21:04 |
| drobilla | Well, technically it's almost impossible we "need" LV3 for anything, since you can graft on whatever | 21:04 |
| drobilla | There's some kind of line there where you might as well, though | 21:04 |
| drobilla | With that, it's more of a question of whether you even want to do it | 21:04 |
| drobilla | Shared mutable data is, in general, evil | 21:05 |
| drobilla | An infinite world of problems | 21:05 |
| drobilla | Best avoided if at all possible | 21:05 |
| Anchakor | the way I understood it, atom ports are supposed to send arbitrary structured data as messages (aka events) between plugins and hosts, so that is a way how to implement it | 21:05 |
| Anchakor | kinda like in PD sending messages | 21:05 |
| drobilla | Sure, if they're small enough to send the whole thing as a message, then no problem. | 21:06 |
| drobilla | I can't think of a very simple compelling example along those lines, though. | 21:06 |
| Anchakor | yeah no need for shared mutable data for small stuff like that | 21:06 |
| *** NickSB2 has quit IRC | 21:06 | |
| *** ssj72 has quit IRC | 21:07 | |
| Anchakor | btw small for you is < 1kB? | 21:07 |
| * drobilla shrugs | 21:07 | |
| drobilla | Sure | 21:07 |
| drobilla | Ingen sends stuff in the hundreds-of-bytes range, probably over a KB at times | 21:08 |
| Anchakor | well maybe later for bigger data an established data transfer protocol could be used | 21:09 |
| drobilla | Ultimately we need facilities to request larger buffers, possibly more sophisticated ones at some point, but http://lv2plug.in/ns/ext/resize-port#minimumSize suffices for now | 21:09 |
| drobilla | I find it unlikely that adding yet another mechanism will ever be a net good idea | 21:09 |
| *** HarryHaaren has quit IRC | 21:09 | |
| drobilla | Filter coefficients? | 21:11 |
| drobilla | I dunno, maybe just an x/y/size point as pasted is fine and I shouldn't worry about the example too much | 21:11 |
| Anchakor | [21:57] [ drobilla] It would be good to avoid "why wouldn't you just use control ports for that?" | 21:11 |
| drobilla | True | 21:11 |
| Anchakor | I still think the curve is a good example, maybe not the big vision of plugin communication, but just for saving it as state, for example as shape of the release curve | 21:15 |
| drobilla | [] | 21:16 |
| *** ssj72 has joined #lv2 | 21:16 | |
| drobilla | a eg:Segment ; | 21:16 |
| drobilla | eg:endX 1.6 ; | 21:17 |
| drobilla | eg:endY 0.5 ; | 21:17 |
| drobilla | eg:shape eg:linear . | 21:17 |
| drobilla | I wonder if the (new?) top level inline blank node syntax is less confusing for the initiated | 21:18 |
| *** rncbc|AFK has quit IRC | 21:19 | |
| drobilla | Which would be | 21:19 |
| drobilla | [ | 21:19 |
| drobilla | a eg:Segment ; | 21:19 |
| drobilla | eg:endX 1.6 ; | 21:19 |
| drobilla | eg:endY 0.5 ; | 21:19 |
| drobilla | eg:shape eg:linear ; | 21:19 |
| drobilla | ] . | 21:19 |
| Anchakor | how would you explain to the people why this should be RDF an not a binary blob? | 21:19 |
| drobilla | It is a binary blob. | 21:19 |
| drobilla | It happens to be serializable to Turtle, and it happens to be more convenient to talk about it that way, being humans and all | 21:20 |
| drobilla | As opposed to a meaningless binary blob like an arbitrary C struct, mainly that it's portably serialisable and more flexibly extensible | 21:20 |
| Anchakor | yeah ok, but I would pick an example something which is not serializable do RDF (aside from being a literal) | 21:21 |
| Anchakor | s/do/to/ | 21:21 |
| drobilla | I am not sure what you mean | 21:21 |
| drobilla | In a paper essentially about this data model, I don't want to use an example that doesn't even use it | 21:22 |
| Anchakor | for example the path to a sample is a nice simpel string, everyone understands that | 21:22 |
| drobilla | That it's serialisable is a very large part of the point | 21:22 |
| drobilla | Yes, but you can't just send a path. Path to what? What's this path mean? | 21:22 |
| Anchakor | path to a sample, the property in the triple is the important thing | 21:23 |
| Anchakor | not if the value is a literal or another RDF node | 21:23 |
| drobilla | I don't understand. You want not RDFey then you say "property in the triple" | 21:23 |
| Anchakor | s/value/object/ to keep the RDF terminology | 21:23 |
| drobilla | There are two examples here. One sets a property, being a message designed to do just that. | 21:24 |
| drobilla | This point one does not. It's just a point. | 21:24 |
| Anchakor | I think it is more accessible to explain this as a sort of key-value store, where the keys are unique identifiers | 21:24 |
| drobilla | In atomese these are "objects", which are essentially dictionaries. | 21:24 |
| drobilla | "dictionary" being by far the most accessible way to pitch it, IMO. | 21:25 |
| Anchakor | then go on explaining that you can by atom transform binary blobs or more structured data | 21:25 |
| drobilla | But basically the intent of this point example is it's just some arbitrary dictionary thing you can send that a plugin author can invent | 21:25 |
| drobilla | Explicitly because this conversation has more or less convinced me to not go off into patch vocab land | 21:25 |
| drobilla | Yes, there will be a few sentences in there about how you can send whatever, like MIDI, and there's atom:Chunk though using it is not a good idea, blah blah | 21:26 |
| drobilla | That's trivial, though. The standard type model is more or less the point of the paper. | 21:26 |
| drobilla | Perhaps it shouldn't be, but I certainly can't fill a paper with "stuff starts with a 32-bit size and type". If this isn't the meat, then something else would have to be | 21:27 |
| *** Gethiox4 has joined #lv2 | 21:27 | |
| drobilla | Ultimately I *want* to convince people building meaningful standard types is good, and meaningless binary crap is bad | 21:28 |
| drobilla | Examples specifically highlighting that would be best, but it's tough without getting into inter-plugin comm | 21:28 |
| *** Gethiox3 has quit IRC | 21:28 | |
| Anchakor | well I think the best is if you drafted the thing and I can then offer advice how to make it better, rather then theorizing now | 21:30 |
| drobilla | Plus this is a pseudo-academic paper, if there's anywhere to really describe this, it's here | 21:30 |
| drobilla | Fair enough | 21:30 |
| drobilla | Hopefully I can finish the draft today.. taking way more time than expected :/ | 21:30 |
| Anchakor | I think I'm in a good position to do so, since I understand the semweb fairy land, but on the other hand don't see a reason a common audio dev would understand why building meaningful standard types is good, so the paper would have to convince me too :) | 21:31 |
| drobilla | That is mainly why my original 'culmination' was how it meshes with state | 21:32 |
| drobilla | Then in future work mention plans to make an automagic framework to do all this for you, and just provide some 'property changed' callbacks or whatever | 21:32 |
| drobilla | I am starting to be convinced that I *shouldn't* mention arbitrary objects at all | 21:33 |
| Anchakor | for the functionality of state it is irrelevant if you have ':xyz :envelope "j4u3i2hd3h2..." .' or ':xyz :envelope [ ... ] .' | 21:33 |
| drobilla | Maybe the whole thing is just a big wank and you should indeed just send around C structs | 21:34 |
| drobilla | Maybe even over the network you only care about x86 anyway | 21:34 |
| drobilla | Maybe you don't care about engine/UI separation whatsoever | 21:34 |
| Anchakor | I think it's not a wank if you consider interoperability of plugins and hosts made by different people | 21:35 |
| drobilla | Well, yes, but obviously (I'd think) it's more compelling to show sensible things and not big strings of binary mess | 21:35 |
| Anchakor | so that is probably the big point in the argument | 21:35 |
| drobilla | That (+ network capability) are a big part of the point | 21:36 |
| drobilla | There's also a 'this is based on very simple obvious necessary things' argument I'm trying to work in there somehow | 21:36 |
| drobilla | Like, WTF good is a plugin framework if you can't send an int around? Absurd. | 21:36 |
| Anchakor | but then if you are talking only about sending atoms between host and a plugin, then it is less obvious to see why such interoperability is needed | 21:36 |
| drobilla | So, we have an int container, and some other primitives. Obvious. | 21:36 |
| drobilla | Build a wee bit on top of that and you have a fancy data model, but ultimately, you need something more or less like this anyway to do anything serious | 21:37 |
| Anchakor | with communication between plugins, it is suddenly obvious why there should be a standard atom format for an envelope | 21:37 |
| drobilla | Well, hosts and plugins are written by different people. UI:Plugin is the only real case where that's not usually true. | 21:38 |
| drobilla | Yep. Even just plain old numeric controls. | 21:38 |
| drobilla | I am not sure how popular using a dict for that will be, though. | 21:38 |
| Anchakor | how about values with different units as an example? | 21:38 |
| drobilla | Units somehow would be good. Been wondering if I want to get into controls since we don't have a standard vocab for that yet | 21:40 |
| drobilla | Port groups would also be good, but gets blank nodey | 21:40 |
| Anchakor | hmm how about an example of using a saved state from one plugin (a filter) and then using it with different plugin (also a filter of same kind)? | 21:40 |
| drobilla | Can of worms, that. | 21:41 |
| Anchakor | thats as far as you can get with examples of host-plugin interoperability | 21:41 |
| drobilla | One nice thing that justifies state being similar is expressing default state in the plugin .ttl file | 21:41 |
| drobilla | Also justifies why meaningful | 21:42 |
| drobilla | (in other cases hosts could serialize to whatever) | 21:42 |
| Anchakor | exactly | 21:42 |
| drobilla | Back to the original focus on mesh with state, I suppose | 21:44 |
| Anchakor | I guess all the exciting things once can look forward to to overcome the distaste to learn and adopt, are kind of cans of worms from your point of view | 21:45 |
| drobilla | Not really, but there is no direct sharing of plugin state like that, nor should there be | 21:52 |
| drobilla | You communicate with messages, full stop. | 21:52 |
| drobilla | These messages being property-based and correlating to plugin state is convenient in several ways | 21:52 |
| drobilla | But I don't want to imply that the state one plugin saves on disk is somehow directly accessed by another. That *is* a can of worms | 21:53 |
| drobilla | You can sort of share default state descriptions in your .ttl I guess, but that's basically a mildly convenient abbreviation | 21:53 |
| *** mlpug has quit IRC | 21:55 | |
| drobilla | The main benefit mesh with state-as-in-saved-stuff is that a plugin author doesn't have to design a whole new model to save and restore. You can store all your properties that you use at runtime, andd to save and restore just dump/load those | 21:55 |
| drobilla | Ideally, in the future, all done automatically by reusable StateDictionary thingie | 21:55 |
| drobilla | (Which I would try to just write if I had the time but I don't) | 21:55 |
| Anchakor | right, but that doesn't address the interoperability aspect - you could just as well be saving binary blobs | 21:58 |
| drobilla | As values, yes. | 21:59 |
| drobilla | The point is doing it with properties gets you that win. | 21:59 |
| drobilla | which means your messages are meaningful dictionary things, even if a value in them happens to be a blob | 21:59 |
| drobilla | Which is fine, really, I don't even care so much about that. If the value truly is useless to anyone else, fair enough. If it is there's inherent incentive not to. | 22:00 |
| drobilla | The main thing to combat is using a big meaningless struct as *the whole message* | 22:00 |
| drobilla | Which is the default knee-jerk of a C curmudgeon | 22:00 |
| drobilla | That said........ surely I'm not the only person who likes that you can just look at the data and it's pretty and makes sense. jalv -d is so useful. | 22:01 |
| drobilla | Sometimes I do feel like the only one | 22:01 |
| drobilla | Among the seething masses of WHATEVER BINARY SHIT EVERYWHERE | 22:01 |
| drobilla | (Maybe mentioning jalv -d is a good idea, come to think of it) | 22:02 |
| Anchakor | yeah, but appeal to abstract aesthetics won't get you far | 22:02 |
| drobilla | That's for sure. | 22:02 |
| drobilla | Though when you're debugging it's anything but abstract. | 22:02 |
| Anchakor | you still have to explain to people why it is good to use URIs and why go beyond the big struct as a payload of the property-labeled message | 22:03 |
| drobilla | When ingen does weird shit, this is exactly what I do to figure out what's going on. Run it in jalv -d and look at what's flying over the wire. | 22:03 |
| drobilla | Maybe. I think I kind of want to leave it at "serializes nicely to Turtle" | 22:04 |
| drobilla | Getting in to URI evangelism in this one would probably just be a huge turn-off. Maybe one sentence. | 22:04 |
| drobilla | "Like most things in LV2, types and properties are defined by URI so anyone can define their own without clashes." or whatever | 22:05 |
| drobilla | Maybe auto-docs? | 22:05 |
| *** rncbc has joined #lv2 | 22:05 | |
| Anchakor | I think like half an hour ago you were saying that an academic paper is the best place to write up about the overall vision and motivations | 22:06 |
| drobilla | Well, yes, but specifically Re: the atom data model in this case | 22:06 |
| drobilla | Basically it's in my favour to sound as not-semweb as possible without outright lying. | 22:06 |
| drobilla | In this context, we use Turtle, like it or not, so given that, this is the natural model | 22:06 |
| drobilla | I could go in to how these properties are exactly the same ones that are used in plugin descriptions, and can be documented in exactly the same way, and hosts can make sense of this, and so on. | 22:07 |
| drobilla | It is nice stuff, don't get me wrong. | 22:07 |
| drobilla | I am just trying to avoid boring/repelling people as much as possible. | 22:07 |
| Anchakor | I think it's best to be honest and describe the advantages which you see and your motivation, even if it might be harder to understand. | 22:08 |
| drobilla | You aren't as paranoid and defensive as myself :) | 22:08 |
| drobilla | Basically all I ever get is hate and negative feedback. | 22:09 |
| drobilla | I'm not complaining, it's just how it goes, but obviously it affects how I try to present things. | 22:09 |
| Anchakor | well it's common to hate and criticize what you don't understand | 22:10 |
| drobilla | Standard and APIs in general, it's just how it goes. If it's based on a philosophy you don't understand, even moreso, yeah. | 22:10 |
| drobilla | Whatever, I'm doing my best to try and present this stuff in a more palatable way, but I'm in too deep, it's hard, and few think that I actually do need to hear why they find it confusing, because I simply don't. | 22:11 |
| drobilla | Anyway, meaningful properties. | 22:11 |
| drobilla | Well, to me, I actually write schemas in .ttl, which generates all those docs. | 22:11 |
| drobilla | From these you can figure out, say, the range of a property | 22:12 |
| drobilla | Get a nice translatable label for it | 22:12 |
| Anchakor | even if a genuinely interested person new to lv2 was trying to understand its overall vision and why it is how it is, he doesn't have much opportunity | 22:12 |
| drobilla | You don't get that with a big struct of whatever, maybe I'll try to work it in | 22:12 |
| drobilla | I know, but it's hard to sit down and write a vision from first principles. | 22:13 |
| drobilla | I should have been writing LAC papers for the past 5 years, but oh well. | 22:13 |
| drobilla | (There is also always the argument that tangible user benefits trump that by a billion fold and time is a thing I do not have much of) | 22:13 |
| Anchakor | well start from list of advantages and what it makes possible what wouldn't be possible otherwise. this rewritten to a more readable form would do as a vision :) | 22:14 |
| drobilla | Even I'm a little dubious of the merits of separate static data files at times these days. | 22:16 |
| Anchakor | yeah, this might serve as a good excercise to reconsider why you did decide do make something the way it is :) | 22:17 |
| Anchakor | I think that is what happened with semweb - people in middle of work forgot why they were actually doing it and what it was meant to enable to be created and instead went on to indulge in abstract aesthetics wankery :) | 22:18 |
| Anchakor | well anyway I'll get back to my work now | 22:19 |
| drobilla | I don't know about that. If the semweb community was concerned with aesthetics they did a pretty extremely bad job of it. | 22:19 |
| drobilla | I sum up that failure as "too many enterprisey dorks and a few mathey logic people focused on the parts nobody cares about" | 22:20 |
| drobilla | Yeah, me too. | 22:20 |
| * drobilla tries to figure out HTF all that translates to a section skeleton | 22:21 | |
| *** rncbc is now known as rncbc|AFK | 22:38 | |
| *** edogawa has quit IRC | 23:15 | |
| *** wrl has joined #lv2 | 23:38 | |
| *** HarryHaaren has joined #lv2 | 23:58 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!