| *** gianMOD has joined #lv2 | 00:18 | |
| *** bgribble has joined #lv2 | 00:38 | |
| *** falktx has quit IRC | 00:55 | |
| *** gianMOD has quit IRC | 01:13 | |
| *** gianMOD has joined #lv2 | 01:14 | |
| *** falktx has joined #lv2 | 01:18 | |
| falktx | I need some help here | 01:21 |
|---|---|---|
| falktx | a plugin has this: | 01:21 |
| falktx | lv2:extensionData <http://lv2plug.in/ns/ext/state#Interface> | 01:21 |
| falktx | note the capital I in Interface | 01:21 |
| falktx | which seems wrong according to state.h | 01:22 |
| falktx | #define LV2_STATE__interface LV2_STATE_PREFIX "interface" | 01:22 |
| falktx | note the lowercase i | 01:22 |
| falktx | the plugin code even has the bad Interface | 01:22 |
| falktx | https://github.com/nicklan/drmr/blob/lv2unstable/drmr.c#L544 | 01:22 |
| falktx | was this plugin ever actually working?? | 01:23 |
| *** bgribble has quit IRC | 01:25 | |
| falktx | https://github.com/nicklan/drmr/pull/12 | 01:36 |
| falktx | fails to save&load in jalv because the plugin can't handle symlinks | 01:40 |
| falktx | I guess it would be the same in ardour | 01:40 |
| falktx | will need https://github.com/nicklan/drmr/issues/13 as well | 01:46 |
| falktx | nvm, it was another issue. fixed now too on pull request | 02:16 |
| *** falktx has quit IRC | 03:46 | |
| drobilla | Today on "why those defines are there" | 04:38 |
| drobilla | (and why sord_validate exists. I need to make an idiot proof LV2 wrapper for that thing) | 04:39 |
| *** gianMOD has quit IRC | 05:27 | |
| *** gianMOD has joined #lv2 | 06:28 | |
| *** gianMOD has quit IRC | 06:44 | |
| *** bgola has quit IRC | 06:47 | |
| *** triune has quit IRC | 06:47 | |
| *** Anchakor_ has quit IRC | 06:47 | |
| *** triune has joined #lv2 | 07:00 | |
| *** Anchakor_ has joined #lv2 | 07:00 | |
| *** bgola has joined #lv2 | 07:09 | |
| *** bgola has quit IRC | 07:28 | |
| *** triune has quit IRC | 07:29 | |
| *** Anchakor_ has quit IRC | 07:29 | |
| *** bgola has joined #lv2 | 07:32 | |
| *** bazz has quit IRC | 07:37 | |
| *** triune has joined #lv2 | 07:37 | |
| *** Anchakor_ has joined #lv2 | 07:37 | |
| *** bazz has joined #lv2 | 07:37 | |
| *** grejppi_ has joined #lv2 | 08:18 | |
| *** grejppi_ has quit IRC | 08:22 | |
| *** edogawa has joined #lv2 | 08:24 | |
| *** gianMOD has joined #lv2 | 08:27 | |
| *** gianMOD has quit IRC | 08:32 | |
| *** wumpus has quit IRC | 09:14 | |
| *** wumpus has joined #lv2 | 09:16 | |
| *** gianMOD has joined #lv2 | 09:47 | |
| *** NickSB2 has quit IRC | 09:53 | |
| *** NickSB2 has joined #lv2 | 09:53 | |
| *** wumpus has quit IRC | 09:55 | |
| *** wumpus has joined #lv2 | 09:56 | |
| *** gianMOD has quit IRC | 11:04 | |
| *** falktx has joined #lv2 | 11:05 | |
| *** gianMOD has joined #lv2 | 11:08 | |
| *** gianMOD has quit IRC | 11:10 | |
| *** gianMOD_ has joined #lv2 | 11:13 | |
| *** gianMOD_ has quit IRC | 11:18 | |
| *** rncbc has joined #lv2 | 11:51 | |
| *** ricardocrudo has joined #lv2 | 12:08 | |
| *** ricardocrudo has quit IRC | 12:10 | |
| *** ricardocrudo has joined #lv2 | 12:10 | |
| *** rncbc has quit IRC | 12:16 | |
| *** rncbc has joined #lv2 | 12:16 | |
| *** rncbc_jolla has joined #lv2 | 13:05 | |
| *** rncbc has quit IRC | 13:09 | |
| *** bgribble has joined #lv2 | 13:34 | |
| *** gabrbedd has quit IRC | 13:56 | |
| *** falktx has quit IRC | 14:06 | |
| *** falktx has joined #lv2 | 14:28 | |
| *** gabrbedd has joined #lv2 | 14:31 | |
| *** falktx has quit IRC | 15:06 | |
| *** falktx has joined #lv2 | 15:48 | |
| *** bgribble has quit IRC | 15:52 | |
| *** zth has joined #lv2 | 16:41 | |
| *** NickSB has quit IRC | 17:30 | |
| *** NickSB has joined #lv2 | 17:35 | |
| *** zth_studiocomp has joined #lv2 | 18:11 | |
| *** mlpug has joined #lv2 | 18:51 | |
| *** zth_studiocomp has quit IRC | 19:10 | |
| *** rncbc has joined #lv2 | 19:26 | |
| *** mlpug has quit IRC | 20:06 | |
| *** gian_ has joined #lv2 | 20:21 | |
| *** gianMOD has joined #lv2 | 20:23 | |
| *** gian_ has left #lv2 | 20:23 | |
| *** gianMOD has quit IRC | 20:23 | |
| *** gianMOD has joined #lv2 | 20:24 | |
| *** gianMOD_ has joined #lv2 | 20:37 | |
| *** gianMOD_ has quit IRC | 20:47 | |
| *** zth has quit IRC | 21:27 | |
| *** rncbc has quit IRC | 21:34 | |
| *** gianMOD has quit IRC | 21:37 | |
| *** gianMOD has joined #lv2 | 21:41 | |
| falktx | drobilla: one question | 21:41 |
| falktx | I just found out NTK blocks while waiting for any dialog or menu operation | 21:41 |
| falktx | (blocks the main thread waiting for the user to click something) | 21:41 |
| falktx | BUT while this happens NTK still sends the registered idle functions | 21:42 |
| falktx | drobilla: what do you think of a host callback the UI can call when it needs to block like this? | 21:43 |
| falktx | drobilla: or should we impose UIs to never block? | 21:43 |
| *** gianMOD has quit IRC | 21:51 | |
| *** gianMOD has joined #lv2 | 21:55 | |
| *** gianMOD has quit IRC | 21:56 | |
| *** gianMOD has joined #lv2 | 22:00 | |
| *** ricardocrudo has quit IRC | 22:06 | |
| *** gianMOD has quit IRC | 22:07 | |
| drobilla | falktx: A host callback for what? | 22:14 |
| drobilla | falktx: The idle callback must not block for an extended period of time, anyway. It's effectively the main toolkit loop, which you can never block in any case (though you can pretend to, as Gtk/NTK/etc do in some cases) | 22:15 |
| falktx | ok, then NTK devs can't use dialogs or main menus for now | 22:18 |
| * drobilla gets bug reports about people packaging svn lilv and not its dependencies (svn sord) | 22:18 | |
| drobilla | Sigh. I wish there was some technological way to just make doing that impossible. If it was ready/suitable for packaging IT'D BE A RELEASE. That's what a "release" is. | 22:19 |
| drobilla | falktx: Hm. Seems the same would apply to Gtk dialogs (at least if you use run() and friends). Never come up | 22:20 |
| drobilla | Though at least Ingen and presumably some other plugins use them | 22:20 |
| drobilla | Which is probably magically fine if the host uses the same toolkit, but not otherwise. | 22:20 |
| drobilla | Not obvious if there's a good solution or what it is | 22:20 |
| falktx | drobilla: my "solution" was to have a host-side function the UI calls at regular intervals during the blocking time | 22:21 |
| falktx | the host-side function gives the host a chance to handle events, while still having a plugin UI waiting | 22:21 |
| falktx | in a qt4 host running NTK or Gtk2 UIs, the host-side function would call qApp->processEvents() | 22:23 |
| drobilla | bit of a PITA | 22:23 |
| falktx | VST is already doing this I think, this is a big issue in win32 afaik | 22:23 |
| drobilla | If the UI code blocks on the dialog call, how does it periodically call a host function? | 22:24 |
| falktx | it registers an idle funtion | 22:24 |
| falktx | gtk2, qt4 and ntk has API for that | 22:24 |
| falktx | it needs to be done carefully of course | 22:25 |
| falktx | the setup would be something like this: | 22:25 |
| falktx | 1. UI realizes it's going to open a file-dialog, so it registers an idle function in gtk2 | 22:25 |
| falktx | 2. UI opens file-dialog. the idle function keeps calling host-side idle while waiting | 22:26 |
| falktx | 3. file-dialog returns, UI unregisters the previous idle function | 22:26 |
| falktx | drobilla: does it make sense to you? | 22:26 |
| drobilla | Is this really easier than doing non-blocking dialog stuff in the UI? | 22:26 |
| falktx | do gtk dialogs not block? | 22:27 |
| drobilla | Yeah, it's basically the same recursive idle loop thing most toolkits do | 22:27 |
| drobilla | You can do either | 22:28 |
| falktx | afaik win32 file dialogs block | 22:28 |
| drobilla | run() is basically just a wrapper that does what you just explained. | 22:28 |
| drobilla | Well, I certainly dislike it, but it's reasonable and seems like just an LV2 applying of a relatively widespread concept | 22:30 |
| drobilla | Send a patch against LV2 and I'll include it | 22:30 |
| falktx | ok | 22:31 |
| falktx | I want to have a test case first, so it won't be now | 22:31 |
| wrl | falktx: the vst idle callback is deprecated | 22:33 |
| wrl | most vst plugs register timers | 22:34 |
| wrl | at this point | 22:34 |
| falktx | wrl: how do timers solve UI blocking issues? | 22:35 |
| wrl | falktx: the win modal loop continues to call them | 22:36 |
| wrl | likewise on OSX (though not by default, you have to specify a different runloop mode for the NSTimer) | 22:37 |
| falktx | you can't do that on linux afaik | 22:37 |
| wrl | well, there's no OS-level timer | 22:37 |
| wrl | so e.g. juce has to spin up a thread for things like that | 22:38 |
| falktx | yep | 22:38 |
| falktx | this seems like something the host would have to do too | 22:38 |
| falktx | what can a host do when a plugin blocks the main thread? | 22:38 |
| wrl | nothing, really? | 22:40 |
| falktx | that's why I'm proposing the host-side callback | 22:41 |
| drobilla | wrl: Do you know why it was deprecated? | 22:41 |
| drobilla | falktx: It would be easy enough to do with basically any toolkit that can do the idle thing | 22:42 |
| falktx | the docs can include examples for that | 22:43 |
| drobilla | Though I don't really get it. The UI would have to deal with dialogs in a non-blocking way anyway, in which case registering a new idle handler doesn't help much | 22:43 |
| *** NickSB2 has quit IRC | 22:43 | |
| wrl | drobilla: nope. presumably because it's so easy to just register timers on win/osx | 22:43 |
| drobilla | wrl: Yes, but I don't see how that really helps with handling dialogs | 22:43 |
| *** NickSB2 has joined #lv2 | 22:44 | |
| wrl | which tbh is only necessary because the native windowing system/constructs don't work well with threads | 22:44 |
| drobilla | In Gtk, for example, you'd just show the dialog and set a handler for the closed (or whatever it is) signal which does the thing that needs doing when the dialog is finished. Adding a second idle/timer callback doesn't help | 22:45 |
| falktx | drobilla: this is an issue right now in NTK | 22:46 |
| falktx | since it's not a native LV2 UI type, it has to use X11UI and ui-idle for handling events | 22:47 |
| falktx | some NTK operations block, which happens on ui-idle | 22:47 |
| falktx | this will block the host main thread | 22:47 |
| wrl | what's the problem with just spinning up a thread? | 22:47 |
| wrl | and running the UI in that | 22:47 |
| falktx | you have to create and destory the UI on that thread as well no? | 22:48 |
| wrl | generally, yeah | 22:48 |
| drobilla | wrl: Short answer: multi-thread + toolkit = hell in the best case | 22:48 |
| falktx | this sounds a bit complex | 22:48 |
| drobilla | That's one of those "theoretically possible, sometimes, but you really, really do not want to do that" things | 22:49 |
| wrl | yeah that's fair | 22:49 |
| wrl | i can imagine with a general-purpose toolkit that would be tricky | 22:49 |
| wrl | does gtk use global state? | 22:49 |
| wrl | ntk? | 22:49 |
| falktx | I don't think is going to be an issue with gtk or qt | 22:50 |
| drobilla | Not really, but it doesn't have to for there to be a problem. Your widget is a child of another widget | 22:50 |
| drobilla | falktx: I think it will be an issue for anything not using the same idle thread (e.g. glib) | 22:51 |
| drobilla | The idle callback is just called in that anyway | 22:51 |
| drobilla | Presumably you get away with it with Gtk, and maybe Qt, since the recursive idle loop stuff will do the right thing | 22:51 |
| falktx | building an example in NTK is easy. but I want to try it with qt as well | 22:52 |
| falktx | jalv.gtk + qt plugin works for file dialogs | 22:53 |
| falktx | there is some magic in there... | 22:53 |
| drobilla | I wonder if plugins doing this will be a problem if they *do* use the same toolkit or idle loop | 22:53 |
| drobilla | recursive-recursive... | 22:53 |
| drobilla | dialog.run() is recursively calling idle(), meanwhile, so is the plugin code... | 22:54 |
| drobilla | which I guess is fine since it's all in the same thread, but the rate might be fucked | 22:54 |
| falktx | the UI only calls host idle if it knows is going to block | 22:54 |
| falktx | hah, closing jalv.gtk while a qt dialog is still open results in a crash | 22:55 |
| falktx | *** Error in `jalv.gtk': free(): invalid pointer: 0x00007fffd29515e0 *** | 22:55 |
| drobilla | Yes, but e.g. a Gtk dialog will do the exact same thing. Naturally it doesn't *really* block everything | 22:56 |
| drobilla | Meh, you were closing it anyway, just took a shortcut :P | 22:56 |
| falktx | but imagine ardour closing a single UI | 22:56 |
| drobilla | Yes, it would be a problem if it actually happens in that case | 22:58 |
| drobilla | Though the UI should be cleaning itself up when requested anyway | 22:58 |
| drobilla | So it should not be possible for a dialog to be present when the host exits, assuming the host destroyed the UI first | 22:58 |
| drobilla | Anyway, I need to do some work | 23:00 |
| wrl | i'm in favor of "in-process plugin UIs that have global state" becoming an anti-pattern | 23:01 |
| drobilla | Global state is not the issues. They're part of the same UI. They inherently share state. | 23:01 |
| drobilla | You can always do a separate thread or process thing with show() hide(), you just lose embedding, among other things | 23:04 |
| falktx | you can still do embedding with a separate thread | 23:05 |
| falktx | proof here: https://github.com/distrho/Zynaddsubfx | 23:05 |
| falktx | I use NTK on a separate thread for that, but I don't like it | 23:06 |
| drobilla | Well, yes, XEmbed is cross-process | 23:06 |
| falktx | yeah, I have XEmbed working with a different process for carla-vst :) | 23:07 |
| drobilla | I don't see the win, though | 23:07 |
| falktx | crazy stuff | 23:07 |
| *** edogawa has quit IRC | 23:20 | |
| *** gianMOD has joined #lv2 | 23:23 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!