Saturday, 2016-11-19

ssj71http://drobilla.net/software/jalv00:00
pablo7ssj71: so i should read jalv and lv2apply.c to see how its done? sorry, i'm not very good at english, so i may not understand what you are suggesting.. Are you telling me to use jalv as a reference?00:01
pablo7ssj71: or to use somehow jalv inside my app?00:02
ssj71pablo7: use it as a reference, and use parts of it inside your app00:05
pablo7ssj71: thanks! i'll look trhoug it then!00:06
*** pablo7 has quit IRC00:07
*** ssj71 has quit IRC00:12
*** grejppi has quit IRC00:15
*** Yruama_Lairba has joined #lv200:19
*** grejppi has joined #lv200:31
*** rgareus has quit IRC02:48
*** rgareus has joined #lv203:14
*** trebmuh has quit IRC03:22
*** Yruama_Lairba has quit IRC03:50
*** edogawa has joined #lv210:27
*** Yruama_Lairba has joined #lv212:23
*** trebmuh has joined #lv212:27
*** edogawa has quit IRC15:06
*** rncbc has joined #lv215:08
*** oofus has joined #lv215:54
*** jcelerier has joined #lv216:59
jcelerierhello :)16:59
jcelerierI am trying to grasp the lv2 worker extension (from the host side)17:00
jcelerierI've looked at the jalv code, and it just saves the lv2_worker_interface in the global context of jalv since there is a single plug-in loaded17:00
jcelerierbut I don't understand how, in the worker schedule function, one is supposed to know from which lv2_worker_interface the "work" function should be called17:01
jceleriersince (if I understood correctly) the worker schedul is a host-wide feature with a single instance, and the interface is a per-plugin instance17:02
jcelerierand please don't tell me that I should just set some "current_worker_iface" field prior calling for some processing from the plug-in17:03
rgareusjcelerier: your host  provides the  LV2_Worker_Schedule  feature to the plugin..  that struct has a   ->handle   which the host can set.17:21
rgareusjcelerier: the plugin calls   schedule_work (that_handle)   and the host can resolve this to the current instance17:22
rgareuse.g. the C++ class that represents the plugin in your host17:22
jcelerierrgareus: that's what I feared :( ("the current instance")17:22
rgareuswhat's the issue with that?17:23
rgareusit does not even need to be the plugin instance17:23
rgareusbut the worker instance17:24
jcelerierthat's very bug prone, you have to take more care with threading, etc...17:25
rgareusno it isn't the LV2 specs are very precise about threading17:25
jcelerier& I would assume that the worker instance would be per-plugin that has the "worker" feature, so generally stored in the same struct or something like this17:25
rgareusthe worker is self contained17:26
jcelerier...yes, that does not remove the human error factor :p17:26
rgareus?17:26
rgareusyou create a new worker instance.  and pass a pointer to that instance as handle.17:26
jcelerierthe spec could be as precise as possible, it doesn't prevent humans from not following the spec17:27
rgareusthe same is true for the plugin itself.  if an audio plugin  does something stupid in  run()   same thing17:27
jcelerierthat's why most people prefer languages where it's hard to shoot yourself in the foot17:27
rgareussadly most of those languages are neither efficient not realtime safe.17:28
rgareusrust may count. or lua maybe.  but other than that options apart from C, C++ and asm are slim if noexistent17:29
rgareusjcelerier: http://pastebin.com/Gr3kx5Vt is some code that I've recently used in a LV2 host17:35
rgareusC++ in this case17:35
rgareusit doesn't include the ringbuffer.17:37
rgareusardour has similar code as well: https://github.com/Ardour/ardour/blob/master/libs/ardour/worker.cc17:38
rgareus"most people prefer languages where it's hard to shoot yourself in the foot" -- I wonder where that leaves the French :)17:46
jcelerierrgareus: sorry, had to go out quickly18:41
jcelerierfrench shoots arrows at girl's hearths, of course18:42
jcelerierthanks for the code snippets18:42
jcelerierare there many french people here ?18:43
rgareusje ne sais pas18:48
*** rncbc has quit IRC18:51
jcelerieroki18:52
*** unclechu has quit IRC19:40
*** frinknet_ has quit IRC19:59
*** jcelerier has quit IRC20:20
*** jcelerier has joined #lv220:39
jcelerierthere's something dubious either in the docs or in jalv21:01
jcelerierthe docs says " The instance should cast this data pointer to const LV2_Options_Option* and scan the array for any options of interest "21:02
jcelerierbut here, in jalv, it does pass a LV2_Options_Option*: "https://github.com/x42/jalv/blob/c3aa280b83c3ebf70192eb30d3e66efc0539ce37/src/jalv.c#L1422"21:02
jcelerier**21:02
jcelerieror in the actual source code at line 1089 : http://git.drobilla.net/cgit.cgi/jalv.git/tree/src/jalv.c21:03
rgareusbest use  upstream http://git.drobilla.net/cgit.cgi/jalv.git/21:03
rgareushah21:03
jcelerieryeah, I hadn't noticed this wasn't upstream21:04
rgareuswell options_feature.data = &options;21:04
rgareuslooks fine to me21:05
jceleriershouldn't it be &options[0] ?21:05
rgareusthat'd be a pointer to the first element.21:06
jcelerierwhich would be of type LV2_Options_Option21:06
jcelerier*21:06
rgareuswell in jalv's case it's on the stack21:06
jcelerierhere it's of type LV2_Options_Option**21:06
rgareusin a multi-plugin host, you may want to malloc it21:06
rgareusjcelerier: did you get the worker working?21:07
jcelerierI'm working on it :p21:10
*** oofus has quit IRC21:32
trebmuhjcelerier, y'en a un au moins :)22:11
ColaEuphoriaフランス語だろう?22:12
trebmuhColaEuphoria, yes I am :)22:13
*** jcelerier has quit IRC22:15
*** rncbc has joined #lv222:17
*** edogawa has joined #lv222:28
*** jcelerier has joined #lv222:31
*** rncbc has quit IRC23:06
*** dsheeler has quit IRC23:37
*** edogawa has quit IRC23:50

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