| *** edogawa_ has quit IRC | 00:02 | |
| *** falktx has quit IRC | 05:27 | |
| *** edogawa has joined #lv2 | 08:59 | |
| *** ddom has joined #lv2 | 09:28 | |
| *** grejppi has quit IRC | 12:27 | |
| *** grejppi has joined #lv2 | 12:33 | |
| *** ricardocrudo has joined #lv2 | 12:54 | |
| *** ricardocrudo has quit IRC | 12:59 | |
| *** ricardocrudo has joined #lv2 | 13:00 | |
| *** NickSB2 has quit IRC | 13:21 | |
| *** falktx has joined #lv2 | 15:13 | |
| *** edogawa_ has joined #lv2 | 15:14 | |
| *** edogawa has quit IRC | 15:17 | |
| *** ddom has quit IRC | 16:14 | |
| *** mlpug has joined #lv2 | 16:39 | |
| *** falktx_ has joined #lv2 | 16:45 | |
| *** falktx has quit IRC | 16:45 | |
| *** ddom has joined #lv2 | 18:39 | |
| *** rncbc has joined #lv2 | 19:14 | |
| *** mlpug has quit IRC | 19:24 | |
| *** zth has joined #lv2 | 19:27 | |
| *** NickSB2 has joined #lv2 | 19:50 | |
| *** ricardocrudo has quit IRC | 21:29 | |
| *** ricardocrudo has joined #lv2 | 21:44 | |
| *** ricardocrudo has quit IRC | 22:24 | |
| *** ricardocrudo has joined #lv2 | 22:25 | |
| *** rncbc has quit IRC | 22:25 | |
| *** unclechu has joined #lv2 | 22:55 | |
| unclechu | hi there, where I can found ladspa channgel? | 22:56 |
|---|---|---|
| unclechu | #ladspa is empty | 22:56 |
| *** ricardocrudo has quit IRC | 23:02 | |
| rgareus | unclechu: LV2 is LADSPA Version 2. | 23:04 |
| unclechu | rgareus, ok then | 23:05 |
| rgareus | wht bother about LADSPA version 1 ? | 23:05 |
| rgareus | s/wht/why/ | 23:05 |
| unclechu | rgareus, i try to write my first ladspa plugn, but i'm confused by error: "multiple definition of `_init'" | 23:05 |
| unclechu | i wrote initialization of descriptor in _init, like in example in ladspa sdk | 23:06 |
| rgareus | unclechu: smells like a compiler flag problem | 23:08 |
| unclechu | rgareus, `gcc -shared -fPIC -DPIC src/bit-crusher.c src/ladspa.c -o ladspa/bit-crusher.so` | 23:08 |
| rgareus | _init is usually reserved for library intialization and should not be explicityly defined in code. | 23:09 |
| unclechu | rgareus, then why it has in example from sdk? | 23:09 |
| unclechu | rgareus, legacy way? | 23:09 |
| unclechu | rgareus, any way, how i can init descriptor right? | 23:10 |
| rgareus | don't know. It's been years since I wrote my last LADSPA plugin. | 23:10 |
| rgareus | with gcc, static __attribute__((constructor)) void my_init() {}; should work | 23:14 |
| rgareus | or simply void __attribute__((constructor)) my_init {} | 23:16 |
| rgareus | replace void _init {} function by thta | 23:17 |
| rgareus | same with _fini , if you have one. | 23:17 |
| rgareus | void __attribute__((destructor)) my_fini() {} | 23:17 |
| unclechu | rgareus, it looks like i can init descriptor in "ladspa_descriptor" | 23:20 |
| unclechu | rgareus, but i'm afraid of memory leaks, do i need to destroy descriptors? | 23:20 |
| rgareus | unclechu: no, they're not allocated in the first place, but static | 23:21 |
| falktx_ | I need to clear a doubt | 23:21 |
| falktx_ | jalv is only sending the initial time position and never updates it | 23:22 |
| falktx_ | ie, time:Bar is set to a value but never refreshed when playing | 23:22 |
| falktx_ | am I suppose to calculate the next bar value myself? | 23:23 |
| falktx_ | cause that might be a bit tricky or even impossible with jack transport... | 23:24 |
| rgareus | falktx_: I'm pretty sure it sends updates when there's a change | 23:25 |
| falktx_ | not here | 23:25 |
| falktx_ | was this fixed recently? | 23:25 |
| falktx_ | rgareus: I have a printf when I receive an atom object, and while the transport is rolling I only receive 1 | 23:26 |
| rgareus | falktx_: there was a bug in earlier versions, but it was fixed at least a year ago (when I wrote the midifilters) | 23:26 |
| rgareus | falktx_: see http://svn.drobilla.net/lad/trunk/jalv/src/jalv.c search for 'xport_changed' | 23:28 |
| rgareus | falktx_: when transport is rolling... (pos.frame != jalv->position) in every jack cycle and you'll get a message | 23:29 |
| falktx_ | I don't think that's true | 23:30 |
| falktx_ | see | 23:30 |
| falktx_ | jalv->position = rolling ? pos.frame + nframes : pos.frame; | 23:30 |
| falktx_ | when it's rolling, jalv->position will get the next frame pos | 23:30 |
| falktx_ | which matches the next process callback | 23:30 |
| falktx_ | thus no new data sent | 23:30 |
| rgareus | falktx_: do you have an atom:supports time:Position ? | 23:31 |
| falktx_ | yes, I get the transport info correctly | 23:32 |
| falktx_ | the issue is that I only get that once | 23:32 |
| falktx_ | that line "jalv->position = rolling ? pos.frame + nframes : pos.frame;" has to be the issue | 23:33 |
| rgareus | falktx_: you were right. yes you ned to calc the new BBT position yourself. | 23:39 |
| rgareus | falktx_: https://github.com/x42/midifilter.lv2/blob/master/midifilter.c#L208 does this in one of my plugins. | 23:39 |
| falktx_ | that seems seriously wrong | 23:39 |
| rgareus | falktx_: what seems wrong? | 23:40 |
| falktx_ | jack transport can change at anytime | 23:40 |
| rgareus | falktx_: can it? | 23:40 |
| falktx_ | yes | 23:41 |
| falktx_ | does jalv register a transport info callback? | 23:41 |
| falktx_ | the timeSignature can change and afaik current jalv will not react to it | 23:41 |
| rgareus | falktx_: with locate and start/stop. it takes at least 2 cycle to take effect and it's in sync. see http://jackaudio.org/api/group__TransportControl.html | 23:42 |
| rgareus | falktx_: transport info callback ? | 23:45 |
| falktx_ | slow sync I think it's called | 23:45 |
| rgareus | aah. | 23:45 |
| falktx_ | anyway, I don't think it's fair to expect the plugins to do all sorts of calculations just to get timing right | 23:45 |
| rgareus | no that's different. | 23:45 |
| falktx_ | current jalv is broken to me | 23:46 |
| rgareus | falktx_: probably all other plugin hosts as well, then | 23:46 |
| falktx_ | carla is not | 23:46 |
| rgareus | except Carla if you implemented it diffeently | 23:46 |
| falktx_ | I send message about any detail that changed | 23:46 |
| falktx_ | I even implement all time position as control ports | 23:47 |
| rgareus | falktx_: IMHO it makes no sense to TX all those bytes every cycles, it's a very simple calc after all | 23:47 |
| falktx_ | you don't | 23:47 |
| falktx_ | you just send the ones that changed | 23:47 |
| rgareus | falktx_: the function to update the BBT should be in the LV2 util headers though | 23:47 |
| falktx_ | I'm not sure what's the official thing to do here | 23:49 |
| rgareus | I suppose, opening a bug ticket or email to lv2-devel is the right way forward | 23:49 |
| falktx_ | if lv2 hosts only send time info once and expect plugins to update accordindly, jalv needs to adjust for time-signature changes and a few other things | 23:49 |
| falktx_ | I'd be more happy if hosts sent every little change when it happens | 23:50 |
| falktx_ | the plugin will cache the values and update what's received | 23:50 |
| rgareus | falktx_: your plugin will need to update internally anyway e.g. if the cycle spans multiple beats | 23:51 |
| rgareus | falktx_: or do you expect the host to send a message for every tick? | 23:51 |
| falktx_ | every run() | 23:51 |
| rgareus | falktx_: I don't think that makes sense, mainly since you need to calc it anyway. | 23:52 |
| falktx_ | I do? | 23:52 |
| rgareus | sending it every run would only encourage plugin-authors to negect sub-cycle BBT changes inside the plugin | 23:52 |
| rgareus | and it's like "you have this information already, but do I tell it to you again (and again)" overhead | 23:53 |
| falktx_ | no, the plugin is only telling the new data | 23:54 |
| falktx_ | *the host | 23:54 |
| falktx_ | ie, frame changed | 23:54 |
| rgareus | falktx_: how does plugin get simpler? you get this during run already and no need to parse an Atom. | 23:55 |
| falktx_ | just seems a bit overcomplex for the plugin to do this | 23:55 |
| falktx_ | oh, and since playing speed is a float, I'd have to adjust the values even more carefully | 23:56 |
| rgareus | falktx_: I think it should become part of some LV2 SDK utility header | 23:56 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!