| *** LAbot has joined #lv2 | 00:49 | |
| *** tytel has quit IRC | 01:02 | |
| *** LAbot` has joined #lv2 | 03:31 | |
| *** LAbot has quit IRC | 03:31 | |
| *** edogawa has joined #lv2 | 05:38 | |
| *** ventosus has joined #lv2 | 07:15 | |
| *** sigma6 has joined #lv2 | 07:33 | |
| *** ricardocrudo has joined #lv2 | 09:11 | |
| *** falktx has joined #lv2 | 09:17 | |
| *** ventosus has quit IRC | 10:03 | |
| *** ventosus has joined #lv2 | 11:02 | |
| *** falktx has quit IRC | 11:10 | |
| *** falktx has joined #lv2 | 12:15 | |
| *** kalimann has joined #lv2 | 12:41 | |
| kalimann | hi, is there some info on how to use this lv2? | 12:42 |
|---|---|---|
| kalimann | installed it through pacman on linux chakra, but thats it, dont know where to go from here | 12:42 |
| *** falktx has quit IRC | 12:56 | |
| *** frinknet has joined #lv2 | 13:00 | |
| *** falktx has joined #lv2 | 13:04 | |
| *** drobilla has joined #lv2 | 13:12 | |
| rgareus | kalimann: LV2 are usually plugins. you get plugins and a host (that loads those plugins) | 13:25 |
| rgareus | kalimann: http://ardour.org or http://kxstudio.linuxaudio.org/Applications:Carla are common hosts which load plugins... but there are a lot more | 13:25 |
| rgareus | kalimann: as for plugins.. there are LOTS. http://calf-studio-gear.org/ or http://guitarix.org/ are popular. just to name two | 13:26 |
| *** ventosus has quit IRC | 13:41 | |
| kalimann | ahh, i see | 13:52 |
| kalimann | i was recommended them because i wanted an eq | 13:52 |
| kalimann | for my arch environment | 13:55 |
| kalimann | not to make music, but to equalize my general sound on my computer for media and music and games | 13:55 |
| *** kalimann has quit IRC | 13:55 | |
| *** kalimann has joined #lv2 | 13:55 | |
| kalimann | rgareus: my response above ^ | 13:55 |
| *** kalimann has quit IRC | 14:27 | |
| *** NickSB2 has quit IRC | 14:34 | |
| *** kalimann has joined #lv2 | 14:37 | |
| rgareus | falktx, drobilla: brace yourselves :) | 14:40 |
| *** son0p has quit IRC | 14:48 | |
| *** son0p has joined #lv2 | 14:50 | |
| *** ventosus has joined #lv2 | 15:02 | |
| *** kalimann has quit IRC | 15:05 | |
| falktx | rgareus: oh I'm writing a bit response already :) | 15:07 |
| falktx | *big | 15:07 |
| *** curlymorphic has quit IRC | 15:08 | |
| rgareus | falktx: cool. | 15:16 |
| * ssj71 goes for popcorn ;) | 15:18 | |
| falktx | ok, I'm tired now... | 15:49 |
| *** kalimann has joined #lv2 | 15:56 | |
| rgareus | falktx: Siesta | 15:57 |
| falktx | ps4 now! | 15:59 |
| falktx | better wait until the boss leaves :P | 15:59 |
| *** sigma6 has quit IRC | 16:05 | |
| rgareus | falktx: I'm going to reply in length. but your premise that plugin-analysis if off-line is wrong. it's real-time data | 16:16 |
| rgareus | maybe that's why we had this misunderstanding all the time. | 16:17 |
| falktx | rgareus: but does it spawn a 2nd instance or not? | 16:17 |
| rgareus | no | 16:17 |
| falktx | ah wow | 16:17 |
| falktx | so, hmm how does that work? | 16:17 |
| rgareus | it could.. | 16:17 |
| rgareus | and thereby avoid the problem, but that would duplicate DSP load | 16:17 |
| falktx | so ardour processes the regular plugin that is loaded (timeline), then again for analysis? | 16:19 |
| falktx | rgareus: please don't write too much, I don't want this to turn into a long discussion | 16:19 |
| falktx | rgareus: at least not until drobilla says a thing | 16:20 |
| falktx | drobilla: emmm ping? | 16:20 |
| rgareus | so far I'm only reading | 16:20 |
| rgareus | falktx: there is a 2nd instance just for the impulse-response. but the actual current spectrum is /live/ data, using a larger block-size (for proper FFT) | 16:21 |
| falktx | rgareus: so what happens if the plugin being analyzed has automation? | 16:21 |
| rgareus | the automation granulary becomes larger while under test. | 16:21 |
| falktx | the analyze buffers are fixed size right? | 16:22 |
| rgareus | yep 8K | 16:22 |
| falktx | ok | 16:22 |
| falktx | quite a big change in there | 16:22 |
| *** tytel has joined #lv2 | 16:22 | |
| rgareus | same as export, which some see as a bug. since export-automation does not match when you have with live-playing < 8K | 16:22 |
| falktx | 256 frames => 8192 => then back to 256 | 16:22 |
| falktx | why does export need to use 8192 anyway? | 16:23 |
| falktx | make it faster? | 16:23 |
| rgareus | because it's a lot faster | 16:23 |
| rgareus | yes | 16:23 |
| rgareus | it was 64K which is blazing.. | 16:23 |
| falktx | I'd assume quality > performance during export | 16:23 |
| falktx | I don't use ardour, but if I did I'd love to have an option for this | 16:23 |
| rgareus | but 64K screwd up automation and crashes some plugins :) | 16:23 |
| falktx | ie, Max HQ export = 8 frames :) | 16:24 |
| falktx | let the cpu burn, I want that quality precise automation changes | 16:24 |
| * falktx wonders what other hosts do | 16:24 | |
| rgareus | falktx: in reality a control rate (automation) or 20Hz is more than one sufficient. most plugins actually smooth it much lower. | 16:24 |
| rgareus | how fast can you turn a knob or move fader on a real mixing desk? 100ms from end-to end if you're good. | 16:25 |
| falktx | reducing zipper noise in bad plugins is a good thing | 16:25 |
| rgareus | "sample accurate automation" is just some marketing thing. nobody needs it :) | 16:26 |
| rgareus | anyway. getting OT. | 16:26 |
| ssj71 | isn't exposing that a plugin is bad better? | 16:26 |
| falktx | how is bad better? | 16:26 |
| ssj71 | KNOWING its bad is better than hiding the fact | 16:26 |
| falktx | sure | 16:27 |
| ssj71 | IMHO, anyway OT | 16:27 |
| falktx | but on commercial world we get no source | 16:27 |
| falktx | maybe there's one fantastic plugin that does crazy shit, but has that stupid zipper noise | 16:27 |
| rgareus | well, you can measure it. | 16:27 |
| ssj71 | if commercial plugins are zippering they don't deserve our money | 16:27 |
| falktx | well, freeware then | 16:27 |
| falktx | anyway really OT | 16:27 |
| * ssj71 stopping | 16:27 | |
| rgareus | ssj71: lol. that did't keep a lot of VST being sold. | 16:27 |
| rgareus | ssj71: well, you're good with *our* money | 16:28 |
| ssj71 | just sayin. now I'm really stopping | 16:28 |
| ssj71 | ok. I'm not stopping. I don't use closed source stuff, so I'm jaded. | 16:29 |
| rgareus | falktx: another quick question: since there's currently no callback. how will a plugin notice the buffersize has changed? | 16:35 |
| rgareus | ssj71, falktx: what happens with rkrlv2 in carla. instantiate plugin. then use jack_buffersize and increase the period (say from 256 to 1024) ? | 16:42 |
| falktx | rgareus: options->set | 16:42 |
| rgareus | IIUC rkrlv2 pre-allocates buffers using maxBuffersize during instantiation. | 16:42 |
| rgareus | falktx: how does rkrlv2 respond to this? | 16:43 |
| falktx | https://github.com/falkTX/Carla/blob/master/source/backend/plugin/CarlaPluginLV2.cpp#L3783 | 16:43 |
| falktx | no idea | 16:43 |
| falktx | my plugins do | 16:43 |
| rgareus | falktx: will the set() trigger a callback? | 16:44 |
| falktx | set is the "callback" | 16:44 |
| rgareus | falktx: the link you posted is the host-side? or a plugin-wrapper? | 16:47 |
| ssj71 | rgareus: I guess either 1) rkrlv2 will need to instatiate options->set() or 2) the host must reinstantiate or call run() multiple times to not exceed the maxBufSize | 16:47 |
| falktx | it's carla | 16:47 |
| *** rncbc has joined #lv2 | 16:47 | |
| falktx | host-side | 16:47 |
| rgareus | falktx: do you have a DSP example ie a plugin that responds to this? | 16:47 |
| falktx | all dpf and juce plugins do | 16:48 |
| falktx | rgareus: https://github.com/DISTRHO/DPF/blob/master/distrho/src/DistrhoPluginLV2.cpp#L660 | 16:48 |
| rgareus | aah, yes. so it *is* lv2_extension_data() ! | 16:49 |
| rgareus | and not an instantion option. | 16:49 |
| falktx | see below | 16:49 |
| falktx | rgareus: https://github.com/DISTRHO/DPF/blob/master/distrho/src/DistrhoPluginLV2.cpp#L1011 | 16:49 |
| rgareus | I think L660 is great. but L1011 is not. | 16:50 |
| falktx | I don't see how it's different | 16:50 |
| falktx | but please comment on the mail instead | 16:50 |
| rgareus | see rkrlv2's case here. it wants' max buf-size to allocate during instantation. | 16:51 |
| falktx | feel free to use snipets of that code, or just link to it | 16:51 |
| falktx | same as here | 16:51 |
| rgareus | falktx: ok | 16:51 |
| *** son0p has quit IRC | 16:52 | |
| rgareus | falktx: long story short: I think we need a #currentBlockSize the min/max does not cut it. do you agree? | 16:52 |
| *** son0p has joined #lv2 | 16:54 | |
| rncbc | howdy | 16:55 |
| rncbc | drobilla: http://dev.drobilla.net/ticket/1084 | 16:56 |
| ssj71 | rgareus: so do you have an opinion what should happen to rkrlv2 in your proposed scenario? | 17:04 |
| ssj71 | it will need to allocate new larger buffers | 17:04 |
| rgareus | ssj71: I think the *proper* solution is for the host to set *max* buffersize during instantiate to the max. possible that the host will even use | 17:04 |
| rgareus | 8K in jack's case. | 17:04 |
| ssj71 | ah yes. | 17:05 |
| rgareus | and for falktx's use-case of requiring the *current* we need a currentBlocksize (not max) | 17:05 |
| ssj71 | since rkrlv2 is independant of "currentBufSize" then I don't need options->set() | 17:05 |
| ssj71 | I concur | 17:05 |
| rgareus | I expect this will be most of the plugins: pre-allocate buffers. the convolution ones (which need current) are a corner-case. | 17:06 |
| *** badmankali has joined #lv2 | 17:07 | |
| falktx | rgareus: sorta, I think "current" is the wrong name | 17:09 |
| rgareus | "expected" or "nominal" | 17:10 |
| *** kalimann has quit IRC | 17:10 | |
| falktx | nominal sounds fancy :) | 17:11 |
| *** badmankali has quit IRC | 17:12 | |
| falktx | normalBlockLength ? | 17:12 |
| falktx | expected doesn't sound right | 17:12 |
| *** badmankali has joined #lv2 | 17:13 | |
| *** badmankali is now known as kalimann | 17:13 | |
| ssj71 | nextBlockLength? | 17:13 |
| falktx | nominalBlockLength | 17:17 |
| ssj71 | newBlockLength | 17:20 |
| ssj71 | nominal doesn't make a lot of sense to me. | 17:20 |
| falktx | maxRunBlockLength | 17:23 |
| ssj71 | no, because thats what maxBlockLength is | 17:23 |
| ssj71 | we're only talking about blocks handed to run | 17:24 |
| ssj71 | we have a max and min, and want a way to know what it will be when run is called() | 17:25 |
| ssj71 | or in other words what the next block size will be. What the current block size being used is. | 17:25 |
| falktx | but current seems like a wrong name | 17:26 |
| falktx | because the size is variable, the "current" one will change all the time | 17:26 |
| falktx | but I have no ideas for any other names | 17:26 |
| ssj71 | why? it is the block size currently being used and when it changes, the host passes the new current value to options->set() | 17:26 |
| ssj71 | isn't that exactly what you want to track? what the "current" one changes to? | 17:27 |
| ssj71 | I'm missing the distinction. | 17:27 |
| *** ventosus has quit IRC | 17:32 | |
| rgareus | falktx: I'm halfway done with a reply. bu need to go grocery shopping before it's too late. | 17:36 |
| rgareus | bbl | 17:36 |
| falktx | ssj71: see my reply to lv2 | 17:37 |
| falktx | ssj71: I don't want a "current" one (ie, the one used in run), since that can always be changing in carla | 17:38 |
| falktx | I want a "max possible in the current engine state" value :) | 17:38 |
| falktx | ssj71: does that make sense? | 17:38 |
| falktx | ssj71: I hope it does... | 17:43 |
| ssj71 | not fully. so you are kind of wanting to know what the jack bufsize is? | 17:44 |
| ssj71 | and why/how is the plugin dependent on that? | 17:44 |
| ssj71 | rereading your message in lv2 | 17:47 |
| falktx | it's the maximum that run() is ever going to take | 17:48 |
| falktx | that what other specs consider the "current buffer size" | 17:49 |
| falktx | but I always felt that calling that "current" was a bad idea | 17:49 |
| ssj71 | ok, now that I understand your desire a bit better, perhaps nominalMaxBlockSize makes sense, but I don't understand why still. | 17:49 |
| falktx | I just think using currentBlockLength some devs might get the wrong impression | 17:49 |
| ssj71 | why not just set up for maxBlockSize because sooner or later ardour will throw it at you | 17:49 |
| ssj71 | falktx: I agree now | 17:50 |
| ssj71 | with the semantics that is. | 17:50 |
| falktx | ẃell, if ardour changes the code back again this whole thing stops :P | 17:50 |
| falktx | this disussion only happened because of rgareus ;) | 17:50 |
| ssj71 | falktx: actually because of the change rgareus made to resolve the bug report I made after rkrlv2 were crashing | 17:51 |
| ssj71 | so I'll take the blame. I just don't get why you can't use the current implementation of maxBlockLength. it matches the definition you gave: run will never be called with more than that value | 17:52 |
| falktx | it's just overkill | 17:52 |
| ssj71 | the only reason I can think of needing to know the block length is to allocate adequate buffers. | 17:53 |
| falktx | yep | 17:53 |
| ssj71 | ffts efficiency as well | 17:53 |
| falktx | although for me is to make the plugin wrapper happy too | 17:54 |
| *** brummer has joined #lv2 | 17:54 | |
| ssj71 | thats the part that I don't understand the details of at all so its hard for me to analyze | 17:55 |
| ssj71 | so you want a lower value that 90% of the blocks will be smaller than. Then when the 8k buffer comes you want a notification so that you can re-allocate, then run(), then get the smaller buffer size again and re-allocate again? | 17:56 |
| ssj71 | 90% is obviously a fictitious value | 17:56 |
| falktx | most hosts will use the "max engine" has current | 17:57 |
| falktx | at least the opensource ones | 17:57 |
| falktx | *as | 17:57 |
| ssj71 | max engine would be the jack block size? | 17:57 |
| falktx | yes | 17:58 |
| falktx | or the alsa one | 17:58 |
| ssj71 | sure | 17:58 |
| ssj71 | maybe its just the engineer in me, but it just seems like a bad idea when ardour may at any time pass you an 8k block. | 18:00 |
| ssj71 | in realtime. | 18:00 |
| ssj71 | its a tradeoff between load balancing and RAM | 18:03 |
| ssj71 | anyhow bbl | 18:05 |
| *** ricardocrudo has quit IRC | 18:13 | |
| *** falktx has quit IRC | 18:19 | |
| *** kalimann has quit IRC | 18:20 | |
| brummer | A plugin shout be resposible to didn't extend it's own allocated buffers. A host, can't realy know, were the max buffer size goes, as the buffersize could be changed from outside. | 18:21 |
| brummer | So, what you expect as max value here, is usless in 99% of the cases. | 18:21 |
| brummer | So, what I understand from the current maxBuffersize value given from the host, is what the current Jack buffer size is. | 18:24 |
| brummer | Otherwise, this maxBuffersize value is allready known, before you start to code your plugin. | 18:25 |
| brummer | The very same is true for the min value | 18:26 |
| brummer | A nicely coded plug needs to know the jack buffersize, that's why jack does it the way it's done. | 18:27 |
| brummer | any other value is since. | 18:27 |
| rgareus | a host does know what the max possible buffer-size is | 18:28 |
| rgareus | you can query it from the hardware. ALSA has an API for it, ASIO has, Coreaudio has | 18:29 |
| rgareus | as opposed to JACK, coreaudio (and pulseaudio) can change the buffer-size dynamically (no dropout) | 18:29 |
| rgareus | using sliding buffers | 18:29 |
| brummer | but it didn't change the stance that the max buffersize to be expected is allready known, before you start to code your plugin | 18:32 |
| brummer | because smaller values then the once given by hardware could be changed any time from outside | 18:34 |
| *** nicksbx has quit IRC | 18:42 | |
| *** nicksbx has joined #lv2 | 18:42 | |
| *** falktx has joined #lv2 | 18:51 | |
| brummer | so please, forgime my ignorance (and my engish writtig skills), but for what, exactely is the maxBuffersize extension is worse? | 18:59 |
| rgareus | brummer: the extention is fine. The problem is that the specs are not 100% clear: Can "maxBuffersize" change while the plugin is running? | 19:01 |
| rgareus | some people said "yes of course" (thinking maxBlockLength is like jack's period). other said "no, certainly not." | 19:02 |
| brummer | as I sad, a plu shout be responsible to take care that it didn't extend it's own allocated buffers. Given a value for that, removes this resposibility. That's bad, in my opinion. | 19:03 |
| rgareus | http://lv2plug.in/ns/ext/buf-size/#maxBlockLength by itself is rather clear. | 19:03 |
| brummer | Well, then again my question, for what is it worse? | 19:06 |
| rgareus | brummer: yeah the solution you came up with is valid: plugin checks run(). buffersize mismatches -> schedule worker.. and do silent-runs. | 19:07 |
| rgareus | brummer: I think gx currently passes the value unmodified (rather than produce silence) while it is re-initializing. | 19:07 |
| rgareus | brummer: is that correct? | 19:07 |
| rgareus | s/value/audio/ | 19:07 |
| rgareus | "..for what is it worse" "fuer welche anwendungs-zwecke es schlechter ist?" Schlechter als was? | 19:09 |
| brummer | yes | 19:09 |
| *** flexus has joined #lv2 | 19:09 | |
| rgareus | brummer: instantiate(.. option) { plugin looks up max buffersize option, allocates a buffer large enough). run() will _always_ work, no re-init is needed. | 19:10 |
| rgareus | no "silent-runs" ever. | 19:10 |
| rgareus | as you may know ssj71's rkrlv2 uses this for example. allocate once. run forever. | 19:12 |
| rgareus | for plugins like this it would be a regression if buffer-size changes would cause a dropout. | 19:13 |
| brummer | do you know that this plugs run in guitarix without receive any value from guitarix? | 19:14 |
| brummer | They realy didn't need it, and runs well without asking for this | 19:15 |
| rgareus | I expect ssj71 is cool and pre-seeded the buffersize. | 19:16 |
| brummer | sorry mean s/worse/worth/ | 19:16 |
| brummer | exact, and he can do that, because he realy didn't need to know the buffersize. | 19:17 |
| rgareus | so he did. plug->period_max = INTERMEDIATE_BUFSIZE; | 19:17 |
| rgareus | INTERMEDIATE_BUFSIZE is 1024. try running at 2048 and it'll crash in guitarix (unless guitarix tells the plugin a proper LV2_BUF_SIZE__maxBlockLength) | 19:19 |
| brummer | otherwise, when no bufsize is given, the buffer get allocated to a fixed value ( witch he simple choose to small for the ardour analysys tool) | 19:19 |
| rgareus | brummer: many people mix and master at 2k or 4k. | 19:20 |
| brummer | however, my question remains, for what should the maxBuffersize feature be worth (do you see my development in the writting skills, I wrote worth, not worse) he, he | 19:22 |
| rgareus | maxBuffersize is worth a LOT if a plugin needs to pre-allocate buffers. | 19:24 |
| rgareus | delaylines, reverb,... are common examples | 19:24 |
| brummer | to the silence, in case of convolution, when the buffersize grow, the convolution effect get smothed out, so there is no need to produce silence, or return just the buffer, as the effect is anyway smaler the expected | 19:25 |
| rgareus | during run() N samples will be written to those buffers. and N <= maxBlockLength | 19:25 |
| rgareus | brummer: yeah convolution kernels are different. | 19:25 |
| brummer | but, again, the maxBuffersize is a KNOWN value beforehand | 19:26 |
| rgareus | brummer: convolution is the only case that I know where "nominalBufferLength" (current buffer-size) can be very useful to optimize the convolution kernel | 19:26 |
| rgareus | the difference: maxBufferLenght MUST not change (it requires alloc, not realtime safe), current aka "nominalBufferLength" (jack-period-size) can change any time it may not require re-allocation | 19:27 |
| rgareus | you can implement convolution kernels less optimized for the latter case. | 19:27 |
| rgareus | brummer: well, if you're of different opinion. please reply to the LV2-devel thread. | 19:32 |
| rgareus | the "actual" problem is that the specs are really not clear. some plugins/host interpreted it one way (max can change)... whatever it'll be.. all hosts/plugins should behave he same. | 19:34 |
| rgareus | The actual change (implement nominalBufferLength on hosts or make maxBufferSize dynamic) will be trivial in most cases. | 19:36 |
| brummer | oh, I'm done, I acept what ever get thrown on me, even if it sounds that I'm pissed, I'm not, be ensured. Even when others feel like I hitch them, sorry for that, I wont. My skills in writting may be the culprit here. But, to be honest, for my future work, it dosen't matter any more, what this feature means. I made my plugs independend from that. As I said in the guitarix bug thread, here we are at a point were comerzial develpoers | 19:38 |
| brummer | will throw there twols, as I do. | 19:38 |
| falktx | please leave that discussion to the list | 19:40 |
| falktx | brummer: don't panic, drobilla hasn't said a word yet | 19:40 |
| brummer | falktx>:no panic here. (I'm in Berlin right now, for the next 2 month, I guess we will see us) | 19:42 |
| drobilla | Holy backlog, batman | 19:44 |
| * drobilla doesn't get how maximum buffer size is in any way confusing | 19:47 | |
| brummer | Oh, the master of desaster enter the scene | 19:49 |
| rgareus | drobilla: tl;dr Can maxBufferLength be changed while the plugin is instantiated? | 19:49 |
| brummer | ???? | 19:50 |
| rgareus | brummer: I don't think your assessment is correct. proprietary standards (VST, AU) have specifified this precicely. | 19:53 |
| rgareus | LV2-doc is not bad but not yet on the same level as commercial documentation. | 19:53 |
| *** tytel has quit IRC | 19:54 | |
| drobilla | AFAIK the only actual use of that property is as an instantiation time option | 19:54 |
| drobilla | So, inherently, no. | 19:54 |
| rgareus | drobilla: then jalv does it wrong :) | 19:55 |
| rgareus | and ardour did | 19:55 |
| drobilla | how? | 19:55 |
| drobilla | Jack buffer size change? | 19:56 |
| rgareus | drobilla: yes, | 19:56 |
| rgareus | jack_buffer_size_cb() { jalv->block_length = nframes; } | 19:56 |
| drobilla | Like anything supports that correctly... :P | 19:56 |
| rgareus | and block_length is used for jalv.urids.bufsz_maxBlockLength | 19:57 |
| drobilla | Yes, but at that point the plugin has no idea anyway | 19:57 |
| rgareus | as long as it's only valid during instantiate, all is fine. | 19:57 |
| drobilla | It's not really maxBufferSize changing so much as the actual buffer size changing and exceeding the previously established value | 19:57 |
| drobilla | Oh, it's totally not fine, but the weird description confused me | 19:58 |
| falktx | drobilla: carla and my plugins/ports have been using this dynamicly for years | 19:58 |
| rgareus | drobilla: start a plugin with jack_bufsize 256 -> plugin instantiates, allocates buffers.. then run jack_bufsize 1024 -> crash. | 19:58 |
| * falktx feels ignore here | 19:58 | |
| rgareus | falktx: ? | 19:58 |
| * drobilla shrugs | 19:59 | |
| falktx | my plugins and host have been doing this for years, dang it | 19:59 |
| drobilla | y'all know the drill | 19:59 |
| falktx | I hate it when you all say nothing supports this | 19:59 |
| rgareus | drobilla: what? write Proposals to amend the spec to lv2-devel? | 19:59 |
| drobilla | To say what, exactly? | 20:00 |
| falktx | lv2 used to have a bug tracker | 20:00 |
| drobilla | I see a jalv bug | 20:00 |
| drobilla | and a whooooooooooooole lot of ado about nothing spec wise | 20:00 |
| falktx | should we use the lv2 github project for bugs/requests? | 20:00 |
| drobilla | Currently if you support dynamic then it's kind of implied you support dynamic everything, which is limited but doing that fine-grained doesn't sound very fun | 20:00 |
| drobilla | falktx: *shrug* I guess. | 20:01 |
| falktx | drobilla: well, I want to use the old one, but all the bugs were lost with the site update | 20:01 |
| drobilla | There weren't any of significance | 20:02 |
| rgareus | drobilla: the actual bug-fixing is indeed trivial. but currently the spec is not clear which way it need fixing. | 20:02 |
| rgareus | drobilla: http://lv2plug.in/ns/ext/options/ says " dynamic properties that may be changed at run time" | 20:03 |
| drobilla | rgareus: I fail to see why. Clearly reporting a given maximum buffer size during init() then calling run() with a bigger one is not okay | 20:03 |
| rgareus | drobilla: maxBlockLength is a property.. and hence could change any time. | 20:03 |
| drobilla | rgareus: Leaving two options: re-instantiate plugin, or use the dynamic thing if the plugin supports it | 20:03 |
| drobilla | Well, yes, as I said earlier, we could establish a bunch of vocab for this-and-that-and-the-other-property can be dynamic | 20:04 |
| drobilla | Which I can do, but nobody is going to like it. | 20:04 |
| rgareus | drobilla: I don't think it needs a vocab. just a small sentence in the doc. | 20:05 |
| drobilla | Given the context I'd rather just reinstantiate the thing and call it a day | 20:05 |
| rgareus | drobilla: I'm right with you there. | 20:06 |
| drobilla | Note that the dynamic options interface is in the instantiation threading class | 20:06 |
| rgareus | drobilla: in the email I proposed to add one sentence to #maxBlockLength : "This value will be valid for complete lifetime of the plugin after | 20:07 |
| rgareus | instantiation and not change dynamically." | 20:07 |
| drobilla | So there't not really any issue about actually doing it. You can reallocate whatever and so on | 20:07 |
| drobilla | Just whether or not a plugin exists that supports maxBufferSize and also dynamic options but doesn't want to implement it there | 20:07 |
| drobilla | rgareus: A certain pedantic part of me dislikes baking lifetime semantics into the definition of a property, but that aside, sure. Easy. | 20:08 |
| drobilla | I don't see a whole lot of benefit do burdening plugins with having to do this. Click-free would theoretically be a possibility kinda sorta but since the point is to allocate buffers........ not really. | 20:08 |
| rgareus | drobilla: support "maxBufferSize" can be twofold: (1) query in during instantiate. but not allow dynamic changes. or (2) extention data -> get()/set() dynamic changes | 20:08 |
| rgareus | if a plugin only want to know the max. burdeining the plugin to implement dynamic changes only because it uses the maxBuffersize option in instantiate is IMHO wrong. | 20:09 |
| drobilla | There's a simpler old-school C take on this: define return values for options::set for "I don't know what that is" or "I can not change this dynamically" | 20:10 |
| drobilla | Which should really be there anyway (I made the return a uint32_t but haven't actually defined any codes) | 20:10 |
| rgareus | nice | 20:11 |
| rgareus | -1 on error - oh wait uint32_t :) | 20:11 |
| falktx | lv2 already uses (uint32_t)-1 for some things | 20:13 |
| rgareus | still, that does not address the issue with "nominalBufferLength" (ie current jack buffersize). | 20:15 |
| rgareus | the host does not know a-priori if a plugin supports changing the maxBlockLength. | 20:15 |
| rgareus | the host would need to call the set() function to find out.. | 20:15 |
| falktx | there's supportedOption and requiredOption that could be used for this | 20:15 |
| rgareus | plugin-can change BS -> cool, always use current jack's plugin-can't -> use some large value to be sure. | 20:16 |
| falktx | make it so that if it's supported or required the plugin MUST implement set() | 20:16 |
| drobilla | I don't think "nominal buffer size" makes a whole lot of sense | 20:18 |
| falktx | do you have suggestions for a better name? | 20:19 |
| *** edogawa has quit IRC | 20:19 | |
| drobilla | I don't think the concept itself makes a whole lot of sense. | 20:19 |
| *** ricardocrudo has joined #lv2 | 20:19 | |
| *** edogawa has joined #lv2 | 20:21 | |
| rgareus | a plugin can just check in run() and shedule a worker. but if the BS changes rapidly a dedicated inteface for nominalBlockLength may be beneficial. | 20:23 |
| rgareus | falktx mentioned that VST has an inteface like this.. and so it may make it easier for devs to port plugins to LV2 | 20:23 |
| drobilla | link? | 20:24 |
| rgareus | personally I believe that a plugin requiring to know about BS changes out-of-band leads to writing bad DSP. | 20:24 |
| drobilla | I more or less agree and think this is a bunch of striving for complexity for complexity's sake | 20:25 |
| drobilla | Max, min, and fixed, are necessary and useful for obvious reasons | 20:25 |
| rgareus | drobilla: http://vstdev.richackard.com/doc/vstsdk/faq.html#faqProcessing3 | 20:25 |
| drobilla | I thought you meant VST had some "nominal" thing | 20:26 |
| rgareus | drobilla: I don't know. falktx mentioned this. | 20:26 |
| * drobilla doubts it | 20:27 | |
| rgareus | VST3 requirs a call to setupProcessing() .. which is not unlike re-instantiation | 20:27 |
| falktx | not re-instantiate, but rather activate | 20:28 |
| drobilla | http://vstdev.richackard.com/doc/vstinterfaces/structSteinberg_1_1Vst_1_1ProcessSetup.html | 20:28 |
| rgareus | drobilla: I dimly recall that VST2 has some callback for the block-length. | 20:28 |
| falktx | that's old stuff | 20:28 |
| falktx | let me check carla code | 20:28 |
| rgareus | effSetBlockSize | 20:28 |
| falktx | yes | 20:28 |
| falktx | ardour should have that too | 20:28 |
| rgareus | falktx: yes, it de-activates the plugin when doing that | 20:29 |
| falktx | there's also audioMasterGetBlockSize | 20:29 |
| *** NickSB2 has joined #lv2 | 20:29 | |
| falktx | the plugin can request the current buffer size at anytime | 20:29 |
| falktx | and sample rate via audioMasterGetSampleRate | 20:29 |
| rgareus | falktx: right, so in run() a plugin could ask for the "real" audioMasterGetBlockSize | 20:30 |
| rgareus | LV2 can't do this currently | 20:30 |
| falktx | vst plugins usually do that during instantiate or activate | 20:31 |
| falktx | cause they know that value won't change until the next activate | 20:31 |
| falktx | so it can be cached | 20:31 |
| brummer | in lv2 you can get the buffsize durring run, but, when you use the worker extension, you wont know when you can react on the recived information | 20:33 |
| rgareus | drobilla: would you mind chiming in on the mailing-list.. and leave a more permenent record of what you said here? | 20:33 |
| rgareus | brummer: no run() is not the buffer-size | 20:33 |
| rgareus | brummer: it can be less | 20:34 |
| drobilla | I'd prefer just doing that to having my nick mentioned ominously a bunch of times on IRC as you well know :P | 20:34 |
| rgareus | brummer: ardour does that regularly. e.g looping and some hosts split the cycle when parameter changes. | 20:34 |
| * falktx casually mentions drobilla in a self comment :) | 20:34 | |
| drobilla | I don't understand what the worker extension has to do with anything | 20:34 |
| brummer | drobilla>reallocate buffers | 20:35 |
| rgareus | drobilla: run(.., u_int32 n_samples) { if (n_samples != previous_n_samples) { schedule worker... and do silent runs } } | 20:35 |
| falktx | options->set is instantiation class, you're allowed to do anything there | 20:35 |
| drobilla | ... don't do that. | 20:35 |
| drobilla | Though the usual reply mechanism works for whatever if you need to 'apply' work in run() when its done | 20:37 |
| drobilla | Skimmed this thread and linked discussion, still don't get it | 20:43 |
| brummer | so, for what exactly is the maxBufferisze feature worth, is it ofr, let's come on about a value were nobody cares about wasted resorses, so let's use it? | 20:43 |
| drobilla | Seems y'all have invented a bunch of problems by making max not actually the max | 20:43 |
| drobilla | Then wanting to invent a "nominal" thing to be kinda sorta the max but not really the max | 20:43 |
| drobilla | For nebulous purposes | 20:43 |
| drobilla | brummer: it's.................. the maximum buffer size. Obviously. | 20:44 |
| falktx | drobilla: I blame rgareus :) | 20:44 |
| * rgareus blames ssj71 :) | 20:44 | |
| brummer | I know the max bufferasize before i WROTE MY PLUG, SO LEAVE IT | 20:44 |
| drobilla | Well, two things: being called with *less* than the max is clearly okay, so if a plugin broke in that case, the plugin is broken | 20:44 |
| * falktx blames ssj71 too | 20:44 | |
| falktx | ssj71: what did you do!? | 20:44 |
| drobilla | Being called with *more* than the max is clearly a host bug | 20:45 |
| drobilla | brummer: uh...... okay? | 20:45 |
| drobilla | brummer: it is a property of the current system configuration, so that is nonsense | 20:45 |
| rgareus | falktx: well, I blame myself too. I use maxBufferSize in one plugin. and there I don't expect it to change - ever - after instantiation. | 20:45 |
| drobilla | Just so we're clear on that bit I have every intention of sticking "this doesn't change" in the spec in some way or another. | 20:46 |
| drobilla | I am super ultra not into making my life more difficult than it already is as you guys clearly are at the moment ;) | 20:46 |
| rgareus | but since we're already blaming git blame src/jalv.c sets a bad example :) sorry David, could not resist. | 20:47 |
| brummer | As Isaid before, I don | 20:47 |
| drobilla | But if you can sum up the actual utility of a nominal block size in a sentence, feel free | 20:47 |
| drobilla | If it's anything that requires a reallocation if sample_count goes over it, no. That's max. | 20:47 |
| brummer | care about this any more, | 20:48 |
| falktx | ardour uses a static max of 8192, I want the real actual max nframes that's going to be used during run() | 20:48 |
| falktx | that's one sentence | 20:48 |
| brummer | In my plugs I handle buffersize over or under run anyway | 20:48 |
| brummer | so, this value say's nothing then a hint to me | 20:49 |
| drobilla | brummer: Okay. Well, to answer your question, not having to do so is the utility of maxBufferSize | 20:49 |
| rgareus | brummer: yeah, you do. but requiring all plugins to do this is overkill. try to explain this to a newbie LV2 developer. | 20:50 |
| drobilla | If you want to cause a bunch of dropouts instead of use a number given to you, feel free. That doesn't mean the number is not useful. | 20:50 |
| drobilla | Anything that uses auxiliary audio buffers clearly 'needs' it | 20:51 |
| rgareus | drobilla: it can be useful for optimization (convolution kernel size is one good example) | 20:51 |
| brummer | But, the number is'nt usefull for me, as it is abstracted away from the real situation | 20:51 |
| drobilla | It isn't abstracted away from anything. It means exactly what it says on the tin | 20:52 |
| drobilla | falktx: Not changing the spec for that. Max is max. | 20:52 |
| brummer | MAx, well, hardware didicte it | 20:53 |
| falktx | changing the spec != adding new things | 20:53 |
| drobilla | If Ardour wants to make it 8192 and make everything pay the RAM cost, well... okay. Questionable IMO. | 20:53 |
| drobilla | Adding new confusing things with highly questionable motivation, that tellingly doesn't seem to be present in any other audio API I'm aware of... | 20:53 |
| falktx | if lv2 doens't do it, I will | 20:54 |
| drobilla | Of course you will. | 20:54 |
| brummer | and I don't care, I handle that internal, on the cost of the users | 20:54 |
| falktx | not all plugins need to care | 20:54 |
| drobilla | Lovely. | 20:54 |
| drobilla | So we can all see why I find IRC annoying since nobody actually gives a fuck whether or not this makes any sense whatsoever | 20:55 |
| * rgareus cares | 20:55 | |
| drobilla | So if you'll excuse me I have some work to do that both has a purpose and a pay cheque associated with it. ttyl. | 20:55 |
| rgareus | falktx cares, too | 20:55 |
| drobilla | rgareus: The subtext is that it doesn't make any sense, if that's not clear ;) | 20:55 |
| brummer | ahte IRC as well, I'm only here because of this issue | 20:56 |
| drobilla | I might even add the property anyway because of that whole optimization thing | 20:56 |
| drobilla | Though I'm slightly hesitant to do so given how batshit insane the rationale I've been provided is.... | 20:56 |
| falktx | drobilla: did you read all the emails? | 20:57 |
| falktx | drobilla: this talk on irc has been influenced by it. without the emails you'll miss the context | 20:57 |
| rgareus | falktx: I would not mind to add lv2plug.in/ns/ext/buf-size/#nominalBlockLength to Ardour which does what Carla currently does with maxBlockLength | 20:57 |
| falktx | rgareus: I wouldn't mind using min/max as global static values | 20:58 |
| falktx | if that gets added that is | 20:58 |
| rgareus | now we need the dictator's signature. and we're good :) | 20:58 |
| falktx | drobilla: we support you :) | 20:59 |
| falktx | but I still believe lv2 needs more maintainers | 21:00 |
| falktx | one single person taking care of it is exausting, look at all the crap we started :P | 21:00 |
| rgareus | it could also be a http://kxstudio... URI... but lv2plug.in would be a lot better | 21:00 |
| falktx | yep | 21:00 |
| falktx | specially since the URI changed now, damn sourceforge... | 21:01 |
| falktx | *URL | 21:01 |
| brummer | revulution | 21:04 |
| brummer | s/u/o/ | 21:04 |
| falktx | DDR? | 21:05 |
| brummer | s/r/e/ | 21:05 |
| brummer | falktx> nope, western guy | 21:06 |
| *** curlymorphic has joined #lv2 | 21:13 | |
| * falktx doesn't know what to do | 21:15 | |
| drobilla | Is there actually a convolution plugin in existence that will make use of this thing to do an actual optimization? | 21:16 |
| falktx | klangfalter allocates buffers using the "current block length" size | 21:18 |
| drobilla | Buffers clearly need to be allocated with maxBlockLength | 21:18 |
| falktx | if that is too low during processing it reallocates | 21:18 |
| drobilla | That defeats the whole purpose of knowing that value in the first place | 21:18 |
| falktx | well, it prevents xruns because it doesn't need to wait for run | 21:19 |
| drobilla | Let's be super clear about one thing: if a nominalBlockLength exists, it is very definitely totally fine and expected for the host to call run() with a larger value | 21:19 |
| rgareus | drobilla: convo.lv2 currently schedules a worker and goes silent (until re-init) if the current and prev blocksize mismatch in run() | 21:20 |
| drobilla | rgareus: That's because it's really fixed, though | 21:20 |
| rgareus | drobilla: in ardour's loop and analysis case it's bad though. the plugin will constantly re-initialize | 21:21 |
| drobilla | rgareus: Can't Ardour just use a different instance for analysis or something? or just call analysis with the jack block size? | 21:21 |
| rgareus | drobilla: it could follow the nominalBufferLength -> re-init it that changes. and otherwise just ignore short cycles. | 21:22 |
| drobilla | Surely I can't be the only one who thinks this spec fallout from ardour using a static max is dubious at best... | 21:22 |
| * falktx is back to blaming rgareus | 21:23 | |
| falktx | get that engine max value back and implement options->set please | 21:23 |
| rgareus | drobilla: the live-view uses the current-data and instance. the tranfer-function display uses a 2nd instance | 21:23 |
| drobilla | Well, that is the seed, clearly | 21:23 |
| *** edogawa has quit IRC | 21:23 | |
| drobilla | But it seems everyone but myself is conflating max with this new thing | 21:23 |
| rgareus | falktx: that goes waaay back. to before my involvement with ardour as dev. | 21:23 |
| drobilla | Which I emphatically refuse to accept. Max is max is max is max. | 21:23 |
| rgareus | falktx: but I'll take the blame for beeing lazy and not changing it :) | 21:24 |
| drobilla | Optimization? fine. | 21:24 |
| drobilla | But if you're going to reallocate buffers if "nominal" is exceeded, you are doing it wrong. | 21:24 |
| drobilla | and amending the spec so people can do things wrong is not all that motivating :) | 21:24 |
| rgareus | drobilla: "nominal" would schedule a woker in my case. | 21:24 |
| rgareus | drobilla: rather than using run() current != prev_run to trigger that | 21:25 |
| drobilla | rgareus: If you mean a change, it is impossible to change options while rolling anyway. instantiation class | 21:25 |
| *** tytel has joined #lv2 | 21:25 | |
| rgareus | drobilla: but run() must not be called while option->set() is beeing called. (that's in the spec) | 21:26 |
| drobilla | Yes, but it's not real-time either | 21:26 |
| rgareus | the spec says nothing if a plugin may perform non-rt tasks in option->set() yet "instantiation class" implies that | 21:26 |
| drobilla | (The only reason you can even slightly get away with that is if you have no control ports thus skirting split cycles anyway) | 21:27 |
| rgareus | the plugin would indeed behave "badly" during split-cycles (remain silent). but it may not live-loop hog the system when there are constant split-cycles. | 21:28 |
| drobilla | The theme of "let's amend the spec to support clearly wrong things" is getting stronger... :) | 21:28 |
| drobilla | Seems to me fixed plugins should either be literally fixed, or ringbuffer internally and not care. There's no reasonable middle ground | 21:29 |
| *** flexus has quit IRC | 21:29 | |
| brummer | So to be clear, ANY LV2 host, including the reference host jalv, have done it wrong in the past, and now, there is a new way which is right, but clearly different from how this spec is used before. r/e/v/o/u/lution, indeed. | 21:32 |
| drobilla | falktx's take on introcing a new thing that is actually just max is definitely not right. | 21:33 |
| drobilla | We have had a max for a long time, it means precisely what it says it means, and that's that. | 21:33 |
| falktx | drobilla: if you can convince rgareus to change ardour's code back I'll be a happy person | 21:34 |
| drobilla | falktx: I am still not sure what your actual concrete reason to care is | 21:34 |
| drobilla | falktx: Because it sounds like it's to use it as a max, to allocate buffers, which is definitely wrong. | 21:34 |
| brummer | but even jalv didn't use it as that | 21:34 |
| falktx | yep, jalv always used it as the current buf size | 21:34 |
| rgareus | brummer: I don't know if *any* host is correct. but yes, most hosts got it wrong and it caused regular crashes. | 21:35 |
| drobilla | No. Jalv didn't support jack block size changes correctly | 21:35 |
| falktx | not 8192 as it's the real max jack buf size | 21:35 |
| brummer | no host do it, before arour change it | 21:35 |
| drobilla | if the host tells you 8192, from a spec POV, then 8192 is the max. | 21:35 |
| drobilla | If you want to allocate buffers that need to fit a cycle, then they must be 8192 | 21:35 |
| drobilla | We can argue all day about what Ardour does | 21:36 |
| falktx | I guess jalv will change to 8192 as well | 21:36 |
| drobilla | But the meaning is crystal clear there, LV2 wise | 21:36 |
| brummer | and if some one tell you to jump out of the window, . . . | 21:36 |
| drobilla | falktx: I'll reinitialize the thing | 21:36 |
| rgareus | yeah. we need to clarify the spec. implementing (ardour, jalv,....) it will be easy. | 21:36 |
| drobilla | Which is the obvious fix that would take about 1/16th the amount of time as this bloody conversation :P | 21:36 |
| falktx | ok, then *please* decide on something then | 21:38 |
| rgareus | allowing "max" to change seems weird. "current-maxium" is an odd concept. | 21:38 |
| falktx | should it be the 8192 value? yes or no? | 21:38 |
| drobilla | I am not familiar enough with this aspect of Ardour to know. | 21:38 |
| rgareus | falktx: I'm 95% implementing nominalBufferLength in Ardour. some small -Wcast-align remain to be fixed | 21:39 |
| drobilla | From a plugin POV if 8192 is the max you are given, then 8192 is your max, and run() may be called with a value up to 8192 | 21:39 |
| drobilla | Having max and kinda sorta max is fucking insane | 21:39 |
| falktx | it's the "current" value other specs refer to | 21:40 |
| drobilla | Thus far every single case for this aside from an 'optimization' one is wrong, wrong, wrong. | 21:40 |
| falktx | sorry that I don't have a better wording for it | 21:40 |
| drobilla | Other specs have a max, just like ours. | 21:40 |
| falktx | vst doesn't have a max | 21:40 |
| drobilla | (Which is telling) | 21:40 |
| drobilla | ... yes it does | 21:40 |
| falktx | ardour doesn't send vst currentBufferSize as 8192 | 21:41 |
| falktx | vst has a current buffer size and sample rate | 21:41 |
| falktx | not a max | 21:41 |
| falktx | the "current" buffer size in vst is only a hint | 21:41 |
| falktx | hosts can call with higher values | 21:41 |
| rgareus | falktx: right. currentBufferSize is *current* and not MAX | 21:42 |
| drobilla | I see maxSamplesPerBlock | 21:42 |
| drobilla | Clearly Ardour doesn't even vaguely have any such thing | 21:42 |
| falktx | the 8192 was imposed by rgareus | 21:42 |
| rgareus | drobilla, falktx: https://paste.debian.net/311125/ #< ardour support for LV2 current aka nominalBlockLength | 21:42 |
| drobilla | s/Ardour/tons of things/ | 21:42 |
| falktx | rgareus: thanks, let's see how this discussion goes first | 21:43 |
| rgareus | falktx: 8192 is ardour's max. (well, jack's really, but other engines follow) | 21:43 |
| falktx | rgareus: I also need to implement min/current/max in carla engine+plugin class, soon | 21:43 |
| falktx | that way carla-lv2 can work again | 21:43 |
| drobilla | I think it's pretty clear what my position on this is | 21:43 |
| rgareus | max is max. na naa naaaaaah naah nah. max is max. | 21:44 |
| drobilla | and fine, I'll add the property, with a description about optimization or whatever, because this actually makes sense | 21:44 |
| drobilla | what y'all are *actually* seeking to do with it is straight up idiotic | 21:44 |
| falktx | sigh | 21:45 |
| drobilla | Meh. You asked. | 21:45 |
| falktx | drobilla: do you find the vst currentBlockSize idiotic too? | 21:45 |
| rgareus | drobilla: a lot of plugins got used to expect the /buggy/ jalv behaviour maxBufferLength == *current* | 21:45 |
| drobilla | and there is no reason why too large a max should mean anything doesn't work anyway | 21:45 |
| rgareus | drobilla: or even old ardours. now that ardour changed to say max = max = 8192 and not current. -> uproar. | 21:46 |
| drobilla | this "current" business is confusing. | 21:46 |
| rgareus | well, it is. | 21:46 |
| drobilla | "current max" is a perfectly reasonable thing. | 21:46 |
| rgareus | but it was kinda wrong for years.. and nobody noticed except for occasional crashes when increasing the jack_bufsiz .. | 21:46 |
| drobilla | I very highly doubt the jalv bug had much influence on anything whatsoever | 21:47 |
| rgareus | and some plugins like guitarix don't even crash.. just produce silence. | 21:47 |
| falktx | rgareus: which again, carla+distrho/dpf did not have | 21:47 |
| drobilla | (Largely due to almost nobody actually dynamically tinkering their jack block size to begin with, which most drivers don't even support) | 21:47 |
| rgareus | falktx: yeah.. | 21:47 |
| drobilla | I am just extremely irritated at this attempt to invent nonsense and subsequently abuse it to work around a straightforward bug | 21:48 |
| brummer | resonable, may be, but used in the past "wrong" by any hosts, because of the examples given | 21:48 |
| rgareus | soo. long story short. we either keep the "old way" and update the documentation: "max can change any time" or we introduce a new property for the few cases where a plugin (mainly VST ports) needs it. | 21:48 |
| drobilla | effSetBlockSize: "maximum number of sampleframes an audio block may contain" | 21:49 |
| * rgareus votes for the latter. http://lv2plug.in/ns/ext/buf-size/#maxBlockLength is pretty solid as is. just mention it must not change. | 21:49 | |
| rgareus | drobilla: audioMasterGetBlockSize is what you want to look up | 21:50 |
| *** rncbc has quit IRC | 21:51 | |
| falktx | I'm fine with max being static | 21:51 |
| falktx | but the docs have to state that | 21:51 |
| drobilla | I would assume the definition of that is the same "block size" as above | 21:51 |
| rgareus | drobilla: which may or may not be the current run() size | 21:52 |
| drobilla | rgareus: Prove it. | 21:52 |
| rgareus | drobilla: split-cycles | 21:52 |
| drobilla | rgareus: run might be called with *less*, sure. | 21:52 |
| drobilla | Everything I see suggests this is a true max | 21:52 |
| falktx | http://learn.juce.com/doc/classAudioProcessor.php#a3b59606e6e85f262d465c7f779ca0c4a | 21:53 |
| drobilla | I don't actually have a problem with such a thing | 21:53 |
| drobilla | Everybody talking about using it as a max, to allocate buffers, gives me a ton of reason to want this to not exist | 21:53 |
| rgareus | falktx: nice link. "The actual block sizes used may be larger or smaller than this, and will vary between successive calls." | 21:54 |
| drobilla | Because if *you* people get so confused, lord knows what John Q New Implementer will think | 21:54 |
| drobilla | Dropouts are bad, mmkay? | 21:54 |
| rgareus | drobilla: john implementer will be happy so have doc. like the one linked from falktx :) | 21:54 |
| drobilla | But fine. I tire of this. | 21:55 |
| rgareus | they managed to churn out VSTs. | 21:55 |
| drobilla | You get your stupid property. | 21:55 |
| drobilla | I can't stop anyone from writing shitty plugins that drop out all the time for no good reason anyway. | 21:55 |
| rgareus | drobilla: it's a sad world, indeed. | 21:55 |
| drobilla | It's sadder when you encourage such things | 21:56 |
| rgareus | I was not a proponent of this property myself at first.. mostly became pragmatic. | 21:56 |
| drobilla | Pragmatic is using the bloody max and calling it a day :P | 21:56 |
| falktx | I'm not the best one to explain why we need this, but we do | 21:58 |
| drobilla | It's an optimization. We do not "need" it at all. | 22:00 |
| drobilla | That much is certain. | 22:00 |
| brummer | For sure, I didn't need it any more, and, still, if it get implemented, I wont trust it. | 22:01 |
| falktx | if you want to run 100+ plugins all with wasted resources, fine | 22:01 |
| drobilla | brummer: Its definition is not meaningful enough to be "trusted" in any sense at all anyway | 22:02 |
| brummer | falktx>exactly | 22:02 |
| drobilla | nominal block size of 1024? Sure. run(1024); run(1025); run(1026); run(1027); | 22:02 |
| falktx | but we can make that definition! | 22:02 |
| drobilla | No we can't. | 22:02 |
| brummer | If I can't trust it, I dont need it | 22:02 |
| falktx | I sure can | 22:02 |
| drobilla | Because if we did it would be equivalent to maxBlockLength | 22:02 |
| falktx | but max is static | 22:02 |
| falktx | I don't want a static, I want the smaller dynamic one | 22:03 |
| drobilla | Define "static" | 22:03 |
| falktx | 8192 static | 22:03 |
| falktx | as in, never changes, ever | 22:03 |
| drobilla | That is indeed the max ardour currently reports | 22:03 |
| drobilla | Why I'm the only one who thinks fucking up LV2 because of that is a problem is way beyond me | 22:04 |
| falktx | yes, and that's exactly the value I'm *not* interested in | 22:04 |
| drobilla | If there's a nice thing abour proprietary specs it's that this shit just doesn't even get considered, let alone happen :P | 22:04 |
| drobilla | falktx: and why are you interested in the other one? | 22:04 |
| falktx | if you want to run 100+ plugins all with wasted resources, fine | 22:04 |
| falktx | why are not NOT interested on it? | 22:04 |
| drobilla | Indeed, fine. You are a plugin. You do what the host tells you. | 22:04 |
| drobilla | falktx: Burden of proof is on you. | 22:05 |
| falktx | not all plugins use it yeah, but some will | 22:05 |
| drobilla | To do what? | 22:05 |
| falktx | if you want to run 100+ plugins all with wasted resources, fine | 22:05 |
| falktx | do I need to say it again? | 22:05 |
| drobilla | Oh, fuck off. | 22:05 |
| * drobilla works | 22:05 | |
| * falktx doesn't understand how this is not just obvious | 22:05 | |
| drobilla | If you can't even be bothered to give a "why", don't start the god damned conversation in the first place. | 22:06 |
| falktx | I don't make complex plugins, I'm not the most knowledgeable person to fully answer that | 22:06 |
| falktx | but optimization is one big reason | 22:06 |
| drobilla | It's one reason. | 22:07 |
| drobilla | Virtually the entire thread leading up to this is *not* about that, is my point. | 22:07 |
| drobilla | and also has zero to do with wasted resources | 22:07 |
| drobilla | No matter how many times you paste it | 22:07 |
| falktx | whatever reasons discussed here were not made by commercial vendors | 22:07 |
| falktx | ask them if you really want to know what they think | 22:08 |
| drobilla | I'll wrap this up with some meta: | 22:09 |
| drobilla | In the course of this discussion, there's been lamenting the arrival of the benevolent dictator, lamenting the fact that there is one and not more maintainers, and discussing hosting the property in the first place. | 22:09 |
| drobilla | There has not been the 5 line patch which I would have just applied and got on with my life. | 22:09 |
| drobilla | Despite the super magical git repository now existing which I was repeatedly ensured would cause just that to happen | 22:10 |
| falktx | well, tbh, you're not the best person to discuss things with | 22:10 |
| drobilla | Sure aren't! | 22:10 |
| falktx | drobilla: I already have 2 changes for lv2 btw | 22:10 |
| * rgareus still rebases & posts regular jalv patches every months - eagerly awaiting LAD.git | 22:10 | |
| falktx | but because you're always so busy I didn't really made much from them | 22:11 |
| * drobilla shrugs | 22:11 | |
| drobilla | Just saying | 22:11 |
| rgareus | drobilla: I can write up the spec and file a pull-request | 22:11 |
| falktx | https://github.com/falkTX/lv2/commit/0c8b704450019e6cb0fab2794b884e1cbb536e95 | 22:11 |
| rgareus | drobilla: but I wanted to discuss this first rather than /force/ a documentation change | 22:11 |
| falktx | https://github.com/falkTX/lv2/commit/cc48b1f968ce2d07d1e50a3d7fb28ad0df11edad | 22:11 |
| drobilla | This, right here, fucks up my life. I'm already having a nervous breakdown as it is | 22:11 |
| falktx | ^that last one needs some revision on the writing | 22:11 |
| drobilla | But until I'm wise enough to ONLY communicate in emails and patches, I'll just bitch about it instead until I break down | 22:12 |
| * rgareus hands drobilla a cigaratte | 22:13 | |
| rgareus | we need some fresh air | 22:13 |
| drobilla | Getting some fresh air then doing the work I need to do tonight WAS the agenda | 22:14 |
| drobilla | Then IRC happened | 22:14 |
| rgareus | falktx: can you have a quick look at https://paste.debian.net/311125/ line 82.. the LV2_Options_Option will only be valid during the callback. | 22:14 |
| rgareus | falktx: that may not be right. | 22:14 |
| brummer | I'm vote for falktx as a co maintainer | 22:15 |
| rgareus | brummer: he is alredy high-inquistor | 22:15 |
| drobilla | It's kind of a given that set options are valid until proven otherwise (i.e. changed) | 22:15 |
| falktx | me and drobilla have very different viewing points of very different things | 22:15 |
| rgareus | drobilla: the complete LV2_Options_Option block or only the parameter? | 22:16 |
| falktx | I vote for rgareus as co-maintainer | 22:16 |
| drobilla | I also vote for rgareus. No offense :) | 22:16 |
| brummer | not inquisor, but co-mainatiner is what is needed | 22:16 |
| falktx | rgareus: you need to pass that option during instantiate too | 22:17 |
| rgareus | in this specific case line 87 int32_t block_length could just become a class variable .. | 22:17 |
| rgareus | thanks for the confidence. | 22:17 |
| drobilla | falktx is too keen on kludging around things in specs and APIs | 22:17 |
| rgareus | now I wish I had less on my plate. | 22:17 |
| drobilla | You don't need someone who is *quite* as demanding an asshole as myself for such roles, but you do a little bit :) | 22:17 |
| falktx | yeah, 2 asshole leading a project would lead to disasters... :S | 22:18 |
| rgareus | the funny thing is: I don't think neither of you guys is an a*hole :) | 22:18 |
| falktx | that doesn't sound right | 22:18 |
| drobilla | Well, that's mainly a joke. Spec/kernel/API maintainers just need to say no, lots. | 22:19 |
| drobilla | rgareus: I'm not an asshole, but I play one on the Internet :D | 22:19 |
| falktx | 2 stubborn guys leading a project would lead to disasters... | 22:19 |
| rgareus | yeah, I figured. | 22:19 |
| brummer | and, no offence here, but rgareus is a bit to "reticent" for thsi rple | 22:19 |
| rgareus | much more easy on a bus-trip at LAC. | 22:19 |
| drobilla | Though seriously, I've received like..... I don't know, 2 patches for LV2, ever | 22:20 |
| drobilla | Maintenance burden is really not the bottleneck here | 22:20 |
| drobilla | Okay, not 2. Many of the extensions came from others entirely. The bus factor being > 1 would certainly be good, but "maintenance" isn't really the issue. | 22:22 |
| rgareus | well, multiply this 4 person discussion by 100 and you'll know why design by comitte sucks. C++11 specs, anyone? | 22:22 |
| drobilla | Design by la-de-da decentralized everything didn't work out so well either, but live and learn :) | 22:22 |
| brummer | maintenance is the bottleneck, because conversation with you is realy hard (bussy, any one?) | 22:23 |
| drobilla | brummer: You're not so hot yourself on that one, if you hadn't noticed | 22:23 |
| brummer | umpf | 22:23 |
| rgareus | drobilla: hey, he won the FAUST award with an LV2 plugin | 22:24 |
| brummer | but I didn' mention myself to do that | 22:24 |
| rgareus | drobilla: and you were even in the room. | 22:24 |
| falktx | I think we also need more people | 22:24 |
| drobilla | rgareus: I clearly didn't say he was worthless and does nothing of value :P | 22:24 |
| falktx | 4-5 people debating over a thing will get repeated arguments quickly | 22:24 |
| drobilla | Indeed | 22:24 |
| falktx | we need commercial pro-vendors | 22:24 |
| rgareus | right, *hot* is not what it'd call him either :) | 22:25 |
| drobilla | and being the arbiter of acceptance (i.e. spec maintainer) puts you in the asshole role inherently | 22:25 |
| falktx | the sort of people that are making real money with this | 22:25 |
| drobilla | Because you have to convince me. and it's frustrating if you can't. | 22:25 |
| drobilla | I get it, but that's the game. | 22:25 |
| falktx | I suck at convincing others | 22:25 |
| rgareus | drobilla: as long as we can call you bastard, all is fine :) | 22:25 |
| falktx | benevolent bastard? ;P | 22:26 |
| drobilla | I don't care. Part of the game is not getting all personally bent out of shape about development arguments on the Internet | 22:26 |
| drobilla | That's just how things get done | 22:26 |
| drobilla | (Plus I am a bastard, so fair enough) | 22:26 |
| falktx | rgareus: anyway, that looks good, just needs to have the option passed during initialization please | 22:28 |
| falktx | rgareus: also http://lv2plug.in/ns/ext/buf-size/#nominalBlockLength is wrong, there's an extra / before # | 22:28 |
| drobilla | 10 points for anyone who can configure apache to fix that one :/ | 22:29 |
| rgareus | falktx: ok. I'm on it. | 22:29 |
| drobilla | I don't think the pages can be in their own directories and still have proper slashless links | 22:29 |
| falktx | MOD got this right though | 22:29 |
| falktx | see eg, http://portalmod.com/ns/modgui#iconTemplate | 22:30 |
| drobilla | Yes, you just can't have each be its own directory and do that | 22:30 |
| drobilla | Which unfortunately conflicts with the bundle thing | 22:30 |
| drobilla | I could fix it by putting the spec page in the parent directory, just a messy job and the nice self-containedness goes away | 22:31 |
| drobilla | But I try not to let my obsessive compulsive nature think to much about the mess that is the LV2 directory structure... | 22:31 |
| drobilla | (extensions/ is the worst) | 22:32 |
| brummer | apropos comercial vendors, when I get it right, falktx get pait by the MOD currently, so, comercial vendors be on board, when falk takes a more role then a inquisor | 22:32 |
| falktx | drobilla: I seem to have the same issue now though, in https://moddevices.github.io/mod-sdk/modgui/#iconTemplate | 22:33 |
| falktx | :( | 22:33 |
| rgareus | drobilla, falktx: https://paste.debian.net/311131/ | 22:33 |
| falktx | brummer: soon, MOD is not actually selling stuff. just pre-selling | 22:33 |
| *** curlymorphic has quit IRC | 22:34 | |
| rgareus | brummer: I also sell LV2 plugins (with Mixbus) commercially | 22:34 |
| brummer | falktx>I realy hope it males it to paid you very well | 22:34 |
| * falktx would like that too... | 22:35 | |
| brummer | s/males/makes/ | 22:35 |
| brummer | I'm sure it will. | 22:37 |
| drobilla | I look forward to graduating and once again slowly running out of money trying to actually pay the rent with this free software nonsense :P | 22:37 |
| * rgareus should have postponed this discussion. another day without a page written on the thesis | 22:38 | |
| drobilla | ^ this | 22:39 |
| drobilla | Well, written benchmark in my case. | 22:42 |
| drobilla | Motivation has been pretty hard to come by for a loooooong time now | 22:42 |
| brummer | I'm never have a interesst to get paid for my work in open source, and I refuse it. The ever only graduate I accept was the one from GRAME FAUST. | 22:44 |
| drobilla | "nominal" is a bit weird but I can't think of anything better | 22:45 |
| falktx | in my view MOD is not being paid for the opensource work, but for the cloud infrastructure and hardware development + integration | 22:45 |
| drobilla | Must be nice :P | 22:45 |
| falktx | if I had a place to live it would be :P | 22:45 |
| falktx | damn berlin | 22:46 |
| drobilla | I'm pretty much doing a PhD and powerfully hate my life because I didn't make enough doing open source stuff | 22:46 |
| drobilla | Not that I tried very hard, but hey | 22:46 |
| brummer | I'm glade about the MOD | 22:46 |
| falktx | well, it's not starting so well tbh | 22:47 |
| falktx | we're already late for the kickstarter shipment... :( | 22:47 |
| brummer | hey, I'm sure you'll make it, lately, but make it | 22:49 |
| ssj71 | oh my google. I leave for a couple hours and you guys... | 22:49 |
| ssj71 | I'll never get through that backlog | 22:49 |
| falktx | the important part is the hardware, that's the thing we're getting really precise about | 22:49 |
| rgareus | brummer: well, there's some truth to "never make your hobby your profession". but if I can get paid for what you like to do anyway, that's fine with me. | 22:49 |
| falktx | software can be fixed later | 22:49 |
| rgareus | ssj71: did you run out of popcorn? | 22:49 |
| ssj71 | lol. no spent 4 hours loading and unloading fencing supplies :) | 22:50 |
| falktx | shit, I hate writing typos on emails | 22:50 |
| brummer | rgareus> well, for me not, any more, I've loss to much "hobys" this way. | 22:51 |
| falktx | can't edit them now | 22:51 |
| ssj71 | I'll go through the emails and comment if I have any opinion | 22:51 |
| falktx | the important conversation happened on IRC | 22:54 |
| falktx | I wouldn't bother too much | 22:54 |
| rgareus | falktx, drobilla: pushed to ardour-git. I dare way you have a week or three until Ardour-4.3 for this to become /final/. | 22:57 |
| falktx | now you're the fast one | 22:58 |
| falktx | wait for me man | 22:58 |
| * falktx has not done much in kx or carla since working for MOD... | 22:58 | |
| brummer | could you gime a link so that a pure plugin autor know what is to be expected | 22:59 |
| *** tytel has quit IRC | 23:03 | |
| brummer | falktx> I still wonder why the MOD coose to use ingen as endine instead carla, as carlo open a lot more opinions | 23:06 |
| falktx | the change was not made during my time | 23:06 |
| falktx | too late now | 23:06 |
| brummer | sade | 23:07 |
| falktx | but I'll try to convince Gian next year :P | 23:07 |
| brummer | I'll come along near time in beta hause, . . | 23:09 |
| drobilla | "open a lot more opinions"? | 23:09 |
| falktx | brummer: we changed to a different location now | 23:09 |
| brummer | were you are now | 23:10 |
| falktx | brummer: http://www.schleicher-electronic.com/en/contact/ | 23:10 |
| falktx | Wilhelm-Kabus-Str. 21-35 | 23:10 |
| falktx | it's where the assembly will be done | 23:10 |
| brummer | it's around 8 kilometers from my base | 23:17 |
| brummer | so I'll meat you in the next day's | 23:18 |
| falktx | rgareus: thanks for the 09caf8336f4ec681668a940e7df00ec18b3fd836 | 23:19 |
| falktx | rgareus: I'll try a nightly build soon and verify if my plugins work there, sometime soon | 23:19 |
| falktx | so I guess we'll go with nominal as name. good for me | 23:21 |
| brummer | drobilla>yes, unbounded to the requirments of a overhelmd open source spec maintainer. (I hope, you know, I'm not the asshole as it seems to be) | 23:21 |
| falktx | rgareus: oh also, https://distrho.github.io/DPF/classPlugin.html#a2643e638f62cfd4990247ec66bed60d2 | 23:21 |
| falktx | rgareus: already prepared for a real nominal (not <= nframes) in DPF, same as juce | 23:21 |
| rgareus | falktx: nice. so this das was not wasted after all :) | 23:22 |
| drobilla | Meh. I have been and will continue to do the things MOD requires of Ingen | 23:22 |
| falktx | soon ingen will have a real stress test | 23:23 |
| falktx | I hope it handles it well :) | 23:23 |
| drobilla | It has always been designed from the ground up to be suitable for such things, architecturally | 23:24 |
| drobilla | Just needs some features and other changes required of the new use case | 23:24 |
| drobilla | Though all that bundle unloading stuff I still have zero idea what to do about | 23:24 |
| falktx | it's for when a user removes some plugins | 23:25 |
| falktx | or sometimes updates it | 23:25 |
| falktx | we need to remove the old version, then add the new one | 23:25 |
| falktx | if it's being used that gets tricky... | 23:25 |
| drobilla | Doesn't strike me as a click-free thing | 23:25 |
| drobilla | Indeed. | 23:25 |
| falktx | not click-free, there will likely be xruns when installing plugins | 23:26 |
| falktx | but I think that's fine | 23:26 |
| drobilla | Well the *way* easier solution is to just reload everything | 23:26 |
| drobilla | Something more fine-grained might be possible, but hard to get right, and probably way more problematic as a result | 23:27 |
| * falktx -> sleep | 23:29 | |
| *** frinknet has quit IRC | 23:30 | |
| *** falktx has quit IRC | 23:34 | |
| *** brummer has quit IRC | 23:36 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!