| *** ricardocrudo has joined #lv2 | 00:05 | |
| *** ricardocrudo has quit IRC | 01:43 | |
| *** gianMOD has quit IRC | 03:31 | |
| *** drobilla has quit IRC | 03:49 | |
| *** hybrid has quit IRC | 04:18 | |
| *** hybrid has joined #lv2 | 04:31 | |
| *** gianMOD has joined #lv2 | 04:32 | |
| *** gianMOD has quit IRC | 04:43 | |
| *** gianMOD has joined #lv2 | 05:39 | |
| *** gianMOD has quit IRC | 05:43 | |
| *** edogawa has joined #lv2 | 06:32 | |
| *** falktx has joined #lv2 | 07:16 | |
| *** gianMOD has joined #lv2 | 07:27 | |
| *** gianMOD has quit IRC | 07:32 | |
| *** falktx has quit IRC | 09:11 | |
| *** gianMOD has joined #lv2 | 09:16 | |
| *** gianMOD has quit IRC | 09:21 | |
| *** falktx has joined #lv2 | 10:21 | |
| *** edogawa_ has joined #lv2 | 10:48 | |
| *** edogawa has quit IRC | 10:51 | |
| *** edogawa_ is now known as edogawa | 11:00 | |
| *** gianMOD has joined #lv2 | 11:04 | |
| *** HarryHaaren has joined #lv2 | 11:07 | |
| *** gianMOD has quit IRC | 11:18 | |
| *** gianMOD has joined #lv2 | 11:18 | |
| *** gianMOD has quit IRC | 11:19 | |
| *** mlpug has joined #lv2 | 11:27 | |
| *** gianMOD has joined #lv2 | 11:46 | |
| *** HarryHaaren has quit IRC | 11:56 | |
| *** gianMOD has quit IRC | 11:59 | |
| *** ricardocrudo has joined #lv2 | 12:08 | |
| falktx | that yoshimi plugin is amazing | 12:22 |
|---|---|---|
| falktx | the state it saves is 3059640 characters long | 12:22 |
| falktx | the default patch | 12:23 |
| falktx | 5Mb of data just for 1 plugin instance, ouch | 12:39 |
| *** gianMOD has joined #lv2 | 12:57 | |
| rgareus | is there an extension that allows LV2 ports to get/set port-latencies like with jack-ports? | 13:24 |
| rgareus | and related. is there a LV2 host that takes jack-port latencies into account? | 13:25 |
| rgareus | (ardour does to some extend, but only for playback) | 13:26 |
| falktx | non-mixer supports latency | 13:52 |
| falktx | but only for ladspa plugins | 13:52 |
| falktx | I implemented lv2 support in non-mixer, but no latency yet | 13:52 |
| *** falktx has quit IRC | 13:53 | |
| *** falktx has joined #lv2 | 13:55 | |
| *** HarryHaaren has joined #lv2 | 14:09 | |
| *** gianMOD has quit IRC | 14:14 | |
| *** NickSB2 has quit IRC | 14:25 | |
| *** mlpug has quit IRC | 14:25 | |
| *** gianMOD has joined #lv2 | 14:43 | |
| rgareus | aah well. time to scratch my own itch, then. | 14:46 |
| rgareus | would be nice to add it to jalv | 14:46 |
| falktx | rgareus: can you confirm the jack2 latency test client works properly? | 14:48 |
| rgareus | falktx: jack_iodelay? | 14:48 |
| falktx | jack_latent_client | 14:49 |
| rgareus | falktx: uhm. it just caused and an xrun :) | 14:49 |
| rgareus | falktx: I never used it. what does it do? | 14:50 |
| * rgareus checks the source | 14:50 | |
| falktx | https://github.com/jackaudio/jack2/blob/master/example-clients/latent_client.c | 14:51 |
| rgareus | falktx: looks alright in principle | 14:51 |
| rgareus | jack_set_latency_callback() is meant to set the latency. but to query changes one needs to use the graph_order_callback. | 14:52 |
| rgareus | (there was a post on jack-devel about it a while ago) | 14:52 |
| rgareus | it also does not x-fade if the latency changes. - but with jack1 that's moot anyway (no clickless connections) | 14:53 |
| falktx | does that tool/example seem correct to you? | 14:54 |
| falktx | if it is, then I'm missing the point of it.. | 14:54 |
| rgareus | tool/example ? | 14:55 |
| falktx | https://i.imgur.com/dCm4wDu.png | 14:55 |
| falktx | jack_latent_client | 14:55 |
| rgareus | falktx: aait only ever can delay , so you need to use it on _all_ ports | 14:56 |
| falktx | ? | 14:56 |
| rgareus | it's just an example - not useful a stanadline mono version | 14:57 |
| falktx | we need a correctly working example | 14:57 |
| rgareus | it is working | 14:57 |
| falktx | not for me | 14:57 |
| falktx | see the pic | 14:57 |
| falktx | the left channel and right are not aligned | 14:57 |
| rgareus | you didn't connect it right. | 14:57 |
| falktx | jack is not compensating the right channel | 14:58 |
| rgareus | if you use this example. you need to connect it between _all_ connections in the graph | 14:58 |
| rgareus | run jack_lsp -l | 14:58 |
| falktx | but I want to run it this way | 14:59 |
| rgareus | the tool just delays to sync things up if there's a playback latency and then announces a capture latency of 0 | 14:59 |
| falktx | apply some effect on some ports only | 14:59 |
| rgareus | falktx: if there's no latency this example just passes audio through | 14:59 |
| rgareus | it can only make audio later (not earlier) | 15:00 |
| falktx | jack should compensating the audio on system:playback_2 | 15:00 |
| rgareus | jack does not compensate for anything. it just passes numbers around | 15:00 |
| falktx | rgareus: say a plugin has 16 audio outputs. I add an fx to the 3rd and 4th ports only, the rest connects to playback | 15:00 |
| *** HarryHaaren has quit IRC | 15:01 | |
| falktx | I think I can make a graph of this... | 15:01 |
| rgareus | and the effect on port 3 and 4 has latency? | 15:01 |
| falktx | yes | 15:01 |
| rgareus | in this case all other ports need to be delayed | 15:01 |
| rgareus | so you need latent-client on all other ports | 15:02 |
| falktx | so the resposibility of delaying the signal does to the first plugin? | 15:02 |
| falktx | *goes to | 15:02 |
| rgareus | the host | 15:02 |
| falktx | s/plugin/standalone | 15:02 |
| falktx | so the resposibility of delaying the signal goes to the first standalone? | 15:02 |
| rgareus | no dice then. | 15:02 |
| rgareus | jack can tell anyone that it's not aligned. but won't to anything about this by itself. | 15:03 |
| falktx | I think that's bad | 15:04 |
| falktx | jack registers the system ports, it should ajust latency for those ports if needed | 15:04 |
| rgareus | jack is just a mechanism. no policy. | 15:04 |
| rgareus | falktx: in most cases jack cannot always come up with the ideal solution. it may just add unneccesary delay. | 15:05 |
| rgareus | e.g. in a DAW case input -> Track -> output. | 15:06 |
| rgareus | the track can compensate [read-ahead] on playback. | 15:06 |
| rgareus | and write-behind at the same time | 15:06 |
| falktx | still confused a bit | 15:07 |
| falktx | all I need to know is who's client is responsible for adding latency | 15:08 |
| falktx | in this case => https://i.imgur.com/q4sxd82.png | 15:08 |
| falktx | this would be much easier if jack itself handled the latency | 15:08 |
| falktx | ie, we tell jack what latency each client adds and let it handle it | 15:09 |
| rgareus | on 2nd look. latent_client.c just adds latency (argv[1], default 1024) - it does not subscribe to graph-order changes to query it | 16:13 |
| *** drobilla has joined #lv2 | 16:51 | |
| *** HarryHaaren has joined #lv2 | 17:09 | |
| *** gianMOD_ has joined #lv2 | 17:41 | |
| *** gianMOD has quit IRC | 17:41 | |
| *** ricardocrudo has quit IRC | 17:42 | |
| *** gianMOD_ has quit IRC | 17:45 | |
| *** mlpug has joined #lv2 | 17:58 | |
| *** gianMOD has joined #lv2 | 18:15 | |
| *** ricardocrudo has joined #lv2 | 19:02 | |
| *** mlpug has quit IRC | 20:14 | |
| *** falktx has quit IRC | 21:00 | |
| *** hybrid has quit IRC | 21:05 | |
| *** Anchakor_ has quit IRC | 21:19 | |
| *** Anchakor_ has joined #lv2 | 21:23 | |
| rgareus | drobilla: here's a first draft http://paste.debian.net/139970/ | 21:29 |
| rgareus | drobilla: I'll upload it to your tracker when I confirmed that it works as expected. | 21:30 |
| drobilla | So much code :/ | 21:31 |
| drobilla | I guess once an lv2file exists in the LV2 dist Jalv's purpose as a "simple" example will be less important | 21:31 |
| rgareus | drobilla: I could use #defines to cut jack_latency_cb in half :) | 21:31 |
| drobilla | Though splitting the jack stuff into another file might be a nicer design anyway | 21:31 |
| rgareus | JackCaptureLatency and JackPlaybackLatency are symmetric | 21:31 |
| rgareus | but that's less readable IMHO. I even opted for curlies on separate line to make this part more readable | 21:32 |
| drobilla | That'll be the first to go :) | 21:32 |
| drobilla | Whatever, don't worry about it | 21:33 |
| drobilla | Hm, yes, they are pretty much identical | 21:33 |
| drobilla | Looks like only the FLOW_* changes | 21:34 |
| rgareus | just FLOW_INPUT and FLOW_OUTPUT | 21:34 |
| drobilla | Easy to merge | 21:34 |
| rgareus | and JackCaptureLatency vs JackPlaybackLatency which is also given as parameter to the function | 21:34 |
| rgareus | drobilla: yeah. This can be simplified. even w/o nasty #define | 21:35 |
| rgareus | drobilla: wait until the 2nd draft, and post-testing | 21:35 |
| drobilla | flow = ((mode == JackCaptureLatency) ? FLOW_OUTPUT : FLOW_INPUT); | 21:42 |
| rgareus | drobilla: yeah or inline :http://paste.debian.net/139971/ | 21:45 |
| rgareus | works as expected. | 21:45 |
| rgareus | http://dev.drobilla.net/ticket/997 | 21:47 |
| drobilla | rgareus: Better | 21:47 |
| drobilla | one less line with a var :) | 21:47 |
| rgareus | drobilla: I'm not sure about explicit floorf() that will need -lm | 21:48 |
| drobilla | So jack ports can each have a different latency? | 21:48 |
| drobilla | The compensation for that will have to be way more complex then, non? | 21:48 |
| rgareus | drobilla: jalv itself cannot compensate. | 21:49 |
| rgareus | it could align | 21:49 |
| drobilla | Hm. Like, the amount of code in jalv.c entirely sort of complex. That's quite a burden | 21:49 |
| drobilla | Right, align, rather. | 21:49 |
| rgareus | it's not complicated - just a [dezippered] delayline | 21:50 |
| drobilla | I assume there's a reason jack/libjack can't do it, but that's asking a hell of a lot for simple clients :/ | 21:50 |
| rgareus | two reasons actually. one by design: jack is just a mechanism. it only ships data around. | 21:51 |
| drobilla | Well, keeping buffers around and offsetting them even without the DSP is quite a bit, add the DSP and dealing with transport/latency changes and such, eep. | 21:51 |
| drobilla | (Well, I guess transport you can probably ignore, n/m that) | 21:51 |
| drobilla | Don't get me wrong, if you do it, I'll add it, though I don't like it :) | 21:52 |
| rgareus | and the 2nd jack does not know anything about jack-client's internals. it can do a worst-case approach at best | 21:52 |
| * drobilla has to do latency comp in ingen one of these days. That'll be super fun... | 21:52 | |
| rgareus | ardour for eample can read-ahead and write-behind (minimze total latency though the graph( | 21:52 |
| rgareus | ardour for example can read-ahead and write-behind (minimize total latency through the graph) | 21:53 |
| rgareus | jack could not do that just based on the numbers ardour provides | 21:54 |
| rgareus | drobilla: I've added it to my simple jack/lv2 host, but only audio - | 21:54 |
| rgareus | realtime safe midi delaylines are not simple | 21:55 |
| drobilla | Seems simple enough since you have a buffer size limit | 21:57 |
| rgareus | drobilla: sure, if one assumes that there won't be more than 31.25 kbaud (MIDI speed) it's almost trivial. | 21:59 |
| rgareus | drobilla: libs/ardour/delayline.cc | 21:59 |
| rgareus | can delay midi data | 21:59 |
| drobilla | rgareus: You know the jack buffer size, same as audio | 21:59 |
| * drobilla is reminded about atom sequence ports being busted for split cycles :( | 22:00 | |
| rgareus | drobilla: yeah though jack has fixed size buffers (jack2 default: 32KB) per period. | 22:00 |
| rgareus | IIRC one can query the size | 22:00 |
| rgareus | drobilla: yeah I considered split cycles and pass trhough the data (instead of copying it) but with Atom seq that's a PITA. | 22:01 |
| drobilla | Well, changing that again would be just ever so popular, sooooo..... :) | 22:02 |
| rgareus | drobilla: the host could parse the sequence, split it and change the timestamps. | 22:05 |
| rgareus | not too complicated, just not fun | 22:05 |
| drobilla | Yeah, it's not a show-stopper | 22:05 |
| drobilla | I guess any MIDI buffer would have the same issue, you need to pretend the timestamps are different no matter how you slice it | 22:06 |
| drobilla | Well, unless they used delta time | 22:06 |
| *** hybrid has joined #lv2 | 22:29 | |
| *** gianMOD has quit IRC | 22:59 | |
| *** gianMOD has joined #lv2 | 22:59 | |
| *** ricardocrudo has quit IRC | 23:04 | |
| *** edogawa has quit IRC | 23:10 | |
| *** gianMOD has quit IRC | 23:25 | |
| *** gianMOD has joined #lv2 | 23:26 | |
| *** gianMOD has quit IRC | 23:30 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
