rgareus | arrrrrr. lv2 is not free anymore! I will cease lv2 plugin dev and immediatly remove support for LV2 in the *free* projects that I'm involved with :) | 00:12 |
---|---|---|
rgareus | drobilla: "open" is worse. IMHO. | 00:13 |
rgareus | drobilla: I thought you of all people should know better than that. | 00:14 |
rgareus | https://www.gnu.org/philosophy/open-source-misses-the-point.html FTW | 00:14 |
rgareus | please bring back "free" (and link it to the license) | 00:15 |
*** HarryHaaren has joined #lv2 | 00:16 | |
drobilla | jesus fucking christ. | 00:19 |
drobilla | and it doesn't say open source, anyway. It says "LV2 is an open standard" | 00:19 |
drobilla | See, the way this works is, I say it's bullshit | 00:21 |
drobilla | Everyone convinces me it's suuuuuuuuuuuuuuuuuper important | 00:21 |
drobilla | So I do it | 00:21 |
drobilla | And nothing changes | 00:21 |
drobilla | And I get to say "I told you so" | 00:21 |
drobilla | Which isn't much of a reward, personally, but it will do :) | 00:22 |
*** rncbc_ has joined #lv2 | 00:39 | |
*** rncbc has quit IRC | 00:39 | |
*** gianMOD_ has joined #lv2 | 00:53 | |
*** gianMOD has quit IRC | 00:57 | |
*** rncbc_ is now known as rncbc | 00:57 | |
*** rncbc has quit IRC | 01:12 | |
*** gianMOD_ has quit IRC | 01:12 | |
drobilla | Seriously though, "open standard" is pretty good terminology. True in many ways | 01:16 |
drobilla | Nobody except maybe Microsoft thinks open standards are bad :) | 01:16 |
drobilla | and it doesn't carry the bad weight that "extensible" apparently has, but hints at it | 01:17 |
*** gianMOD has joined #lv2 | 02:13 | |
*** gianMOD has quit IRC | 02:18 | |
*** HarryHaaren has quit IRC | 03:04 | |
*** gianMOD has joined #lv2 | 03:14 | |
*** gianMOD has quit IRC | 03:19 | |
*** gianMOD has joined #lv2 | 03:30 | |
*** gianMOD has quit IRC | 03:35 | |
*** gianMOD has joined #lv2 | 04:07 | |
*** gianMOD has quit IRC | 06:54 | |
*** gianMOD has joined #lv2 | 07:55 | |
*** gianMOD has quit IRC | 08:00 | |
*** ColaEuphoria has joined #lv2 | 08:35 | |
ColaEuphoria | new site design looks really nice | 08:35 |
Anchakor | microsoft actually seems to be opening up recently | 08:37 |
Anchakor | not sure how about open standards and dealing with their NIH | 08:37 |
Anchakor | but they open sourced .net implementation | 08:37 |
Anchakor | like native crossplatform .net runtime, instead of Mono | 08:38 |
Anchakor | not really useful to me, but interesting that it is happening | 08:38 |
*** edogawa has joined #lv2 | 08:48 | |
*** gianMOD has joined #lv2 | 08:56 | |
*** gianMOD has quit IRC | 09:01 | |
*** Anchakor_ has quit IRC | 09:25 | |
*** gianMOD has joined #lv2 | 09:40 | |
*** zth has joined #lv2 | 10:27 | |
*** gianMOD has quit IRC | 10:41 | |
*** gianMOD has joined #lv2 | 10:52 | |
*** ricardocrudo has joined #lv2 | 11:32 | |
*** falktx has joined #lv2 | 11:34 | |
falktx | that yoshimi lv2 code makes me cringe... :/ | 11:37 |
falktx | I think the author or some user didn't had the new lv2, so the buf-size and options extensions were missing | 11:39 |
falktx | the code redefines them | 11:39 |
falktx | #define YOSHIMI_LV2_BUF_SIZE_URI "http://lv2plug.in/ns/ext/buf-size" | 11:39 |
falktx | #define YOSHIMI_LV2_BUF_SIZE_PREFIX YOSHIMI_LV2_BUF_SIZE_URI "#" | 11:39 |
falktx | they also modified the external-ui header for some reason... :S | 11:40 |
falktx | hmm, the processing code is confusing... | 11:48 |
falktx | semaphores and ringbuffers on the lv2 plugin !? | 11:49 |
falktx | an extra midi thread? | 11:49 |
* falktx recognizes some code, someone has been copying :P | 11:51 | |
*** HarryHaaren has joined #lv2 | 11:53 | |
falktx | hey HarryHaaren | 11:54 |
HarryHaaren | sup falktx | 11:54 |
falktx | HarryHaaren: I noticed your comment on yoshimi-lv2, have you tried it yet? | 11:54 |
HarryHaaren | nope | 11:54 |
HarryHaaren | but I was talking with Will at the LAC, and he informed me of his work towards this; a contgrats was in order. testing to follow | 11:55 |
falktx | there are some very weird things happening in the code | 11:56 |
falktx | specially semaphores, ringbuffers and threads for MIDI | 11:56 |
falktx | I have no idea why | 11:56 |
falktx | he also modified (and broke) one of my extensions ABI | 11:56 |
falktx | it seems to be he's running a modified carla version. the code is all too similar | 11:58 |
falktx | but also breaking the lv2 specs in some points | 11:58 |
*** HarryHaaren_ has joined #lv2 | 12:00 | |
*** HarryHaaren has quit IRC | 12:00 | |
HarryHaaren_ | sorry falktx , pinged out, did i miss things? ( "but also breaking the lv2 specs" was the last I saw ) | 12:00 |
falktx | that was my last message | 12:01 |
HarryHaaren_ | hmm, that's not ideal. | 12:01 |
HarryHaaren_ | were these threads / ringbuffers added, or already present in Yosh? | 12:01 |
falktx | they were added in the lv2 plugin | 12:01 |
falktx | yoshimi probably has some of it internally, but a plugin interface should not need it | 12:02 |
falktx | it just feeds data to the main code, like a wrapper | 12:02 |
HarryHaaren_ | does this scale better for multiple-voice multithreading? that makes sense in a synth? | 12:02 |
falktx | this breaks multi-threading afaik | 12:03 |
HarryHaaren_ | aka a single thread for all voices will take longer than a thread-per-voice? | 12:03 |
HarryHaaren_ | hmm, then its done wrong. | 12:03 |
falktx | it's waiting on a global mutex | 12:03 |
falktx | or it seems like it | 12:03 |
HarryHaaren_ | that's OK, so long as the mutex is never ever locked by the UI | 12:03 |
falktx | afaik it is | 12:04 |
falktx | the plugin seems a bit quick-hackish made. "kick it until it works" | 12:04 |
HarryHaaren_ | then there's an issue. *When* the UI locks it is important: "often" or only on preset-change | 12:04 |
falktx | for the first version is ok I guess... | 12:04 |
HarryHaaren_ | Will talked about the size of presets for the whole of Zyn, and its not easy to transfer a whole set of parameters to the DSP (according to him) | 12:04 |
falktx | HarryHaaren_: that's the least of my concerns. what I'm wondering is the midi thread | 12:05 |
HarryHaaren_ | we talked some details but I forget what the final choice was. | 12:05 |
HarryHaaren_ | ah ok | 12:05 |
falktx | plus the lv2-programs ABI/API breakage | 12:05 |
falktx | only carla and qtractor support that extension | 12:05 |
falktx | so he's either using a custom carla or qtractor | 12:05 |
falktx | and the modifications can't be pushed officially without breaking plugins | 12:06 |
falktx | I'm sure he's not using any of distrho ports. cause that change will make them crash | 12:07 |
falktx | meh, I though we were going forward with lv2... | 12:07 |
falktx | new plugins are released with old stuff (external-ui and instance-data) | 12:07 |
HarryHaaren_ | falktx, have you emailed him about this? | 12:10 |
falktx | no | 12:10 |
HarryHaaren_ | it seems it'd help if you emailed and discussed what's wrong? | 12:10 |
* falktx is more upset that yoshimi is still being actively developed instead of helping zynaddsubfx | 12:10 | |
falktx | I don't want to help yoshimi | 12:10 |
HarryHaaren_ | well that's a different thing. | 12:10 |
falktx | it's nothing personal, it's just that zynaddsubfx has gone into the correct path now | 12:11 |
HarryHaaren_ | there's not much point detailing all the things he's doing wrong, and then not at least informing him what's wrong. | 12:11 |
falktx | I was just ranting, sorry | 12:11 |
falktx | zyn has NTK UI (so proper plugin version) and dsp<->ui separation (so no global UI mutex) | 12:11 |
falktx | plus the author knows what its doing :) | 12:12 |
falktx | I should rant less, sorry. lunch time | 12:15 |
HarryHaaren_ | no problem in "rant" detailing issues, but i it seems a waste if you don't send the above IRC log to Will. | 12:20 |
falktx | I don't fully understand the code, so it's mostly questions at this point | 12:21 |
falktx | why the midi thread and ringbuffer? etc etc | 12:22 |
falktx | I'm sure he knows about ABI/API breakages | 12:22 |
HarryHaaren_ | still. | 12:24 |
falktx | well, the header file states me as the author | 12:24 |
falktx | he added stuff and his own name in the copyright | 12:24 |
falktx | I wasn't contacted about this, and he released a plugin (stable) with those changes | 12:25 |
falktx | it's ISC licensed anyway, so I don't care | 12:25 |
Anchakor | isn't lv2 also supposed to be getting better in the community cooperation aspect? :) | 12:27 |
falktx | community = communication with more than 1 people | 12:28 |
falktx | if only 1 person does the changes and releases it, it's not much of a community | 12:28 |
HarryHaaren_ | falktx, be fair. Yoshimi has a lot of other users, and there are other people working on it / testing too. | 12:29 |
*** HarryHaaren_ is now known as HarryHaaren | 12:29 | |
falktx | lv2-programs was sorta hackish solution anyway, we should preferably be using lv2-presets | 12:29 |
Anchakor | well if you just ignore it and not talk to him, it's just making matters worse re community | 12:30 |
falktx | I can talk to him if he's here | 12:30 |
falktx | but I'm not going to help getting yoshimi fixed | 12:30 |
HarryHaaren | or email? Will doesn't do IRC | 12:30 |
falktx | I'm working on zyn-lv2/vst right now | 12:30 |
falktx | I kinda hate email, it's the last resort | 12:30 |
HarryHaaren | falktx, define "help". Sending an email is not the same as spending 2 hours coding stuff for Yoshimi. Knowing the above, and detailing it here, and *not* contacting the author is not good practice. even a quick copy/paste of the IRC log above would be sufficient | 12:32 |
falktx | the thing is, why me? | 12:32 |
HarryHaaren | because you worked on the code, and you're the one who brought it up here, and has the knowledge of what's going on. I've never worked with ZASF / Yoshimi, so its not for me to say | 12:33 |
HarryHaaren | also i dont actually *have* the knowledge of whats going on there. | 12:33 |
Anchakor | you want us to copy & paste the ;ogs to him, in stead formulating it yourself for him as you think apropriate? | 12:33 |
falktx | I didn't work on any yoshimi code | 12:33 |
HarryHaaren | falktx, you've read it, understand it, and can criticise some issues that might (or might not) be present. You can "help" Yoshimi by sending an email. | 12:35 |
falktx | but it's mostly questions | 12:35 |
falktx | on a first release | 12:35 |
HarryHaaren | we've spent longer discussing good communication practice in a community than it takes to send an email. | 12:35 |
Anchakor | take it as a bug report | 12:35 |
falktx | I'd rather leave yoshimi broken :P | 12:36 |
HarryHaaren | falktx, not funny. That is a toxic and stupid approach IMO, you're purposely not communicating with members of the linux-audio community. | 12:36 |
HarryHaaren | how would you feel if I was writing a carla-competitor, and knew something you had was wrong, but I never bothered to ask you about it? | 12:37 |
falktx | again, I only have questions | 12:37 |
falktx | he's the one that didn't communicate with me in the first place when breaking lv2-programs | 12:38 |
HarryHaaren | nope, he's *using* your stuff. *You* noticed that its perhaps not working as should. And you're the author of lv2-programs right? | 12:39 |
Anchakor | well your response to that is pretty childish tbh | 12:39 |
falktx | he added stuff to the structs | 12:39 |
falktx | doens't break things now but will very likely in the future, since it's not "official" | 12:39 |
HarryHaaren | anyway, this is a stupid childish conversation. there's the right thing to do (communication healthily with others) and there's the bad-way (not-communicating). | 12:40 |
falktx | who started? | 12:40 |
falktx | I was just ranting about some minor stuff I found | 12:40 |
HarryHaaren | i'm not going to email this IRC to Will on your behalf; that's decision is yours. | 12:40 |
* HarryHaaren done :) | 12:40 | |
* falktx still hasn't eaten | 12:40 | |
HarryHaaren | enjoy the lunch | 12:41 |
falktx | thanks, sorry about all this :S | 12:41 |
*** ricardocrudo has quit IRC | 12:55 | |
*** ricardocrudo has joined #lv2 | 12:55 | |
*** gianMOD has quit IRC | 13:03 | |
*** ricardocrudo has quit IRC | 13:47 | |
*** ricardocrudo has joined #lv2 | 13:54 | |
*** falktx has quit IRC | 14:27 | |
*** Anchakor_ has joined #lv2 | 14:40 | |
*** rncbc has joined #lv2 | 14:51 | |
HarryHaaren | drobilla, PUGL / Cairo, there's no double buffering. As a solution, do you think it could be possible to implement two cairo_t contexts, and double buffer by alternating? | 15:48 |
HarryHaaren | I don't mind trying to implement it, but I'm rubbish with X, so I don't know if this *could* work in theory | 15:48 |
drobilla | Is that really the best way to get double buffering with cairo? | 15:49 |
HarryHaaren | i have no idea. But its something I've thought up. | 15:49 |
HarryHaaren | I've previously drawn large-waveforms to thier own Context, and paint()-ed them onto the main one | 15:49 |
HarryHaaren | rgareus, ^ double buffering with PUGL and Cairo, what do you think? Two cairo_t contexts, and swap between them? | 15:50 |
drobilla | HarryHaaren: Time for some GOogle-fu I suppose | 15:50 |
drobilla | In general, yes, it needs double buffering (probably). Whatever the best/correct way to do so it I have zero clue | 15:51 |
HarryHaaren | google-fu has me reading some slightly OT stuff regarding GTK and double-buffering in general.. I didn't learn much from it. | 15:52 |
HarryHaaren | hmm, i gather the cairo_t context is created from the Surface, which is in returned from cairo_xlib_surface_create() | 15:56 |
HarryHaaren | perhaps that means we're stuck with one context? Or can is there a way we could swap two cairo_t* from one surface.. | 15:56 |
* HarryHaaren google-ies | 15:56 | |
drobilla | https://lists.gnu.org/archive/html/gnustep-dev/2011-10/msg00003.html | 15:58 |
drobilla | Quite old, though. | 15:58 |
drobilla | cairo_surface_create_similar sounds handy for our purposes... | 15:59 |
HarryHaaren | that's pretty true, and two surfaces would also mean two contexts. its swapping the surface X is using and drawing the other that I don't see how to do yet | 16:00 |
HarryHaaren | drob: will I ping an email to the Cairo development list? Seems reasonable? | 16:01 |
drobilla | I think the idea is to always draw to one surface then just copy it to the X one in one go every time? (which would be on expose, I suppose) | 16:02 |
HarryHaaren | ah yes, that makes sense. | 16:03 |
HarryHaaren | that's a plan then? Add a cairo_surface_t* backbuffer; initialize it using cairo_surface_similar(); and memcpy the pixel-data to the frontbuffer just before expose? | 16:04 |
drobilla | There is surely some kinda of cairo correct way to copy between surfaces rather than literally memcpy, but other than that, sounds like a reasonable thing to try | 16:05 |
drobilla | I suppose all of this would happen in the expose handler | 16:05 |
HarryHaaren | POC first :D With context's, one can cairo_paint( fontBufferContext, backBufferContext ) or something. | 16:06 |
HarryHaaren | i know its possible to get raw-pointer to data, and a memcpy + cairo_mark_dirty() should do the same | 16:06 |
* HarryHaaren hacking new surfaces & contexts | 16:10 | |
HarryHaaren | hmm, even older (2005) but coping cairo_t to cairo_t "is really unattractive": http://lists.cairographics.org/archives/cairo/2005-July/004526.html | 16:22 |
HarryHaaren | cairo_xlib_surface_set_drawable() is perhaps an opportunity | 16:22 |
HarryHaaren | ah yes: http://lists.cairographics.org/archives/cairo/2005-July/004469.html | 16:23 |
HarryHaaren | this would suggest that "ping-pong"-ing the surfaces by changing the X drawable is better than copying the data? | 16:25 |
HarryHaaren | hmm the "obvious" other approach is to do partial redraws on the single cairo_context (like before this discussion) and since the redraws will be small, tearing will be small. | 16:26 |
HarryHaaren | still, double buffering > smaller problem. | 16:27 |
* HarryHaaren got somewhere, but its not done yet. Dinner time, and then weekend of socializing. Chat another time! | 17:06 | |
*** HarryHaaren has quit IRC | 17:06 | |
rgareus | just one cairo software surface and GL double buffering. | 17:44 |
rgareus | drobilla: IME, the current state of cairo/GL cairo_surface_create_similar() still performs worse on most hardware than a software surface + blit | 17:45 |
drobilla | rgareus: Maybe, but GL is also a potential world of problems. Having Cairo and just Cairo backend is nice in several ways | 17:50 |
drobilla | I don't know if the API can be twiddled to support both cleanly | 17:50 |
drobilla | The whole bloody desktop renders that way, typically, surely it can't be that bad? | 17:51 |
*** NickSB2 has quit IRC | 17:51 | |
drobilla | Or perhaps there's a if (cairo_via_gl_is_actually_a_good_idea_right_now), but I doubt it | 17:52 |
rgareus | drobilla: I'd avoid mixing puGL + cairo. | 17:55 |
rgareus | drobilla: leave libpuGL just GL. libCairoPuGL is something else. | 17:56 |
*** mlpug has joined #lv2 | 17:56 | |
drobilla | rgareus: Why? | 17:57 |
drobilla | GL is a pain in the ass, and 99% of Pugl has nothing to do with it. | 17:57 |
drobilla | The overwhelming majority of plugin UIs would be better served by an easy way to make portable Cairo UIs | 17:57 |
drobilla | There is a clear separation there anyway. Virtually all of what pugl does doesn't care about the drawing context at all | 17:59 |
drobilla | It could be done in a cleaner way somehow, perhaps, but definitely should be done. Whole reason I did so is people asked me to. People who just want to draw some vectors and text and stuff and have less than zero interest in wrestling with GL to do so | 18:00 |
drobilla | You just don't care about the easy part because you've already dealt with that mess in your own code :) | 18:01 |
rgareus | if you think so, fine. but keep in mind that falktx, wrl, have similar projects. | 18:04 |
rgareus | drobilla: I like pugl because it's the minimal abstraction that provied a GL context on all major platforms. AND does *nothing else*. | 18:04 |
rgareus | (except, well, some basic event abstraction) | 18:05 |
drobilla | rgareus: It's a minimal abstraction that provides a window and event handling on all major platforms | 18:05 |
drobilla | rgareus: ... that had like 4 lines of GL context set up code in there, too | 18:05 |
rgareus | drobilla: I don't think we need another kitchen sink. gl + cairo ... | 18:05 |
rgareus | drobilla: I removed the GL buffer clears | 18:06 |
drobilla | I'd be more inclined to remove both GL and Cairo entirely | 18:06 |
drobilla | But then the user has to set up the contexts and yadda yadda themselves. What's the point? | 18:06 |
rgareus | drobilla: I'm not sure if that's feasible w/o exposing the underlying OS window handle. Window + Event + Context are linked | 18:08 |
drobilla | Yes, it would have to expose the underlying OS window handle that way | 18:08 |
rgareus | drobilla: but yes. GL setup can be done in callbacks. just the context needs to be grabbed | 18:08 |
drobilla | (in an opaque sort of way like the UI extension and suil) | 18:08 |
drobilla | The context should probably be truly separated anyway, minimal to no #ifdef mess that way. Means more files though | 18:10 |
rgareus | drobilla: API wise. I think it'd be smart to keep cairo + pugl separate. I don't mind if it lives in he same repo. but header and implementation should be separate | 18:11 |
drobilla | It's basically setup_visual(), ctx.create(), ctx.enter(), ctx.leave(), ctx.get_handle_to_whatever() | 18:11 |
rgareus | ie add cairo on top of pugl. | 18:11 |
rgareus | just not mix it into pugl.h | 18:12 |
drobilla | Skipping the middle man is better, at least sometimes. | 18:12 |
drobilla | Particularly when that middle man is notorious for drivers just not working, or working terribly. | 18:12 |
drobilla | rgareus: pugl.h doesn't even mention either, tellingly | 18:13 |
drobilla | (other than what puglGetContext returns) | 18:13 |
*** falktx has joined #lv2 | 18:18 | |
*** rncbc has quit IRC | 18:52 | |
*** NickSB2 has joined #lv2 | 19:02 | |
*** NickSB2 has quit IRC | 19:06 | |
*** NickSB2 has joined #lv2 | 19:06 | |
*** rncbc has joined #lv2 | 20:45 | |
*** mlpug has quit IRC | 21:04 | |
*** zth has quit IRC | 21:22 | |
*** NickSB2 has quit IRC | 22:49 | |
*** rncbc has quit IRC | 23:28 | |
*** edogawa has quit IRC | 23:35 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!