Friday, 2014-11-21

*** rncbc has quit IRC00:23
*** falktx has joined #lv200:49
*** mlpug has quit IRC02:07
*** HarryHaaren has joined #lv202:19
*** LAbot has joined #lv203:24
*** Anchakor_ has quit IRC04:11
*** Anchakor_ has joined #lv204:12
*** gianMOD has quit IRC04:25
*** falktx has quit IRC04:25
*** rncbc has joined #lv204:36
*** gianMOD has joined #lv204:41
*** zth has joined #lv205:22
*** HarryHaaren has quit IRC06:42
*** mlpug has joined #lv210:02
*** rncbc has quit IRC11:40
*** bazz has quit IRC11:49
*** bazz has joined #lv211:50
*** mlpug has quit IRC12:00
*** NickSB2 has joined #lv212:02
*** HarryHaaren has joined #lv212:16
*** zth has quit IRC12:26
*** ricardocrudo has quit IRC12:28
*** gianMOD has quit IRC12:53
*** gianMOD has joined #lv213:08
*** unclechu has joined #lv213:17
*** rncbc has joined #lv213:17
*** gianMOD has quit IRC13:47
*** edogawa has quit IRC14:52
*** rncbc has quit IRC15:55
HarryHaarenok, I'll keep an eye on there then, and if there's something hackable i see, i'll give it a shot / pull-request16:15
drobillaI don't think the site is the sole problem, but it's a big part of it16:15
drobillaThe biggest problem in general is what happens when people say "how the hell do I write an LV2 plugin/host?"16:16
HarryHaarensure. Fancy graphics always help :D16:17
drobillaThey look and find a bunch of strange detailed information that doesn't answer their question, and typically just give up there16:17
drobillaOn the plugin side, I think lack of a good standard C++ template plugin is probably a significant part of it16:19
drobillaHost, same deal, which jalv serves, but is at drobilla.net and depends on a bunch of libraries which are as well16:19
rgareusright. we should first prepare the "code" part before moving on to the site representation16:21
rgareussome easy to download "all in one"  libs+headers + template16:21
drobillaBut anything that makes LV2 itself something contributed to would help16:22
rgareuslots of stuff is already there eg-sampler is not bad.16:22
drobillaI love what the community builds with it (for the most part), but on that part, I'm alone and almost totally unsupported16:23
drobillaWhich is fine, but I really suck at a lot of this stuff, being part of the problem :)16:24
rgareusas I see it it's mostly some re-organizing of exiting stuff and a nice easy to use [visual] wrapper. plus a good OOTB experience.16:24
drobillargareus: True16:24
rgareuseasier said than done though16:24
drobillaSo back to that basic technical question, is there even a point in keeping lilv and friends in a separate repo if they end up in the tarball anyway?16:25
drobilla(I doubt I can do so and preserve revision history in any case, but oh well)16:27
rgareusdrobilla: I don't care. The only difference there is your convenience.16:27
rgareusdrobilla: I suppose it'll be a script of some kind.16:28
drobillargareus: No submodules is a lot more convenient than submodules16:28
rgareuseither commit-hooks  or some roll-the-tarball  script16:28
drobillaWell, I'm skeptical of my instinct to keep things separate, since that's sort of the problem16:29
drobillaI can't think of any particularly good tangible reason to not just cram it all in the same tree and be done with it16:30
rgareusdrobilla: AFAICT the decision there is a technical one:  how much do the APIs depend on each other?16:31
drobillaPackagers will not be fans of this, no doubt.  Version of lv2 != actual dependencies of programs16:31
drobillargareus: They don't.16:32
rgareuscan I mix lilv version X with serd verion Y and sord version Z ?  if yes -> separate repos.  if no -> one big repo16:32
drobillaDepends if Y is compatible or not according to the usual rules16:33
*** gianMOD has joined #lv216:34
drobillaMost convenient would be to just have to depend on lv2-x.y.z and be done with it16:35
rgareusinstead of one big repo, submodules are an option. but that's mostly taste / maintainer preferences.16:35
drobillaPut all the headers in PRPEFIX/include/lv2-x.y.z16:35
drobillaThough that's also something not currently done due to the "specness" of the thing16:36
drobillargareus: Well, all the separate projects are a headache for me anyway16:37
drobillaRadical simplification is probably the medicine in order, here16:37
rgareusdrobilla: one big repo it is.16:37
drobillargareus: Suppose so.16:38
drobillaI can/will continue to maintain the actual library versions correctly as good general practice16:39
rgareusdrobilla: I dare say you keep the source subdirs anyway. so that's fine for packagers too.16:39
drobillaThough parallel installs get a bit weird16:39
drobillaYeah, I don't know.  ideally pkg-config for lilv and pkg-config for the appropriate LV2 with lilv inside will both work16:41
rgareusdrobilla: add a meta .pc  that depends on all the other ones16:41
drobillaThe real trouble here is that libraries potentially break more16:42
drobillargareus: I suppose that works.16:42
rgareus"lv2-host-stack version X.Y.Z"  depends on  lv2 >= A.B.C liblilv >= D.E.F   etc16:45
drobillalv2-everything.pc or something16:45
rgareussamefor "lv2-plugin-stack"16:45
drobillabetter16:46
rgareuswell, yeah naming is going to be a problem :)16:46
drobillaPerhaps I should put them in the same repo but otherwise have installation remain exactly as it is16:47
rgareusand if lvtk becomes part of the family  "lv2-c++-plugin-stack"  give or take some letters16:48
drobillaWell, the host one would be nice.  Plugins currently have no use for one anyway16:48
*** ricardocrudo has joined #lv216:53
*** ricardocrudo has quit IRC16:54
rgareusdrobilla: on a different, but related note: can we amend the lv2 specs regarding plugin architecture?  i386/x86_64/arm/armel etc?17:06
rgareusso far the spec says /usr/lib/lv2/ for everything regardless17:07
drobillargareus: Far as I can tell there is no universal standard17:07
rgareusosx is easy (multi-arch binaries). windows, too %PROGRAMFILES%\LV2  vs %PROGRAMFILES64%\LV217:09
rgareuson linux we have two options. some library suffix   plugin.i386.so   plugin.x86_64.so  or arch-triples17:10
rgareusthe latter makes more sense IMHO.17:11
rgareuswell maybe just saying     $libdir/lv2   is good17:12
rgareuson debian/ubuntu etc  $libdir  = /usr/lib/i386-linux-gnu/  or whatever   and   fedora will be happy with $libdir too17:13
drobillaEvery host is never going to add the code to find the right name, and it'd all be slightly different and broken even if they did17:13
rgareusthe only problem there are binary hosts  (which don't know what libdir is)17:14
drobillaWell, hosts look in LV2_PATH.  Petty much end of story.17:15
drobillaWhere the plugins should be installed is under-specified, but it's different between distros, so I don't see what we can do17:15
rgareusif the host (or rather liblilv) is compiled by the distro, then there's no problem (give or take packager's mistakes).17:16
rgareusbut if say Bitwig comes a binary with liblilv inside    then it'd need different paths17:17
rgareusfor Fedora and debian and ...17:18
drobillaThat's what LV2_PATH17:18
drobillaIf the user's LV2_PATH is wrong, you're screwed.17:19
drobillaThey're certainly not going to be building if (debian) checks into run-time code17:20
rgareusso long story short. we need to communicate to liblilv packagers to add some /etc/profile.d/lilv which sets the LV2PATH17:20
drobillaor just set the default correctly17:23
rgareusand even then. the user may not have liblilv insttaled but gets just uses some *binary commercial LV2 host with static liblilv*..17:24
drobillaI learned about the lack of consistency here by trying to implement that, as it happens17:24
drobillamaybe a if (exists(PREFIX/lib64)) print("WARNING: blah blah")17:25
rgareuswho's gonna read printf()s ?17:26
drobillaWell, more than who will read one that isn't there17:27
drobillaI don't see anything more to do17:27
drobillaYeah, it sucks.17:27
rgareushosts could implement a "specify LV2 Path in preferences"17:28
rgareusbut chaging it a runtime is a bit of a problem.17:29
drobillaHm.  Perhaps plugins should check LV2_PATH at compile time and find the lib under PREFIX, if present, to know where to install17:31
drobillaGood luck expecting Makefiles to do that, though17:32
* rgareus asks pianoteq.com for the source to compile with proper LV2_PATH :D17:34
*** HarryHaaren has quit IRC17:58
*** NickSB2 has quit IRC19:50
*** gianMOD has quit IRC20:07
*** falktx has joined #lv222:18
drobillaMarkdown page: http://drobilla.net/files/lv2_pelican.png22:25
drobillaI'm sold.  We've got waay more people around here who'd rather edit a plain text file in git than dick around with a wiki22:27
drobilla(spending time writing documentation nobody actually needs! yay!)22:35
*** unclechu has quit IRC22:46
*** NickSB2 has joined #lv222:57
*** drobilla has quit IRC20:53
*** drobilla has joined #lv221:05
*** gianMOD has quit IRC21:23
*** zth has joined #lv221:29
*** LAbot has joined #lv221:31
drobillaI think I might only preserve post-unification tags21:40
drobillaThe old independent extension releases are all weird and not really 'tags' in the git sense21:40
*** rncbc has quit IRC22:00
*** NickSB2 has quit IRC22:07
*** zth has quit IRC22:16
*** NickSB has quit IRC22:21
*** NickSB has joined #lv222:31
*** ricardocrudo has quit IRC22:33
*** NickSB has quit IRC22:46
*** NickSB has joined #lv222:48
*** NickSB has quit IRC22:53
*** NickSB has joined #lv222:56
drobillapugl git doesn't build on OSX23:07

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