Saturday, 2014-12-06

rgareusarrrrrr. 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
rgareusdrobilla: "open" is worse. IMHO.00:13
rgareusdrobilla: I thought you of all people should know better than that.00:14
rgareushttps://www.gnu.org/philosophy/open-source-misses-the-point.html FTW00:14
rgareusplease bring back "free" (and link it to the license)00:15
*** HarryHaaren has joined #lv200:16
drobillajesus fucking christ.00:19
drobillaand it doesn't say open source, anyway.  It says "LV2 is an open standard"00:19
drobillaSee, the way this works is, I say it's bullshit00:21
drobillaEveryone convinces me it's suuuuuuuuuuuuuuuuuper important00:21
drobillaSo I do it00:21
drobillaAnd nothing changes00:21
drobillaAnd I get to say "I told you so"00:21
drobillaWhich isn't much of a reward, personally, but it will do :)00:22
*** rncbc_ has joined #lv200:39
*** rncbc has quit IRC00:39
*** gianMOD_ has joined #lv200:53
*** gianMOD has quit IRC00:57
*** rncbc_ is now known as rncbc00:57
*** rncbc has quit IRC01:12
*** gianMOD_ has quit IRC01:12
drobillaSeriously though, "open standard" is pretty good terminology.  True in many ways01:16
drobillaNobody except maybe Microsoft thinks open standards are bad :)01:16
drobillaand it doesn't carry the bad weight that "extensible" apparently has, but hints at it01:17
*** gianMOD has joined #lv202:13
*** gianMOD has quit IRC02:18
*** HarryHaaren has quit IRC03:04
*** gianMOD has joined #lv203:14
*** gianMOD has quit IRC03:19
*** gianMOD has joined #lv203:30
*** gianMOD has quit IRC03:35
*** gianMOD has joined #lv204:07
*** gianMOD has quit IRC06:54
*** gianMOD has joined #lv207:55
*** gianMOD has quit IRC08:00
*** ColaEuphoria has joined #lv208:35
ColaEuphorianew site design looks really nice08:35
Anchakormicrosoft actually seems to be opening up recently08:37
Anchakornot sure how about open standards and dealing with their NIH08:37
Anchakorbut they open sourced .net implementation08:37
Anchakorlike native crossplatform .net runtime, instead of Mono08:38
Anchakornot really useful to me, but interesting that it is happening08:38
*** edogawa has joined #lv208:48
*** gianMOD has joined #lv208:56
*** gianMOD has quit IRC09:01
*** Anchakor_ has quit IRC09:25
*** gianMOD has joined #lv209:40
*** zth has joined #lv210:27
*** gianMOD has quit IRC10:41
*** gianMOD has joined #lv210:52
*** ricardocrudo has joined #lv211:32
*** falktx has joined #lv211:34
falktxthat yoshimi lv2 code makes me cringe... :/11:37
falktxI think the author or some user didn't had the new lv2, so the buf-size and options extensions were missing11:39
falktxthe code redefines them11: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
falktxthey also modified the external-ui header for some reason... :S11:40
falktxhmm, the processing code is confusing...11:48
falktxsemaphores and ringbuffers on the lv2 plugin !?11:49
falktxan extra midi thread?11:49
* falktx recognizes some code, someone has been copying :P11:51
*** HarryHaaren has joined #lv211:53
falktxhey HarryHaaren11:54
HarryHaarensup falktx11:54
falktxHarryHaaren: I noticed your comment on yoshimi-lv2, have you tried it yet?11:54
HarryHaarennope11:54
HarryHaarenbut I was talking with Will at the LAC, and he informed me of his work towards this; a contgrats was in order. testing to follow11:55
falktxthere are some very weird things happening in the code11:56
falktxspecially semaphores, ringbuffers and threads for MIDI11:56
falktxI have no idea why11:56
falktxhe also modified (and broke) one of my extensions ABI11:56
falktxit seems to be he's running a modified carla version. the code is all too similar11:58
falktxbut also breaking the lv2 specs in some points11:58
*** HarryHaaren_ has joined #lv212:00
*** HarryHaaren has quit IRC12:00
HarryHaaren_sorry falktx , pinged out, did i miss things?   ( "but also breaking the lv2 specs" was the last I saw )12:00
falktxthat was my last message12:01
HarryHaaren_hmm, that's not ideal.12:01
HarryHaaren_were these threads / ringbuffers added, or already present in Yosh?12:01
falktxthey were added in the lv2 plugin12:01
falktxyoshimi probably has some of it internally, but a plugin interface should not need it12:02
falktxit just feeds data to the main code, like a wrapper12:02
HarryHaaren_does this scale better for multiple-voice multithreading? that makes sense in a synth?12:02
falktxthis breaks multi-threading afaik12: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
falktxit's waiting on a global mutex12:03
falktxor it seems like it12:03
HarryHaaren_that's OK, so long as the mutex is never ever locked by the UI12:03
falktxafaik it is12:04
falktxthe 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-change12:04
falktxfor 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
falktxHarryHaaren_: that's the least of my concerns. what I'm wondering is the midi thread12:05
HarryHaaren_we talked some details but I forget what the final choice was.12:05
HarryHaaren_ah ok12:05
falktxplus the lv2-programs ABI/API breakage12:05
falktxonly carla and qtractor support that extension12:05
falktxso he's either using a custom carla or qtractor12:05
falktxand the modifications can't be pushed officially without breaking plugins12:06
falktxI'm sure he's not using any of distrho ports. cause that change will make them crash12:07
falktxmeh, I though we were going forward with lv2...12:07
falktxnew plugins are released with old stuff (external-ui and instance-data)12:07
HarryHaaren_falktx, have you emailed him about this?12:10
falktxno12: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 zynaddsubfx12:10
falktxI don't want to help yoshimi12:10
HarryHaaren_well that's a different thing.12:10
falktxit's nothing personal, it's just that zynaddsubfx has gone into the correct path now12: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
falktxI was just ranting, sorry12:11
falktxzyn has NTK UI (so proper plugin version) and dsp<->ui separation (so no global UI mutex)12:11
falktxplus the author knows what its doing :)12:12
falktxI should rant less, sorry. lunch time12: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
falktxI don't fully understand the code, so it's mostly questions at this point12:21
falktxwhy the midi thread and ringbuffer? etc etc12:22
falktxI'm sure he knows about ABI/API breakages12:22
HarryHaaren_still.12:24
falktxwell, the header file states me as the author12:24
falktxhe added stuff and his own name in the copyright12:24
falktxI wasn't contacted about this, and he released a plugin (stable) with those changes12:25
falktxit's ISC licensed anyway, so I don't care12:25
Anchakorisn't lv2 also supposed to be getting better in the community cooperation aspect? :)12:27
falktxcommunity = communication with more than 1 people12:28
falktxif only 1 person does the changes and releases it, it's not much of a community12: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 HarryHaaren12:29
falktxlv2-programs was sorta hackish solution anyway, we should preferably be using lv2-presets12:29
Anchakorwell if you just ignore it and not talk to him, it's just making matters worse re community12:30
falktxI can talk to him if he's here12:30
falktxbut I'm not going to help getting yoshimi fixed12:30
HarryHaarenor email? Will doesn't do IRC12:30
falktxI'm working on zyn-lv2/vst right now12:30
falktxI kinda hate email, it's the last resort12:30
HarryHaarenfalktx, 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 sufficient12:32
falktxthe thing is, why me?12:32
HarryHaarenbecause 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 say12:33
HarryHaarenalso i dont actually *have* the knowledge of whats going on there.12:33
Anchakoryou want us to copy & paste the ;ogs to him, in stead formulating it yourself for him as you think apropriate?12:33
falktxI didn't work on any yoshimi code12:33
HarryHaarenfalktx, 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
falktxbut it's mostly questions12:35
falktxon a first release12:35
HarryHaarenwe've spent longer discussing good communication practice in a community than it takes to send an email.12:35
Anchakortake it as a bug report12:35
falktxI'd rather leave yoshimi broken :P12:36
HarryHaarenfalktx, not funny. That is a toxic and stupid approach IMO, you're purposely not communicating with members of the linux-audio community.12:36
HarryHaarenhow 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
falktxagain, I only have questions12:37
falktxhe's the one that didn't communicate with me in the first place when breaking lv2-programs12:38
HarryHaarennope, 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
Anchakorwell your response to that is pretty childish tbh12:39
falktxhe added stuff to the structs12:39
falktxdoens't break things now but will very likely in the future, since it's not "official"12:39
HarryHaarenanyway, 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
falktxwho started?12:40
falktxI was just ranting about some minor stuff I found12:40
HarryHaareni'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 eaten12:40
HarryHaarenenjoy the lunch12:41
falktxthanks, sorry about all this :S12:41
*** ricardocrudo has quit IRC12:55
*** ricardocrudo has joined #lv212:55
*** gianMOD has quit IRC13:03
*** ricardocrudo has quit IRC13:47
*** ricardocrudo has joined #lv213:54
*** falktx has quit IRC14:27
*** Anchakor_ has joined #lv214:40
*** rncbc has joined #lv214:51
HarryHaarendrobilla, 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
HarryHaarenI don't mind trying to implement it, but I'm rubbish with X, so I don't know if this *could* work in theory15:48
drobillaIs that really the best way to get double buffering with cairo?15:49
HarryHaareni have no idea. But its something I've thought up.15:49
HarryHaarenI've previously drawn large-waveforms to thier own Context, and paint()-ed them onto the main one15:49
HarryHaarenrgareus, ^ double buffering with PUGL and Cairo, what do you think? Two cairo_t contexts, and swap between them?15:50
drobillaHarryHaaren: Time for some GOogle-fu I suppose15:50
drobillaIn general, yes, it needs double buffering (probably).  Whatever the best/correct way to do so it I have zero clue15:51
HarryHaarengoogle-fu has me reading some slightly OT stuff regarding GTK and double-buffering in general.. I didn't learn much from it.15:52
HarryHaarenhmm, i gather the cairo_t context is created from the Surface, which is in returned from cairo_xlib_surface_create()15:56
HarryHaarenperhaps 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-ies15:56
drobillahttps://lists.gnu.org/archive/html/gnustep-dev/2011-10/msg00003.html15:58
drobillaQuite old, though.15:58
drobillacairo_surface_create_similar sounds handy for our purposes...15:59
HarryHaarenthat'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 yet16:00
HarryHaarendrob: will I ping an email to the Cairo development list? Seems reasonable?16:01
drobillaI 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
HarryHaarenah yes, that makes sense.16:03
HarryHaarenthat'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
drobillaThere 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 try16:05
drobillaI suppose all of this would happen in the expose handler16:05
HarryHaarenPOC first :D With context's, one can cairo_paint( fontBufferContext, backBufferContext ) or something.16:06
HarryHaareni know its possible to get raw-pointer to data, and a memcpy + cairo_mark_dirty() should do the same16:06
* HarryHaaren hacking new surfaces & contexts16:10
HarryHaarenhmm, even older (2005) but coping cairo_t to cairo_t "is really unattractive": http://lists.cairographics.org/archives/cairo/2005-July/004526.html16:22
HarryHaarencairo_xlib_surface_set_drawable() is perhaps an opportunity16:22
HarryHaarenah yes: http://lists.cairographics.org/archives/cairo/2005-July/004469.html16:23
HarryHaarenthis would suggest that "ping-pong"-ing the surfaces by changing the X drawable is better than copying the data?16:25
HarryHaarenhmm 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
HarryHaarenstill, 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 IRC17:06
rgareusjust one cairo software surface and GL double buffering.17:44
rgareusdrobilla: IME, the current state of cairo/GL  cairo_surface_create_similar() still performs worse on most hardware than a software surface + blit17:45
drobillargareus: Maybe, but GL is also a potential world of problems.  Having Cairo and just Cairo backend is nice in several ways17:50
drobillaI don't know if the API can be twiddled to support both cleanly17:50
drobillaThe whole bloody desktop renders that way, typically, surely it can't be that bad?17:51
*** NickSB2 has quit IRC17:51
drobillaOr perhaps there's a if (cairo_via_gl_is_actually_a_good_idea_right_now), but I doubt it17:52
rgareusdrobilla: I'd avoid mixing puGL + cairo.17:55
rgareusdrobilla: leave libpuGL just GL.   libCairoPuGL is something else.17:56
*** mlpug has joined #lv217:56
drobillargareus: Why?17:57
drobillaGL is a pain in the ass, and 99% of Pugl has nothing to do with it.17:57
drobillaThe overwhelming majority of plugin UIs would be better served by an easy way to make portable Cairo UIs17:57
drobillaThere is a clear separation there anyway.  Virtually all of what pugl does doesn't care about the drawing context at all17:59
drobillaIt 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 so18:00
drobillaYou just don't care about the easy part because you've already dealt with that mess in your own code :)18:01
rgareusif you think so, fine. but keep in mind that falktx, wrl, have similar projects.18:04
rgareusdrobilla:  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
drobillargareus: It's a minimal abstraction that provides a window and event handling on all major platforms18:05
drobillargareus: ... that had like 4 lines of GL context set up code in there, too18:05
rgareusdrobilla: I don't think we need another kitchen sink. gl + cairo ...18:05
rgareusdrobilla: I removed the GL buffer clears18:06
drobillaI'd be more inclined to remove both GL and Cairo entirely18:06
drobillaBut then the user has to set up the contexts and yadda yadda themselves.  What's the point?18:06
rgareusdrobilla: I'm not sure if that's feasible w/o exposing the underlying OS window handle.  Window + Event + Context are linked18:08
drobillaYes, it would have to expose the underlying OS window handle that way18:08
rgareusdrobilla: but yes. GL setup can be done in callbacks. just the context needs to be grabbed18:08
drobilla(in an opaque sort of way like the UI extension and suil)18:08
drobillaThe context should probably be truly separated anyway, minimal to no #ifdef mess that way.  Means more files though18:10
rgareusdrobilla: 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 separate18:11
drobillaIt's basically setup_visual(), ctx.create(), ctx.enter(), ctx.leave(), ctx.get_handle_to_whatever()18:11
rgareusie add cairo on top of pugl.18:11
rgareusjust not mix it into pugl.h18:12
drobillaSkipping the middle man is better, at least sometimes.18:12
drobillaParticularly when that middle man is notorious for drivers just not working, or working terribly.18:12
drobillargareus: pugl.h doesn't even mention either, tellingly18:13
drobilla(other than what puglGetContext returns)18:13
*** falktx has joined #lv218:18
*** rncbc has quit IRC18:52
*** NickSB2 has joined #lv219:02
*** NickSB2 has quit IRC19:06
*** NickSB2 has joined #lv219:06
*** rncbc has joined #lv220:45
*** mlpug has quit IRC21:04
*** zth has quit IRC21:22
*** NickSB2 has quit IRC22:49
*** rncbc has quit IRC23:28
*** edogawa has quit IRC23:35

Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!