*** wolftune has quit IRC | 00:05 | |
*** youki has joined #kxstudio | 00:10 | |
*** BitPuffin|osx has joined #kxstudio | 00:22 | |
*** wolftune has joined #kxstudio | 00:55 | |
*** wolftune has quit IRC | 00:57 | |
*** wolftune has joined #kxstudio | 00:58 | |
*** wolftune has quit IRC | 01:00 | |
*** wolftune has joined #kxstudio | 01:00 | |
*** spectromas has quit IRC | 01:33 | |
*** orngjce223 has joined #kxstudio | 01:37 | |
*** wolftune has quit IRC | 01:50 | |
*** JackWinter has joined #kxstudio | 01:51 | |
*** wolftune has joined #kxstudio | 01:55 | |
*** BitPuffin|osx has quit IRC | 01:59 | |
*** wolftune has quit IRC | 02:26 | |
*** youki has quit IRC | 02:49 | |
*** wolftune has joined #kxstudio | 03:08 | |
*** wolftune has quit IRC | 03:15 | |
*** danni has quit IRC | 03:41 | |
*** JackWinter has quit IRC | 03:42 | |
*** danni has joined #kxstudio | 03:45 | |
*** wolftune has joined #kxstudio | 03:55 | |
*** danni has quit IRC | 03:57 | |
*** wolftune has quit IRC | 05:32 | |
*** wolftune has joined #kxstudio | 05:36 | |
*** wolftune has quit IRC | 06:03 | |
*** JackWinter has joined #kxstudio | 06:55 | |
*** JackWinter has quit IRC | 06:59 | |
*** JackWinter has joined #kxstudio | 07:01 | |
*** JackWinter has quit IRC | 07:05 | |
*** JackWinter has joined #kxstudio | 07:08 | |
*** JackWinter has quit IRC | 07:15 | |
*** JackWinter has joined #kxstudio | 07:17 | |
*** danni has joined #kxstudio | 07:49 | |
*** danni has quit IRC | 07:55 | |
*** orngjce223 has quit IRC | 08:19 | |
*** falktx has joined #kxstudio | 08:51 | |
*** Animtim_ has joined #kxstudio | 09:30 | |
*** Animtim has quit IRC | 09:33 | |
*** BitPuffin has joined #kxstudio | 10:19 | |
*** grobda24 has joined #kxstudio | 10:55 | |
*** designbybeck_ has joined #kxstudio | 13:05 | |
*** spectromas has joined #kxstudio | 13:06 | |
*** youki has joined #kxstudio | 13:11 | |
*** BitPuffin has quit IRC | 13:11 | |
*** itPuffinB has joined #kxstudio | 13:12 | |
*** itPuffinB is now known as BitPuffin | 13:12 | |
youki | falktx: i had a problem last night when i tried to open a session with Ardour 4.2 while the same session doesn't make any problems with Ardour 4.1 or Ardour 4.2-dbg | 13:15 |
---|---|---|
youki | falktx: obviously Klangfalter is the problem | 13:15 |
falktx | obviously? | 13:15 |
youki | falktx: i copied the chat i had with rgareus to debug it here : http://pastebin.com/Nnqcir6H | 13:16 |
falktx | youki: the distrho builds do not generate denormals | 13:17 |
youki | falktx: tthere are no denormals | 13:18 |
youki | "in which case it's likley memory corruption (which would also explain the crashes and other random behaviour). ie Klangfalter writes to some memory where it should not write to." | 13:18 |
youki | falktx: i put all the chat for better understanding, but the useful informations are at the end i guess | 13:19 |
rgareus | falktx: we tried a couple of different things. the problem only manifests itself if Klangfalter was present | 13:20 |
falktx | youki: do you run ardour from the terminal? if klangfalter is the issue it will print something to terminal ("assertion failed..." or similar) | 13:20 |
rgareus | falktx: there's no crash. it most cases it just uses 100% CPU | 13:20 |
rgareus | falktx: we checked with bitmeter if there are NaN or denormals, but there were not | 13:21 |
rgareus | s/we/youki/ | 13:21 |
falktx | youki: where did you get klangfalter from? the kx repos? | 13:21 |
youki | falktx: it just crashes sometime when i was disabling the plugins | 13:21 |
youki | falktx: yes from the repos | 13:21 |
rgareus | falktx: and it can crash sometimes when its bypassed but only in ardour-optimized not ardour's debug version (which hints a memory corruption) | 13:22 |
falktx | it can crash is there's a deactivate/activate call out of order | 13:22 |
falktx | *if | 13:22 |
youki | falktx: Installé : 2:20150718-1kxstudio3 | 13:22 |
rgareus | falktx: that's a good hint! sometimes bypass/unbypass fixed the issue. | 13:23 |
rgareus | ardour had a previous bug calling activate twice or so. | 13:23 |
falktx | rgareus: please recheck this if you can | 13:24 |
rgareus | falktx: I'm on it. | 13:25 |
falktx | I guess it's a change in the 4.2 code | 13:25 |
rgareus | falktx: that's the issue. there have been almost no changes to LV2 since 4.1 | 13:25 |
rgareus | falktx: and 4.1 works for youki . | 13:25 |
falktx | klangfalter hasn't changed either | 13:26 |
rgareus | the only change was min/max buffersize support for 4.2 | 13:26 |
falktx | juce yes, but I can't think of something related to this | 13:26 |
falktx | maybe I use those values, let me check | 13:26 |
rgareus | falktx: if it's a memory issue. then this would be erratic. and also explain why 4.2-debug works but 4.2 optimized dows not. | 13:26 |
rgareus | sadly running ardour under valgrind takes aaaaaages. | 13:27 |
falktx | LV2_BUF_SIZE__boundedBlockLength is a required feature | 13:27 |
falktx | oh | 13:28 |
falktx | LV2_BUF_SIZE__maxBlockLength is used to know the current block size | 13:28 |
falktx | rgareus: ardour sets that as a static 8192 value right? | 13:29 |
falktx | cause I don't think that is correct | 13:29 |
falktx | the max block size would be the jack buffer-size. | 13:29 |
falktx | and when the jack buffer-size changes you report that to the plugin via options->set() | 13:30 |
falktx | I'm going to say that https://github.com/Ardour/ardour/commit/53e969e925eb087459eba620770e95abb46945be is wrong | 13:31 |
falktx | the min size is 1, that part is correct | 13:31 |
falktx | but the max size should be the current block size | 13:31 |
rgareus | oops got ckieck off | 13:33 |
rgareus | flaky internet | 13:33 |
rgareus | the max is the maxium possible.. which is not *current* | 13:33 |
rgareus | split cycles for example. export/freewheeling. changing jack buffersize.. | 13:34 |
falktx | when the buffer-size changes you tell the plugin about it | 13:34 |
rgareus | falktx: that can happen every cycle (ie plugin analyisis) | 13:35 |
falktx | so call options->set every cycle | 13:35 |
falktx | btw, klangfalter sets the fixedBlockLength property | 13:36 |
rgareus | falktx: run() gets the *current* IIUC max is really the max possible that will ever called used in run() | 13:36 |
falktx | rgareus: does ardour respect that^ ? | 13:36 |
rgareus | falktx: probably not | 13:36 |
falktx | well, I need to know the currently, in-use buffer-size | 13:36 |
falktx | max size is "the maximum sample_count parameter that will ever be passed to run()" | 13:37 |
rgareus | ardour should refuse to load the plugin (like currently all plugins with in-place broken) | 13:37 |
falktx | I don't think ardour will pass a higher than current-buffer-size to run, will it? | 13:37 |
falktx | rgareus: then ardour will refuse to load convo.lv2 as well | 13:38 |
rgareus | falktx: it does | 13:38 |
rgareus | falktx: convoLV2 handles these cases | 13:38 |
rgareus | falktx: it's not a hard requirement for convoLV2. | 13:38 |
falktx | well, I don't like this situation | 13:38 |
falktx | until now all hosts used max-size to set the current buffer-size | 13:39 |
falktx | and plugins used it to know the current buffer-size as well | 13:39 |
rgareus | falktx: which is wrong according to http://lv2plug.in/ns/ext/buf-size/#maxBlockLength | 13:39 |
LAbot | Title: LV2 Buf Size (at lv2plug.in) | 13:39 |
rgareus | in Ardour "bounce with processing" for example uses 8K | 13:40 |
falktx | for those you change the max-size before bouncing | 13:40 |
rgareus | ssj71 brought up the issue | 13:40 |
falktx | I'd like to propose this: | 13:40 |
falktx | hear me out... | 13:40 |
falktx | 1. set min as 1 | 13:40 |
falktx | 2. set max as the current buffer size | 13:41 |
falktx | when bouncing or analyzing, set the max to whatever max value those actions will use | 13:41 |
rgareus | falktx: it's an LV2 option. so you need to de-instantiate and re-instantiate the plugin don't you? | 13:42 |
falktx | 3. when changing between RT and Non-RT bouncing, use options->set to report the change to the plugin, or re-instantiate | 13:42 |
falktx | correct | 13:42 |
rgareus | no go | 13:42 |
falktx | https://github.com/DISTRHO/DISTRHO-Ports/blob/master/libs/juce/source/modules/juce_audio_plugin_client/LV2/juce_LV2_Wrapper.cpp#L1654 | 13:42 |
rgareus | that'll produce clicks when you re-instantiate | 13:42 |
falktx | I'd prefer if you did NOT reinstantiate | 13:43 |
rgareus | falktx: how else can the option be changed? | 13:44 |
falktx | I just posted code that does that in the plugin | 13:44 |
rgareus | keep a pointer to the option object's data? | 13:45 |
rgareus | I don't think you can rely on that being valid in places other than instantiate() | 13:45 |
falktx | hm? it's one of the reasons why C functions were made | 13:46 |
rgareus | falktx: in ardour's case LV2_Options_Option options[] is inside the init function (on the stack). it will go out of scope after the plugin is instantated | 13:46 |
falktx | and that's ok | 13:46 |
falktx | just pass another stack variable to options->set() | 13:47 |
falktx | the plugins do not keep pointers that are in options | 13:47 |
falktx | bufferSize = *(int*)options[j].value; | 13:47 |
falktx | note the * (int *) | 13:47 |
falktx | it's like an atom buffer | 13:47 |
rgareus | nitpick: should that not be int32_t ? | 13:48 |
falktx | probably | 13:49 |
falktx | rgareus: does export always call run at 8192 and does it vary too? | 13:50 |
rgareus | falktx: currently export/freewheel is at fixed at max 8192 | 13:51 |
falktx | that's good :) | 13:51 |
rgareus | it was 64K previously but that caused lots of issues | 13:52 |
rgareus | 64K OR next automation-event (that is) | 13:52 |
falktx | does ardour respect powerOf2 at least? | 13:53 |
rgareus | no. :) | 13:53 |
rgareus | falktx: I don't know a host that does. does Carla do that? | 13:53 |
falktx | yes, kinda | 13:53 |
rgareus | ideally the host would wrap such plugins in a ringbuffer | 13:54 |
rgareus | but that has all sorts of issues | 13:54 |
falktx | if the current buffer-size is not ^2 and the plugin requires it, carla won't load it | 13:54 |
falktx | I don't handle changing buffersize => invalidate plugin yet though | 13:54 |
rgareus | on windows one almost never gets 2^N. ASIO latecy is configured in msec. common buffersizes are 441 and 480 fpp :( | 13:54 |
falktx | bbl | 13:54 |
rgareus | falktx: ardour should also refuse to load those plugins. | 13:55 |
rgareus | anyway. we now know that Klangfalter has a problem IFF lv2-max buffersize != current buffersize. (current Ardour 4.2) | 13:56 |
rgareus | as for the solution.. that's still TBD. | 13:56 |
falktx | rgareus: that's not the single issue | 14:38 |
falktx | rgareus: the issue is buffersize != real-one + not fixed | 14:38 |
rgareus | falktx: can you rephrase that? | 14:41 |
rgareus | which buffersize? | 14:42 |
falktx | rgareus: the issue is max plugin buffersize != current host buffersize + host not using fixed value (as requested by the plugin) | 14:43 |
falktx | I think the issue would be fixed if ardour used fixed bufsize, but I'm not counting on that happening | 14:44 |
rgareus | that's what run (... uint32_t n_samples) does | 14:47 |
rgareus | oops | 14:47 |
rgareus | scratch that | 14:48 |
*** wolftune has joined #kxstudio | 14:48 | |
rgareus | falktx: the plugin should fail to instantiate if requires http://lv2plug.in/ns/ext/buf-size/#fixedBlockLength and bufsz:minBlockLength != bufsz:maxBlockLength | 14:49 |
LAbot | Title: LV2 Buf Size (at lv2plug.in) | 14:49 |
rgareus | falktx: I'll update ardout to not allows plugins that require 2^N or require fixedBlockLength because it's not likley ardour will support that | 14:50 |
rgareus | AFAICT jalv does not support it either. | 14:50 |
rgareus | the architecture is prepared in ardour: All plugins are wrapped into a processor object. the "processor" could include a ringbuffer. | 14:52 |
rgareus | someone would need to add that and then take care of all sorts of latency issues that come from that. | 14:53 |
rgareus | the latter is the reason why it hasn't happened yet. | 14:53 |
rgareus | it would basically mean the plugin will always have max-buffersize latency. | 14:54 |
falktx | well, and I dont know what to do here then | 15:19 |
falktx | I need a property that tells me the current in-use engine buffer size | 15:20 |
falktx | if max-size is not the one, then I'll create one myself | 15:20 |
falktx | and fallback on max-size if that's not defined | 15:20 |
falktx | rgareus: does that^ sound good to you? | 15:20 |
rgareus | falktx: #fixedBlockLength is what you want isn't it? | 15:22 |
rgareus | that requires the host to say min-blocksize == max-blocksize and ensure that run () is only ever called with that | 15:23 |
*** jablo1 has joined #kxstudio | 15:24 | |
falktx | rgareus: not really, afaik fixed length has nothing to do with min and max | 15:27 |
falktx | rgareus: the host can have a min, max and current values. the current one will be fixed, which is the value I need | 15:27 |
falktx | do the specs say anything about fixed forcing min == max ? | 15:28 |
rgareus | falktx: yes | 15:31 |
rgareus | falktx: see http://lv2plug.in/ns/ext/buf-size/#fixedBlockLength | 15:32 |
LAbot | Title: LV2 Buf Size (at lv2plug.in) | 15:32 |
rgareus | it has a strong MUST | 15:32 |
falktx | ah ok, makes sense then | 15:32 |
falktx | and then klangfalter is also correct | 15:32 |
falktx | it was never made to be ran without fixed buffers | 15:33 |
rgareus | yes. except it should fail to instantiate if min-length != max-length | 15:33 |
falktx | err, I though that was meta-data was there for | 15:33 |
rgareus | falktx: yeah that's why I said *should*. not *must* :) | 15:33 |
falktx | :P | 15:34 |
rgareus | falktx: fixedBlockLength is an extention. the host may not provide it | 15:34 |
rgareus | but in this case ardour is wrong. it provides the extention and still allows the plugin | 15:34 |
*** wolftune has quit IRC | 15:37 | |
rgareus | falktx: I know it's not nice towards plugins https://github.com/Ardour/ardour/commit/ac1065b43 | 15:52 |
rgareus | falktx: but at least it won't crash. | 15:52 |
falktx | rgareus: can't you do that check during discovery? | 15:53 |
falktx | rgareus: if you never going to support those plugins, then please don't show them :) | 15:54 |
rgareus | falktx: makes sense | 15:54 |
rgareus | I just added to the existing case (in-place broken) | 15:54 |
rgareus | without thinking | 15:54 |
rgareus | falktx: actually I can't the plugin list is generated by lilv | 15:55 |
rgareus | mmh still possible to have ardour filter it | 15:56 |
rgareus | I'll look into it | 15:56 |
rgareus | falktx: done | 16:12 |
falktx | rgareus: are you checking for *optional* feature? | 16:14 |
rgareus | falktx: i think it's requiredFeature | 16:15 |
rgareus | falktx: at least that's what I've been testing | 16:15 |
falktx | ok, that's good | 16:15 |
rgareus | lilv_plugin_has_feature() | 16:15 |
rgareus | mmh | 16:16 |
falktx | yeah, I saw the commit | 16:16 |
falktx | that's why I asked. it seems like it might use optional features too | 16:16 |
rgareus | it does not. I just checked | 16:17 |
rgareus | phew | 16:17 |
rgareus | even though the lilv API documentation says otherwise | 16:18 |
falktx | sounds like something that might change in the future | 16:28 |
falktx | I remember lilv having calls to get the required features | 16:28 |
*** wolftune has joined #kxstudio | 16:37 | |
rgareus | falktx: I'm looking into it | 16:39 |
rgareus | falktx: when installing the A4.2 .deb can you display a note post-install? | 16:40 |
rgareus | like the usual debian maintainer messages. | 16:40 |
rgareus | Note to VST plugin users: After installing, please open a new session (so you won't lose any plugin settings in your existing session) and then click "Preferences->Plugins->Clear VST Cache" and then re-scan your plugins. | 16:40 |
rgareus | 4.2 changed the vst-cache format | 16:41 |
rgareus | mmh lilv should check both. the code /looks/ correct. | 16:43 |
rgareus | but empirically it only triggers if I add bufsz:powerOf2BlockLength to lv2:requiredFeature . if I add it to lv2:optionalFeature. lilv does not find it | 16:44 |
rgareus | aah n/m my bad. | 16:45 |
falktx | rgareus: can't that clear vst cache be done automatically? | 16:51 |
falktx | doesn't ardour store the version on is config file? | 16:51 |
falktx | *its | 16:51 |
rgareus | falktx: it's really about creating the new cache | 16:52 |
rgareus | falktx: the old cache is ignored | 16:52 |
falktx | ah ok | 16:53 |
rgareus | but you may have .fsi files all over the place (e.g /usr/local/lib/vst/) | 16:53 |
rgareus | load a session with VST -> VST is not yet scanned -> missing plugin -> save session -> lost plugin | 16:53 |
rgareus | most users are smart enough to not save | 16:54 |
*** BitPuffin has quit IRC | 16:54 | |
*** itPuffinB has joined #kxstudio | 16:55 | |
*** itPuffinB is now known as BitPuffin | 16:55 | |
*** wolftune has quit IRC | 16:56 | |
*** wolftune has joined #kxstudio | 16:58 | |
*** prpl has joined #kxstudio | 17:01 | |
*** designbybeck has quit IRC | 17:18 | |
*** wolftune has quit IRC | 17:23 | |
*** distrozapper has joined #kxstudio | 17:27 | |
*** BitPuffin has quit IRC | 17:27 | |
*** tjingboem has joined #kxstudio | 17:30 | |
*** wolftune has joined #kxstudio | 17:30 | |
*** JackWinter1 has joined #kxstudio | 18:12 | |
*** tjingboem has quit IRC | 19:06 | |
*** youki_ has joined #kxstudio | 19:34 | |
*** youki__ has joined #kxstudio | 19:45 | |
*** youki_ has quit IRC | 19:46 | |
*** grobda24 has quit IRC | 20:13 | |
*** prpl has quit IRC | 20:26 | |
*** jablo1 has quit IRC | 20:26 | |
*** flexus has joined #kxstudio | 20:38 | |
*** wolftune has quit IRC | 20:39 | |
*** wolftune has joined #kxstudio | 20:40 | |
*** flexus has quit IRC | 21:44 | |
*** youki__ has quit IRC | 21:47 | |
*** JackWinter1 has quit IRC | 21:54 | |
*** designbybeck_ has quit IRC | 22:03 | |
*** youki has quit IRC | 22:42 | |
*** youki has joined #kxstudio | 22:50 | |
*** youki_ has joined #kxstudio | 23:45 | |
*** youki has quit IRC | 23:47 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!