| *** NickSB2 has joined #lv2 | 01:10 | |
| *** awilliams has quit IRC | 06:24 | |
| *** ssj72 has quit IRC | 07:07 | |
| *** ssj72 has joined #lv2 | 07:20 | |
| *** bazz has joined #lv2 | 07:37 | |
| *** abique has joined #lv2 | 07:37 | |
| *** falktx has joined #lv2 | 07:40 | |
| *** timbyr has quit IRC | 08:55 | |
| *** timbyr has joined #lv2 | 08:56 | |
| *** timbyr has quit IRC | 09:39 | |
| *** timbyr has joined #lv2 | 09:41 | |
| *** timbyr has quit IRC | 09:56 | |
| *** timbyr has joined #lv2 | 09:58 | |
| *** Anchakor_ has quit IRC | 10:22 | |
| *** magnetophon has quit IRC | 10:23 | |
| *** timbyr has quit IRC | 10:49 | |
| *** timbyr has joined #lv2 | 10:50 | |
| *** falktx has quit IRC | 10:57 | |
| *** falktx has joined #lv2 | 11:06 | |
| *** timbyr has quit IRC | 11:30 | |
| *** timbyr has joined #lv2 | 11:32 | |
| *** Anchakor_ has joined #lv2 | 11:39 | |
| *** timbyr has quit IRC | 12:37 | |
| *** timbyr has joined #lv2 | 12:39 | |
| *** magnetophon has joined #lv2 | 12:50 | |
| *** falktx has quit IRC | 12:58 | |
| *** timbyr has quit IRC | 13:13 | |
| *** timbyr has joined #lv2 | 13:15 | |
| *** mlpug has joined #lv2 | 13:31 | |
| *** NickSB2 has quit IRC | 13:43 | |
| *** falktx has joined #lv2 | 15:18 | |
| *** mlpug has quit IRC | 15:46 | |
| *** wrl has quit IRC | 16:51 | |
| *** drobilla has joined #lv2 | 17:07 | |
| *** abique has quit IRC | 17:19 | |
| *** HarryHaaren has joined #lv2 | 17:24 | |
| falktx | there should be a way to ask the host about a right-click menu | 17:26 |
|---|---|---|
| drobilla | "ask about" how? | 17:38 |
| falktx | a callback I guess | 17:39 |
| drobilla | I mean, what information are you expecting? | 17:39 |
| falktx | to show automation info for example | 17:39 |
| falktx | UI knob right click -> automate this param... (shows some dialog) | 17:40 |
| drobilla | i.e. you want the plugin to be able to tell the host "pop up a right-click menu here?" | 17:40 |
| falktx | yes | 17:40 |
| falktx | but the UI needs to inform the host what param is selected/under | 17:40 |
| drobilla | I suppose the touch interface could have been a bit more expressive and cover this as well | 17:41 |
| drobilla | Oh well | 17:41 |
| falktx | drobilla: do you see the usecase? | 17:42 |
| drobilla | yes | 17:42 |
| falktx | ok, I'm not working on this now, but saying the idea | 17:43 |
| drobilla | kinda smells enough like talking actual events between UI and host it kind of begs the question... | 17:44 |
| falktx | drobilla: can the lv2 wiki have a "future ideas" page? | 17:44 |
| drobilla | Maybe just because someone else is trying to convince me that a full event API between them and making the host implement all that + RGB surface is what should happen | 17:44 |
| drobilla | Is there not already one of those? | 17:45 |
| falktx | drobilla: in a similar topic. I want small UIs for embed canvas so bad... | 17:45 |
| drobilla | falktx: Feel free to create whatever pages you like | 17:45 |
| falktx | drobilla: like you do with ingen embed UI right now | 17:45 |
| drobilla | I need to clean it up and make the wiki more inviting, more use of it would be good | 17:45 |
| falktx | drobilla: if there was a event-based + rgba thing in lv2, we could draw those directly on the canvas :) | 17:46 |
| drobilla | falktx: I'm almost half considering whether I want to even do that anymore, but the possibility is certainly nice in any case | 17:46 |
| falktx | instead of relying on embed, gets a bit messy sometimes | 17:46 |
| drobilla | Yeah, it's a nice idea (if you ignore GL), but events is the real problem | 17:47 |
| drobilla | Actual RGBA or cairo surface, I don't know. The latter is more powerful and probably can skip some copying overhead in most cases, but less portable. | 17:47 |
| drobilla | But still, making hosts implement a full on event interface strikes me as an unbelievably terrible idea | 17:48 |
| falktx | say it's optional ? | 17:48 |
| drobilla | Not much condolence there, really. | 17:48 |
| falktx | maybe provide already working code for gtk2 or something | 17:48 |
| falktx | ie, build the rgba thing and you get an gtk2 UI for free | 17:49 |
| drobilla | Adding graceful degradation to external for any UI, and fixing the "bunch of different definitions for the same UI" problem strikes me as a much more pragmatic approach | 17:49 |
| drobilla | falktx: An absolutely massive amount of platform specific code that hosts have to implement is the problem, not UI side. Even if there's a drop in, I don't know... | 17:50 |
| drobilla | A bunch of API is a bunch of API is a future compatibility headache. | 17:50 |
| drobilla | Plus I don't know about the feasibility of various toolkits to draw to an RGB buffer. | 17:53 |
| drobilla | and lots of people want to use GL anyway which definitely doesn't (reasonably). | 17:53 |
| falktx | I understand the API problem | 17:53 |
| drobilla | So as much as I would like to completely destroy non-portable anything in the host:UI interface it just doesn't seem like a good plan :/ | 17:53 |
| falktx | can we perhaps have string mapping to functions? | 17:53 |
| falktx | func_type get_functions("THIS_FUNC_NAME") ? | 17:54 |
| drobilla | (this also makes me think of another thing, whether pugl really should do the glut thing, or use structs which are way more extensible) | 17:54 |
| falktx | drobilla: if we map strings to functions, the API can be extensible | 17:55 |
| drobilla | Well, if you really want to hit the LV2 crack pipe you can take that one step further and describe events as atom objects :) | 17:55 |
| falktx | nice | 17:55 |
| drobilla | falktx: This was my idea for doing external UI | 17:55 |
| drobilla | a varargs command thing instead of show() hide() and run() or whatever it was | 17:56 |
| HarryHaaren | saw that on the lv2-list, seemed a good idea to me | 17:56 |
| drobilla | Not type safe, but whatever | 17:56 |
| drobilla | Though just sticking a size as the first field as discussed earlier would let it be extensible but still just have normal functions | 17:57 |
| drobilla | Iiiiiiiiiiiiiiii dunno | 17:57 |
| drobilla | Thinking maybe the best plan is to make a really simple exampe plugin with a pugl UI, make it work for all platforms (including both wayland and X11), and just hammer on that until it's Nice™ | 17:58 |
| * falktx appreciates lv2 more and more after trying to make sense of the vst3 spec | 18:00 | |
| HarryHaaren | +1 for simple plugin | 18:01 |
| falktx | having to subclass a bunch of classes just to make a bypass plugin is the wrong way to do it! | 18:01 |
| drobilla | Yeah, honestly, LV2 takes quite a bit of flak for compatibility given what VST did there | 18:03 |
| drobilla | Though event/atom was indeed a total screw-up, so fair enough. | 18:03 |
| falktx | I say just give it time | 18:04 |
| falktx | lv2 takes a lot of time to get into, with time we'll see new plugins | 18:04 |
| drobilla | Yeah. Things are going alright, really. | 18:04 |
| falktx | drobilla: I'm also working on a plugin framework like juce that works with UIs properly (no instance-data) | 18:05 |
| drobilla | Pushing event into the dustbin and sorting out this UI junk will be good. | 18:05 |
| falktx | I was going to present it at lac, but that paper was too much work... | 18:05 |
| drobilla | falktx: Using JUCE as just UI with having proper comm would be nice | 18:05 |
| drobilla | Yeah, I spent waaaaayy too much time on my paper | 18:06 |
| falktx | drobilla: jules doesn't use linux, and juce itself is not that good in linux | 18:06 |
| falktx | I manage the ports but for my own plugins I won't use it | 18:07 |
| drobilla | falktx: fair enough | 18:07 |
| drobilla | I don't like the flavour of the thing, but it's pretty, and can do portable UIs, at least | 18:07 |
| drobilla | (Frankly the self-praise about stellar code quality all over its site is pretty divorced from the reality I've seen...) | 18:08 |
| falktx | juce own code is pretty good, can't say the same about open plugins for juce though | 18:09 |
| falktx | there are a few odd choices in the framework. like base64 not actually being as the RFC | 18:10 |
| drobilla | There's way too many things that are "base64" | 18:11 |
| falktx | for lv2 presets I needed the "common" base64 | 18:12 |
| falktx | no juce classes provided that | 18:13 |
| drobilla | Yeah. IIRC xsd:base64binary is as per original RFC but with 76 character line length limit removed | 18:14 |
| drobilla | I think I managed to do it in 50 lines or so of C | 18:15 |
| falktx | drobilla: is adding new ui types still ok? | 18:23 |
| falktx | I want lv2ui:NTK | 18:23 |
| falktx | and lv2ui:Qt5 (rui synths can already use that) | 18:24 |
| *** root1 is now known as Guest23415 | 18:25 | |
| *** HarryHaaren has quit IRC | 18:26 | |
| drobilla | Everyone I asked about NTK thus far, including the author, thinks it should just work via X11 (or whatever underlying thing is there) | 18:30 |
| falktx | cause they don't know how it works | 18:31 |
| drobilla | We can add types but I also think it's kind of becoming clear that it's not the way to go | 18:31 |
| falktx | harry was a bit confused by ui types | 18:31 |
| drobilla | Does an NTK host exist? What's the pointer type? etc. | 18:31 |
| drobilla | It also doesn't strike me as the most stable thing to bake into the spec in the world. | 18:32 |
| falktx | carla will do NTK once there is a plugin for it | 18:33 |
| drobilla | Basically there's a lot of questions about that one I don't know the answer too, and know of little reason to care. | 18:34 |
| drobilla | Qt5, fine. | 18:34 |
| falktx | I'll talk to harry to try and expose its lv2-ui as NTK widget | 18:34 |
| falktx | then we'll have something to test | 18:34 |
| drobilla | Yeah, but......... why? | 18:34 |
| falktx | it skips the x11 embed business | 18:35 |
| drobilla | and, importantly, is "NTK" widget a binary stable thing | 18:35 |
| drobilla | it does if your host is NTK, which AFAIK none are. | 18:35 |
| falktx | ntk and x11 embed have some issues | 18:35 |
| drobilla | but I can't really put "oh, y'know, whatever the hell 'ntk' means this week" into a spec, you know? | 18:35 |
| falktx | I know | 18:36 |
| falktx | but since it's a shared lib, supposedly all apps are built against the same version | 18:36 |
| drobilla | (Anyway, I am tired of hearing about vague undefined "issues") | 18:36 |
| drobilla | For a lib that's deliberately light and static/bundled appropriate, and not packaged basically anywhere, that's a stretch | 18:37 |
| falktx | I understand the situation | 18:38 |
| drobilla | (Also, a lot of the backroom criticism I hear about LV2 is UI stuff being done totally wrong and completely inappropriate for other platforms, commercial plugs, etc) | 18:38 |
| falktx | the author has not been very actively lately... it's weird... | 18:38 |
| drobilla | But basically as far as I am concerned, X11 embedding works perfectly. | 18:39 |
| drobilla | Unless you're doing GL and need hard vsync, which is not figured out. | 18:39 |
| drobilla | Since that needs to work anyway, fixing any issues - were I to actually know about them - would be the first priority. | 18:40 |
| falktx | drobilla: I was just thinking using the real widget type vs X11 would be a good choice | 18:40 |
| drobilla | If that fails, *then* working around them and fragmenting the interface even more | 18:40 |
| drobilla | falktx: Just more for hosts to deal with | 18:40 |
| falktx | if the plugin exposes both ntk and x11 uis, no | 18:41 |
| drobilla | There's a LOT of widget sets one could use. | 18:41 |
| drobilla | Ultimately the host is just going to need to add code to get the native window for each one of them. | 18:41 |
| drobilla | Anyway, in summary strikes me as a generally pointless idea, but if all the above questions are answered, and the answers are appropriate, fine. | 18:43 |
| drobilla | Since I personally have roughly 99999999999999999999999 things way more important to do, I won't be doing that research. | 18:43 |
| drobilla | But I'm almost positive male will actively refuse the idea of a stable ABI for it anyway. | 18:44 |
| falktx | drobilla: is it ok if I make my host implement lv2ui:NTK and a plugin using that too without it being official? | 18:44 |
| falktx | other hosts will simply load the x11 ui | 18:44 |
| drobilla | falktx: No, it is not okay for you to invent URIs in namespaces that you do not control | 18:44 |
| drobilla | Especially when you can't even describe a reason for doing so. | 18:45 |
| drobilla | Do something useful :P | 18:45 |
| drobilla | You can of course invent URIs in appropriate namespaces all you like. | 18:45 |
| drobilla | But of all the toolkits anyone is using whatsoever, this one is most likely to be fragmented across UIs. This is a bad idea. | 18:47 |
| drobilla | Particularly when I'm fucking well finally trying to *resolve* UI fragmentation :P | 18:48 |
| drobilla | Speaking of resolving fragmentation, consider yourself warned that I will actively sabotage any interfaces defined in lv2plug.in/ns that are not official. Including putting plugins in the SDK that segfault the host, and making lilv reject plugins automatically. | 18:55 |
| drobilla | That shit will not be happening again. | 18:56 |
| falktx | what about plugins that use lv2plug.in? :P | 18:57 |
| falktx | it happened before... | 18:57 |
| falktx | drobilla: I have a kxstudio namespace for this sort of things now. won't use lv2plug.in for experimental things, promise | 18:58 |
| drobilla | Yeah, those got moved. | 18:58 |
| drobilla | I don't know, I figured it was mind-blowingly obvious that you simply don't do that. | 18:59 |
| drobilla | It's been put in the docs in various places since, but it's kind of hard to find one place everyone will read | 18:59 |
| drobilla | I highly recommend for your own sake that you don't go out of your way to deliberately add compatibility headache to the host:UI interface for no reason, but you're free to do whatever unwise nonsense you like. That is why we hijack DNS :) | 19:00 |
| falktx | I need to get my host fully working first... | 19:01 |
| falktx | drobilla: is ingen going to be released anytime soon? | 19:03 |
| * drobilla shrugs | 19:03 | |
| falktx | no rush on my side, i'm just wondering | 19:03 |
| drobilla | I would like to do so. I try to do so. | 19:03 |
| drobilla | An overwhelming majority of my time gets spent addressing LV2 problems no body else does anything about. | 19:04 |
| drobilla | IIRC the TODO there is blablack submitted a few bugs and I need to make MIDI binding saving work. | 19:04 |
| falktx | what do you want me to do? | 19:05 |
| drobilla | ganv layout stuff needs to be reigned in a bit. | 19:05 |
| falktx | I'm not sure if I can help lv2 directly that much | 19:05 |
| drobilla | but I did clean up the major gross aspects of that one, so ganv+patchage release will probably happen first, followed by Ingen | 19:05 |
| drobilla | I don't know. Everyone implementing whatever is decided for sorting out the UI stuff would be good. | 19:06 |
| drobilla | I'm not really complaining, it's just the way it is. I get why nobody else works directly on the spec. | 19:07 |
| drobilla | I get it very much, because it's a shitty entirely thankless job :) | 19:07 |
| falktx | does the svn repo have a public section? | 19:08 |
| drobilla | oh, that reminds me, blablack made a video, where was that... | 19:08 |
| drobilla | falktx: for what? | 19:08 |
| falktx | for devs to contribute more stuff directly ? | 19:09 |
| drobilla | yeah, but I mean, like what? there's plugins, there's specs, there's lv2specgen | 19:09 |
| falktx | well, you're the one that said no one else is working directly on the spec | 19:10 |
| falktx | I think lv2 might be good to have on github | 19:10 |
| drobilla | I don't know what else would go in there. Nice simple examples are among the most helpful contributions almost anyone can do. | 19:10 |
| drobilla | eeeeehhh. In some ways yes, in some ways no. | 19:11 |
| drobilla | It's very definitely not the sort of thing where forking is good. | 19:11 |
| drobilla | I will move to git at some point, but it's not really high priority. | 19:11 |
| drobilla | I can spend days on that OR any of the above things people actually care about... | 19:12 |
| drobilla | Honestly given how immensely difficult it seems to be to get people to even think or talk about what to do, encouraging willy-nilly breaking of the headers hardly seems like the right thing anyway. | 19:13 |
| drobilla | Patches Welcome™ | 19:14 |
| * drobilla watches http://youtu.be/LWfF71NerkQ | 19:14 | |
| falktx | calf is working on ingen again? | 19:16 |
| falktx | I though calf synths didn't work because of event extension | 19:16 |
| drobilla | is there calf in Ingen in here? I didn't notice | 19:17 |
| falktx | drobilla: is the ingen graph processing using multi-core? | 19:18 |
| drobilla | falktx: No. | 19:19 |
| drobilla | I implemented that a while ago but I doubt it actually works right now. | 19:19 |
| drobilla | I need to switch to the non-callback Jack interface to do it properly. | 19:19 |
| drobilla | It may sound odd, but actual implementation of the audio processing is an extremely low priority for Ingen right now. I'll probably rewrite it later. | 19:19 |
| drobilla | File format, compatibility, stability, etc. is top priority. Internal guts don't affect anything of long-term importance, so that's post-release stuff. | 19:20 |
| falktx | ok, bbl | 19:20 |
| drobilla | Making it parallel shouldn't be too hard. | 19:20 |
| drobilla | Need to think about parallel across voices too, though. | 19:21 |
| drobilla | In general I think it needs to be rewritten in a compiler style. | 19:21 |
| * drobilla returns to horrible tedious marking | 19:21 | |
| *** NickSB2 has joined #lv2 | 19:24 | |
| *** falktx has quit IRC | 19:25 | |
| *** mlpug has joined #lv2 | 19:36 | |
| * drobilla 's volcas arrive 5 months after the fact | 19:44 | |
| drobilla | aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaand work stops | 19:44 |
| *** falktx has joined #lv2 | 19:50 | |
| Anchakor | with the UI stuff, why not just make/pick a API for the RGBA buffer + events and let people implement it for various GUI toolkits? | 19:55 |
| falktx | limitations | 19:56 |
| falktx | what about touch? | 19:57 |
| Anchakor | [18:53] [ drobilla] Plus I don't know about the feasibility of various toolkits to draw to an RGB buffer. | 19:57 |
| Anchakor | [18:53] [ drobilla] and lots of people want to use GL anyway which definitely doesn't (reasonably). | 19:57 |
| Anchakor | hmm just got to this in my reading of the backlog | 19:57 |
| Anchakor | falktx: well that API should be fairly extensible | 19:57 |
| Anchakor | but having this thin API layer between lv2 and GUI toolkits to do embedded UI seems like the only reasonable thing to do | 19:59 |
| *** rncbc has joined #lv2 | 20:00 | |
| falktx | it's also very to get wrong | 20:00 |
| falktx | *very easy | 20:00 |
| Anchakor | well, it would be essentially a very thin meta-GUI-toolkit | 20:01 |
| Anchakor | GUI adaptor in OOP speak :) | 20:01 |
| falktx | that implies limitations | 20:01 |
| Anchakor | I'm sure we could learn from the mistakes of various GUI toolkits | 20:02 |
| drobilla | Anchakor: "Let people implement it" | 20:03 |
| drobilla | Anchakor: hah ;) | 20:03 |
| Anchakor | it beats the current approach of many GUI-toolkit extensions in that it wouldn't require hosts to constantly change their code to support plugins, but if a plugin author wanted to use some new shiny GUI toolkit, THEY would have to implement its mapping to the GUI adaptor API | 20:04 |
| drobilla | That latter point is also true of window handles. | 20:04 |
| drobilla | Except "implement" is usually unbelievably trivial in that case, e.g. calling a get function. | 20:04 |
| Anchakor | are you sure? | 20:05 |
| Anchakor | the GUI adaptor could even make it possible for falktx's wine running separete process win vsts to render into the host embedd :) | 20:06 |
| falktx | those have nothing to do with lv2 or embed | 20:07 |
| falktx | you can't use them directly in lv2 | 20:07 |
| Anchakor | drobilla: with the window handles, the host still needs to implement the event stuff in the GUI framework the plugin is in, no? | 20:07 |
| Anchakor | if the GUI adaptor API was done with atoms, you could embedd a GUI of a process running on a different machine :) | 20:08 |
| falktx | OR, ...OR.... | 20:11 |
| falktx | if the UI doesn't need instance-data | 20:11 |
| falktx | you can just run it on that machine | 20:11 |
| falktx | the atom communication already allows this | 20:12 |
| drobilla | Anchakor: No. The UI can implement that. | 20:14 |
| drobilla | Anchakor: Most likely via a toolkit, or portability framework like Pugl. | 20:14 |
| drobilla | No native window handle, no ability to get events period, and you're a slave to what the special LV2 API says, and what the host actually implements. | 20:15 |
| drobilla | The jist of it is that there is only one linga franca for draw+events, and that's the native window handle for whatever platform. | 20:17 |
| drobilla | There is no such things that is truly portable. | 20:17 |
| Anchakor | well my idea is that the burden of implementing support for new GUI frameworks should be on the plugin developers which want to use it, not the host developers, nor the lv2 core developers (aka drobilla) | 20:18 |
| drobilla | And lots of stuff requires that handle anyway. So the thing to do is, make that as nice as possible. | 20:18 |
| drobilla | Anchakor: Precisely. Adding a bunch of LV2 special API for events does the exact opposite of that. | 20:18 |
| Anchakor | drobilla: I don't see how that is true | 20:19 |
| drobilla | Well, you want to ADD a bunch of complicated and almost certainly limited API to the interface | 20:19 |
| drobilla | Meaning hosts actually have to implement all that, which is far from trivial, especially considering portable. | 20:20 |
| drobilla | The absolutely massive imposition this is can not be understated. | 20:20 |
| drobilla | The benefit? Well, it's theoretically possible to write a plugin that doesn't need a portability framework or native anything itself. | 20:20 |
| drobilla | Something very few people actually want to do anyway. | 20:20 |
| drobilla | And something that can't do whate everyone wants anyway. | 20:20 |
| drobilla | The cost:benefit is really not appealing at all. | 20:20 |
| Anchakor | hosts can use an utility library like lilv, how is that worse from the current state? | 20:20 |
| drobilla | Then gluing that to any toolkit a UI author actually wants to use is a ton of work for every UI author, on top of it. | 20:21 |
| drobilla | It's worse because, well, you've added a shitload of problems and solved almost none. | 20:22 |
| Anchakor | now we have X frameworks hosts support and Y frameworks plugins use, rather then working it out so that the X*Y combinations work fine isn't it better to make a 1 middleware for everyone to work with? | 20:23 |
| Anchakor | we already got very extensible communication tool with atoms | 20:23 |
| drobilla | Even from the fantasy perspective of people who don't actually intend to do any of that work whatsoever it's not very appealing. | 20:23 |
| drobilla | Anchakor: The closest thing to such a middleware is a native window handle. | 20:25 |
| drobilla | Which can, basically by definition, do *anything*, and does not restrict anyone to a special LV2 interface for events or whatever, and thus does not force hosts to implement that thing. | 20:25 |
| Anchakor | but that means the host needs to implement the API of the GUI framework the plugin uses | 20:26 |
| Anchakor | no? | 20:26 |
| drobilla | Basically I can rephrase your idea as "make an LV2 toolkit and force it on everybody" | 20:26 |
| drobilla | Even if it was a good idea it'd fail so ultra hard... | 20:26 |
| drobilla | Anchakor: Not really, you need to show the thing somehow. Either via suil, which just gives you whatever you want, or by essentially calling show() which anyone can do. | 20:27 |
| drobilla | This is not even in the same universe of pain in the ass as implementing an entire toolkit API worth of event handling. | 20:28 |
| Anchakor | how does the event handling work? | 20:28 |
| drobilla | It works in the same way event handling works for every other program with a window. | 20:28 |
| Anchakor | even if X11, cocoa an win32 all have a function called show() in their window handle API | 20:28 |
| drobilla | That's what windowing systems do. | 20:28 |
| drobilla | They don't, that's (the graceful replacement of) external-ui. | 20:29 |
| Anchakor | in what you propose, what code does translate Qt5 events into GTK events? | 20:29 |
| drobilla | What I propose is what we already have, which works. | 20:30 |
| drobilla | No code does any such thing. | 20:30 |
| Anchakor | I am probably fairly ignorant what we have already then | 20:30 |
| Anchakor | I'm just trying to understand, but I don't know | 20:31 |
| drobilla | X11, Wayland, Carbon, Windows, etc, etc, of course have their own event systems. | 20:31 |
| drobilla | Let's just say it's self evident that any window can handle events. | 20:32 |
| Anchakor | we agree that the burden of implementing support for new GUI frameworks should be on the plugin developers which want to use it, not the host developers, nor the lv2 core developers (aka drobilla) | 20:34 |
| drobilla | Effectively when you use native window handles at the interface there is no burden, you just use them. | 20:34 |
| Anchakor | now in your solution, how would this plugin author implement this plugin? where would he put the code handling the new GUI framework so all existing hosts can use his plugin (without any code changes)? | 20:35 |
| drobilla | I do not know what "handling" you speak of. | 20:35 |
| drobilla | Same way you write any UI, basically. | 20:36 |
| Anchakor | lets say a new alteranative to X11, Wayland, Carbon, Windows appears, where does the code handling it go? | 20:36 |
| drobilla | Any window on, say, X11, will have an X11 window handle regardless of what high level framework you wrote it in. Any reasonable toolkit will provide access to it. | 20:36 |
| drobilla | Hosts, or more realistically a library like suil. | 20:37 |
| drobilla | This is inherent. | 20:37 |
| drobilla | So don't bother trying to tie it to your argument that it should be plugin's problem because it's not possible anyway ;) | 20:37 |
| Anchakor | ok I think I get it now | 20:38 |
| drobilla | Basically if you're on X11, you can do everything via an X11 handle. Wayland transition sucks, but such is life. | 20:38 |
| drobilla | or, you can do the combinatorial explosion of every single toolkit under the sun thing. | 20:38 |
| Anchakor | but I'm afraid not many GUI toolkits support working with just vanilla window handles | 20:38 |
| drobilla | Clearly not really feasible, but interface wise, the solution is to let UIs provide whatever. | 20:39 |
| drobilla | Anchakor: incorrect. | 20:39 |
| drobilla | Anchakor: I am not aware of a single one that doesn't. | 20:39 |
| drobilla | Other than non-C situations and such, anyway | 20:39 |
| *** mlpug has quit IRC | 20:40 | |
| Anchakor | I don't think in Qt you can make a QWindow out of a X11 window handle | 20:41 |
| drobilla | You don't have to. A QWindow inherently is an X11 window. | 20:42 |
| drobilla | You get the handle and give that to the host. | 20:42 |
| falktx | there's no QWindow... | 20:42 |
| drobilla | Embedded is a little more sophisticated because you need to specify a parent and such | 20:42 |
| Anchakor | drobilla: I meant when making a host to handle X11 handles of plugins | 20:44 |
| drobilla | I think my default answer to this from now on is going to be "we are adding graceful degradation so you can just call show() and a window will pop up" | 20:46 |
| drobilla | I have spent way too much time talking around the issue in non useful ways this week. | 20:46 |
| drobilla | and my default answer for how hosts do it is, use suil. | 20:46 |
| drobilla | The how is none of your concern ;) | 20:46 |
| Anchakor | I'm sorry but it's a pretty complex for people like me who don't know ins and outs of windowing systems and GUI toolkits | 20:47 |
| Anchakor | ok, "use suil" is a good enough answer :) | 20:47 |
| drobilla | It's not that complex when you realize that ANY window is, well, a window. | 20:47 |
| drobilla | Qt, Gtk, NTK, Pugl, everything ever that will actually show a UI on your screen is the same thing under there somewhere. | 20:48 |
| Anchakor | yeah, but the point is the API | 20:48 |
| drobilla | That thing that everything inherently is has an API. | 20:49 |
| Anchakor | if I were to generalize a bit, Suil is the middleware I was talking about at the start, except it isn't about RGBA buffer but window | 20:49 |
| drobilla | In a way, I suppose. | 20:50 |
| drobilla | Basically this is frustrating me for the same reason the list is, and my private email conversation with another dev is. | 20:50 |
| drobilla | Nobody will fucking even talk about the actual relatively simple UI API things that really actually need doing. | 20:51 |
| drobilla | So I'll just do it. | 20:51 |
| drobilla | </discussion> | 20:51 |
| falktx | lv2 UIs are not an issue for me now | 20:52 |
| falktx | whatever toolkit appears next, I just need to make a small tool that will show that | 20:52 |
| Anchakor | well a common plugin writer or a linux musician isn't people who will have useful feedback for you I guess, you better speak to people who wrote the core of GTK/Qt and dealt with issues like that | 20:52 |
| drobilla | No, this is what I mean. This is all missing the point. | 20:53 |
| drobilla | Toolkits are beside the point. | 20:53 |
| drobilla | The issue we have currently is precisely toolkits. They affect the host:UI interface. To some degree this is always going to be true. | 20:54 |
| drobilla | The actual problem is that UIs are foced to choose ONE per UI, with the consequence that they have to describe a billion different UIs, all alike, which are actually the same thing. | 20:54 |
| drobilla | It can, and should, Just Fucking Work, easily, always. | 20:55 |
| drobilla | Maybe I'm a Gtk and ideally I'd like a Gtk widget. Can you give me that? No? Okay, well, I can embed and we're on X11, so can you give me that? No, okay, well, do you support the show API that can always work? Yes, great, pop up a window please. | 20:55 |
| drobilla | That is what we need. | 20:56 |
| falktx | that is great | 20:56 |
| falktx | I don't think anyone will ever oppose that | 20:56 |
| drobilla | Graceful degradation. | 20:56 |
| Anchakor | yeah that is good | 20:56 |
| Anchakor | but I thought you were thinking of some intra-toolkit embedding solution (as the most advised GUI solution and first on the list of graceful degradation) | 20:57 |
| drobilla | Tricky bit is backwards compatibility, I suposse, but it's not that tricky. You can add the 'askey' interface as extension_data and still be an X11UI or whatever for hosts that don't know abou tit. | 20:57 |
| drobilla | That is an intra-toolkit embedding solution. | 20:57 |
| Anchakor | s/intra-toolkit/inter-toolkit/ | 20:57 |
| drobilla | A large part of the reason I need to make it easy to just provide all these things, which is trivial to do, is so I can embed. | 20:58 |
| drobilla | Without having these constant retarded discussions about embedding and how can it all work and wayland and oh no the sky is falling and maybe we should make LVTK and whatever the fuck. | 20:58 |
| drobilla | It lets everyone just write their damned code. | 20:58 |
| drobilla | Problem solved, and we move on to the next thing where the spec is getting in the way, if necessary. | 20:59 |
| drobilla | (Not this discussion in general, this is a years long theme) | 20:59 |
| falktx | curiously, LVTK does exist... | 21:00 |
| drobilla | We just lack a level of divorce between what UIs provide and what hosts support. | 21:00 |
| Anchakor | I'm still not sure - Suil will provide the API which host will use to tell the plugin by a window handle "hey, draw here at (x, y) with (width, height)", right? | 21:00 |
| drobilla | When really what we want is UIs provide everything that's easy for them to do so (which is usually 3 things), and hosts support whatever. | 21:00 |
| drobilla | Anchakor: The short answer of how embedding works is that the host (suil) provides a parent window handle. | 21:01 |
| drobilla | I guess I should finish killing myself^W^Wmarking so I can actually do this | 21:02 |
| *** rncbc has quit IRC | 21:03 | |
| falktx | this means UIs will just work on osx without me having to deal with cocoa reparenting :) | 21:03 |
| Anchakor | I had a professor at my university who market by putting the paper near an opened window and marking by the clusters the papers formed | 21:04 |
| Anchakor | marked* | 21:04 |
| Anchakor | papers* | 21:04 |
| falktx | drobilla: I should try to fix that someday if harrison or you don't, but having a working UI is a start | 21:04 |
| * falktx is talking about pugl | 21:04 | |
| drobilla | Well, hopefully somebody figures out proper embedded OSXey things at some point, but yeah, that's the idea. At the veery least UIs can always work externally (assuming they implement that interface) | 21:04 |
| drobilla | falktx: I have no host, so never tested it. | 21:04 |
| drobilla | I'm going to try and install an OSX VM | 21:05 |
| drobilla | (Have a Windows one now, but no compiler. They want a login. Ugh.) | 21:05 |
| falktx | doesn't ardour3 have cocoa UIs? | 21:05 |
| drobilla | Anchakor: I'm sure I could mark by how horribly awful their code looks at first glance and have a < 10% error rate | 21:05 |
| falktx | rgareus told me before that ardour3 did lv2 cocoa UIs | 21:05 |
| drobilla | Ardour uses suil, and suil still doesn't support cocoa specific anything. AFAIK Ardour 3 dists on OSX still use X11 | 21:06 |
| drobilla | I'm a bit stuck for changing much of anything in pugl right now since I don't have OSX around. | 21:08 |
| falktx | I'm going to see if I can install osx86 again (a recent version) | 21:09 |
| falktx | I only have 10.5 working which is a bit old | 21:09 |
| drobilla | I have a 10.6.something lying around. It worked at some point. | 21:21 |
| drobilla | Speaking of which, man is Windows bloated. My install is like 18 gigs. | 21:21 |
| drobilla | Probably a lot of that is office, I suppose. | 21:21 |
| drobilla | I'm half tempted to just make an LV2 UI 'command' interface, which can be provided in both directions, that has one function, int command(const char* cmd_uri, const char* fmt, ...) | 21:23 |
| drobilla | show, hide, run, touch, menu, whatever, go nuts. | 21:23 |
| drobilla | fmt basically just being there so we can stick the GCC tags to make it type check, but could just be ommitted | 21:24 |
| Anchakor | you mean uint32_t urid, no? :) | 21:26 |
| drobilla | Does performance really matter enough to justify the nuisance in this case? I doubt it. | 21:28 |
| drobilla | Certainly not for show/hide, if it was to be used for control rate things, maybe (but even then) | 21:28 |
| Anchakor | consistency | 21:30 |
| drobilla | Well, consistency would be to just add normal interfaces with explicit functions like everything else in there | 21:33 |
| drobilla | Which is probably what I'll actually do. Add a show/hide one. | 21:33 |
| Anchakor | if they don't need to be very extensible | 21:33 |
| drobilla | Unfortunately external needs a "oh, I closed" thing in the other direction too. | 21:34 |
| falktx | the ui idle already has that | 21:37 |
| falktx | it returns != 0 when it doesn't want more idle. we can re-use that | 21:38 |
| drobilla | falktx: Hm, true. Pretty much polling though, bit nasty. | 21:48 |
| falktx | on the old external-ui it states ui_closed must be called from within run/idle | 21:48 |
| drobilla | Do many even need idle? | 21:49 |
| drobilla | Well, less interface is always good. I will try it, anyway. | 21:51 |
| falktx | all pugl based plugins need idle afaik | 21:52 |
| falktx | except when using a 2nd thread, but that's not very good practice | 21:52 |
| drobilla | Yeah, but toolkit ones generally don't. | 21:55 |
| falktx | sometimes they might | 21:57 |
| falktx | having an idle func ready is easier than having to set a callback I think | 21:57 |
| drobilla | This reminds me, anyone have any opinions on just sticking pugl in the LV2 dist? | 23:08 |
| drobilla | It would be the trailblazer for /lib | 23:08 |
| drobilla | I'm torn on the general idea of including libraries in LV2, but I want a good example GUI plugin, and also no/minimal external dependencies... | 23:09 |
| fps | i don't like plugin guis very much ;D | 23:11 |
| * fps is not being constructive so he shuts up | 23:13 | |
| Anchakor | drobilla: it's good by me, even if non-lv2-projects started to use it, lv2+pugl are small enough | 23:14 |
| Anchakor | if you want to be hip, bundle together a bunch of libs and call it a "framework" ;) | 23:15 |
| drobilla | fps: I seriously hate this shit so much, you have no idea :) | 23:21 |
| drobilla | Please, for the love of everything that is good, make this next bit of work make all the UI nonsense fuck off so I can get on with something actually relevant to SOUND | 23:22 |
| drobilla | Advanced plugin control, sequencing, multi-channel, note-specific control, automatable events, so much cool stuff to do. So much cool stuff I'd probably have done already if I didn't need to waste the majority of my time on UI crap I don't care about... | 23:24 |
| drobilla | Anchakor: LV2 SDK® :) | 23:24 |
| drobilla | I think maybe the way to include libs is to just put them in the tarball, but otherwise have them be 100% independent libs. Their own include paths, own versions, etc. | 23:25 |
| drobilla | (the LV2 URI-like include path style can't really do parallel installation anyway) | 23:25 |
| drobilla | There is UI stuff I want to do, e.g. control panel builder and so on, but it's basically the opposite of custom plugin GUIs. | 23:28 |
| fps | drobilla: would that latter thing mean building UIs by the host? And still having everything available as ports/other mechanism for maximum hackability and usability? | 23:29 |
| drobilla | fps: yep. | 23:30 |
| fps | drobilla: +1 | 23:30 |
| drobilla | Which is how LV2 control ports work anyway, and custom UIs work via those, or events | 23:30 |
| drobilla | We did that bit way more right than VST anyway | 23:31 |
| fps | drobilla: yeah, i think i remember looking at that stuff after blatantly ripping the sampler example with its GTK gui to load the sample | 23:31 |
| fps | i'd like to just not include the GTK gui ;D | 23:31 |
| drobilla | fps: jalv can show a file selector for that one, but that stuff is sort of experimental still | 23:32 |
| fps | drobilla: cool.. since i use the same mechanism, i guess that should work with jalv, too? | 23:32 |
| drobilla | that UI is indeed totally silly | 23:32 |
| drobilla | fps: if you document the property in the same way it should | 23:33 |
| fps | drobilla: cool, doing this before going to bed ;D | 23:33 |
| fps | https://github.com/fps/ladspa.m.lv2/blob/master/instrument.ttl | 23:34 |
| fps | atom:Path? | 23:34 |
| Anchakor | I guess there are things for which host wouldn't support decent UI ever, like setting sample loop points | 23:36 |
| drobilla | fps: looks rightish | 23:36 |
| fps | drobilla: what version of jalv would support that? | 23:36 |
| drobilla | Anchakor: Sure. But the 99% case is basically numbers. | 23:36 |
| drobilla | This is why you talk about it as "automation" | 23:36 |
| drobilla | Everybody agrees automation is good | 23:36 |
| drobilla | Avoids all that BUT I NEED CUSTOM warring. | 23:37 |
| fps | oh jalv.gkt doesn't seem to have a --version switch | 23:37 |
| drobilla | fps: I dunno. Has for a while. | 23:37 |
| fps | [at least in the version i have here, which i don't know what it is ;D] | 23:37 |
| drobilla | huh. so it doesn't. | 23:37 |
| drobilla | fps: Well, just run jalv.gtk -g http://lv2plug.in/plugins/eg-sampler | 23:37 |
| drobilla | fps: and see if it works | 23:37 |
| fps | it does :D | 23:38 |
| fps | coolio | 23:38 |
| fps | :D | 23:38 |
| drobilla | I don't know if the vocab for this is really the right thing, but that is my little "look at this" use case currently, anyway | 23:38 |
| drobilla | a patch:Set can only set one thing at a time, which is pretty weak. but it also looks less scary. | 23:39 |
| drobilla | (My likely topic for LAC2015) | 23:40 |
| fps | drobilla: seems to work with my little plugin, too :D | 23:40 |
| fps | great | 23:40 |
| fps | hmm, no, i guess i'll have to touch some more code.. well, tomorrow | 23:41 |
| * drobilla opens a .docx with a photo of a diagram hand-drawn on a piece of paper in it | 23:47 | |
| drobilla | Sigh. | 23:47 |
| fps | ;D | 23:48 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!