| *** ricardocrudo has quit IRC | 00:00 | |
| *** NickSB2 has quit IRC | 00:55 | |
| rgareus | drobilla: thanks | 01:53 |
|---|---|---|
| rgareus | drobilla: one last thing: could you add to #maxBlockLength | 01:55 |
| rgareus | "This value will be valid for the lifetime of the plugin after instantiation and must not be changed dynamically. | 01:55 |
| rgareus | or something along those lines | 01:56 |
| rgareus | I understand that it's not ideal to add it literally to the doc only (without ttl vocab), but it can't hurt to have this as a first step and clarification. | 02:14 |
| drobilla | Well, there's no going back from the property itself saying it can never be changed, so it could hurt... | 02:55 |
| rgareus | gotta make a decision. keeping this status-quo hurts more: "it's the maxium and if it's an instantation option it can't be changed .. unless maybe someday we decide de-activate and option-interface may allow it..." is IMHO worse. | 03:01 |
| rgareus | as it is now. it's ambiguous. http://lv2plug.in/ns/ext/buf-size/#maxBlockLength is already strongly phrased. BUT http://lv2plug.in/ns/ext/options/#interface has a backdoor for it. | 03:04 |
| rgareus | we need to close this backdoor :) | 03:04 |
| *** curlymorphic has joined #lv2 | 05:21 | |
| *** curlymorphic has quit IRC | 06:24 | |
| *** drobilla` has joined #lv2 | 06:27 | |
| *** drobilla has quit IRC | 06:27 | |
| *** falktx has joined #lv2 | 07:20 | |
| *** ricardocrudo has joined #lv2 | 07:58 | |
| *** NickSB2 has joined #lv2 | 08:48 | |
| *** sigma6 has joined #lv2 | 08:48 | |
| *** falktx has quit IRC | 08:52 | |
| *** NickSB2 has quit IRC | 09:12 | |
| *** falktx has joined #lv2 | 09:30 | |
| *** nicksby has joined #lv2 | 09:35 | |
| *** son0p has quit IRC | 10:31 | |
| *** son0p has joined #lv2 | 10:31 | |
| *** nicksby has quit IRC | 10:49 | |
| *** nicksb2 has joined #lv2 | 10:58 | |
| *** nicksb2 has quit IRC | 11:39 | |
| *** nicksb2 has joined #lv2 | 12:06 | |
| *** nicksb2 has quit IRC | 13:12 | |
| *** nicksb2 has joined #lv2 | 13:14 | |
| *** son0p has quit IRC | 13:27 | |
| *** son0p has joined #lv2 | 13:29 | |
| *** drobilla` is now known as drobilla | 13:30 | |
| *** frinknet has joined #lv2 | 14:35 | |
| drobilla | falktx: Do you still have the test bundle for the sord issue? pastebin expired... | 14:39 |
| falktx | let me check | 14:39 |
| falktx | drobilla: I don't think so. let me do another one | 14:41 |
| falktx | drobilla: found a plugin that loading its bundle causes the issue | 14:47 |
| falktx | https://github.com/moddevices/mod-pitchshifter | 14:48 |
| falktx | Harmonizer2 | 14:48 |
| falktx | you can clone the repo and do a load_bundle on ./Harmonizer2/ttl/ | 14:49 |
| drobilla | falktx: OK, thanks | 14:49 |
| falktx | when the lilv instance is destroyed the bug happens (sorta, since it's a invalid write better use valgrind to catch it) | 14:50 |
| falktx | I'm not sure if it requires some extra lilv methods, like checking the class, port count or whatever | 14:51 |
| falktx | drobilla: if you're unable to reproduce it let me know | 14:51 |
| drobilla | Probably reference counting bindings hell | 14:55 |
| drobilla | Longest build process evar | 15:21 |
| falktx | heh, you're trying to build the plugins? | 15:21 |
| falktx | the fftw operation is quite long | 15:21 |
| falktx | drobilla: btw I think you perhaps haven't seen this yet, https://github.com/moddevices/modgui-embed | 15:30 |
| drobilla | Good grief, python3 in valgrind is crazy noisy | 15:39 |
| drobilla | falktx: nice | 15:40 |
| rgareus | falktx: +1 for modgui-embed | 15:41 |
| falktx | :) | 15:41 |
| rgareus | now we really need a solution to hide (or line-break) ardour's state title bar. | 15:42 |
| drobilla | Not to mention shrink in general. Thing wastes a ton of space for no particularly good reason. | 15:43 |
| rgareus | falktx: the black space left/right is not due to ardour, is it? Is that where the ports are in the /real/ MOD gui? | 15:46 |
| falktx | rgareus: yeah, it's something introduced by the modguis | 15:46 |
| falktx | rgareus: this is why I wanted a property for this | 15:46 |
| falktx | ie, the host tells the plugin what background color it should use | 15:47 |
| falktx | I have a proper screenshot somewhere... | 15:47 |
| falktx | rgareus: https://i.imgur.com/x5cBNxE.png | 15:49 |
| rgareus | aah that's better :) | 15:49 |
| rgareus | falktx: can't you get rid of the space where the ports are? | 15:50 |
| falktx | already did | 15:50 |
| falktx | code has changed a lot | 15:50 |
| rgareus | AmpVTS has different margins bottom vs left | 15:50 |
| falktx | but haven't tested if that still works or not | 15:50 |
| falktx | drobilla: you might like this one https://i.imgur.com/ecXAscX.png | 15:51 |
| rgareus | falktx: the other plugins. well ardour's title-bar screws things up. | 15:51 |
| falktx | let me see how it looks now | 15:51 |
| rgareus | ingeeeeeeeen! yay | 15:51 |
| rgareus | that's one thing I love the MOD for, taking a cool floss project and making it even cooler. Kudos! | 15:52 |
| rgareus | one might even say, take it to the next level, except there was no previous level :) | 15:53 |
| falktx | I think there's still some borders | 15:54 |
| rgareus | falktx: n/m those borders are a detail.. for later | 15:54 |
| drobilla | Not sure UI embedding is going to remain a thing in Ingen's GUI in the long term, but neat :) | 15:55 |
| falktx | rgareus: latest screen from right now, https://i.imgur.com/521N7W5.png | 15:56 |
| drobilla | At least in the modules themselves. I don't know. Toolkits, sigh... | 15:56 |
| falktx | rgareus: you can see some minor issues in swh-delayorama. ignore that.. | 15:56 |
| falktx | rgareus: btw, isn't it possible to center the X11 window there? | 15:57 |
| falktx | putting in the left side looks wrong | 15:58 |
| rgareus | falktx: probably yes. | 16:06 |
| rgareus | falktx: but I think we need a better approach for cases where plugin-width < preset-toolbar-width | 16:07 |
| *** ricardocrudo has quit IRC | 16:09 | |
| rgareus | maybe an expandable/dropdown toolbar (hidden by default) or some hot corner | 16:09 |
| rgareus | presets are really a one-off operation no need to waste screen-state for them all the time | 16:10 |
| falktx | there's bypass too | 16:11 |
| rgareus | mmh, indeed. | 16:11 |
| falktx | and pass keyboard | 16:11 |
| falktx | bypass is important, but the keyboard on/off can be an option in a menu | 16:11 |
| rgareus | mmh lv2_plugin_ui.cc already wraps the child in a Gtk::manage((container = new Gtk::Alignment())) | 16:16 |
| rgareus | default ctor: Alignment (float xalign=0.5, float yalign=0.5, float xscale=1.0, float yscale=1.0) | 16:17 |
| rgareus | it should be centered | 16:17 |
| drobilla | Keyboard thing is bigger than it needs to be | 16:17 |
| drobilla | A hot zone at the top would be nice, but I could see that being annoying... | 16:18 |
| *** nicksb2 has quit IRC | 16:18 | |
| drobilla | But it would be less of a problem if the thing was much smaller and more tidy looking as a header bar | 16:19 |
| rgareus | falktx: looks like this is in libsuil. ardour sets _parent_feature.data = _gui_widget->gobj(); (where _gui_widget is the Alignment) | 16:19 |
| rgareus | and suil does the X11 -> GTK wrapping | 16:20 |
| rgareus | falktx: so it needs to be centered there | 16:20 |
| drobilla | No point in using an alignment then. It can't align that way. I think Ardour needs to stick a container in the alignment (which is is then capable of centering), then pass /that/ as the plugin parent | 16:22 |
| *** rncbc has joined #lv2 | 16:31 | |
| falktx | so just add an extra widget in there | 16:36 |
| rgareus | drobilla: the Alignment is a container and is *parent*. and child packed in it will be centered | 16:36 |
| rgareus | works for gtk in gtk | 16:37 |
| *** tytel has joined #lv2 | 16:37 | |
| *** edogawa_ has joined #lv2 | 16:41 | |
| drobilla | rgareus: Yes, but in that situation you're passing the alignment X11 window as parent | 16:47 |
| drobilla | rgareus: I don't think "packing" in the Gtk sense even happens there, hence the non centeredness | 16:48 |
| drobilla | (I might be wrong, need to check, but if that's the case, then it won't center) | 16:48 |
| rgareus | drobilla: I'll check other cases. but it seems tha suil_x11_in_gtk2 should add it. no need to add a middle-layer for all other GUIs | 16:49 |
| drobilla | rgareus: That means suil has to make assumptions about the parent | 16:50 |
| rgareus | x11_in_gtk. it can expect the parent to be a gtk widget | 16:50 |
| rgareus | x11_in_gtk. it can expect the parent to be a gtk container | 16:50 |
| * drobilla shrugs | 16:52 | |
| drobilla | Yes, but I don't see why suil should add a container to the container because the host might not have passed a container that actually behaves the way it wants the plugin UI container to behave | 16:53 |
| drobilla | This whole "let's work around everything Ardour does in the LV2 stack" theme better taper off soon :P | 16:53 |
| * falktx has the pitchfork ready | 16:54 | |
| drobilla | But needs looking into. The situation is weird. | 16:54 |
| drobilla | The definition of "parent" for Gtk (being a Container) is designed for just Gtk | 16:54 |
| rgareus | drobilla: X_in_gtk parent is a gtk-container and a gtk widget need to go inside it. | 16:55 |
| *** tytel has quit IRC | 16:55 | |
| drobilla | Yes. Namely a Plug | 16:56 |
| rgareus | drobilla: maybe all that's wrong is the Plug's size_request(), size_allocate() implementation ? | 16:56 |
| drobilla | rgareus: Wouldn't be surprised, it's a relatively dumb forward-to-X11 thing right now | 16:57 |
| rgareus | drobilla: I just checked, x11_in_gtk2. does not connect "size-request" only "size-allocate" | 17:00 |
| rgareus | that explains it. | 17:01 |
| drobilla | That'd do it | 17:01 |
| drobilla | Some time in 2058 we'll get this perfect :) | 17:01 |
| *** sigma6 has quit IRC | 17:03 | |
| *** falktx has quit IRC | 17:08 | |
| *** NickSB2 has joined #lv2 | 17:13 | |
| *** aombk2 has quit IRC | 17:33 | |
| rgareus | 2058 is nearer than one may think. | 20:14 |
| rgareus | drobilla: I've implemented a gtk size request for suil x11->gtk.. only to find out that it's the wrong approach. the widget itself will still be allowed to grow. and we can't easily XMove it to the center (that approach works for Cocoa but not X11) | 20:37 |
| rgareus | so I'm fixing this in ardour after all | 20:38 |
| rgareus | suil does call gtk_set_size_request() on the Plug itself. so all is good on that end | 20:40 |
| rgareus | crap. if ardour does not allow to the widget to expand. fixed-size X11 UIs are centered. but resizable x11 and resizable GTK guis don't resize anyore :( | 20:43 |
| *** ricardocrudo has joined #lv2 | 20:51 | |
| *** six6110 has quit IRC | 21:15 | |
| *** six6110 has joined #lv2 | 21:26 | |
| *** rncbc has quit IRC | 21:48 | |
| *** edogawa_ has quit IRC | 22:27 | |
| drobilla | rgareus: There are probably a bunch of questions there about how okay it is for wigets to grow, how much, when... | 22:54 |
| drobilla | Re: changing buffer size stuff, seems LV2_Options_Status needs a LV2_OPTIONS_ERR_NOT_DYNAMIC or some such? | 22:55 |
| *** ricardocrudo has quit IRC | 23:14 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
