| falktx | rgareus: manual says "This warns if an extern declaration is encountered within a function. " | 00:00 |
|---|---|---|
| rgareus | falktx: thanks | 00:00 |
| rgareus | drobilla: I'll wait another 24h then update https://github.com/drobilla/lv2/pull/7 with falktx' comment. | 00:03 |
| drobilla | -Wsign-conversion is rough | 00:05 |
| falktx | hahah, welcome! | 00:06 |
| falktx | I have a few casts for that | 00:06 |
| falktx | the warning helps catch a little bad code sometimes. rarely, it's just worth it by a tiny bit | 00:07 |
| falktx | -Weffc++ is "nice" too | 00:08 |
| falktx | but they need to do a -Weffc++11 | 00:08 |
| drobilla | That one has way too many spurious warnings about things that really aren't problems | 00:10 |
| * falktx -> sleep | 00:11 | |
| * rgareus too | 00:18 | |
| *** ricardocrudo has quit IRC | 00:30 | |
| *** oofus_lt has joined #lv2 | 00:45 | |
| oofus_lt | trying to build latest LV2 and associated libs and Lilv 0.22 is failing to configure because it can't find Sord >= 0.13.0, but I just installed 0.14.0 and I'm pretty sure that installed correctly. | 00:45 |
| oofus_lt | anybody seen anything similar or maybe have any pointers ? | 00:46 |
| drobilla | Whatever pkg-config says is what configure finds | 00:48 |
| drobilla | pkg-config --modversion sord-0 | 00:48 |
| oofus_lt | ah, ok, 0.12.2 | 00:50 |
| oofus_lt | drobilla: sorted, thanks | 00:56 |
| *** oofus_lt has quit IRC | 01:51 | |
| *** artfwo has quit IRC | 02:38 | |
| drobilla | Hm. Now that I think about it, I'm not sure sure I like the idea of unloading bundles because one with a newer plugin is later encountered to begin with. | 02:52 |
| drobilla | Following the LV2_PATH as given gives the user control over what takes precedence | 02:52 |
| *** wumpus has quit IRC | 03:00 | |
| *** wumpus has joined #lv2 | 03:02 | |
| *** edogawa has joined #lv2 | 07:06 | |
| *** edogawa has quit IRC | 07:43 | |
| *** ventosus has joined #lv2 | 07:59 | |
| *** sigma6 has joined #lv2 | 08:10 | |
| *** ricardocrudo has joined #lv2 | 09:06 | |
| *** falktx|work has joined #lv2 | 09:16 | |
| *** bgola has quit IRC | 09:50 | |
| rgareus | drobilla: that's not what currently happens either. | 10:29 |
| rgareus | drobilla: but even if it was like this, that'd be a geeky unix solution. musicians don't care about LV2_PATH | 10:33 |
| *** digidog has joined #lv2 | 11:26 | |
| *** digidog has quit IRC | 12:05 | |
| *** artfwo has joined #lv2 | 12:37 | |
| *** gabrbedd has quit IRC | 14:16 | |
| *** oofus has joined #lv2 | 14:29 | |
| *** gabrbedd has joined #lv2 | 14:31 | |
| *** y-kaelig has joined #lv2 | 15:31 | |
| *** ssj71 has quit IRC | 15:52 | |
| y-kaelig | long life to LV2 ! | 16:00 |
| drobilla | rgareus: Well, the idea of unloading entire bundles because one plugin version is different is messy at best, but I guess it's the best available option. | 16:07 |
| drobilla | At least until the nasty issues crop up, anyway :) | 16:07 |
| rgareus | drobilla: what's bad about unloading? | 16:07 |
| drobilla | As the person who has probably dealt with all the associated hell more than any other, funny question | 16:09 |
| drobilla | But, nothing, inherently. In practice it's messy and problematic, particularly since the structure of bundles and what's in them is inconsistent, and can even change fundamentally between versions | 16:09 |
| drobilla | i.e. I wouldn't be surprised if this has nasty consequences | 16:09 |
| drobilla | But whatever. I wrote a version that doesn't do redundant reloads into a subworld, commit soon. | 16:10 |
| drobilla | Well, it does redundant loads of the new/provisional one, but not the already loaded stuff which is in the world model anyway | 16:10 |
| drobilla | Still not a huge fan. Tempted to just amend the spec to require versions in the manifest. Few people actually use the things yet anyway. | 16:12 |
| rgareus | drobilla: the spec says "version is required" yet only very few plugins add one | 16:13 |
| rgareus | things have gotten better since falktx took up the role of LV2 high inquistor | 16:14 |
| falktx|work | plugins without version won't come to mod | 16:14 |
| rgareus | If I had a penny for every "duplicate plugin" message I read in in backtraces.. | 16:15 |
| drobilla | Your patch makes it even more verbose ;) | 16:18 |
| rgareus | does it? damn debug messages. | 16:23 |
| rgareus | drobilla: actually no. I changed it from LILV_ERROR to LILV_WARN | 16:24 |
| drobilla | ... that prints, too. But there are two new ones in the version stuff. The duplicate one doesn't fire anymore. | 16:26 |
| drobilla | Not sure if there's a case where it still can. | 16:26 |
| *** rncbc has joined #lv2 | 17:37 | |
| *** deva has joined #lv2 | 17:54 | |
| *** ssj71 has joined #lv2 | 18:56 | |
| y-kaelig | I was thinking about which GUI toolkit should be used for LV2. I'm askign this question because I fell on a thread from a dev working on LV2, and stop using GTK2 in the next release of his plugin | 19:02 |
| y-kaelig | He don't tell why, but that make me thinking if gtk or Qt also are really the best choice for this purpose | 19:03 |
| ssj71 | y-kaelig: in general neither I think if you want it to be cross platform. GTK can be ok if you are using the C version IIUC (not gtkmm) | 19:05 |
| y-kaelig | Qt is also cross platform, but it is the only point to consider ? | 19:10 |
| ssj71 | while it is cross platform, plugins have specific considerations that make QT of limited use on other platforms | 19:11 |
| ssj71 | Qt is good for linux plugins, but on Windows you can't run two QT things in the same process (IIUC) so you could theoretically only load ONE qt plugin | 19:12 |
| ssj71 | unless the host uses QT | 19:12 |
| y-kaelig | depency could be another one. I think none of dev want ot maintain a software like this with this problem | 19:12 |
| y-kaelig | to* | 19:12 |
| ssj71 | well, qt, gtkmm etc are perfectly good for standalone apps, its just plugins that they pose problems for | 19:13 |
| y-kaelig | yes, I'm talking only for LV2 plugins | 19:14 |
| ssj71 | right. did you see this thread from the mailing list? http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2016-March/001593.html | 19:14 |
| y-kaelig | ssj71, no, thx look interesting | 19:16 |
| ssj71 | oh yes, thats the problem with gtk, 2&3 are incompatable | 19:16 |
| ssj71 | so you couldn't load a gtk2 plugin AND a gtk3 | 19:17 |
| rgareus | neither gtk2 nor gtk3 are relocatable. You can pretty much only use gtk if you rely on a Linux distro provided lib | 19:37 |
| rgareus | QT has similar issues (modules are dynamically loaded by libqt, and can't be packaged with the plugin to form a self contained bundle) | 19:38 |
| rgareus | but it gets worse. if there are multiple gtk2 plugins in a host, all those gtk versions must be binary compatible.. | 19:39 |
| rgareus | gtk (also gtk3) has some static initialization functions, on Linux we can work around this (-Wl-nounload) That's not possible on OSX and Windows | 19:40 |
| y-kaelig | Well, there are some interesting things in this thread, but I don't understand one thing. If we are able to use gtk or Qt toolkit for LV2 , what's the problem to dev from scratch one specially dedicated for this purpose. | 19:41 |
| rgareus | I don't know about the BSD linker, but I expect it's like Darwin (OSX) | 19:41 |
| rgareus | y-kaelig: the problem is time. | 19:41 |
| rgareus | and getting the community to agree on one | 19:42 |
| rgareus | there are 8 or 9 toolkits specifically for LV2 plugins. everyone rolls his/her own. | 19:42 |
| rgareus | which is also what the VST world does | 19:42 |
| y-kaelig | no I'm sorry but the time is not important. One day or other, the benefict of this new tookkit will be thx by devs in the futur. | 19:43 |
| rgareus | s/time/man-months/ | 19:44 |
| rgareus | someone needs to spend his/her time on writing one. | 19:44 |
| drobilla | y-kaelig: The farthest we've come in that respect is pugl, which is a minimal portable lib for getting a window and events. | 19:45 |
| drobilla | (lol @ time is not important) | 19:45 |
| y-kaelig | as LV2 was, and I have to say that look like a success for the most of devs , because I can see more and more LV2 plugins | 19:46 |
| drobilla | avtk, some other things, build toolkits on top of that | 19:46 |
| y-kaelig | drobilla, I don't know, pugl ? try to find some info. A link ? | 19:50 |
| rgareus | https://drobilla.net/software/pugl/ | 19:52 |
| y-kaelig | thx | 19:53 |
| rgareus | drobilla: re unloading. ^^ the only issue I see would be the underying tree implementation. rebalancing is no fun. but I don't share your reservation against unloading bundles | 19:55 |
| drobilla | The tree is the least of my concerns, that is extremely well-tested | 20:03 |
| drobilla | More likely stuff like resources which have Lilv* representations disappearing. UIs, say. But if the bundles are mostly of the same form, it might be alright. ish. | 20:03 |
| y-kaelig | interesting but I have a question. Suppose I want to build a external controler for this plugins, and use midi event to control it. Is this will be possible ? none of us want to us mouse or keyboard for a live. | 20:05 |
| y-kaelig | use* | 20:05 |
| drobilla | y-kaelig: Depends on exactly what you mean by that (some forms of MIDI control inherently depend on how the host works, for example), but LV2 plugins of course support MIDI | 20:06 |
| ssj71 | y-kaelig: if you are the one writing the plugin then yes you can give it a midi port and use it however you like. If its an existing plugin you need a host that will allow you to map midi to the controls you want | 20:07 |
| drobilla | Some sort of grand control unification would certainly be nice, but when/whether we get around to that is anyone's guess... | 20:08 |
| *** deva has quit IRC | 20:33 | |
| * drobilla submits paper | 20:43 | |
| drobilla | ++freedom; | 20:43 |
| ssj71 | for class or to a journal? | 20:50 |
| drobilla | conference. | 20:51 |
| drobilla | rgareus: Pushed a reworked implementation of the version stuff. Seems to work fine for my simple test case. | 20:52 |
| rgareus | w00t | 20:52 |
| rgareus | drobilla: thanks. | 20:53 |
| drobilla | Maybe not worth optimizing, but splitting the querying from the loading made factoring it out to use the existing data easy anyway (once it used just basic sord stuff). | 20:53 |
| *** ventosus has left #lv2 | 21:47 | |
| *** falktx|work has quit IRC | 21:49 | |
| *** ricardocrudo has quit IRC | 21:50 | |
| *** digidog has joined #lv2 | 21:52 | |
| *** oofus_lt has joined #lv2 | 22:21 | |
| *** oofus_lt has quit IRC | 22:25 | |
| *** oofus_lt has joined #lv2 | 22:25 | |
| rgareus | OK, mixer-strip inline-displays are now lua processors in Ardour. Bye bye LV2 | 22:33 |
| rgareus | and the nice part of it all, I don't need mono/stereo variants anymore. | 22:34 |
| rgareus | I'll check back once the community agreed on how to best implement them with LV2:UI and w/o instance access and there's a prototype. | 22:36 |
| falktx | rgareus: this community will never 100% agree on one subject.. | 22:39 |
| *** oofus_lt_ has joined #lv2 | 22:39 | |
| *** oofus_lt has quit IRC | 22:40 | |
| rgareus | well, I made two revisions of the spec, and working prototype host + plugins. now it's up to the maintainer to merge the pull request or not.. | 22:41 |
| falktx | you mean drobilla? I understand his position of not wanting in the official spec | 22:42 |
| rgareus | given the current feedback on the lv-dev list, I don't think I can move this further | 22:42 |
| falktx | rgareus: I think it's fine as it is, and staying a ardour namespace extension | 22:42 |
| drobilla | I thought I was pretty clear about that yesterday. | 22:43 |
| rgareus | it's currently a harrisonconsole.com URI but it should really be an ardour.org one | 22:43 |
| *** ricardocrudo has joined #lv2 | 22:44 | |
| ssj71 | rgareus: I never commented on your last message, but both points you made were good ones. Alberts point of giving something for outsider plugin devs to admire is worth something as well | 22:44 |
| rgareus | I'm 50/50 if to keep it for official releases. currently all those non-standard extensions require a #define | 22:44 |
| rgareus | if someone else takes this further, It'd be cool. | 22:44 |
| drobilla | Ignoring my objection to the fundamental way the thing works, the biggest power problem is it only supports a single "view" per plugin, which seems pretty short-sighted. | 22:44 |
| drobilla | Too many problems, most of which I mentioned yesterday. I'd merge an ARGB32 "UI" extension, but not this. | 22:46 |
| ssj71 | rgareus: out of defining a way to do it through UI vs trying to define a few interfaces to give the host the necessary info to make the plot, which would you prefer? | 22:46 |
| rgareus | drobilla: mmh multiple views might have some merit | 22:47 |
| falktx | click to change views! | 22:47 |
| ssj71 | or an atom message to say next view or something | 22:48 |
| rgareus | render_argb32 (uint32 view_id, ...); | 22:48 |
| rgareus | where view_id is a mapped atom (views are defined in the ttl) | 22:48 |
| drobilla | ... and I'd be happy to help work on / refine that, and do whatever implementation work for selecting and whatnot is required. | 22:49 |
| drobilla | Generally not a fan of sinking my time into things I think are the wrong solution, though. | 22:49 |
| rgareus | ssj71: the issue there is that it puts a lot of work on the host side and is eventually not very flexible. | 22:50 |
| drobilla | "work" that's already implemented... | 22:50 |
| rgareus | ssj71: I do like the inline scope for example. | 22:50 |
| drobilla | (and it's more flexible if anything) | 22:51 |
| rgareus | ssj71: so giving a plain canvas to the plugin seems straight forward. | 22:51 |
| ssj71 | rgareus: its less straightforward but an audio waveform could be a legitimate inline_display_data function though | 22:52 |
| ssj71 | idd_waveform(float*, uint32_t npoints, double rate) | 22:53 |
| rgareus | one thing to fear with a ARGB canvas - as PipeManMusic put it: If these where comercial LV2s the first thing they'd do is figure a way to cram their logo in there. | 22:53 |
| drobilla | With my host author hat on, the main reason I hate this is all the work it burdens me with that I shouldn't have to do at all. | 22:53 |
| ssj71 | rgareus: but that is exactly the motivation that will increase adoption, especially with multiple views | 22:54 |
| rgareus | :) | 22:54 |
| ssj71 | rgareus: and that could be stemmed with an easy "hide inline" context menu item | 22:55 |
| rgareus | ssj71: I do like the idea of dedicated messages and let the host plot it. but I don't think it'll fly. | 22:55 |
| drobilla | Which is an option (and only an option) you already have that's already implemented if it's a bloody UI :P | 22:55 |
| rgareus | we'd have to get at least rncbc (qtractor), faltx (Carla) and drobilla (jalv) on board to implement all specified drawing functions... | 22:56 |
| rgareus | just showing a ARGB image in the host is trivial | 22:56 |
| ssj71 | yes | 22:57 |
| rgareus | ssj71: Ardour has a global preference (show inlines by default) and a per plugin override in the context menu. | 22:57 |
| rgareus | the latter place could also allow to change views | 22:57 |
| ssj71 | so maybe ui:inline; ui:argb32 is the way to go | 22:57 |
| ssj71 | rgareus: or just click on inline to change view | 22:58 |
| rgareus | the number of possible views could be defined in the .ttl (along with a title) | 22:58 |
| rgareus | ssj71: right. or double-click... but that'll be a detail. | 22:58 |
| ssj71 | ya | 22:59 |
| rgareus | having written 3 inline displays.. if there was no insance access it would significantly compliate things. passing EQ curves through Atom messages is no fun. | 23:00 |
| rgareus | Peak displays likewise need special attention (needs a handshake to not miss peaks) | 23:00 |
| rgareus | and scope. well it's not hard to pass raw audio data to the GUI, but it'll arrive with significant latency | 23:01 |
| rgareus | (ringbuffer to host, ringbuffer to UI) usually 3 frames. that's noticable. (which is why meters.lv2 goniometer uses instance access) | 23:01 |
| rgareus | 3 video-frames ~ 75-100ms. | 23:02 |
| rgareus | if this extension is going to be w/o instance access, I highly recommend to prototype it first and check usability. | 23:03 |
| drobilla | This UI slippery slope thing is getting pretty irritating, to be honest. | 23:04 |
| drobilla | If it doesn't make sense to do it that way, then don't do it that way. It certainly makes sense for others. | 23:05 |
| drobilla | "extension is going to be w/o instance access" doesn't really make any sense. instance-access is a thing a UI has available (if it's available). It can use it, or not. | 23:05 |
| rgareus | if you make it a fully fledged new ui spec, then yes | 23:06 |
| drobilla | meaning? | 23:06 |
| rgareus | https://github.com/drobilla/lv2/pull/8 is currently not a UI | 23:07 |
| rgareus | and instance access is baked into that extenstion | 23:07 |
| drobilla | Well, yes. I figured you were talking about hypothetically doing it as a UI. I doubt anyone is going to prototype a non-UI version that mandates comm in some new way | 23:07 |
| drobilla | That's doubling up on the insanity | 23:07 |
| rgareus | :) | 23:08 |
| rgareus | what I really like about the current extension: it'd dead simple on both host and plugin side. | 23:09 |
| drobilla | It's dramatically more complicated, to me. | 23:10 |
| rgareus | how so? | 23:10 |
| drobilla | Bunch of weird plugin side stuff and image transport and threading issues and sync and blah blah I have to implement. | 23:10 |
| rgareus | gtk/gtkmm? | 23:10 |
| drobilla | Particularly egregious for Ingen, but even in Jalv the bloat would be offensive | 23:10 |
| drobilla | I see it as literally a bunch of new weird shit to implement that does things that are already there and I have already implemented. | 23:11 |
| drobilla | To achieve a goal I don't need to re-implement them to achieve. | 23:11 |
| drobilla | Aside from the ARGB bit, obviously. | 23:12 |
| rgareus | on_expose_event() { Cairo::RefPtr<Cairo::Context> ctx = get_window()->create_cairo_context(); /* 3,4 more LOC */ } done | 23:12 |
| rgareus | the size allocation is the most trick part. that's one thing i'd probably change | 23:12 |
| drobilla | 3,4 more LOC that might require executing code in a plugin binary running in China, sure | 23:13 |
| drobilla | or, at least, less hyperbolically, on an object owned by a thread at least a ringbuffer away (and back) | 23:13 |
| rgareus | true | 23:13 |
| rgareus | well, no RB, just a pointer to the extension | 23:14 |
| drobilla | Sure, it's not rocket science in most realistic cases. | 23:14 |
| drobilla | But still, bunch of new work I have to do that I could not have to do. Which isn't a great sell. | 23:15 |
| rgareus | drobilla: and making it an additional UI would be less work? | 23:16 |
| drobilla | rgareus: Yes. I've already done all the work required to have plugins talk to UIs that do whatever | 23:16 |
| drobilla | rgareus: An ARGB UI would just mean implementing the ARGB part, which I'd have to do regardless | 23:17 |
| rgareus | drobilla: can one select which UI to display in jalv and ingen? | 23:17 |
| rgareus | or have two (in ingen) | 23:18 |
| drobilla | All that other stuff I don't have to do, and inline UIs would have the ability to be lighter weight, network transparent, and so on, where appropriate | 23:18 |
| ssj71 | rgareus: any reason to prevent an inline x11 or gtk ui? | 23:18 |
| drobilla | rgareus: Not at the moment, no. | 23:18 |
| drobilla | (but they can't choose to show a view either, obviously) | 23:18 |
| rgareus | ssj71: x11 is horrible for this (passing all kinds of events forth and back, and translating them. besides there's no clear standard on size-limits and aspect) | 23:19 |
| *** falktx has quit IRC | 23:19 | |
| drobilla | The amount of "selectey stuff" work seems pretty much the same in either case | 23:19 |
| rgareus | ssj71: gtk would be easy in Ardour, but no so much in other hosts | 23:19 |
| rgareus | X11 color maps are no fun. | 23:19 |
| drobilla | or you could just not, and explicitly get an inline UI and display it somewhere special and ignore it otherwise | 23:19 |
| ssj71 | rgareus: but qt would be easy in qtractor and carla (I assume) my only point is that were inline just a property it opens up some additional options for plugin devs | 23:20 |
| drobilla | which if it was an ARGB32 one you'd get away with currently anyway, since it wouldn't conflict with the main (wrappable) one and just be ignored | 23:20 |
| ssj71 | hosts would know what they do and don't support. perhaps that only will create discontent among users though IDK | 23:21 |
| *** falktx has joined #lv2 | 23:21 | |
| drobilla | I see "inline" as basically just metadata, orthogonal to type at least in theory. | 23:22 |
| *** rncbc has quit IRC | 23:22 | |
| drobilla | Seems like literally just one subclass (ui:InlineUI or ui:SmallViewUI or whatever) would do it | 23:22 |
| rgareus | ssj71: if it's going to be display only (no events), then pretty much all window-system (cocoa, x11, HWND, wayland) stuff is overkill. | 23:22 |
| rgareus | and once cairo/ARGB32 is in the C++ spec. drawing is going to be easy-peasy. | 23:23 |
| ssj71 | rgareus: I suppose the more important thing to me is that there may be people who want to make an ARGB32 ui thats NOT inline | 23:26 |
| ssj71 | so making inline and ui type orthogonal has advantage | 23:27 |
| *** falktx has quit IRC | 23:35 | |
| *** falktx has joined #lv2 | 23:36 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!