drobilla | falktx: The feature structs do it | 00:04 |
---|---|---|
drobilla | That bool parameter seems like the best way, though I dislike the prototype not being exactly the C one less a handle | 00:05 |
drobilla | I think I might go with the Derived thing | 00:06 |
drobilla | It means the entire wrapper can be tidily wrapped in a class, much of it private | 00:07 |
drobilla | Surely inheriting from Plugin<MyPlug> or Lib<MyLib> isn't *that* weird | 00:07 |
drobilla | It's a mixin, but it's not a huge list of them with fancy delegation and template metaprogramming and all that. Relatively straightforward, and all you have to do or understand is to inherit like that | 00:08 |
falktx | yeah, I'm going with that route too, but the static parts need to be better handled | 00:09 |
drobilla | Hm, I think the C entry point can just be "return new ..." this way | 00:12 |
falktx | with a try/catch please | 00:13 |
drobilla | ? | 00:13 |
drobilla | I guess......... | 00:13 |
falktx | what happens if a C host tries to load a plugin that throws during instantiate? | 00:14 |
drobilla | I would ideally like to avoid exceptions entirely. Maybe more embedded folks even want to compile without | 00:14 |
drobilla | Bad things? :) | 00:14 |
drobilla | I'll look into it | 00:14 |
drobilla | const violations oh my | 00:21 |
*** gianMOD has quit IRC | 00:24 | |
drobilla | ooh, the names clash | 00:27 |
drobilla | hrm | 00:27 |
falktx | drobilla: btw, LV2_SYMBOL_EXPORT is missing from lv2_lib_descriptor | 00:37 |
drobilla | falktx: Yeah, just noticed that. | 00:39 |
drobilla | I can't help but think that with <Derived> in there, mixin methods can happen | 00:45 |
drobilla | I guess we'll see how interfaces work out without | 00:45 |
falktx | I'm not really sure how interfaces can work | 00:46 |
falktx | it needs to be static | 00:47 |
falktx | how can it be extended like that? | 00:47 |
falktx | we need some global pointer | 00:48 |
drobilla | Hm, that trick doesn't work for Plugin. You need a Descriptor *without* instantiating the class. | 00:49 |
drobilla | falktx: MyPlug() : MyExt<MyPlug>(this) | 00:50 |
drobilla | MyExt::whatever() { plug->whatever(); } | 00:50 |
drobilla | Hm, I guess it could cast self to Derived, too, if it's inherited. downcast though | 00:51 |
falktx | extension_data is a static function, created before the plugin is initialized | 00:51 |
drobilla | yep. | 00:51 |
drobilla | hm. | 00:52 |
drobilla | That part's weird. | 00:52 |
drobilla | Same problem I just hit, essentially. | 00:52 |
falktx | I'm not seeing how one can add new stuff to it externally | 00:52 |
drobilla | The descriptor is a descriptor of the class, but C++ classes are not first class. | 00:52 |
falktx | well, for me I have "static const LV2_Descriptor* createDescriptor(const char* uri)" | 00:52 |
falktx | that gets called somewhere in lv2_lib_descriptor for all plugins | 00:53 |
falktx | of course, a reverse "destroyDescriptor" is needed in this case | 00:54 |
Haskellfant | (setq helm-command-prefix-key "C-c h") | 00:54 |
Haskellfant | ups sry | 00:54 |
falktx | but anyway, lv2-extension-data, can't see how one will add stuff externally | 00:54 |
drobilla | I have all that working, but need to think how extension_data works | 00:54 |
drobilla | It's a static method, so... | 00:54 |
drobilla | This kind of ruins 99% of the point of <Derived> but lemme see | 00:55 |
drobilla | Maybe messing up user code so the header (who cares) is cleaner is wrong thinking | 00:55 |
drobilla | MyPlug::descriptor(uri); is nice though | 00:56 |
drobilla | falktx: For magic extension_data it seems either mixins, or a vector/whatever of extensions to loop through is necessary | 01:01 |
falktx | yeah | 01:02 |
drobilla | I think that might be the end of that valiant effort to not use extension mixins.... | 01:03 |
drobilla | This could maybe be pushed into some class specifically for handling this that the extensions register with | 01:04 |
drobilla | falktx: Pushed a version with a lib wrapper, and fully class isolated wrapping stuff | 01:08 |
falktx | if (!t) delete t; ?? | 01:13 |
falktx | you're deleting a null pointer | 01:13 |
falktx | also c++ "new" never fails, unless using -fno-exceptions afaik | 01:14 |
falktx | LV2_Lib_Descriptor::cleanup looks wrong too | 01:16 |
falktx | lv2_lib_descriptor returns "new AmpppLib", which is lv2::Lib | 01:17 |
falktx | hmm wait, reinterpret_cast<Derived*> is confusing me a bit | 01:18 |
falktx | is it Derived from plugin or lib? | 01:18 |
falktx | drobilla: having those functions marked virtual would be nice | 01:19 |
falktx | drobilla: it means devs can use 'override' and detect possible function argument mistakes | 01:20 |
falktx | without override mistakes will go by unnoticed | 01:20 |
falktx | (I think...) | 01:20 |
drobilla | falktx: Yeah, that's where the if (!t->valid()) thing should go. | 01:22 |
drobilla | falktx: Overhead free wrapper. Period. | 01:22 |
drobilla | There are a few contraints that sticking to will make this thing actually get done and not become a rabbit hole and source of potential fuck-up. That's one of them. | 01:23 |
drobilla | There is already too much function call overhead in the current state of things thanks to connect_port(), adding even more is the opposite of what I want to do. | 01:24 |
drobilla | If you override it incorrectly you'll get a compile time error because the static wrappers call them with specific arguments | 01:25 |
falktx | but some float/int conversion might still happen | 01:25 |
drobilla | Possibly. | 01:26 |
falktx | anyway, doesn't look bad yet :) | 01:27 |
drobilla | There are a few things you have to go without without a whole 100% RTTI virtual thing | 01:27 |
drobilla | C'est la vie, this is pretty much a canonical domain where "hey let's be Java!" isn't appropriate. It's nice enough. | 01:27 |
drobilla | It would be nice if C++ had pure non-virtual methods | 01:28 |
drobilla | I find it a bit amusing how blatantly amppp.cpp shows off the horrors of connect_port :) | 01:31 |
drobilla | run(), then 6 times as much boilerplate crap for setting buffers in a plugin that would be pure/stateless otherwise | 01:31 |
drobilla | Okay, so, extension_data(), hmm | 01:34 |
*** gianMOD has joined #lv2 | 01:35 | |
drobilla | Mixins really are The way to do this sort of thing | 01:36 |
*** gianMOD has quit IRC | 01:40 | |
drobilla | I'm starting to think maybe I don't care | 01:41 |
drobilla | User code is what matters | 01:41 |
drobilla | The nasty thing is that means two classes per extension mixin, the one you inherit from (to take the required parameter), then the interface nested inside that | 01:43 |
drobilla | unless ": public Mixins<Worker, false, URIMap, true>" is somehow possible | 01:46 |
drobilla | Only alternative to template hackery I can think of is class ExtHandler { ... } | 01:53 |
drobilla | then require any plugin with extra data to have one as a member, then extension classes take that as a param | 01:54 |
drobilla | MyPlug() : Worker(_exts, features), URIMap(_exts, features) {} | 01:54 |
drobilla | then void* extension_data(const char* uri) { return _exts.lookup(uri); } | 01:54 |
drobilla | Flat inheritance tree, at the cost of having to deal with that manually, if through an object that makes it almost free | 01:55 |
drobilla | (overhead doesn't matter in this case, it can just be std::map or whatever) | 01:55 |
* drobilla idly wonders if we can do all this without using bloody inheritance whatsoever | 02:22 | |
drobilla | Hm, actually, the object thing could be a bit cleaner, if you have to *inherit* from ExtensionManager, then Plugin::extension_data could static_cast to that and call it on itself, so user code wouldn't need to write an extension_data | 02:23 |
falktx | later | 02:33 |
*** falktx has quit IRC | 02:33 | |
*** zth_studiocomp has quit IRC | 02:42 | |
*** zth_studiocomp has joined #lv2 | 02:42 | |
*** zth_studiocomp has quit IRC | 03:03 | |
*** zth_studiocomp has joined #lv2 | 03:03 | |
*** NickSB2 has quit IRC | 03:40 | |
*** greenkobold has quit IRC | 04:32 | |
*** o0o0o has joined #lv2 | 04:51 | |
*** edogawa has joined #lv2 | 07:56 | |
*** sigma6 has joined #lv2 | 08:15 | |
*** ricardocrudo has joined #lv2 | 09:22 | |
*** gianMOD has joined #lv2 | 09:23 | |
*** NickSB2 has joined #lv2 | 09:36 | |
drobilla | bgola: I implemented RT-safe server side presets | 09:45 |
drobilla | bgola: It's a little strange, not sure it's 100% correct, but seems to work and shouldn't cause dropouts/zombies at least | 09:45 |
drobilla | bgola: The GUI loads them this way now as well | 09:45 |
drobilla | bgola: No query interface yet, but if you know the URI you can set them | 09:46 |
*** ddom has joined #lv2 | 09:51 | |
*** gianMOD has quit IRC | 10:00 | |
*** falktx has joined #lv2 | 10:32 | |
*** gianMOD has joined #lv2 | 11:01 | |
*** gianMOD has quit IRC | 11:05 | |
*** EntropySink has joined #lv2 | 11:15 | |
*** ricardocrudo has quit IRC | 12:00 | |
*** gianMOD has joined #lv2 | 12:02 | |
*** EntropySink has quit IRC | 12:05 | |
*** EntropySink has joined #lv2 | 12:05 | |
*** gianMOD has quit IRC | 12:06 | |
*** ricardocrudo has joined #lv2 | 12:13 | |
*** edogawa_ has joined #lv2 | 12:13 | |
*** edogawa has quit IRC | 12:16 | |
*** ricardocrudo has quit IRC | 12:30 | |
* falktx wonders if zyn-lv2 can work on osx | 12:41 | |
falktx | hmm starting fltk freezes carla | 12:45 |
*** gianMOD has joined #lv2 | 13:02 | |
*** gianMOD has quit IRC | 13:08 | |
*** ricardocrudo has joined #lv2 | 13:15 | |
*** gianMOD has joined #lv2 | 13:30 | |
*** ricardocrudo_ has joined #lv2 | 13:42 | |
*** ricardocrudo has quit IRC | 13:44 | |
*** HarryHaaren has joined #lv2 | 14:15 | |
*** NickSB2 has quit IRC | 14:29 | |
* HarryHaaren notes interesting email on LV2-dev, been thinking about it, makes sense. Will reply there when I have a coherent response | 14:56 | |
*** HarryHaaren has quit IRC | 14:58 | |
*** gianMOD has quit IRC | 15:29 | |
*** gabrbedd has quit IRC | 15:34 | |
*** gabrbedd has joined #lv2 | 15:36 | |
*** gabrbedd has quit IRC | 15:44 | |
*** gabrbedd has joined #lv2 | 15:44 | |
*** gianMOD has joined #lv2 | 15:51 | |
*** EntropySink has quit IRC | 16:30 | |
*** EntropySink has joined #lv2 | 16:30 | |
*** edogawa_ has quit IRC | 16:32 | |
*** gianMOD has quit IRC | 16:39 | |
*** gianMOD has joined #lv2 | 16:40 | |
*** gianMOD has quit IRC | 17:49 | |
*** ddom has quit IRC | 17:50 | |
*** ricardocrudo_ has quit IRC | 17:56 | |
*** o0o0o has quit IRC | 17:56 | |
*** gianMOD has joined #lv2 | 18:31 | |
*** gianMOD has quit IRC | 18:35 | |
*** falktx has quit IRC | 19:16 | |
*** LAbot has joined #lv2 | 21:41 | |
*** edogawa has joined #lv2 | 22:04 | |
*** gianMOD has quit IRC | 22:27 | |
*** gianMOD has joined #lv2 | 22:31 | |
*** ricardocrudo_ has quit IRC | 22:31 | |
*** gianMOD has quit IRC | 23:05 | |
* drobilla realizes sord_validate doesn't check class restrictions at all, just properties | 23:19 | |
drobilla | I wonder what I'll find if I implement that... | 23:19 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!