Sunday, 2015-10-25

*** edogawa has quit IRC00:02
*** tytel has joined #lv202:06
*** uncle-j_j has quit IRC02:32
*** Magnus_RM has quit IRC03:19
*** Bernhard_L has joined #lv206:41
Bernhard_LHello, looking for a scatter plugin. Tried granular scatter processor, but don't get any result out of it.06:42
*** tytel has quit IRC07:59
*** edogawa has joined #lv208:19
*** tytel has joined #lv208:32
*** tytel has quit IRC08:37
*** falktx has joined #lv208:49
*** tytel has joined #lv209:27
*** tytel has quit IRC09:31
*** uncle-j_j has joined #lv209:39
*** tytel has joined #lv210:21
*** tytel has quit IRC10:25
*** uncle-j_j has quit IRC10:36
*** uncle-j_j has joined #lv210:38
*** rncbc has joined #lv210:40
*** Mark__ has joined #lv210:51
*** Mark__ has left #lv210:51
*** uncle-j_j has quit IRC10:53
*** tytel has joined #lv211:15
*** tytel has quit IRC11:19
*** rgareus|afk is now known as rgareus11:24
rgareusdrobilla: nice.11:25
rgareusdrobilla: still fails when double-clicking (not embedd)  (_instance is NULL)11:25
rgareusdrobilla:  http://paste.debian.net/317996/11:25
rgareusmmh there still seems to be a race-condition. Sisco.lv2 (x11_in_gtk2).  embedd/close/embedd-again/... the UI signal sent during instantiate  does not always make it though.11:31
*** Bernhard_L has quit IRC11:37
rgareusssh in sisco's case. the issue is now the other way 'round.  the first message(s) from DSP to UI may not be delivered11:42
rgareusUI to DSP works now properly.  but the other way round not yet.  in this case: GUI settings are not always restored.11:43
rgareuss/restored/initialized/11:44
*** tytel has joined #lv211:59
*** tytel has quit IRC12:04
*** rncbc has quit IRC12:31
*** uncle-j_j has joined #lv212:45
rgareusdrobilla: found it.  there can be  N  DSP run()  before  PortImpl::monitor()14:17
rgareusdrobilla: I added a printf() to the plugin's   run()   and a printf() to ingen's    PortImpl::monitor()14:17
rgareusI get 2 runs  for one  PortImpl::monitor()14:17
drobillaHm.  Yes, I guess the explicitly monitored case needs to work differently14:18
rgareusatom-messages send in the first   run()   just go nowhere.  the 2nd run() overwrites the buffer14:18
drobilla(The usual is e.g. audio/activity monitoring where the goal is to not go insane with traffic)14:18
rgareusdrobilla: it's odd.   PortImpl::monitor() is supposed to be called in RT-context, isn't it?14:19
rgareusfrom   LV2Block::post_process()14:19
drobillargareus: yes14:21
drobilla... Though that parameter isn't ProcessContext& for some reason I can't remember14:22
rgareushang on.   LV2Block::post_process() is called every cycle.   but   context.notify() in  PortImpl::monitor() is not14:25
drobillaCorrect14:26
drobillaAt least in general.  The _monitored check in the early return there is supposed to make it happen every time for explicitly monitored ports14:27
rgareusI get a regular  pattern14:28
rgareus   run();   LV2Block::post_process();  run();   LV2Block::post_process() -> context.notify();    // repeat14:28
rgareusgive me a min. I'll check where in   in PortImpl::monitor() it stops every 2nd time14:29
*** sigma6 has joined #lv214:31
rgareusright at the top    !context.must_notify(this)14:31
rgareusif I comment that out  in   PortImpl::monitor()   all works well14:32
rgareusscratch that.14:37
rgareusthat does not make a difference.14:37
rgareusdrobilla: ok.  now the definitive answer:    time_to_send   is false every 2 time14:43
drobillargareus: Yes, but _monitored should be true14:47
rgareusingen/src/server/PortImpl.cpp:429      if (!time_to_send && (!is_sequence || _monitored || buffer(0)->value()))  { return ; }14:47
rgareusdrobilla: what's the logic here?14:47
rgareusI think that should be changed:    monitored sequences should ignore  time_to_send.14:48
rgareus  if (!time_to_send && !(is_sequence && _monitored) && (!is_sequence && buffer(0)->value()))14:51
rgareus^^ seems right to me14:51
drobillaMmm, yes, seems odd14:52
drobillaSeems reasonable14:52
rgareusie always  notify the GUI if it's a monitored sequence.   but buffer-value updates depend on the time14:52
rgareusit seems that there's some issue with     _frames_since_monitor14:54
rgareusbut still atom-sequences, should always be forwarded regardless.14:55
drobillaShouldn't matter in that case, it's only used for value things14:56
drobillaThe monitored sequence branch just calls notify in the loop directly14:57
rgareus_monitored  is always true.     and  time_to_send is  false every 2nd time (here 1024fpp, jack dummy)15:06
rgareusmonitor rate is 25Hz,  so 1920 frames. (@48KSPS)15:07
rgareusso that's good too15:07
rgareusdrobilla: http://paste.debian.net/318028/  fixes all my issues15:14
rgareusdrobilla: can you commit that?15:16
drobillargareus: Sure.  Thanks15:25
*** edogawa has quit IRC15:30
*** deva has joined #lv217:14
*** rgareus is now known as rgareus|afk17:49
drobillargareus|afk: http://dev.drobilla.net/changeset/578618:17
*** rncbc has joined #lv218:21
*** NickSB2 has quit IRC19:18
*** uncle-j_j has quit IRC19:38
*** deva has quit IRC19:40
*** drobilla` has joined #lv219:48
*** drobilla has quit IRC19:51
*** drobilla` has quit IRC20:30
*** uncle-j_j has joined #lv220:44
*** uncle-j_j has quit IRC20:49
*** uncle-j_j has joined #lv220:54
*** uncle-j_j has quit IRC21:34
*** aombk has joined #lv221:51
*** tytel has joined #lv221:57
*** tytel has quit IRC22:07
*** tytel has joined #lv222:09
*** edogawa has joined #lv222:11
*** tytel has quit IRC22:37
*** falktx has quit IRC22:58
*** rncbc has quit IRC23:03
*** edogawa has quit IRC23:36

Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!