Friday, 2014-04-25

*** ricardocrudo has quit IRC00:33
*** falktx has quit IRC01:16
*** edogawa_ has quit IRC02:03
*** triune has quit IRC02:40
*** triune has joined #lv202:42
*** damo22 has joined #lv209:00
*** damo22 has quit IRC09:36
*** damo22 has joined #lv209:36
*** damo22 has quit IRC09:38
*** damo22 has joined #lv209:39
*** damo22 has quit IRC09:39
*** damo22 has joined #lv209:40
*** damo22 has quit IRC09:47
*** damo22 has joined #lv209:47
*** damo22 has quit IRC10:02
*** damo22 has joined #lv210:02
*** damo22 has quit IRC10:05
*** damo22 has joined #lv210:06
*** damo22 has quit IRC10:06
*** damo22 has joined #lv210:06
*** edogawa has joined #lv210:46
*** damo22 has quit IRC10:53
*** falktx has joined #lv211:05
*** ricardocrudo has joined #lv213:04
*** falktx has quit IRC15:45
*** falktx has joined #lv215:46
*** bgribble has joined #lv217:51
bgribblehey lv2ers. I'm trying something a bit nonstandard with an lv2 plug and I'm a bit stymied.  My app is a puredata-type patching system.  I have added a "save as LV2" option which saves a patch file, TTL file, and .so in an LV2 dir.  The LV2 implementation is generic and loads the saved patch file in the normal app engine at instantiation time.17:58
bgribblethis mostly works.17:58
bgribblethe problem is that the .so has to return an appropriate unique URI in its descriptor function, where the URI of the plugin is basically the name of the patch file, which the .so does not know at compile time17:59
bgribbleand no information gets passed in to the descriptor function that would let the .so know what plugin the host is looking for18:00
falktxlinux has ways the know the current running shared lib name18:00
falktxbgribble: a file:/// path is a valid URI, you could use that18:01
bgribbleI have kludged this into working by saving, in the LV2 dir of the plugin, a symlink to the .so where the name of the symlink includes the patch file name (i.e. the actual implementation is libmfpdsp.so, but in saved plugin mfp_stereo2param.lv2 the symlink will be called libmfp_stereo2param_lv2.so)18:01
falktxif this is not meant to be shared across users, you can use local filepaths18:02
bgribblethen I can use dladdr() to get the name of the library and work backwards to figure out what URI is being queried for18:02
bgribblefalktx: not sure I understand18:03
falktxyou can use "<>" as URI in the ttl, which resolves to its current path18:04
falktxsay file:///home/me/bundle.lv2/this.ttl18:04
falktxthe shared lib could look for the ttl and match that URI18:04
* bgribble perks up ears18:04
bgribbleah, ok.  but I didn't mention tha last part of the problem, which is still a problem:18:05
bgribblemy solution (basically the same as yours, but using a different strategy to get the URI) works fine for the first plugin implemented by the library that is loaded by the host18:05
bgribblebut when you want to load a second saved patch in the same host, dladdr() "intelligently" sees that the .so is actually the same even though it was found by different names, and returns the first path that was used to load it18:06
Anchakorbgribble: your solution is quite ugly hack18:08
bgribbleanchakor: thank you!  I agree18:08
Anchakor1) it has this problem which it wouldn't have if you used <>18:08
Anchakor2) it is not crossplatform18:08
bgribbleanchakor: I don't see how <> would help.  I'm willing to use it if it does!18:09
Anchakorbtw Ingen also does this (saving patches as lv2 plugins) so you might look into its code18:09
bgribbleok, I'll have a look18:10
Anchakor<> would help because file:///home/me/bundle.lv2/patch1.ttl is different from file:///home/me/bundle.lv2/patch2.ttl18:10
bgribbleok, but what would the descriptor function return?  how would it know what plugin the host is trying to instantiate?18:11
*** edogawa_ has joined #lv218:12
bgribbleI don't really have a problem coming up with unique URIs, which is why I didn't think <> would help... the problem is that the library can instantiate basically a wildcarded URI with any value at the tail18:12
Anchakoryeah, look into ingen code how it manages returning the valid URI18:14
*** edogawa has quit IRC18:15
*** edogawa_ is now known as edogawa18:15
Anchakorbgribble: I might have misunderstood your problem, but wouldn't it be easiest to make the generic .so look for a manifest.ttl in the dir they both are and get the URI from it on load?18:34
bgribbleanchakor: yep, that's what I do, the problem is that the only way I know to find the path is dladdr() and it always returns the same thing (wherever the .so was when first loaded)18:36
bgribblemaybe if I copy rather than symlinking the library it will work, I'll try that18:37
Anchakoryeah, you need to copy the .so around18:37
bgribbleanyway thatnks for the ingen tip I'll look at it18:37
AnchakorI'd stick with the copied-.so solution if it works, seriously doubt ingen is doing something else (maybe baking it's own .so for each patch?)18:39
edogawahm i think ingen just saves ttl files, at least when i tried back in februauy it saved just a manifest.ttl and another ttl named after that patch19:13
Anchakoryeah but it the plugin itself needs to know the URI to return in the descriptor19:14
edogawayou surely know details better than me, no idea really19:14
bgribbleanchakor, edogawa: it looks like this is all just me failing to find something in the lv2 dox... there appears to be a "new" descriptor-function signature that includes the bundle_path, which is all I need.  not sure if it is what I need but it looks like it.19:47
bgribblethe "lv2_lib_descriptor()" signature.19:52
Anchakoryeah I saw that, but I thought you still had to have the other one too19:52
falktxingen only uses the new one19:56
Anchakorbgribble: btw is there anywhere when we can track your progress on your plugin? would be great to have another modular/semi-modular synth20:05
bgribbleanchakor: http://github.com/bgribble/mfp20:30
falktxneeds some screenshots20:36
bgribblethere are a few in the LAC paper in doc/20:39
*** drobilla has joined #lv221:43
*** bgribble has quit IRC21:55
*** edogawa has quit IRC23:09
*** edogawa has joined #lv223:16
*** edogawa has quit IRC23:17

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