| *** ricardocrudo has quit IRC | 00:01 | |
| *** frinknet has quit IRC | 01:18 | |
| *** Spark[01] has joined #lv2 | 01:44 | |
| *** trebmuh has quit IRC | 01:46 | |
| *** falktx has joined #lv2 | 03:18 | |
| *** falktx` has quit IRC | 03:22 | |
| *** Spark[01] has quit IRC | 06:54 | |
| *** Spark[01] has joined #lv2 | 07:56 | |
| *** trebmuh has joined #lv2 | 09:09 | |
| *** dsheeler has quit IRC | 09:16 | |
| *** ricardocrudo has joined #lv2 | 09:47 | |
| *** dsheeler has joined #lv2 | 10:11 | |
| *** rncbc has joined #lv2 | 11:19 | |
| *** unclechu-audio_ has quit IRC | 11:53 | |
| *** edogawa has joined #lv2 | 13:28 | |
| *** drobilla has joined #lv2 | 15:11 | |
| drobilla | Random fantasyland thoughts: I think it was a mistake to make the type of all atoms dynamic | 17:05 |
|---|---|---|
| drobilla | Needing access to dynamic mapped URID state makes things like making wrappers super annoying | 17:06 |
| drobilla | I'm halfway tempted to add a URID feature that reserves a range for predefined URIDs which always map to a given static value | 17:06 |
| drobilla | So current things continue to work, but we can retroactively just define enums for things like atom types and future code can just use that | 17:07 |
| rgareus | good idea | 17:25 |
| rgareus | saving custom state is more complicated than it needs to be. | 17:25 |
| drobilla | You mentioned that earlier, wasn't sure really what could be done about that | 17:27 |
| drobilla | But I suppose the URIDs are a part of it | 17:27 |
| drobilla | Though you need them to process the RT messages anyway, and they're typically the same | 17:28 |
| drobilla | for the keys, that is | 17:28 |
| drobilla | Probably was a questionable idea to use a URID key for the state interface at all, I suppose | 17:29 |
| drobilla | Not like the performance particularly matters there | 17:29 |
| rgareus | the current API is fine as low-level API | 17:32 |
| drobilla | Yeah, it can't get much simpler, really. Your save gets called, you're passed a function where you store(key, value, type, flags). | 17:32 |
| rgareus | but it takes a 5 or 6 LOC for a to save or load a single key/value pair incl mapping URIs for the key and the type(s) | 17:33 |
| drobilla | The potential for variable size things makes having some shiny State wrapper object in C pretty difficult | 17:33 |
| rgareus | save/restore arrays is even more cubmersome | 17:33 |
| drobilla | The key is kind of unavoidable, type could go away, yes | 17:34 |
| drobilla | It's a lot less cumbersome if you just store them as atoms always | 17:34 |
| rgareus | yet, I don't see how it could easily be abstracted in a general way. | 17:35 |
| drobilla | If you have a state dict thingie that *points* to the values elsewhere, you could do it | 17:36 |
| rgareus | plugin code can just use #define MYKEY(K) PLUGIN_URI "#" K etc | 17:36 |
| drobilla | Though magically handling RT messages that set strings is tricky | 17:36 |
| drobilla | Well, if you consider a plugin that uses old stuff and just uses state to save and has no message interface, the burden seems like it's on state | 17:37 |
| drobilla | Which you do, so you see it that way | 17:37 |
| drobilla | They were deliberately designed to mesh, though, and mapping keys is just necessary for RT changes | 17:38 |
| rgareus | actually I do try to only use standard ports whenever possible, so there's no need for a custom state IF | 17:38 |
| drobilla | The way to make this easy is to have a state utility thingie that you use in both/all cases | 17:39 |
| drobilla | Trouble there is I'm not sure you can do it without a key lookup being everywhere | 17:39 |
| rgareus | speaking of state: is there a spec for GUI state? | 17:39 |
| drobilla | Maybe define some probably-standard-questionable struct format State { LV2_URID key, LV2_Atom* value, ...} | 17:39 |
| drobilla | rgareus: Conceptually you can just use the same stuff. Not established / well defined / tested / supported, though | 17:40 |
| drobilla | eg-parms has its own thing trying to get close to save/restore being terse | 17:46 |
| drobilla | It's not clever enough to magically know the key and be reducible to a for loop though | 17:46 |
| drobilla | If there were such a structure, there could also be an easy one-call "map all these URIs" for it, which would be great | 17:47 |
| drobilla | But I don't think that's possible without the actual contents being stored elsewhere, and I can't think of how to make that not a PITA | 17:47 |
| drobilla | Maybe two structs, one for actual state, one for keys | 17:49 |
| drobilla | StateKeys { { uri, urid, atom* } ... } | 17:49 |
| drobilla | But I don't think *that* can be set up without a line per key | 17:49 |
| drobilla | (Though that's maybe not so bad since currently you have a line per URId map anyway, so it's a net reduction in PITA) | 17:50 |
| * drobilla wonders if it's standard to iterate over a struct with the same element type | 17:56 | |
| drobilla | or cast to an array of that element type | 17:56 |
| drobilla | You can do something like this: http://pastebin.com/WEZF5rrn | 18:06 |
| drobilla | State save/restore could loop similarly. It has URIDs and pointers to the actual values | 18:06 |
| drobilla | Ditto for handling messages if you don't care about special logic for whenever a particular thing changes, but that's O(n) | 18:07 |
| drobilla | Something along these lines is definitely needed. Sort it by URId and you can get log(n) which lets you implement patch:Get with good enough efficiency (currently a ton of boilerplate in params.c) | 18:12 |
| drobilla | Automagic mapping of the type would also be good, but adding type there bloats it a bit. | 18:13 |
| drobilla | 'course you don't get to actually use brace syntax since C rather annoyingly doesn't let you do that | 18:15 |
| *** Spark[01] has quit IRC | 18:21 | |
| drobilla | Speaking of saving state being a PITA, trying to remember why the plugin is responsible for path mapping... if there even is a reason... | 18:36 |
| *** oofus has joined #lv2 | 18:38 | |
| drobilla | Oh, right. Avoidable in the simple case, but if you store paths, you need to recursively map them anyway | 19:10 |
| drobilla | rgareus: ... curse you and your digressions :P | 19:43 |
| drobilla | The size is also a bit of a PITA | 19:43 |
| drobilla | Macros to the rescue: http://pastebin.com/nbfdk41K | 20:50 |
| drobilla | I've distilled the plugin down quite a bit with this, which is nice, but there's a few problems | 20:50 |
| drobilla | The key URIs get mapped, but you don't have access to them via an easy static identifier, which can be trouble when e.g. you want to send updates (or use them for whatever) | 20:51 |
| drobilla | General concept of state is split into two things which makes swapping them more trouble if you consider dynamicism | 20:51 |
| drobilla | (Not if you don't because the actual values are only in the second thing) | 20:51 |
| rgareus | drobilla: nice and concise | 21:01 |
| drobilla | rgareus: Yeah, it's not bad. If you're willing to pay O(lg(n)), you can handle Set and Get messages with very little code, too | 21:04 |
| drobilla | Trying to wrap up the tricks for this in more general utility headers. The trick is to use a forge writing method as the "store" callback so you can use the same code to save state or write a message | 21:05 |
| drobilla | It's conceptually super elegant, but wee differences and lack of a sensible header for such things... | 21:05 |
| drobilla | Then again conceptually super elegant and also a giant pain in the ass in practice is pretty much the creed of LV2 :D | 21:06 |
| drobilla | I suppose the other way around is another trick I should implement: a retrieve callback that lets restore() be used to restire from an atom message | 21:14 |
| drobilla | So the host can atomically set a bunch of properties, or the entire plugin state, in one message | 21:15 |
| * drobilla notes we're getting kind of close to the state extension not actually being necessary here | 21:15 | |
| drobilla | Hm... the groups stuff (just posted to ML) throws a wrench in this, though | 22:01 |
| drobilla | I think I need to bake that in at ground level for this stuff to be prime time ready | 22:03 |
| *** rncbc has quit IRC | 22:11 | |
| *** ricardocrudo has quit IRC | 22:14 | |
| rgareus | drobilla: is there some kind of abstraction to use existing/widespread translation utils (.po, gettext) for .ttl ? some extract + replace mechnanism for port-name etc | 22:29 |
| drobilla | rgareus: Not that I know of | 22:30 |
| drobilla | rgareus: Translating via replacing for a format that has built-in multilingual capabilities is a bit odd | 22:31 |
| drobilla | rgareus: It'd be pretty easy to write one, though | 22:31 |
| drobilla | Well, depending on how easy it is to read .po and so on, I don't know that part | 22:31 |
| rgareus | drobilla: it'd be nice to translate the a-* plugins bundled with Ardour. | 22:32 |
| rgareus | prokoudine might manage to edit .ttl - but he's probably the only one from all contributing translators | 22:32 |
| drobilla | It's not exactly rocket science, but yeah, same workflow would be nice | 22:33 |
| rgareus | and labels like "Gain" etc are already translated and could just be re-used | 22:33 |
| rgareus | but don't bother. | 22:33 |
| rgareus | I thought there might already be something exiting that you know about. | 22:34 |
| drobilla | The part I don't know is a get_translated_strings(in_str) function | 22:34 |
| drobilla | Given that, the tool is basically foreach(s, p, literal) { strings = get_translated_strings(literal.str); write_translated_strings(s, p, strings) } | 22:35 |
| drobilla | Maybe easier in Python even though rdflib is terrible | 22:35 |
| drobilla | (or just replace if you're intent on one-language bundles but that seems to not work in any reasonable case) | 22:37 |
| drobilla | You could turn off lilv's built-in i18n and just do it runtime with gettext() like other things, but that would break translated bundles | 22:40 |
| drobilla | dgettext() will get you it for a specific domain, reducing the problem to figuring out all the domains that are defined | 22:43 |
| drobilla | lilv_get_lang() has code for converting to ttl format language tags | 22:43 |
| drobilla | Hm, no, domain != language | 22:46 |
| drobilla | In conclusion: no | 22:46 |
| drobilla | :) | 22:46 |
| rgareus | drobilla: stash it. | 22:47 |
| rgareus | drobilla: I didn't mean to side-track you. | 22:47 |
| rgareus | just keep it in mind for next time when you're bored or low on battery on a plane or something... | 22:48 |
| drobilla | Idling anyway | 22:48 |
| drobilla | Just pointing out the core issue that needs doing that I won't do | 22:48 |
| drobilla | Given that, I can write the actual ttl tool easily/quickly | 22:49 |
| rgareus | drobilla: file a feature request. | 22:49 |
| drobilla | But I'm not wading around in gettext | 22:49 |
| drobilla | Back on (my) topic, what's the status of other plugin APIs and dynamic parameters anyway? | 22:51 |
| drobilla | Can plugins add/remove parameters in response to external changes? e.g. a n_envelopes parameter... | 22:51 |
| drobilla | I might be getting design featureitis here, but it seems silly to have such a dynamic mechanism logistically and not actually have a dynamic number of twiddleable things | 22:52 |
| *** drobilla has quit IRC | 23:05 | |
| *** edogawa has quit IRC | 23:05 | |
| *** drobilla has joined #lv2 | 23:05 | |
| *** oofus has quit IRC | 23:51 | |
| *** oofus has joined #lv2 | 23:52 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!