| *** NickSB2 has joined #lv2 | 01:29 | |
| *** NickSB2 has quit IRC | 02:11 | |
| *** aombk3 has joined #lv2 | 02:48 | |
| *** aombk2 has quit IRC | 02:50 | |
| *** yann-kaelig has quit IRC | 03:09 | |
| *** artfwo has joined #lv2 | 03:52 | |
| *** edogawa has joined #lv2 | 06:40 | |
| *** edogawa has quit IRC | 06:49 | |
| *** ricardocrudo has joined #lv2 | 07:01 | |
| *** edogawa has joined #lv2 | 07:45 | |
| *** sigma6 has joined #lv2 | 07:53 | |
| *** falktx has joined #lv2 | 08:27 | |
| *** rncbc_jolla has joined #lv2 | 11:39 | |
| *** yann-kaelig has joined #lv2 | 11:40 | |
| *** rncbc_jolla has joined #lv2 | 11:40 | |
| *** rncbc_jolla has quit IRC | 11:41 | |
| *** rncbc_jolla has joined #lv2 | 11:41 | |
| *** rncbc_jolla has quit IRC | 11:45 | |
| *** rncbc_jolla has joined #lv2 | 11:46 | |
| *** rncbc_jolla has quit IRC | 11:55 | |
| *** rncbc_jolla has joined #lv2 | 11:55 | |
| *** rncbc_jolla has quit IRC | 11:59 | |
| *** rncbc_jolla has joined #lv2 | 12:48 | |
| *** rncbc_jolla has quit IRC | 12:48 | |
| *** rncbc_jolla has joined #lv2 | 12:49 | |
| *** rncbc_jolla has quit IRC | 12:49 | |
| *** rncbc_jolla has joined #lv2 | 12:50 | |
| *** rncbc_jolla has quit IRC | 12:56 | |
| *** tytel has joined #lv2 | 13:39 | |
| falktx | hmm I don't think doap:shortname is valid for ports | 13:47 |
|---|---|---|
| falktx | there's a reason lv2 made lv2:name, and I think it was because doap:* stuff only applies to projects | 13:48 |
| *** rncbc has joined #lv2 | 13:52 | |
| *** flexus has joined #lv2 | 13:59 | |
| *** tytel has quit IRC | 14:10 | |
| *** ricardocrudo has quit IRC | 15:55 | |
| *** ricardocrudo has joined #lv2 | 15:56 | |
| falktx | good news, drobilla is not dead :) | 16:01 |
| rgareus | falktx: you make it soud like he's barely alive | 16:09 |
| falktx | apparently on vacation | 16:10 |
| *** sigma6 has quit IRC | 16:31 | |
| *** ricardocrudo has quit IRC | 17:02 | |
| ssj71 | falktx: do you have an opinion on whether I should have a bypass control on the rkr ports? | 18:53 |
| rgareus | ssj71: if the bypass is smooth and clickless, then yes. | 18:55 |
| ssj71 | rgareus: naturally | 18:55 |
| rgareus | ssj71: if it's just a hard bypass (like hosts do) then there's no need | 18:55 |
| ssj71 | rgareus: no it would be whatever the original rakarrack does with bypass | 18:55 |
| ssj71 | I guess I should double check that that is clickless. I know it does some cleanup of delay buffers and things like that | 18:56 |
| rgareus | ssj71: at some point (hopefully sooner than later) there'll be a dedicated port-property for bypass ports. | 18:56 |
| ssj71 | rgareus: mostly I just wish I had thought of it before doing 36 of them that I now need to edit :\ | 18:57 |
| rgareus | the idea is to allow for click-free plugin insert/remove: ie host adds plugin in bypassed mode, then unbypasses it. and likewise for remove. and if a plugin has a "bypass" tagged port, the host should use that instead of the host's built in. | 18:57 |
| rgareus | but there is currently no such port-prop. | 18:57 |
| falktx | rgareus: nothing is stopping you from creating that port designation | 18:57 |
| falktx | not a port prop. designation is what we need | 18:58 |
| rgareus | falktx: well it should be on lv2plug.in officially. | 18:58 |
| falktx | make a patch :) | 18:58 |
| falktx | I'll apply it into kxstudio pkgs until drobilla officially merges it | 18:59 |
| rgareus | falktx: drobilla already did (make two). the question is if it should be an atom message (sample-exact) or a port or both | 18:59 |
| rgareus | falktx: he sent the patch out shortly after the LAC. | 19:00 |
| rgareus | it quicksanded with Fons reply. | 19:01 |
| falktx | I'd prefer a designation | 19:01 |
| rgareus | http://pastebin.com/8iCVSy89 | 19:01 |
| falktx | it can be used later as parameter | 19:01 |
| falktx | *later used | 19:01 |
| rgareus | falktx: yes. MUST designate both an input and output control port as lv2:bypass | 19:01 |
| falktx | output? | 19:02 |
| rgareus | falktx: to confirm that the plugin has bypassed | 19:03 |
| rgareus | falktx: depending on the period size and the plugin in question this can take > 1 cycle | 19:04 |
| ssj71 | bleh | 19:04 |
| ssj71 | it makes sense, but seems like a bit of a hassle | 19:04 |
| rgareus | e.g a fade out of 64 samples will still click for all signals > 48000/64 = 750Hz | 19:05 |
| falktx | got it | 19:05 |
| rgareus | uhm less than 750Hz (at 48K) | 19:06 |
| rgareus | anyway. | 19:06 |
| ssj71 | how do you get from bypassed latency to remove latency? is every plugin supposed to implement a timestretch? | 19:07 |
| rgareus | ssj71: you can just do a x-fade. There may be a short comb-filter effect but that's probably lost in transition anyway | 19:09 |
| rgareus | ssj71: it depends what's causing the latency in the first place and what the effect is about | 19:09 |
| ssj71 | rgareus: several of my plugins have some latency. Not so much in the rakarrack ports. One of the infamous plugins has 10 seconds of latency though | 19:11 |
| rgareus | ssj71: whatfor? | 19:11 |
| ssj71 | to see the future of course | 19:12 |
| rgareus | lol | 19:12 |
| rgareus | but 10 seconds... | 19:12 |
| ssj71 | http://ssj71.github.io/infamousPlugins/plugs.html#powerup | 19:12 |
| ssj71 | it allows up to 10 second acceleration period | 19:13 |
| ssj71 | its terribly obnoxious but the only conceivable way to accomplish it (in my little brain at least) | 19:13 |
| rgareus | ssj71: did you try it in Ardour? if you start playback at 00:00:00:00 it should take 10 sec until playback starts rolling | 19:16 |
| ssj71 | yep it does (hence terribly obnoxious) | 19:16 |
| ssj71 | rgareus: I should make a version that only goes to 1s. | 19:16 |
| rgareus | ardour is also somewhat odd in that case. ideally it'd just read-ahead 10 sec. but that's small problem when starting at 0. | 19:17 |
| ssj71 | it would be nice if variable latency were supported. The latency is just a function of the rise time. then if you only have it set to 500ms you'd only have about that much delay | 19:18 |
| ssj71 | now I don't know what to do about bypass though. Maybe I'll have a single port for it and just have the redundancy | 19:20 |
| ssj71 | the host can wait until the output is silent and take out the latency if it chooses | 19:21 |
| ssj71 | :) | 19:21 |
| * ssj71 is lazy | 19:21 | |
| ssj71 | falktx: lets make an extension that has a simple bypass designator for single port bypass operation. | 20:02 |
| falktx | that's just a string | 20:03 |
| ssj71 | yep | 20:03 |
| ssj71 | falktx: so not extension worthy you mean | 20:03 |
| ssj71 | ? | 20:03 |
| falktx | use lv2:bypass then | 20:03 |
| ssj71 | can we have an lv2:inverted_bypass as well for an On button logic? (most stomp pedals light up when bypass is OFF) | 20:04 |
| falktx | the host can do that | 20:04 |
| ssj71 | ok | 20:05 |
| ssj71 | just that I wasn't really thinking about it and now have to go through all 36 plugins ttl again :| | 20:05 |
| ssj71 | I guess I have to add lv2:bypass anyway | 20:05 |
| ssj71 | its going to have to wait until next lunch break. I've gotta get caught up at work | 20:09 |
| rgareus | there's no lv2:bypass aka http://lv2plug.in/ns/lv2core/#bypass is there? | 20:14 |
| rgareus | at least not yet in version 12.4 from 2015-04-07 | 20:14 |
| ssj71 | good point. We don't have control of that domain. kxstudio:bypass it is :) | 20:19 |
| rgareus | please don't do this. it'll be the issue we had with extUI and nedko all over again | 20:19 |
| ssj71 | aw :( | 20:19 |
| rgareus | as soon as the's lv2:bypass there'll be 2 almost equivalent implementations | 20:19 |
| rgareus | I suppose we'll have to wait until drobilla comes back from his holidays | 20:20 |
| ssj71 | rgareus: fair enough | 20:20 |
| rgareus | ssj71: I suppose you can add kxstudio:bypass for the time being if you want to *test* and falktx supports it.. but eventually it'll be duplicate work | 20:21 |
| ssj71 | I would propose a "simple" version that would reqire the host to monitor the audio output to know when it's bypassed if it cares | 20:22 |
| ssj71 | I really think its a mistake to make the plugin to change the latency | 20:22 |
| rgareus | but not many hosts will add support for kxstudio:* uris. probably only Carla. I doubt ingen, jalv (qjtractor, ardour) will do it. | 20:23 |
| ssj71 | sure | 20:23 |
| rgareus | ssj71: what do you think should happen? | 20:23 |
| rgareus | with latency, I mean | 20:23 |
| ssj71 | the host should handle it. Its not going to change at all between plugins | 20:23 |
| rgareus | ssj71: it's only the plugin that knows what to do.. so the plugin needs to do it. | 20:23 |
| ssj71 | on latency change? | 20:24 |
| rgareus | yes | 20:24 |
| rgareus | the host has no clue how to clicklessly get back from latency X to 0. | 20:24 |
| ssj71 | neither do my plugins | 20:24 |
| rgareus | it really depends what the plugin is about. an EQ, a lookahead limiter... | 20:24 |
| rgareus | ssj71: sure the plugin does the DSP. it does know | 20:24 |
| rgareus | if you know the algorithm.. you know. | 20:25 |
| ssj71 | I know of 1 way to "silently" change latency and thats time stretching. | 20:26 |
| ssj71 | once the plugin has no effect but latency I don't see why it matters what the plugin is about | 20:26 |
| rgareus | the main use case is "live use" so it only has to be click-free. time-strech is valid, but for most cases probably overkill | 20:27 |
| rgareus | many EQs have 1-2 samples latency, limiters or compressors can have as well. that 10 sec effect of yours is an odd one out. | 20:28 |
| ssj71 | but why would an EQ's latency removal be different than a limiters? | 20:28 |
| ssj71 | oops sorry. Need patience | 20:29 |
| ssj71 | rgareus: sure. 10s is really extreme | 20:29 |
| ssj71 | but a couple of mine have hundreds of samples latency | 20:30 |
| ssj71 | or full on delay lines | 20:30 |
| ssj71 | I guess though once 100% dry delay lines are 0 latency though | 20:30 |
| rgareus | the host has no clue what the effect does and what the correct way is. a cross-fade may be correct or it may introduce peaks (resonance with delaylines in the effect). | 20:31 |
| ssj71 | I still don't see the need for /plugins/ to implement the 1 to 2 transition in the paste you gave earlier. Once in state 1 it makes no difference what the effect is. The host knows the latency and can remove it if it wants. I agree with the rest though. that all makes sense | 20:32 |
| rgareus | lv2:bypass is intended as option. if an effect supports it great. if not: just hard-switch and possibly "click". | 20:32 |
| ssj71 | sure | 20:32 |
| ssj71 | is a plugin supposed to transition from 0 latency to its target latency when instantiated? | 20:34 |
| ssj71 | I'm not trying to be argumentative. I just genuinely don't understand. It could well be something missing in my DSP education. But I want the gap filled if its there | 20:36 |
| rgareus | ssj71: IIRC when we discussed this the first idea was that the reported latency does not change and the plugin delays the signal. but then every latent plugin would need a delayline | 20:36 |
| ssj71 | that is how my plugins operate. Is that not how its suposed to work? | 20:37 |
| rgareus | ssj71: it's still under discussion. | 20:38 |
| rgareus | to remove a plugin, the latency will have to be reduced to zero before removing it | 20:38 |
| rgareus | so the host will have to do some work (it may simply swap the bypassed plugin with a delayline itself for live use) | 20:39 |
| ssj71 | rgareus: I've been under the assumption that the plugin has a delay line | 20:39 |
| rgareus | but it'd be a lot clener if the plugin could reduce its own latency to zero | 20:39 |
| rgareus | ssj71: right. a variable delayline is not too hard though. so it could be part of a header implementation that comes with lv2 | 20:40 |
| ssj71 | rgareus: I'll have to stew on this a bit. I'm unconvinced its cleaner to push this to the plugin | 20:42 |
| rgareus | ssj71: yes. that's where it's at. it's not a "hard problem" but it's somthing to be thought over. | 20:42 |
| ssj71 | agreed | 20:44 |
| rgareus | the initial proposal came up at LAC. a discussion with the MOD-team (who want clickless bypass), Fons, drobilla and me. I'm not sure if falktx was around. We had a few beers with it, so probably not. | 20:47 |
| rgareus | drobilla kept notes, Fons & I were drinking^Wdiscussing and Gian did the catering :) | 20:49 |
| ssj71 | rgareus I suppose I can see the case for 1->2 by the plugin. Now I'm starting to think though that many plugins would want to jump right from 0->2. i.e. x-fade right to a no latency state | 20:52 |
| rgareus | indeed | 20:53 |
| rgareus | though the plugin can just make 0->1 noop | 20:54 |
| rgareus | and do all the work in 1->2 | 20:54 |
| ssj71 | wouldn't it need to be 100% dry at that point that it returns 1? | 20:54 |
| rgareus | that's what the last "Q" is about. | 20:55 |
| rgareus | "Is 1 being identical to the plugin not being there at all, except for latency" | 20:55 |
| ssj71 | rgareus: I assumend it was | 20:57 |
| rgareus | there hasn't been consensus it. | 21:00 |
| rgareus | as you said. jumping from 0->2 in one step may be something to consider one way or another | 21:01 |
| ssj71 | rgareus: perhaps a few different designations in ttl are in order to indicate what the plugin does (0->1 only, 0->2 in one step, all 3 states etc) | 21:07 |
| ssj71 | then the host can deal accordingly. But then again thats a lot of cases for the host to deal with | 21:07 |
| *** flexus has quit IRC | 21:09 | |
| *** flexus has joined #lv2 | 21:21 | |
| *** rncbc has quit IRC | 21:37 | |
| *** rncbc has joined #lv2 | 21:38 | |
| *** rncbc has quit IRC | 21:49 | |
| *** ricardocrudo has joined #lv2 | 22:09 | |
| *** NickSB2 has joined #lv2 | 22:10 | |
| *** falktx has quit IRC | 22:26 | |
| *** ricardocrudo_ has joined #lv2 | 22:59 | |
| *** edogawa has quit IRC | 23:01 | |
| *** ricardocrudo has quit IRC | 23:02 | |
| *** flexus has quit IRC | 23:36 | |
| *** ricardocrudo_ has quit IRC | 23:37 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!