| *** falktx has joined #lv2 | 01:44 | |
| *** zth has joined #lv2 | 05:34 | |
| *** zth has quit IRC | 06:47 | |
| *** edogawa has joined #lv2 | 07:59 | |
| falktx | hmm, error when building lv2 with -Wl,-no-undefined | 08:01 |
|---|---|---|
| falktx | [42/59] cshlib: build/plugins/eg03-metro.lv2/metro.c.3.o -> build/plugins/eg03-metro.lv2/eg-metro.lv2/metro.so | 08:01 |
| falktx | plugins/eg03-metro.lv2/metro.c.3.o: In function `instantiate': | 08:01 |
| falktx | metro.c:(.text+0x870): undefined reference to `sin' | 08:01 |
| *** edogawa has quit IRC | 08:24 | |
| *** rachidori has joined #lv2 | 08:45 | |
| *** edogawa has joined #lv2 | 08:55 | |
| *** edogawa has quit IRC | 09:29 | |
| *** edogawa has joined #lv2 | 09:32 | |
| *** edogawa has quit IRC | 09:34 | |
| *** edogawa has joined #lv2 | 09:39 | |
| *** HarryHaaren has joined #lv2 | 09:40 | |
| *** rachidori has quit IRC | 10:27 | |
| *** rachidori has joined #lv2 | 10:32 | |
| *** edogawa has quit IRC | 10:41 | |
| *** zth has joined #lv2 | 11:29 | |
| *** bgribble has quit IRC | 11:30 | |
| *** rncbc_jolla has joined #lv2 | 11:46 | |
| *** NickSB2 has quit IRC | 11:50 | |
| *** falktx has quit IRC | 11:55 | |
| *** falktx has joined #lv2 | 11:57 | |
| *** rncbc_jolla has quit IRC | 12:50 | |
| *** ricardocrudo has joined #lv2 | 13:06 | |
| *** zth has quit IRC | 13:15 | |
| *** ricardocrudo has quit IRC | 13:17 | |
| *** ricardocrudo has joined #lv2 | 13:18 | |
| *** rncbc has joined #lv2 | 13:34 | |
| *** Anchakor has joined #lv2 | 13:59 | |
| *** falktx has quit IRC | 14:47 | |
| *** magnetophon has joined #lv2 | 15:24 | |
| *** rncbc is now known as rncbc|AFK | 16:53 | |
| *** rncbc|AFK has quit IRC | 16:55 | |
| *** rachidori has quit IRC | 16:58 | |
| *** rachidori has joined #lv2 | 17:01 | |
| *** NickSB_ has joined #lv2 | 17:56 | |
| *** NickSB_ has quit IRC | 18:08 | |
| *** zth has joined #lv2 | 18:44 | |
| HarryHaaren | rgareus, have a minute? I'm confused a little while writing Lv2 Atoms, its probably a small thing, but I don't get it | 19:29 |
| HarryHaaren | this is the code, and the output from jalv -d http://pastebin.com/0DURWDZf | 19:29 |
| HarryHaaren | the [ and ] need to be around the rest: but I don't know how to make that happen in the LV2 atom forge code :/ | 19:30 |
| rgareus | HarryHaaren: hang on sec | 19:30 |
| HarryHaaren | sure | 19:31 |
| rgareus | HarryHaaren: that is in the GUI, right? | 19:31 |
| HarryHaaren | indeed yes | 19:31 |
| * HarryHaaren notes this is to support a routing matrix presented in a (custom) UI | 19:32 | |
| rgareus | HarryHaaren: it looks fine. | 19:32 |
| HarryHaaren | hmm, ok. I don't fully understand why I have a "frame" and a "blank" | 19:32 |
| HarryHaaren | I didn't figure out how to write the frame without the blank, but I think one of the two is redundant? | 19:32 |
| rgareus | HarryHaaren: the 'frame' is just an internal representation pointer here (for later lv2_atom_forge_pop() | 19:33 |
| HarryHaaren | ok, so the "blank" is the [ and ]? | 19:34 |
| HarryHaaren | writing the data is fine: but decoding it in the DSP side is where things aren't going as I expected | 19:34 |
| rgareus | HarryHaaren: yes, I think drobilla changed that in LV1.8 lv2_atom_forge_blank() should be deprecated | 19:34 |
| rgareus | it confused a lot of people | 19:35 |
| HarryHaaren | yeah, objects == blank right? | 19:35 |
| rgareus | or maybe it's only SVN after LV1.8 | 19:35 |
| rgareus | HarryHaaren: yes blank is the [] | 19:35 |
| HarryHaaren | something yeah. I'll look into decoding a bit, then maybe ping you in a while if I can't figure it out? | 19:36 |
| rgareus | HarryHaaren: and that's a "generic object" | 19:36 |
| HarryHaaren | sure :) | 19:36 |
| HarryHaaren | everything is generic in Lv2 land :D | 19:36 |
| rgareus | HarryHaaren: You're on the right track | 19:36 |
| * HarryHaaren goes checking code | 19:36 | |
| *** falktx has joined #lv2 | 19:39 | |
| HarryHaaren | rgareus, got it, thanks: i wasn't casting to lv2 object in checking the event type: this (from your lv2/book example code) http://pastebin.com/cHKxa4yd | 19:41 |
| HarryHaaren | cheers! | 19:41 |
| rgareus | HarryHaaren: usual case of: all you have to do to find the problem yourself is explain it to someone. | 19:45 |
| falktx | quite a few things get auto-solved like that :) | 19:46 |
| HarryHaaren | heh yeah pretty much. Still though, a listening ear is needed, thanks for that! | 19:48 |
| * HarryHaaren high-fives falktx , how's things? | 19:48 | |
| falktx | good, thanks | 19:51 |
| falktx | doing some latency stuff in Carla now. either I'm wrong or plugins are :S | 19:51 |
| HarryHaaren | haha, don't use my plugins anyway :D | 19:53 |
| falktx | afaik latency in plugins is done via output control port designated for latency | 19:55 |
| falktx | the value is integer, >= 0 | 19:55 |
| falktx | the latency means the # of samples I need to "delay" the input if I mix it with something else | 19:56 |
| falktx | right^ ? | 19:56 |
| falktx | (I currenly use this only for dry/wet) | 19:57 |
| HarryHaaren | falktx, i think you need "anti-latency" to get it right, so you should A) delay the audio to all *other* tracks of audio | 19:58 |
| HarryHaaren | or B) "forward" the audio into the track with the latency-causing plugin | 19:58 |
| falktx | HarryHaaren: yes, but since this is carla, a modular host, I don't have tracks | 19:58 |
| falktx | I just need to adjust latency for dry/wet and jack-latency API | 19:58 |
| HarryHaaren | right, so you get to have more fun than the rest of us :D | 19:59 |
| falktx | well, I would, if this was working | 19:59 |
| magnetophon | HarryHaaren: I made a nice compressor/expander in faust that you might wanna work you gui magic on: https://github.com/magnetophon/qompander | 19:59 |
| HarryHaaren | i don't understand what dry/wet has to do with latency | 19:59 |
| magnetophon | HarryHaaren: oh, and hi! | 19:59 |
| magnetophon | :) | 19:59 |
| HarryHaaren | magnetophon, checking it out, thanks for the link! ( hoi! ) | 19:59 |
| falktx | HarryHaaren: the output signal is delayed compared to input | 19:59 |
| falktx | HarryHaaren: so I have to delay the input as well for dry/wet mixing | 19:59 |
| magnetophon | HarryHaaren: It's a translation of a pd-external into faust. | 20:00 |
| falktx | HarryHaaren: "delay input" = store the last x latency samples in a buffer, in case that wasn't clear :) | 20:00 |
| *** zth has quit IRC | 20:02 | |
| HarryHaaren | magnetophon, does it cause much latency? | 20:02 |
| HarryHaaren | falktx, yeah i get that part :) I don't see how the dry/wet thing changes things that's all | 20:03 |
| magnetophon | HarryHaaren: none afaik. haven't formally tested though | 20:03 |
| falktx | HarryHaaren: well, it's not working as it should :P | 20:03 |
| HarryHaaren | hah k, well good luck anyway :D | 20:03 |
| * falktx needs to find a good known working latency plugin | 20:03 | |
| falktx | lv2 needs an example plugin for this! | 20:03 |
| HarryHaaren | artificial-latency probably gets it right, falktx | 20:03 |
| falktx | HarryHaaren: I think that one is broken, I can never get it to work | 20:04 |
| HarryHaaren | ah ok... i havent tried it actually, so no experience here | 20:04 |
| falktx | it's from swh-plugins, right? | 20:04 |
| HarryHaaren | magnetophon, generally compression / limiting / expanding has a "look-ahead" of X ms, which is how it reacts (amplifiying or attenuating the signal without causing loads of distortion) | 20:05 |
| magnetophon | HarryHaaren: actually I can answer that better: No it does not: 0 samples. It does mess with the phase of the signal though, so you can't easily use it for paralel compression | 20:05 |
| HarryHaaren | ah ok.. strange: and very interesting. I'll certainly check it out | 20:05 |
| Anchakor_ | falktx: well you are not doing any internal routing in carla are you? then you are just translating APIs: jack-latency -> lv2-latency -> jack-latency | 20:06 |
| rgareus | falktx: https://github.com/x42/nodelay.lv2 | 20:06 |
| magnetophon | HarryHaaren: it's all explained in a lot of detail here: http://www.katjaas.nl/compander/compander.html | 20:06 |
| HarryHaaren | i checked that yup, reading now | 20:06 |
| falktx | Anchakor_: not even that yet. I'm only doing audio input -> run -> mix input/output for dry/wet -> out | 20:07 |
| Anchakor_ | yeah so it is now just jack-latency-in -> jack-latency-out | 20:08 |
| falktx | Anchakor_: I don't use the jack-latency api yet, none of it | 20:08 |
| magnetophon | HarryHaaren: I'm also working on a translation of my voice synth into faust: https://github.com/magnetophon/VoiceOfFaust | 20:09 |
| falktx | rgareus: that seems useful, and readable code too, thanks! | 20:09 |
| Anchakor_ | I dunno what you are doing then :) | 20:09 |
| falktx | rgareus: I don't think swh-plugs have readable code... | 20:09 |
| Anchakor_ | anyway the ir.lv2 plugin has latency reporting support | 20:10 |
| falktx | yes, and that one seems "broken" too | 20:10 |
| Anchakor_ | (versions 1.3.x) | 20:10 |
| rgareus | falktx: yes swh uses some fancy homemade xml spec from which the actual code is generated. | 20:10 |
| rgareus | falktx: for testing I used 2 channels. one has the nodelay.lv2 , the other a phase inverter. | 20:12 |
| rgareus | falktx: if the LV2 hosts compensates the latency correctly, the output when mixing the channels is 0 | 20:12 |
| falktx | that is something I have to try when I get into jack-latency api | 20:12 |
| falktx | last time I tried it I couldn't make sense of it. but that was perhaps because my latency code was broken | 20:13 |
| rgareus | falktx: so far this is for plugins only (not jack related) | 20:13 |
| rgareus | falktx: the plugin-host - in my case ardour - has additional delaylines to sync things up in the case of busses or effect chains.. | 20:14 |
| falktx | dealing with jack-latency will probably not be very fun... | 20:14 |
| rgareus | ... and special logic to read-ahead on tracks | 20:14 |
| rgareus | falktx: jack-latecy API itself is simple, just 2 numbers. | 20:15 |
| rgareus | doing something with those numbers is the hard part. | 20:15 |
| falktx | yeah | 20:15 |
| falktx | I imagine I'll have to do some extra compensation to ensure 2 plugin-clients output that get fed into a new plugin are aligned | 20:18 |
| Anchakor_ | but you are not doing any complex routing in carla so you will be spared of most of the horros | 20:18 |
| Anchakor_ | horrors* | 20:18 |
| Anchakor_ | ah you can do that in carla? then you will not be spared I guess :) | 20:19 |
| falktx | it can probably be done at the engine level, without the plugin knowing, ...hopefully | 20:20 |
| Anchakor_ | well there is no other way is there, you will have to set up buffering to sync the 2 plugins outputs | 20:22 |
| falktx | damn latency, it shouldn't exist! | 20:22 |
| Anchakor_ | plugins just report their latency, host does the work :) | 20:22 |
| Anchakor_ | would be neat if there was some C library wrapping the host stuff to allow arbitrary directed-acyclic graph data flows with proper latency handling :) | 20:24 |
| falktx | carla is close, the exposed API is C compatible | 20:25 |
| Anchakor_ | I thought you were just going for straight buses and leaving the 2 plugins going into 1 plugin mixing for jack | 20:26 |
| Anchakor_ | that would be much simpler | 20:26 |
| falktx | that one plugin that receives the output from the 2 plugins needs to have audio aligned | 20:27 |
| falktx | jack-latency api also only reports latency values, it doesn't do any work :P | 20:27 |
| Anchakor_ | well jack has to do that work, because jack clients recieve single input buffer no matter how many connections are routed into it | 20:28 |
| falktx | hmm right | 20:29 |
| Anchakor_ | (it = port) | 20:29 |
| falktx | if that's true, then all I'll have to do is report the plugin latency value to jack | 20:29 |
| Anchakor_ | afaik thats how qtractor does it - just simple plugin pipes, for mixing use jack and make more tracks/buses | 20:30 |
| Anchakor_ | (though qtractor GUI makes this workflow quite tedious) | 20:31 |
| Anchakor_ | yeah, just report input jack-lacency + sum of the latencies of the plugins in the pipeline | 20:31 |
| falktx | nice | 20:32 |
| falktx | the less work the better! | 20:32 |
| Anchakor_ | as long as it is a pipline - you are not doing any mixing with other pipelines (aka its not a graph) you are fine | 20:32 |
| Anchakor_ | though dry/wet mixing... that actually is a problem | 20:34 |
| Anchakor_ | maybe you could get lazy and outsource even that to jack, paying a price of more littered jack connection graph | 20:35 |
| falktx | not possible | 20:35 |
| falktx | this is not hard to do anyway, I have 90% of the work done already | 20:36 |
| Anchakor_ | I think it would be possible - for each plugin pipeline you would have an extra ghost pipeline with some internal simple mixer plugin with inputs: the clean input + the real pipeline output | 20:38 |
| Anchakor_ | all jack IO so jack does the latency compensation | 20:39 |
| *** NickSB2 has joined #lv2 | 20:41 | |
| Anchakor_ | actually I think the internal mixer plugin would have to do the compensation anyway so never mind me :) | 20:42 |
| falktx | that's overcomplicating things | 20:44 |
| falktx | tomorrow I'll try to sort this latency thing 100% | 20:44 |
| rgareus | jack does *not* delay the input at the end. | 20:49 |
| rgareus | jack only passes around numbers | 20:49 |
| *** edogawa has joined #lv2 | 20:49 | |
| falktx | rgareus: what if 2 outputs have different latencies, connected to 1 input port? | 20:51 |
| rgareus | falktx: that's why jack has a min and max latency for each port in every direction | 20:51 |
| falktx | rgareus: but the client of that 1 input port has no way to compensate latencies | 20:52 |
| rgareus | falktx: jack will set the 'min' to the the smaller one of the two ports and 'max' to the larger one | 20:52 |
| falktx | the 2 outs signal come joined | 20:52 |
| rgareus | falktx: correct | 20:52 |
| falktx | anyway, talk later | 20:52 |
| falktx | really need to go, bbl | 20:52 |
| *** falktx has quit IRC | 20:52 | |
| rgareus | falktx: if the user makes odd jack connections, there's nothing the app can do. | 20:52 |
| Anchakor_ | oh thats bad | 20:52 |
| Anchakor_ | anyway one of things in which lv2 can be proven as much better approach | 20:53 |
| rgareus | Anchakor_: why? it's not really up to jack to tell you what is "right". | 20:53 |
| rgareus | jack is a mechanism - not policy | 20:53 |
| rgareus | Anchakor_: lv2 is just the same. it's up to the host to get this right. | 20:54 |
| Anchakor_ | ok, you have option to set up mixer jack clients which deal with it | 20:54 |
| rgareus | Anchakor_: just as with jack it's up to the client | 20:54 |
| Anchakor_ | I take that back that it's bad | 20:54 |
| Anchakor_ | it's just bad for common users who want good audio renders without unnecessary delay without complicated setup :) | 20:55 |
| rgareus | Anchakor_: jack tells the clients about connections and sends a callback to the clients | 20:55 |
| rgareus | when the port latency changes | 20:55 |
| rgareus | Anchakor_: the clients should handle it, update its port latency and the situation where min != max is resolved | 20:56 |
| Anchakor_ | when min != max the client can't do anything as the signals were already mixed | 20:57 |
| rgareus | Anchakor_: it's the client that does set the value in the first place | 20:57 |
| Anchakor_ | I don't think so, you get it by jack_port_get_latency_range() and you can't do anything with it | 20:58 |
| rgareus | it's not jackd that sets these numbers, it's every jack-client. | 20:59 |
| Anchakor_ | the jack client doesn't have access to the output ports connected to its input port does it? | 20:59 |
| rgareus | but if the client does not have an explict jack_set_port_latency function a default implementation is used | 20:59 |
| rgareus | and that default implementation does the min/max thing | 20:59 |
| *** timbyr has quit IRC | 20:59 | |
| rgareus | Anchakor_: yes it does have access to it | 21:00 |
| rgareus | Anchakor_: jack calls all clients in the flow of signal direction. | 21:00 |
| rgareus | Anchakor_: twice, first upstream, then downstream | 21:00 |
| rgareus | that's all jackd does. | 21:00 |
| rgareus | the port-latencies are set by every jack application, only that most developers don't care and simply use the default | 21:01 |
| *** timbyr has joined #lv2 | 21:01 | |
| rgareus | function that only does the min/max thing | 21:01 |
| Anchakor_ | so in my jack client I can for all input ports enumerate their connections and then set up the latency compensation, mixing the values of my input ports myself? | 21:01 |
| rgareus | Anchakor_: correct | 21:01 |
| Anchakor_ | s/enumerate/interate/ | 21:02 |
| rgareus | Anchakor_: jackd calls the latency_callback for every port in your app | 21:02 |
| Anchakor_ | ah ok, thought you were just given the input buffers and deal with it | 21:02 |
| rgareus | Anchakor_: that, too :) | 21:02 |
| rgareus | https://jackaudio.github.io/api/group__ClientCallbacks.html#ga70a38fb1e74c5e9df9f1305c695c58bf | 21:03 |
| Anchakor_ | so basically for mixer jack app I have responsibility to correctly latency compensate the mixing of all its input ports and then the mixing app itself | 21:04 |
| rgareus | Anchakor_: yes | 21:04 |
| rgareus | Anchakor_: the API doc makes it clear that the 'default' function is only good for certain cases. | 21:05 |
| Anchakor_ | is there some default implemenation for this? :) | 21:05 |
| rgareus | Anchakor_: there is a default somewhere in libjack | 21:07 |
| Anchakor_ | anyway based on what you said the first of the 4 items in the list "have only input ports" is wrong no? | 21:08 |
| Anchakor_ | even a plugin with 1 input can recieve multiple signals with various latencies into it | 21:08 |
| Anchakor_ | so it needs to compensate this and mix them properly, no? | 21:09 |
| Anchakor_ | s/plugin/client/ | 21:09 |
| rgareus | Anchakor_: but that's not up to the jack-client that has the input | 21:09 |
| rgareus | Anchakor_: if they're already mixed. then it's too late | 21:09 |
| Anchakor_ | well thats what I was talking about | 21:09 |
| rgareus | Anchakor_: the apps before that will see that they go into a common place. and one of them will need to delay itself | 21:10 |
| Anchakor_ | thats why if you just have a value and range what the latency might be in, then you are done, it's too late | 21:10 |
| Anchakor_ | rgareus: who then does the delaying? | 21:10 |
| rgareus | Anchakor_: the app with the shorter latency | 21:10 |
| Anchakor_ | I thought in that the jack server handles this | 21:11 |
| rgareus | Anchakor_: then when it added a delayline to itself, it updates its port latency.. | 21:11 |
| rgareus | Anchakor_: jackd does not do anything | 21:11 |
| rgareus | Anchakor_: it passes around numbers | 21:11 |
| rgareus | or memory blocks | 21:11 |
| rgareus | and it can mix | 21:12 |
| rgareus | and keep track of connections | 21:12 |
| Anchakor_ | ok, so tell me, hypothetically I am writing 3 clients A, B, C, each introducing latency 10ms, 20ms and 30ms respectively | 21:12 |
| rgareus | but that's basically it - apart from hardware I/O | 21:12 |
| Anchakor_ | A and B each have 1 output port and are connected to a single input port of client C | 21:13 |
| rgareus | Anchakor_: too bad, jackaudio.org is down at the moment | 21:13 |
| Anchakor_ | so on that input port of C the latency can be in range 10..20 | 21:13 |
| rgareus | Anchakor_: there a nice picture there | 21:13 |
| Anchakor_ | google cache? | 21:14 |
| Anchakor_ | who then compensates for the latency? A, B, C or jack server? | 21:14 |
| rgareus | Anchakor_: the server does nothin. just pass around information. | 21:15 |
| rgareus | http://manual.ardour.org/ardour/manual/html/diagrams/jack-latency-excerpt.png is part of it | 21:15 |
| rgareus | the orignal image shows a 2nd chain and explains algorithms | 21:15 |
| * rgareus searches google images by image similarity | 21:16 | |
| Anchakor_ | if jack server just passes around information then probably only C has information to do the compensation and mixing | 21:18 |
| rgareus | Anchakor_: every client could | 21:18 |
| Anchakor_ | unless there is global connection graph knowledge, but then it would also not make much sense as C is the one with the input port | 21:19 |
| rgareus | Anchakor_: jack calls every client and provides the requires graph knowledge for every port | 21:19 |
| Anchakor_ | there could be other stuff done with the mixing - like deciding what kind of mixing should be done | 21:19 |
| *** falktx has joined #lv2 | 21:20 | |
| Anchakor_ | so am I right that the plugins with the input ports have the responsibility to do the proper latency compensation and mixing of their input port? | 21:21 |
| Anchakor_ | (each of their plugin ports) | 21:21 |
| falktx | what have I missed? | 21:21 |
| rgareus | Anchakor_: way-back machine http://jackaudio.org/files/jack-latency.png | 21:21 |
| Anchakor_ | falktx: it's confusing, seems like jack doesn't do jack shit ;) | 21:22 |
| rgareus | Anchakor_: https://web.archive.org/web/20120411032518/http://jackaudio.org/files/jack-latency.png | 21:22 |
| falktx | that graph is too simplistic | 21:22 |
| rgareus | Anchakor_: jack cannot do anything about it | 21:22 |
| falktx | I want to know about this: | 21:23 |
| falktx | client A has 1 output port, no latency | 21:23 |
| Anchakor_ | yeah that graph doesn't deal with the case I talked about | 21:23 |
| rgareus | Anchakor_: Only the client knows what the right thing to do is. | 21:23 |
| falktx | client B has 1 output port, 612 frames latency | 21:23 |
| Anchakor_ | "hypothetically I am writing 3 clients A, B, C, each introducing latency 10ms, 20ms and 30ms respectively" | 21:23 |
| falktx | client C has 1 input port, no latency | 21:23 |
| Anchakor_ | "A and B each have 1 output port and are connected to a single input port of client C" | 21:23 |
| falktx | client A and B connect to C | 21:23 |
| rgareus | Anchakor_: same thing really. | 21:23 |
| Anchakor_ | yeah, same thing really | 21:23 |
| falktx | since the audio sent to C is mixed/joined by jack, it can't compensate latencies | 21:24 |
| rgareus | Anchakor_: A gets told what that it feeds C and the downstrea latency from C onwards. B gets the same | 21:24 |
| Anchakor_ | we were discussing what client is responsible for the mixing and latency compensation of the outputs connected to the input port of C | 21:24 |
| rgareus | Anchakor_: then A realizes it's too early | 21:24 |
| rgareus | Anchakor_: then A delays its signal 10ms more | 21:24 |
| Anchakor_ | that is a pretty strange design | 21:25 |
| rgareus | Anchakor_: I don't think it can be designed any other way | 21:26 |
| rgareus | Anchakor_: jack cannot know what the right way to delay the signal is | 21:26 |
| falktx | well, it could at least make a way to compensate for clients that don't implement latency | 21:26 |
| Anchakor_ | why doesn't the client which has the input port do the mixing and compensation? | 21:27 |
| rgareus | Anchakor_: because it's the only component in the system that know how to do it right for the case at hand | 21:27 |
| rgareus | same with plugin bypass. | 21:27 |
| Anchakor_ | why are you agreeing with me when you just described that it's done differently? ;) | 21:28 |
| rgareus | depending what DSP the client does. the correct way to bypass or delay the signal can be very different | 21:28 |
| Anchakor_ | ok, so it is done this way to enable auto-bypassing | 21:29 |
| Anchakor_ | that makes sense | 21:29 |
| rgareus | Anchakor_: I don't follow. | 21:30 |
| rgareus | Anchakor_: the 'plugin-bypass' was a reference to plugin-hosts that do the bypassing (which is wrong). | 21:31 |
| rgareus | Anchakor_: 'bypass' should be a function of every plugin. | 21:31 |
| rgareus | just like latency-compenstion is a function of every jack-clients | 21:31 |
| Anchakor_ | I thought you said that jack is designed so the output-port-clients do the delaying so the input-port-clients could be bypassed | 21:32 |
| Anchakor_ | because otherwise I would make it (based on intuition) that the input-port-clients are responsible for the mixing and latency compensation | 21:33 |
| rgareus | Anchakor_: it does both ways. | 21:33 |
| falktx | rgareus: did we got any consensus about bypass on lv2? | 21:33 |
| rgareus | Anchakor_: there are separate values for input and output latency per port | 21:33 |
| rgareus | falktx: almost. So far we agree we need an API for it | 21:34 |
| falktx | rgareus: would a control input port suffice? | 21:35 |
| rgareus | falktx: that was my first idea as well. | 21:35 |
| falktx | designated port, host sets it to 1 when wants bypass | 21:35 |
| rgareus | falktx: and a reply port. bypass completed | 21:35 |
| falktx | hm? | 21:36 |
| Anchakor_ | rgareus: btw that image you linked seems to deal with measuring latency, not with reporting and dealing with it | 21:36 |
| rgareus | falktx: the latter is reason why an Atom port would be more suitable | 21:36 |
| falktx | rgareus: why do we need bypass complete status? | 21:36 |
| rgareus | falktx: to allow safe clickless removal and insertion | 21:36 |
| falktx | hm, I wouldn't call that bypass then | 21:37 |
| falktx | more like "safe-cleanup" | 21:37 |
| rgareus | falktx: it's the sae API really. | 21:37 |
| falktx | sure, but calling it bypass is a bit misleading | 21:37 |
| rgareus | falktx: if we now add a bypass port, and then in 1 year a second API that does the same and more... | 21:37 |
| rgareus | falktx: then we'll invoke the wrath of many | 21:38 |
| falktx | rgareus: so if I would remove a plugin that has this "bypass completetion", I would have to wait for it to finish, right? | 21:38 |
| rgareus | falktx: the idea is: add plugin in bypassed state, make connections, unbypass plugin. | 21:38 |
| rgareus | falktx: and for removal: bypass plugin, wait until it's bypassed , remove it | 21:38 |
| falktx | rgareus: what if the plugin takes too long? | 21:39 |
| rgareus | falktx: too long for what? | 21:39 |
| falktx | to complete bypass | 21:39 |
| rgareus | falktx: you just wait. | 21:39 |
| falktx | like 10x 512 buffer cycles | 21:39 |
| rgareus | falktx: if that's what it takes, then yes | 21:39 |
| falktx | what if it doesn't send bypass complete? :P | 21:40 |
| rgareus | falktx: then the plugin is broken | 21:40 |
| rgareus | falktx: if a plugin says it supports "bypassFeature" it should do that | 21:40 |
| falktx | maybe it needs 100 seconds | 21:40 |
| rgareus | unlikly | 21:41 |
| rgareus | falktx: you could add a 'force remove - beware of clicks' options | 21:41 |
| falktx | don't underestimate how broken plugins can be ;) | 21:42 |
| rgareus | to provide context: http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2014-May/001397.html | 21:42 |
| rgareus | falktx: just don't use those broken plugins | 21:42 |
| falktx | rgareus: so this would be like a reverb effect waiting for the "tail" to stop ? | 21:42 |
| rgareus | falktx: the reverb would not wait but fade out | 21:43 |
| rgareus | falktx: same with an amp. that would just fade to 0dB | 21:43 |
| rgareus | fade-out != x-fade with original (the latter would introduce comb-filtering) | 21:44 |
| falktx | hmm, but that can be done by the host too | 21:44 |
| rgareus | falktx: the host does not know the proper thing to do | 21:44 |
| falktx | fade-out for 1sec | 21:44 |
| rgareus | falktx: a x-fade on some effect with latency will act like a bad eq. | 21:45 |
| rgareus | falktx: fade-out in context of a reverb only affects the wet signal | 21:45 |
| falktx | not x-fade, fade out the output | 21:45 |
| falktx | yes, only to wet signal | 21:45 |
| falktx | plugin remove, fade-out; plugin added, fade-in | 21:46 |
| rgareus | falktx: if the reverb has an internal dry/wet and also a pre-delay. the host cannot do it | 21:46 |
| falktx | oh, if the audio keeps playing it would be a bit tricky | 21:46 |
| *** edogawa has quit IRC | 21:46 | |
| falktx | but carla always has dry/wet if possible | 21:46 |
| falktx | I don't like plugin-side dry/wet | 21:47 |
| rgareus | falktx: that's really hard to do host side. the host has too little info to do this | 21:47 |
| falktx | it only needs to know the input, output and latency | 21:47 |
| falktx | that's what I'm doing in carla right now | 21:48 |
| rgareus | falktx: that works for many cases | 21:48 |
| rgareus | falktx: but for stereo-phasers or cabinet simulation. there should not be a dry bypass to start with | 21:49 |
| falktx | hehe, stereo phasers could have a weird effect, yes | 21:50 |
| falktx | we need an lv2 hint to say "this plugin cannot be used for dry/wet" | 21:51 |
| rgareus | falktx: I think your premise "the host can do everything" is wrong. | 21:53 |
| rgareus | falktx: it's the same with jack + latency. yes there could be delayline in jackd itself to align things... | 21:54 |
| rgareus | .. and yes they'd be right i many cases. | 21:54 |
| rgareus | but no they won't be right in all cases | 21:54 |
| falktx | but it will be broken in most of them | 21:56 |
| rgareus | falktx: then file bug reports or don't use those apps | 21:58 |
| falktx | no, I mean the A + B => C situation | 21:58 |
| falktx | A client has latency, B has not | 21:59 |
| falktx | both connect to C | 21:59 |
| rgareus | falktx: if B does not copensate properly, don't use "B" | 21:59 |
| falktx | B cannot compensate anything | 21:59 |
| falktx | B only outputs | 21:59 |
| rgareus | then it makes no difference | 22:00 |
| rgareus | it does not matter how B aligns at al | 22:00 |
| falktx | ? | 22:00 |
| falktx | it does matter how C gets the input audio | 22:00 |
| falktx | jack does the port mixing internally | 22:01 |
| rgareus | but if B is just a player (and not uses jack-transport) | 22:01 |
| rgareus | then it makes no differnce if it's early relative to A | 22:01 |
| falktx | let's say A and B are synths | 22:02 |
| falktx | no input, just output | 22:02 |
| falktx | but A has output latency | 22:02 |
| rgareus | they have MIDI in puts I suppose | 22:02 |
| falktx | probably yes, I'm just trying to think of the simplest example | 22:03 |
| falktx | A and B are assumed to be in sync | 22:03 |
| falktx | but A has latency > B (which has none) | 22:03 |
| falktx | if both connect to something, the audio will not be in sync because of A's latency | 22:04 |
| rgareus | then 1) either B's input or B's output needs to be delayed. | 22:04 |
| rgareus | or 2) if "A" gets is input from disk (midi-file) it should read-ahead | 22:05 |
| falktx | why can't jack just do the latency compensation in this case? | 22:05 |
| rgareus | falktx: it could, in this case | 22:05 |
| rgareus | falktx: except for the initial delay. | 22:06 |
| rgareus | falktx: the right way here would be to delay the midi-data to B | 22:06 |
| rgareus | falktx: and not the audio output of B | 22:06 |
| rgareus | falktx: jack does not know this. | 22:06 |
| rgareus | falktx: but "B" does | 22:06 |
| falktx | that can get overly complex too soon | 22:07 |
| rgareus | falktx: it's very simple in every client itself | 22:07 |
| falktx | ie, if a extra A2 client is added in the mix with a different latency value | 22:07 |
| rgareus | falktx: it's only complex if jack tried to do this | 22:07 |
| falktx | then A(1) needs to compensate too | 22:07 |
| rgareus | falktx: right | 22:08 |
| falktx | but then, what if they connect to an input port that also has latency? | 22:08 |
| Anchakor_ | so if you have 10 output clients routed into a single input port of some plugin, then all 10 output clients have to find which of them has the highest latency and delay their signals? | 22:09 |
| rgareus | falktx: in that case it makes you confused :) | 22:09 |
| Anchakor_ | seems much easier if the input client did that | 22:09 |
| Anchakor_ | s/plugin/client/ | 22:10 |
| falktx | or jack | 22:10 |
| rgareus | falktx: just look at every individual client only. it does not care where it connects to or how many other clients also feed the same output | 22:10 |
| rgareus | falktx: all everything client needs to know is "how long has it been since the signal arrived at the edge of the jack-graph" | 22:11 |
| falktx | I think this overcomplicates things for regular jack clients | 22:11 |
| rgareus | falktx: and "how long will it take until it hits the outputend" | 22:11 |
| falktx | a simple FX plugin will need to always implement latency | 22:11 |
| falktx | s/plugin/jack app/ | 22:11 |
| rgareus | falktx: it's a simple as possible. without making compromises | 22:11 |
| rgareus | every other implementation would compromise something. | 22:12 |
| Anchakor_ | what would they compromise? | 22:12 |
| rgareus | falktx: qtractor and ardour can compensate by read-ahead for example. | 22:12 |
| falktx | but if the fx output connects to some port that some latency-apps also connect, then this simple fx has to compensate | 22:12 |
| rgareus | falktx: ardour can also write-behind to compensate latency | 22:13 |
| rgareus | non-daw probably can do, too. but I don't know | 22:13 |
| rgareus | in those cases jack adding some delayline would be wrong - because it'd increase the total latency... | 22:13 |
| falktx | afaik this makes 99% of jack fx clients broken right now | 22:14 |
| rgareus | ... when in fact there are better ways | 22:14 |
| rgareus | falktx: probably 95% or so | 22:14 |
| falktx | simple client should NOT have to deal with this | 22:14 |
| rgareus | as side story, that's why I don't use calf-plugins nor carla. they're just toys unsuitable for pro-audio in their current state. | 22:14 |
| rgareus | falktx: a 'simple client' should just use pulsaudio then | 22:15 |
| rgareus | jack is a tool for professional audio. | 22:15 |
| Anchakor_ | rgareus: but proper latency reporting makes read-ahead and write-behind possible | 22:16 |
| rgareus | Anchakor_: yes | 22:16 |
| falktx | so almost all jack-standalone effects are broken right now | 22:16 |
| Anchakor_ | delay lines are inevitable and are fine when reported | 22:16 |
| rgareus | Anchakor_: sadly only the minority of plugins and jack-clients do report their latency correctly or handle this | 22:17 |
| rgareus | even if jack did delay the audio. it'd be broken in 95% of all cases simply because the client does not report it | 22:18 |
| magnetophon | falktx: I'm looking for a multi-platform UI framework for a synth I'm writing. HarryHaaren just recommended DISTRHO, but also said it's not great for plugins whit many parameters. Mine has many dozens of parameters. What are your thoughts? | 22:18 |
| falktx | magnetophon: DPF should be able to handle just fine | 22:18 |
| falktx | magnetophon: too many params is an issue for hosts, not the plugin | 22:18 |
| falktx | hosts just have to deal with it | 22:18 |
| rgareus | magnetophon: dozens of parameters? I think it's Harrys's well beyond the thousands :) | 22:19 |
| falktx | magnetophon: see https://github.com/DISTRHO/DPF, there's some already made plugins with this framework on that README | 22:19 |
| Anchakor_ | rgareus: well jack would only delay it if it was reported | 22:19 |
| HarryHaaren | background info, yes, I have a matrix of dials, which scales *very* badly in terms of control-ports | 22:20 |
| falktx | hm, need to update that, DPF now exports JACK standalones too :) | 22:20 |
| HarryHaaren | even adding 1 new input to the matrix would mean I have to code another 40/50 control ports (including names, default values / ranges etc) | 22:20 |
| HarryHaaren | and I hope to add lots more inputs & outputs :/ | 22:21 |
| falktx | HarryHaaren: macros to the rescue! | 22:21 |
| HarryHaaren | or Lv2:Atom's ;) | 22:21 |
| falktx | we need to automate atoms | 22:21 |
| rgareus | HarryHaaren: it could be a single atom port | 22:22 |
| rgareus | HarryHaaren: that only reports what has changed | 22:22 |
| rgareus | HarryHaaren: rather than n^2 parameters every cycle | 22:22 |
| magnetophon | falktx: which of HarryHaaren's plugins has that many? | 22:22 |
| HarryHaaren | magnetophon, ninja would have a ridiculous amount of ports if they were all control ports | 22:23 |
| falktx | magnetophon: an upcoming one, not release yet afaik | 22:23 |
| HarryHaaren | rgareus, all matrix events now as Atoms, so yes one Atom port, done | 22:23 |
| HarryHaaren | indeed it updates only onChanged(), and not all the time! | 22:24 |
| rgareus | magnetophon: I think fabla has a lot, but Harry will know for sure | 22:24 |
| HarryHaaren | 120 or something | 22:25 |
| HarryHaaren | but hard-coding that in TTL was enough to put me off doing it again :D | 22:25 |
| rgareus | HarryHaaren: only 120? did you simplify it ? | 22:25 |
| rgareus | :) | 22:25 |
| falktx | rgareus: ok, my latency code is officially wrong | 22:26 |
| falktx | tested with nodelay.lv2 | 22:26 |
| falktx | it's doing exactly *nothing* :P | 22:26 |
| HarryHaaren | nope, its 16 pads * 7 controls, with some others like master volume / compression etc. 122, just checked lv2info | 22:27 |
| falktx | weird how I can write quite some code and then it turns out it does nothing! ;) | 22:27 |
| HarryHaaren | if ( false ) { <code> } ?? | 22:27 |
| rgareus | falktx: wait. | 22:27 |
| rgareus | falktx: if your latency code is working. nodelay is not a delay | 22:28 |
| rgareus | falktx: if your latency code is broken. you'll hear a delay | 22:28 |
| falktx | doesn't nodelay do latency? | 22:28 |
| rgareus | falktx: it delays the audio signal by N samples and then tells the host it has N samples delay | 22:28 |
| falktx | that's a proper latency plugin then, right? | 22:29 |
| rgareus | falktx: (the later is a toggle checkbox) | 22:29 |
| rgareus | falktx: It's a tool to test if latency compensation is working | 22:29 |
| falktx | yes, that's exactly what I need it for | 22:30 |
| falktx | now just need to get it working | 22:30 |
| rgareus | (and if you set the 'report latency to host' checkbox to off, it's a delayline with sample-accuracy) | 22:30 |
| falktx | rgareus: btw, how does ardour handle latency changes? afaik the plugin doesn't report the max latency value or does it? | 22:30 |
| falktx | ie, when latency gets bigger, we need a bigger buffer | 22:31 |
| rgareus | falktx: there's a pre-allocated memory pool that can be used. | 22:31 |
| magnetophon | Something I've been wondering: do faust plugins report their latency to the host correctly? | 22:31 |
| rgareus | falktx: IIRC up to 3 seconds or maybe 5 | 22:31 |
| falktx | rgareus: what happens when the plugin wants latency bigger than that? | 22:32 |
| rgareus | magnetophon: not yet. I'm discussing FAUST latency compensation behind the scenese with Yann, Julius and Albert | 22:32 |
| rgareus | falktx: nothing yet. | 22:33 |
| falktx | hmm, nodelay sets latency max value, nice :) | 22:33 |
| rgareus | falktx: I'm working on that in Ardour's latcomp+cc branch. | 22:33 |
| magnetophon | rgareus: that sounds promising. Do they see the value in it too? | 22:33 |
| rgareus | magnetophon: too much actually, JoS events wants to feature sub-sample latency | 22:34 |
| rgareus | magnetophon: some of the faust2XXX tools already create code to announce the latency of the effect | 22:34 |
| magnetophon | rgareus: which ones? | 22:35 |
| falktx | rgareus: do you know if lv2 plugins' latency port are required to set maximum value? | 22:35 |
| rgareus | magnetophon: I think you need declare latency "1"; // samples | 22:36 |
| rgareus | magnetophon: this will then translate into C++ m->declare("latency", "1"); | 22:36 |
| rgareus | magnetophon: and 'faust2au' picks that up already | 22:37 |
| magnetophon | rgareus: hmm, I don't have a mac... | 22:37 |
| magnetophon | rgareus: I understand how sub-sample delay time values can be useful within a dsp algo, but what would it do for latency compensation? | 22:38 |
| Anchakor_ | rgareus: I need answers to this http://i.imgur.com/dsHyi1z.png :) | 22:38 |
| rgareus | falktx: one DSP item can only have _one_ latency at any given time. there's no min/max per effect | 22:38 |
| * magnetophon likes the thorough way of designing @ grame :D | 22:39 | |
| falktx | rgareus: I mean max latency value. nodelay has it. "lv2:maximum 192000 ;" | 22:39 |
| rgareus | Anchakor_: the way to get to the answer is the same. | 22:40 |
| rgareus | falktx: aah. ok. | 22:40 |
| Anchakor_ | rgareus: that means nothing there will be inconsistencies and no compensation | 22:41 |
| rgareus | Anchakor_: unless "client A" or "client B" do something about it | 22:41 |
| Anchakor_ | yeah but they don't know about each other do they | 22:42 |
| Anchakor_ | I gtg, will read backlog | 22:44 |
| rgareus | falktx: it's a lv2:ControlPort lv2:OutputPort (that also lv2:reportsLatency ), no having min/max range would not validate it. and the plugin spec would be incorrect | 22:44 |
| falktx | rgareus: afaik out controls don't need mix/max/default set | 22:45 |
| rgareus | falktx: they don't need default | 22:45 |
| falktx | or min/max | 22:45 |
| falktx | well, they should have, but I don't think it's required in lv2 | 22:45 |
| rgareus | that's probably an oversight in the specs | 22:46 |
| rgareus | I can't think of a reason where one would have an unbound range or a changing range | 22:46 |
| rgareus | s/reason/use-cae/ | 22:47 |
| rgareus | use-case, even. | 22:47 |
| rgareus | there might be one. but I cannot think of one. | 22:47 |
| falktx | calf plugins don't set in/out range I think | 22:47 |
| falktx | err, min/max | 22:47 |
| rgareus | and the reason for that is? | 22:48 |
| falktx | hmm they do set it | 22:48 |
| falktx | I know there's some plugin(s) that do not set it, don't remember which one(s) | 22:49 |
| rgareus | but the range is probably finite. | 22:49 |
| rgareus | just not given in the .ttl | 22:49 |
| falktx | max: +inf; :D | 22:49 |
| rgareus | falktx: that's a valid range | 22:49 |
| rgareus | at least you know what to expect | 22:50 |
| falktx | but how do I represent that in a slider? | 22:50 |
| rgareus | falktx: the same way calf does internally | 22:50 |
| falktx | calf knows what's the "biggest" value | 22:50 |
| falktx | a host does not | 22:50 |
| *** ricardocrudo has quit IRC | 22:53 | |
| *** ricardocrudo has joined #lv2 | 22:54 | |
| *** HarryHaaren has quit IRC | 22:54 | |
| falktx | hmm, my line "if (k < pData->latency)" is being ignored... | 22:56 |
| *** crudo has joined #lv2 | 22:56 | |
| *** crudo is now known as Guest55455 | 22:57 | |
| *** ricardocrudo has quit IRC | 22:59 | |
| *** rachidori has quit IRC | 23:03 | |
| falktx | fffffffffffffffffffffuuuuuuuuuuuuuuuuuuuuu | 23:08 |
| falktx | damn this | 23:08 |
| falktx | I had a line of code from when I didn't handle latency still in there | 23:08 |
| falktx | *after* the latency code, overriding the value | 23:08 |
| falktx | aaaaaarrr | 23:08 |
| falktx | https://github.com/falkTX/Carla/commit/0a2270353930b69f423a9df13dd00d617de5fdd9 lol | 23:12 |
| rgareus | falktx: we've all been there. | 23:14 |
| rgareus | falktx: my recent favorite is https://github.com/Ardour/ardour/commit/bf4819a | 23:14 |
| falktx | heh | 23:16 |
| falktx | now I need to find a way to safely recreate the buffer when latency changes | 23:16 |
| rgareus | falktx: you could re-use the code from nodelay itself (which x-fades) | 23:17 |
| falktx | no xfades, hard-cut in there | 23:17 |
| falktx | changing latency should not be a thing plugins do regularly | 23:18 |
| *** Guest55455 has quit IRC | 23:19 | |
| falktx | rgareus: that plugin is the most useful thing I could ask for in this case, many thanks! | 23:29 |
| rgareus | falktx: y/w | 23:30 |
| rgareus | falktx: i wrote it to test Ardour's latency compensation. | 23:32 |
| rgareus | falktx: if you want to 'see' what's going on https://github.com/x42/sisco.lv2 will come in handy as well | 23:32 |
| falktx | ok, confirmed working with ir.lv2 latency too | 23:42 |
| rgareus | wooha. carla is getting better every day. | 23:43 |
| falktx | I patched ir.lv2 to work with showInterface | 23:43 |
| falktx | now it shows the UI in carla :) | 23:43 |
| falktx | calf stuff too, which was accepted upstream already | 23:44 |
| rgareus | falktx: what's the difference between externalUI and showInterface ? | 23:44 |
| falktx | one of official :P | 23:44 |
| falktx | *is | 23:44 |
| falktx | rgareus: we're using windowTitle option instead of human_name, and using idle | 23:45 |
| rgareus | falktx: nothing else? just differnt URIs? | 23:45 |
| falktx | to be honest I prefer the new official way | 23:45 |
| falktx | it's more extensible | 23:46 |
| rgareus | falktx: is there some doc about that on lv2plug.in? | 23:46 |
| falktx | not updated afaik, but the headers have the info as usual | 23:46 |
| rgareus | LAbot: google lv2 showInterface | 23:46 |
| LAbot | rgareus: Cisco IOS Interface and Hardware Component Command Reference: <http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/command/ir-cr-book/ir-s4.html>; Configuring IS-IS for IP on Cisco Routers - Cisco: <http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13795-is-is-ip-config.html>; Calf Studio Gear - Audio Plugin Pack | Free (2 more messages) | 23:46 |
| falktx | rgareus: I'm thinking of using kx-extui and then implement showInterface for that. jalv will be able to load this unpatched | 23:47 |
| falktx | so will ingen, someday | 23:47 |
| falktx | ie, kx-extui as UI type, but providing showInterface as fallback | 23:47 |
| falktx | if the UI must be external, that is | 23:48 |
| rgareus | falktx: so there is no doc how I could change my plugins, yet. | 23:48 |
| rgareus | falktx: except some example code in calf git | 23:48 |
| falktx | let me upload the patch | 23:48 |
| falktx | rgareus: eg-sampler has showinterface too | 23:49 |
| falktx | but a very simple one | 23:49 |
| falktx | rgareus: http://kxstudio.sourceforge.net/Paste/repo/k5uNI | 23:49 |
| rgareus | falktx: aah just an extension_data method | 23:50 |
| falktx | rgareus: it's very clean. it even re-uses idle | 23:50 |
| falktx | qtractor supports it in latest svn I think | 23:51 |
| falktx | jalv (CLI) supports this too in svn | 23:51 |
| *** NickSB has quit IRC | 23:51 | |
| falktx | rgareus: for ardour this is currently not of much use. but I needed it in carla | 23:52 |
| rgareus | falktx: ardour does not care at this level. it's delegated to libsuil which handles that | 23:52 |
| *** NickSB has joined #lv2 | 23:53 | |
| falktx | libsuil can't handle external uis | 23:53 |
| rgareus | falktx: no, it it takes care of showInterface, does it not? | 23:53 |
| falktx | no | 23:53 |
| falktx | well, not that I know, I don't use suil | 23:54 |
| rgareus | mmh I wonder how ardour displays the eg-sampler GUI then. there isn't any reference to showInterface in A3's lv2 code | 23:54 |
| falktx | eg-sampler has the gtk2 ui by default | 23:55 |
| falktx | showinterface is for hosts that can't do embed | 23:55 |
| rgareus | falktx: I'm pretty sure there are people using calf-git with ardour3. Does calf also fall back to gtk? | 23:55 |
| falktx | it always did, it's gtk2 uis | 23:56 |
| falktx | my issue with calf was instance-data | 23:56 |
| falktx | I don't want to use gtk code in my backend directly, or qt even | 23:56 |
| rgareus | falktx: quite understandable | 23:56 |
| falktx | so now the plugin takes care of showing the UI, which is the important thing | 23:57 |
| falktx | since I don't care about embed, it's all good | 23:57 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
