| *** artfwo has quit IRC | 02:36 | |
| *** grejppi has quit IRC | 04:06 | |
| *** grejppi has joined #lv2 | 04:06 | |
| *** ssj71 has quit IRC | 04:23 | |
| *** falktx has joined #lv2 | 04:25 | |
| *** falktx` has quit IRC | 04:29 | |
| *** ventosus has joined #lv2 | 07:23 | |
| *** falktx|work has joined #lv2 | 08:37 | |
| *** ricardocrudo has joined #lv2 | 09:11 | |
| *** sigma6 has joined #lv2 | 09:51 | |
| *** digidog has joined #lv2 | 11:03 | |
| *** ventosus has quit IRC | 11:37 | |
| *** ventosus has joined #lv2 | 12:11 | |
| *** trebmuh has joined #lv2 | 12:17 | |
| *** trebmuh has quit IRC | 14:07 | |
| *** ssj71 has joined #lv2 | 15:42 | |
| *** deva has joined #lv2 | 16:03 | |
| ssj71 | I've often thought there could be some simple port designations for the most important controls, allowing the host to show some of them inline in the strip | 16:06 |
|---|---|---|
| *** ventosus1 has joined #lv2 | 16:31 | |
| *** ventosus has quit IRC | 16:32 | |
| *** artfwo has joined #lv2 | 16:45 | |
| drobilla | ssj71: Such as? | 17:23 |
| ssj71 | gain. its per plugin | 17:23 |
| drobilla | Gain is more complicated than one might think. IIRC there's a thread buried on the ML somewhere about that | 17:24 |
| ssj71 | I was just thinking aloud in response to rgareus's proposed inline display | 17:24 |
| ssj71 | hmm maybe it was before I joined | 17:24 |
| drobilla | But there's http://lv2plug.in/ns/ext/parameters#gain | 17:24 |
| ssj71 | it would just be a hint to the host that "if you wanted to display a subset of parameters for easier access, use this one) | 17:25 |
| drobilla | That's a bit different. A display priority, or some such. | 17:26 |
| drobilla | Wouldn't be good to assume having a designation implies that, since ideally all controls (possibly very many) would have one. | 17:26 |
| drobilla | (though this information could be part of the designation itself) | 17:26 |
| *** sigma6 has quit IRC | 17:29 | |
| *** edogawa has joined #lv2 | 17:30 | |
| *** edogawa has quit IRC | 17:32 | |
| ssj71 | thats all I was proposing, perhaps the designation could be prioritized such that there's a 1st most important control, 2nd most etc, then the host can select how many to display | 17:34 |
| ssj71 | and know which ones to choose | 17:34 |
| ssj71 | oh you already said that | 17:34 |
| ssj71 | yhes | 17:34 |
| ssj71 | it would be a property I suppose, not a designation | 17:35 |
| *** edogawa has joined #lv2 | 17:36 | |
| rgareus | ssj71: you can inline controls in ardour already. | 17:44 |
| rgareus | but only generic control ports | 17:44 |
| ssj71 | but those must be selected by the user, it could be nice for the plugin to reccommend some | 18:01 |
| *** rncbc has joined #lv2 | 18:06 | |
| rgareus | a preference to show those with highest display priority ? | 18:09 |
| rgareus | by default | 18:09 |
| ssj71 | yes if the host chooses | 18:10 |
| rgareus | well, yeah it's a host side preference, which is set by the user. | 18:10 |
| rgareus | an initial hack to add this to ardour would be trivial. but it enatails a lot of work | 18:12 |
| rgareus | remeber the visual state per plugin, in particular when copy/pasting plugins | 18:12 |
| rgareus | default: show the top three, but this instance also has XXX visible and that other one has a preset with yet another visual state... | 18:13 |
| ssj71 | I see | 18:14 |
| ssj71 | I first thought of this when falktx started exposing the first few parameters in carla | 18:15 |
| ssj71 | in my plugins the first ports are rarely the most important, but rather the earliest in the signal chain | 18:15 |
| ssj71 | so I thought it would be nice to be able to indicate which should be shown | 18:16 |
| rgareus | just showing some controls is easy. making it useful while mixing (under time pressure) is hard. | 18:16 |
| rgareus | which is why Mixbus "takes control" of the whole channelstrip layout | 18:16 |
| ssj71 | yes, that makes sense | 18:16 |
| ssj71 | in that veign I'm slightly concerned that some fairly ugly/distracting inline displays may arise | 18:18 |
| rgareus | adding some additional info to "display priority" ie vaue > 1000 "always show". > 500: top 10. > 100 show if there's still vertical space or so | 18:18 |
| ssj71 | seems cryptic | 18:18 |
| rgareus | heh | 18:19 |
| ssj71 | perhaps an extension with prio:always_show, prio:top3 or something | 18:19 |
| * drobilla runs out of easy tickets, proceeds on fantasy bender, breaking serd API willy-nilly to resolve long-standing issues | 18:22 | |
| drobilla | I'm hopeless. :) | 18:22 |
| falktx|work | drobilla: btw, something in unreleased svn/git is causing zyn-lv2 to not load state | 18:24 |
| falktx|work | I mean, something that is on released tarballs, but not on svn/git versions | 18:25 |
| falktx|work | fundamental tracked it down to either sord or sratom | 18:25 |
| falktx|work | drobilla: if it's not much to ask, a small release before major changes would be very nice :) | 18:25 |
| rgareus | drobilla: I'm still waiting for you to merge a couple of my pull requests. | 18:26 |
| *** digidog has quit IRC | 18:31 | |
| drobilla | There will be no incompatible/major changes. This is just some ideal work on the sidelines towards the serd/sord union, to make a one-stop lightweight/high-performance zero-dep RDF+utilities base library on which LV2 and other things can depend | 18:39 |
| drobilla | rgareus: I looked at the version one yesterday, but it still really rubs me the wrong way. I'll get it in there though | 18:40 |
| drobilla | falktx: That is odd, though. Nothing major there since last releases IIRC | 18:40 |
| drobilla | rgareus, ssj71: A simple number seems like the nicest mix of simple + get the job done to me | 18:41 |
| falktx|work | I don't know either.. but fundamental was reproducing the error before, then not anymore after update | 18:41 |
| falktx|work | same for the user who reported it | 18:41 |
| rgareus | drobilla: I agree that the versioning patch is not great. but I don't see a better way without refactoring a whole lot | 18:41 |
| drobilla | Well, if it's fixed anyway, I suppose there's not much point in wasting time figuring out why :) | 18:41 |
| drobilla | rgareus: Yeah. In the usual case, scanning all the manifests only, then deciding which plugins to load, then doing so, would clearly be best | 18:42 |
| drobilla | rgareus: But the ability for the user (i.e. host code) to explicitly load bundles throws a wrench in that one | 18:42 |
| rgareus | drobilla: except the version is not part of the manifest... | 18:42 |
| drobilla | rgareus: I hate unloading... | 18:42 |
| drobilla | rgareus: Probably should have been required to be | 18:43 |
| rgareus | drobilla: a 2nd world just to scan all versions first would be an option. but that'll result in loading everything twice. | 18:43 |
| drobilla | So I guess it's load into temporary model, check version, only merge with world model if appropriate. There's a sort of double load into a separate world thing in the current patch which is the part that makes me cringe a bit | 18:44 |
| rgareus | drobilla: unloading one or two plugins on occasion will be less effective work | 18:44 |
| drobilla | Anyway, I'm emerging from my little private hell and getting back into things, so I'll clear the queue soon enough :) | 18:45 |
| rgareus | drobilla: two worlds!! that's a feature: we're working on expanding the LV2 to a universe :) | 18:45 |
| drobilla | heh | 18:45 |
| drobilla | The preset thing needs fixing, just by working the same way the manifest editing does | 18:48 |
| drobilla | But the spec probably should have just mandated presets be in their own files. This is a PITA, and authors doing that just makes performance shit anyway. | 18:48 |
| *** rncbc has quit IRC | 18:54 | |
| *** falktx|work has quit IRC | 18:54 | |
| *** rncbc has joined #lv2 | 19:25 | |
| falktx | rgareus: I feel like commenting that pure-c toolkits (and qt because it doesn't expose std lib symbols) is fine for *linux* UIs | 19:36 |
| falktx | rgareus: because we can run those in separate processes... | 19:37 |
| falktx | BUT since I know a few of those devs (ahem rncbc ahem) use those toolkits *and* instance-access, this is not an option | 19:37 |
| ssj71 | I just don't want to spend more energy on UI toolkit stuff | 19:48 |
| ssj71 | maybe I'll fork AVTK again | 19:53 |
| rgareus | here we go: https://github.com/drobilla/lv2/pull/7 | 20:03 |
| rgareus | falktx: yes, please do. pure-c is definitly fine. | 20:03 |
| rgareus | falktx: Qt, depends I guess. if you get a qtractor binary you may well run into issues. | 20:04 |
| rgareus | or host from your distro, but plugin binaries from a 3rd party.. | 20:04 |
| rgareus | drobilla: I didn't know what to put in the doap.ttl under file-release and blame.. | 20:07 |
| rgareus | the doc can certainly be refinded a bit, but I hope it's a good start. | 20:09 |
| ssj71 | pure-c does that mean gtk then? | 20:19 |
| ssj71 | or roll your own with X11 or something | 20:19 |
| falktx | robtk is pure C I think | 20:20 |
| falktx | EFL too I think | 20:20 |
| ssj71 | interesting | 20:21 |
| falktx | there's a few plugins made in EFL | 20:21 |
| ssj71 | which ones? I'd never heard of it | 20:22 |
| ssj71 | I'd heard of enlightenment, but didn't realize they had a toolkit | 20:23 |
| *** edogawa has quit IRC | 20:27 | |
| rgareus | ssj71: gtk is pure-c (gtkmm is not), but gtk has different issue | 20:29 |
| rgareus | it's not relocatable for example | 20:30 |
| *** edogawa has joined #lv2 | 20:30 | |
| drobilla | I liked much of where AVTK2 was going, but some of it is pretty weird | 20:30 |
| drobilla | rgareus: file-release and blame only get set when an actual release is made, nevermind them | 20:31 |
| rgareus | on my next sabbatical I'll rewrite robtk (with lessons learned and no more gtk compat) | 20:32 |
| rgareus | drobilla: NEWS as well it seems | 20:32 |
| ssj71 | maybe I'll fork robtk then :) | 20:32 |
| rgareus | drobilla: I have another PR in the queue to update the .gitignore file. | 20:33 |
| *** edogawa has quit IRC | 20:33 | |
| rgareus | ssj71: don't hold your breath.. might be 10 years from now :) | 20:33 |
| drobilla | rgareus: not sure I see the point vs just using a UI | 20:33 |
| drobilla | rgareus: NEWS is generated | 20:34 |
| ssj71 | alright, well I'm not anxious to work on it again. I've got something that seems to be working its hard to let go of that | 20:34 |
| rgareus | drobilla: how you you implement a 2nd very specific UI to swallow in a mixer-strip with or without any event handling? | 20:34 |
| rgareus | cross platform. | 20:34 |
| drobilla | rgareus: Same way as always? | 20:35 |
| rgareus | drobilla: that means don't do it ? :) | 20:35 |
| *** edogawa has joined #lv2 | 20:36 | |
| drobilla | I mean, just.......... make a UI | 20:36 |
| drobilla | Maybe with a bit of metadata to say it's a "minimal mixer strip UI" or whatever, but otherwise... | 20:37 |
| rgareus | drobilla: I tried with suil, there are edge-cases over edge-cases. | 20:37 |
| rgareus | particularly on OSX and windows | 20:37 |
| rgareus | Q5 didn't fare well either (size-request, size-allocate) | 20:37 |
| rgareus | Qt* | 20:37 |
| drobilla | Okay, well, this strikes me as a bit of an overreaction to toolkits you don't want to use anyway | 20:38 |
| drobilla | But if native window UIs won't work, and I choose to not be annoying about the "why not?" part, a non-interactive image surface UI type is an option? | 20:39 |
| *** deva has quit IRC | 20:39 | |
| rgareus | drobilla: there are only 3 real-world use cases: display EQ curve, display compressor reduction, display gate status. | 20:40 |
| drobilla | This is mostly just my initial knee-jerk against API bloat, and my severely intense knee-jerk against extension bloat, speaking, for the record. I'm not terribly opposed to the general "get an image representation" idea | 20:40 |
| rgareus | a fully fledged UI is overkill in 99.9999% of all cases | 20:40 |
| drobilla | 'tis my job 'round here to be critical to an extent :) | 20:40 |
| rgareus | drobilla: it's fine to criticize. For all I know there's a better solution. | 20:41 |
| drobilla | It's not *that* overkill | 20:42 |
| drobilla | With wrapping, and toolkits, and all the hell that *can* be associated with a UI, sure, but a "UI" in the LV2 sense isn't much | 20:42 |
| rgareus | it'd be less of an issue if we had an UI-spec that rncbc alluded to on the email list. | 20:43 |
| *** ricardocrudo has quit IRC | 20:44 | |
| drobilla | If you mean an "image surface UI", I have basically no problem with that | 20:46 |
| drobilla | It only came up in the past in conjunction with baking in an entire event API along with it (which I reject for presumably obvious reasons) | 20:47 |
| rgareus | it'll need event handling. which is probably OKish to add (similar to pugl) | 20:48 |
| drobilla | It does mean you'd have to deal with plugin comm in the usual way, which is a pain compared to just "get an image" in some sense | 20:48 |
| *** edogawa has quit IRC | 20:48 | |
| rgareus | and then someone needs to write a few layout and widget components - which is a bit of work. the really hard part is; Text Entry and File Browser | 20:48 |
| drobilla | You think passing a raw ARGB surface around is an appropriate way to do "full blown" UIs? | 20:49 |
| rgareus | there are lots of VSTs that do just that | 20:49 |
| drobilla | (Proper text rendering is essentially impossible that way, among other things) | 20:49 |
| drobilla | What's particularly wrong with the native window thing, anyway? | 20:50 |
| rgareus | yeah. a cairo_surface_t* (or whatever C++ comes up with) would be preferable. | 20:50 |
| rgareus | drobilla: bridging Events and swallowing the window cross platform has many edge-cases. suil still has lots of issues. | 20:51 |
| drobilla | I suppose. But burdening both hosts and plugin UIs with essentially implementing an entirely new toolkit doesn't seem particularly attractive | 20:52 |
| rgareus | but I think that native windows are *currently* still better for a *fully fleged ui*. | 20:52 |
| falktx | do you know if Wayland allows embedding windows into each other? | 20:52 |
| drobilla | Particularly if we toss proper rendering and a ton of performance potential (acceleration and whatnot) aside in the process | 20:52 |
| drobilla | That said, one could relatively easily write a gtk to pugl event translator, and vice versa, with s/Gtk/whatever/ | 20:53 |
| rgareus | actually one of my text next step will be to expose cairo-lua bindings in Ardour. | 20:53 |
| drobilla | (Which I very much realized when I made PuglEvent in the first place) | 20:53 |
| drobilla | ... Fucking UIs. :P | 20:55 |
| *** edogawa has joined #lv2 | 20:56 | |
| falktx | pfff, who needs UIs? | 20:56 |
| drobilla | A hell of a lot fewer people than the number who think they do, that's for sure :) | 20:56 |
| *** edogawa has quit IRC | 20:57 | |
| *** edogawa has joined #lv2 | 20:59 | |
| drobilla | Anyway, that's a very big sabattical-sized can of worms | 20:59 |
| drobilla | Perhaps an ARGB lv2-ui that has the potential for event stuff to be added in the future, if/when that proves sane, is the best realistic step | 21:00 |
| drobilla | Quite sure I don't like the plugin side of things mucked up here, especially with stuff that intersects so much with what some people want on the UI side of things anyway. That just doubles our number of edge cases | 21:01 |
| drobilla | Particularly given the massive shot in the head that is to any host with any semblance of engine/UI separation | 21:03 |
| drobilla | If an image is generated based on a few numbers, which would typically be the case, rendering that plugin side and having to shunt it over to the UI is insane, even in the same process | 21:04 |
| rgareus | drobilla: back on topic, I think http://www.oofus.co.uk/ardour/InlineScope2.ogv looks awesome :) | 21:04 |
| drobilla | Yes it does :) | 21:04 |
| rgareus | drobilla: I did the maths. transferring the complete audio data via Atom messages can exceed the size of a pixmap | 21:05 |
| rgareus | and currently the pixmap is not even transmitted as POD, it's just a pointer | 21:05 |
| drobilla | Full audio data isn't required for a "scope" of that size/quality, but sure. | 21:06 |
| drobilla | Some might need instance access. So be it. | 21:06 |
| drobilla | Compressor curves and the like are more illustrative examples, there. | 21:07 |
| rgareus | well, meters, too. or compressor data. unless you add a hanshake (to not miss peaks) | 21:07 |
| drobilla | Transferring the image, or whatever really, is still an option with a UI. | 21:08 |
| rgareus | UI:ARGB32 | 21:09 |
| drobilla | It's highly questionable to force every plugin/host on the planet to do this because, essentially, one case in one host did it. | 21:09 |
| rgareus | host side it's trivial. | 21:11 |
| drobilla | in Ardour, maybe | 21:11 |
| drobilla | Frankly the bar being set at "whatever, we did it in Ardour" is ultra not good for LV2. | 21:11 |
| rgareus | reading between the lines. I think rncbc will add "Inline Displays" soonish, falktx also commented in the past about it. | 21:11 |
| falktx | my issue is with mixing UI code in DSP | 21:12 |
| rgareus | falktx: what mix? | 21:12 |
| falktx | DPF separate the shared libs for those | 21:12 |
| falktx | plugin_dsp.so, plugin_ui.so | 21:12 |
| falktx | I like it that way | 21:12 |
| drobilla | Yes, well, I am aware of my position as the only person around who tends to give a fuck about separation, or applicability outside people's little sandboxes :P | 21:12 |
| rncbc | drobilla, rgareus: dead simple in qt -> take QImage::Format_ARGB32 | 21:13 |
| rgareus | rncbc: I thought so. | 21:13 |
| drobilla | To be clear, I have zero problem with ARGB32 | 21:13 |
| drobilla | Achieving this by tacking new API on to the plugin itself is not a good way to go about it for a long list of reasons I don't feel like typing. | 21:13 |
| rgareus | falktx: is linking plugin_dsp.so against libcairo (+libpng + zlib) an option? | 21:14 |
| rgareus | those must be tiny compared to the rest. | 21:14 |
| drobilla | in addition to the above, questionable ownership rules, lack of support for multiple views, high likelihood that the shotgun of thread issues provided will be used to shoot plenty of feet off, etc | 21:15 |
| rgareus | the implicit instance access is a bit scary. | 21:15 |
| drobilla | Bunch of totally new shit to implement that overlaps existing stuff, and overlaps future things people want for UIs even more | 21:15 |
| rgareus | but everything else would a a hell of a lot more complicated. | 21:16 |
| falktx | rgareus: I don't want cairo | 21:16 |
| falktx | rgareus: there's no "rest" in dpf. it's just opengl :P | 21:16 |
| rgareus | drobilla: I don't see any overlap. in fact a small concise display is orthogonal to all UI. | 21:16 |
| rgareus | falktx: mesa, then | 21:18 |
| drobilla | Let me put it this way: if you want to put UI/visual stuff in your DSP code, fine. There is instance access which allows such things, and you can truck back and forth whatever you like. | 21:18 |
| drobilla | The API *forcing* this on everyone is clearly terrible, though. | 21:18 |
| drobilla | If you want real cross-process transparency, then sure, you have to do more work to implement a view like this. | 21:20 |
| drobilla | However, if you don't, you have a pointer to whatever you want, and it's not really that much more complicated. | 21:20 |
| falktx | rgareus: I have a requirement for this. the draw call must always happen on the main/gui thread | 21:22 |
| falktx | if we ever get openGL rendering to ARGB, I may use this | 21:22 |
| falktx | but OpenGL is very strict regarding threading | 21:22 |
| rgareus | falktx: that's fine with me in general. | 21:23 |
| drobilla | There is no such thread in this context. | 21:23 |
| rgareus | I left this open so far to allow to render in the background, double buffer, blit on the GUI thread. | 21:23 |
| drobilla | But I don't see why anyway. That method generates you an image, in the calling thread, and that's that. It can't have any direct interaction with displays or GUI threads and whatnot | 21:24 |
| rgareus | Ardour's current implementation calls render() in the GUI thread (gtk_expose_event) | 21:25 |
| falktx | if I want to use openGL for drawing I will need some thread rules | 21:25 |
| drobilla | Reason #9823568953267892350986123567890 this should be a UI ;) | 21:25 |
| rgareus | falktx: is that also true if you draw off-screen | 21:26 |
| drobilla | But since I need to argue against a working implementation, I suppose I'll probably lose without doing it right myself, which I do not have time to do, so, fine, whatever. | 21:26 |
| falktx | I think this should not be an official spec | 21:27 |
| rgareus | drobilla: I think eventually we do want fully fledged UIs. but that'll be another extension (ui) with event handling | 21:27 |
| drobilla | Do as thou wilt. Benevolent dictator says no as far as making this an official extension in its current form, and with good reason. The *possibility* of DSP/UI separation in LV2 is non-negotiable. | 21:27 |
| drobilla | rgareus: Ignore the event part and "fully-fledged UIs" becomes a lot less burdensome than you seem to think, IMO. | 21:28 |
| rgareus | falktx: would you mind leaving a comment at https://github.com/drobilla/lv2/pull/7/files#diff-3d59acf2b61b65cfa48fa31766c19bc1R77 ? | 21:28 |
| *** edogawa has quit IRC | 21:29 | |
| falktx | a comment? | 21:29 |
| rgareus | falktx: ie s/(usually the main GUI thread)/ must be in the main GUI thread/ | 21:29 |
| rgareus | falktx: well whatever you prefer | 21:30 |
| drobilla | I would like to see an ARGB UI extensions anyway, since this would be quite nice for visualization "plugins" that don't want to deal with toolkit/native window crap at all. | 21:30 |
| rgareus | drobilla: If someone can push this throug, you can. | 21:31 |
| rgareus | if someone else was to propose it, realistically it'll end up in 1 month discussion, 2 more months of of bikeshedding and eventually probably nothing.. :( | 21:33 |
| drobilla | rgareus: It's not exactly difficult. New UI types are easy. | 21:33 |
| rgareus | unless we throw in a couple of beers and do it on some table somewhere. | 21:34 |
| drobilla | Maybe. I don't think that's inherent, though, most of the proposals that end up that way turned out to be a lot more complicated than people figured. | 21:35 |
| drobilla | The analysis thing just fizzled because of that. | 21:35 |
| drobilla | This seems pretty easy, and believe me, I'd love to receive patches that I can just apply and get on with my life :) | 21:35 |
| falktx | rgareus: ...can I make this into a inline display? https://github.com/DISTRHO/ProM#readme :D | 21:36 |
| rgareus | falktx: you probably can. | 21:38 |
| *** ricardocrudo has joined #lv2 | 21:38 | |
| falktx | I only wonder if I should.. | 21:38 |
| rgareus | falktx: if you're bored and have too much time, why not :) | 21:38 |
| falktx | I'm bored but don't have time :( | 21:39 |
| ssj71 | could a plugin have multiple UI's? then one has a property of inline or something? | 21:39 |
| rgareus | falktx: but given your expertise, I can imagine a lot more useful projects for. | 21:39 |
| falktx | ssj71: yes, you can already do that | 21:39 |
| rgareus | ..spending your time on. | 21:39 |
| * falktx needs to decide where to move next. Portugal or USA | 21:40 | |
| * rgareus recommends New Zealand. | 21:40 | |
| falktx | too soon for hell | 21:40 |
| rgareus | falktx: where in the US? | 21:40 |
| falktx | no idea yet. either Texas or SF | 21:41 |
| ssj71 | so why not then just have a ui:argb32_ui or whatever and then plugins can have a second UI hosts that want it instantiate that independently of the full UI | 21:41 |
| ssj71 | if instance access is available if needed | 21:41 |
| falktx | that will make things worse | 21:42 |
| falktx | sounds a good idea initially, but then uis will get used to it | 21:42 |
| rgareus | ssj71: I think ui:argb32_ui will eventually happen, once someone defines event handling | 21:42 |
| falktx | also you'd need to pass atom port and control port events to the ui | 21:42 |
| falktx | having it on the dsp side makes sense for a event-less "UI" | 21:43 |
| rgareus | not with instance access | 21:43 |
| falktx | please no | 21:43 |
| drobilla | ssj71: Yes, though most (all?) hosts don't have good support for selecting one | 21:43 |
| falktx | no no no | 21:43 |
| rgareus | this stuff is IMHO a very good valid use-case for it. | 21:43 |
| ssj71 | why not argb32_read_only_ui or something without events | 21:44 |
| ssj71 | just for this | 21:44 |
| rgareus | but yes instance access in general is evil. | 21:44 |
| rgareus | ssj71: how's that different from the inline display proposal? | 21:44 |
| drobilla | It's certainly not more evil than an extension that mandates the same thing in effect. | 21:44 |
| drobilla | and seriously, stop conflating events with this. | 21:45 |
| ssj71 | rgareus: because its handled as a UI rather than a new extension | 21:45 |
| rgareus | drobilla: worker is another example here. | 21:45 |
| drobilla | Just because it's a UI doesn't mean you need to jump off the events ABI deep-end. | 21:45 |
| rgareus | ssj71: new UI extension is just the same (only a different URI namespace) isn't it? GUI port-events may make all the difference though | 21:45 |
| *** timbyr__ has quit IRC | 21:46 | |
| ssj71 | IDK just pitching ideas :) | 21:46 |
| drobilla | ssj71: Your ideas are well-founded, IMO. | 21:46 |
| rgareus | if it was an ui, we'll need to update a lot of code though. suil in particular. | 21:46 |
| ssj71 | rgareus: the difference is that there will be some inline UIs without instance access | 21:46 |
| drobilla | Would we? Suil just passes through unwrappable things without any fuss. | 21:46 |
| rgareus | drobilla: does it? Last I looked it failed (and returned NULL) | 21:47 |
| rgareus | anyway.. | 21:47 |
| ssj71 | ui:inline_argb32 | 21:47 |
| ssj71 | a special case ui, read_only no events | 21:48 |
| drobilla | I think that is currently in contention because rncbc doesn't like the "graceful failure" thing for that reason | 21:48 |
| drobilla | But in any case, you can just pass NULL for container type and it won't bother attempting to wrap whatsoever | 21:48 |
| rncbc | drobilla: not quite. i also tell it is a no-issue anymore at least for newer qtractor releases | 21:49 |
| drobilla | rncbc: OK. Wasn't sure what to do with that one, but my memory is fuzzy at this point | 21:50 |
| rncbc | drobilla: there's a comment on it | 21:50 |
| drobilla | (Sorry I have been a shit maintainer for a few months, but believe me, I have my reasons) | 21:50 |
| drobilla | rncbc: I'll just close it, I guess, if it's not an issue for you. The reversion opens up a potential undetectable fatal crash scenario, so that's no good. | 21:57 |
| *** timbyr__ has joined #lv2 | 22:03 | |
| rgareus | while I'm not a fan of instace-access, I don't see how instance access is bad in this case. | 22:04 |
| falktx | devs get used to it | 22:05 |
| falktx | "the mini view has fancy graphics, but the full ui does not. guess I'll add instance-access to the full-ui too" | 22:05 |
| drobilla | The interface itself is clunkier than it should be, but if you need it, you need it. | 22:06 |
| drobilla | devs'll get used to GUI code in their DSP, too. | 22:07 |
| rgareus | falktx: that's a non sequitur. what does graphical fancyness have to do with it? | 22:07 |
| drobilla | But I think we've been too hand-wavey about this separation thing. There should be a core principles document somewhere, and that should be on it. | 22:08 |
| ssj71 | EULA for developing lv2 plugins. If you agree check this box | 22:09 |
| ssj71 | jk | 22:09 |
| drobilla | Quick a few wacky things have cropped up that ideally would have been prevented by such a thing, or at least be easy to summarily dismiss as inappropriate | 22:09 |
| drobilla | (in general, I don't mean this one) | 22:09 |
| rgareus | drobilla: I admire your credo. I think it'd be a first time that outlining principles will make result in devs doing the right thing :) | 22:11 |
| rgareus | s/make// | 22:12 |
| drobilla | I'm not that naïve, but the summarily dismissed part would be convenient :) | 22:12 |
| rgareus | anyway, I'll have to get some work done before midnight. | 22:13 |
| drobilla | After all, what is LV2 but a drawn out experiment in the numerous epic ways that laissez-faire fails :) | 22:13 |
| drobilla | If I graduate and have nothing better to do, I'll probably go full on dictator | 22:13 |
| *** SianaGearz has quit IRC | 22:14 | |
| *** SianaGearz has joined #lv2 | 22:15 | |
| *** ventosus1 has left #lv2 | 22:20 | |
| *** rncbc has quit IRC | 22:38 | |
| *** ricardocrudo has quit IRC | 23:08 | |
| *** ricardocrudo has joined #lv2 | 23:25 | |
| drobilla | Tinkering around with serd makes me wonder how much work JSON-LD would be | 23:32 |
| drobilla | Nichey, but if you're doing anything LV2 from a browser, being able to talk directly to all LV2 things in JSON would be nice | 23:33 |
| rgareus | drobilla: wasn't there someone working on a project to translate [LV2] turtle into JSON ? | 23:43 |
| drobilla | falktx: Is your latest list of insanely cranked warning flags handy somewhere? | 23:51 |
| drobilla | rgareus: I don't recall. | 23:51 |
| falktx | drobilla: yes, but you'll hate it very soon | 23:52 |
| falktx | drobilla: https://github.com/falkTX/Carla/blob/master/source/Makefile.mk#L131 | 23:52 |
| drobilla | There is a standard for this, though. It's not quite a straight up serialization (like Turtle) in JSON, though can be. It has extra facilities for defining "contexts" that let you specify a vocabulary of unadorned keywords for normal-looking JSON | 23:52 |
| rgareus | falktx: oh nice. that's a cool list | 23:53 |
| rgareus | falktx: do you find that output more useful than clang's scan-build? | 23:54 |
| falktx | both have their purposes | 23:54 |
| falktx | gcc6 has some fancy warnings, it detects bad indentation leading to non-obvious code paths | 23:55 |
| rgareus | lol | 23:55 |
| ssj71 | wow | 23:55 |
| drobilla | Doesn't have -Wstrict-prototypes and -Wmissing-prototypes which are nice for C (but make Gtk2 noisy) | 23:55 |
| drobilla | 23:55 | |
| falktx | look it up on google https://gnu.wildebeest.org/blog/mjw/2016/01/09/looking-forward-to-gcc6-nice-new-warnings/ | 23:55 |
| falktx | drobilla: I see it there... CFLAGS += -Wnested-externs -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings | 23:56 |
| falktx | those 4 are C only, not valid for C++ | 23:57 |
| drobilla | falktx: Oh, I missed that line. n/m | 23:57 |
| rgareus | what are nested-externs ? | 23:59 |
| drobilla | Bit more noisey than current autowaf --ultra-strict | 23:59 |
| * drobilla removes the utter braindeadism that is -Werror | 23:59 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!