| *** falktx has quit IRC | 00:28 | |
| *** wumpus has quit IRC | 00:36 | |
| *** tytel has joined #lv2 | 01:47 | |
| *** drobilla has joined #lv2 | 02:10 | |
| *** ricardocrudo has quit IRC | 03:52 | |
| *** tytel has quit IRC | 05:17 | |
| *** tytel has joined #lv2 | 06:12 | |
| *** tytel has quit IRC | 06:16 | |
| *** tytel has joined #lv2 | 07:06 | |
| *** tytel has quit IRC | 07:10 | |
| *** tytel has joined #lv2 | 08:00 | |
| *** tytel has quit IRC | 08:04 | |
| *** edogawa has joined #lv2 | 08:09 | |
| *** wumpus has joined #lv2 | 08:26 | |
| *** deva has joined #lv2 | 08:40 | |
| *** tytel has joined #lv2 | 08:54 | |
| *** tytel has quit IRC | 08:58 | |
| *** uncle-j_j has joined #lv2 | 09:04 | |
| *** drobilla has quit IRC | 09:11 | |
| *** tytel has joined #lv2 | 09:18 | |
| *** tytel has quit IRC | 09:23 | |
| *** ventosus has joined #lv2 | 09:33 | |
| *** artfwo has quit IRC | 10:05 | |
| *** rncbc has joined #lv2 | 10:22 | |
| *** uncle-j_j1 has joined #lv2 | 10:44 | |
| *** uncle-j_j has quit IRC | 10:44 | |
| *** falktx has joined #lv2 | 10:47 | |
| *** NickSB2 has joined #lv2 | 10:47 | |
| *** edogawa has quit IRC | 11:20 | |
| *** aombk2 has quit IRC | 12:07 | |
| rgareus | rncbc: quick, question re https://github.com/x42/midifilter.lv2/issues/8 | 12:13 |
|---|---|---|
| rgareus | rncbc: what is the midi buffer size in qtractor? | 12:14 |
| rgareus | rncbc: how many midi-events can a plugin generate in one cycle without causing qtractor to segfault? | 12:14 |
| rgareus | looks like the user in question tries some fancy eurotechno. 1 midi-event in -> 50 events per 0.1 beats out... so 500 events per beat for every incoming midi-event | 12:15 |
| rncbc | rgareus: hi, not sure if it's 2K bytes or events | 12:15 |
| rgareus | ardour, jalv have 32KB . | 12:16 |
| rgareus | 500 events that's 500 * 3 bytes/event 1.5KBytes (+ LV2 atom seq overhead: 2 bytes??) per beat. he didn't mention BPM | 12:17 |
| rncbc | rgareus: qtractor is 1K (1024) MIDI events | 12:18 |
| rncbc | rgareus: the lv2 sequence buffer will double that | 12:19 |
| rgareus | rncbc: I don't know if lv2_atom_forge_* does size-checks (but I think it does). so the LV2 sequence is valid.. - just lots and lots of events | 12:20 |
| rncbc | rgareus: so it's = sizeof(LV2_Atom_Event) + 4) * 2048 bytes | 12:20 |
| rgareus | if the lv2-seq already overflows.. well, it's the plugin's fault (or lv2-headers, whatever,..) | 12:21 |
| rgareus | rncbc: yes well I don't know what the user sends into the plugin. might as well be more than 1 event and high BPM. | 12:22 |
| rncbc | rgareus: yep | 12:22 |
| rgareus | he says hi hats. | 12:22 |
| rgareus | note-on + note-off -> actually *2 | 12:23 |
| rncbc | rgareus: yes, that's why the lv2 buffer size is doubled | 12:23 |
| rgareus | rncbc: I'll see if I can find an easy way to check if the plugin honors LV2 buffersize. If the answer is yes, it must be qtractor.. | 12:26 |
| rncbc | rgareus: trying with reps=50 0.1beat on 120bpm, ok. | 12:26 |
| rncbc | rgareus: trying with reps=50 0.1beat on 240bpm, still ok. | 12:27 |
| rgareus | send more notes :) | 12:28 |
| rncbc | rgareus: trying with reps=50 0.1beat on 280bpm, still ok. | 12:29 |
| rgareus | rncbc: how does it sound? | 12:29 |
| rncbc | rgareus: trying with reps=64 0.1beat on 280bpm, seems fine. | 12:29 |
| rgareus | rncbc: I just checked: the MIDI-event forge does not overflow, but there is potentially an incomplete event at the end. | 12:32 |
| *** NickSB2_ has joined #lv2 | 12:35 | |
| rncbc | rgareus: wait... at 0.1ms it doesn't seem to repeat the notes i send in... | 12:45 |
| rncbc | rgareus: i may be running an old midifilter.lv2 | 12:51 |
| rncbc | rgareus: midifilter.so dates from Jan 20 2014 | 12:54 |
| rncbc | rgareus: ok, will try again from a freshly git pull | 12:57 |
| rgareus | rncbc: there have not been any real changes (only typo fixes and portability) | 13:00 |
| rgareus | I just pushed a fix for the potential truncated event at sequence end, though | 13:01 |
| rncbc | rgareus: yes, but at 0.1ms i don't really seem to notice any repeated notes | 13:01 |
| rncbc | rgareus: sorry, not ms but repeat-time in beats | 13:03 |
| *** NickSB2_ has quit IRC | 13:05 | |
| rncbc | rgareus: i now wonder if the repeat-time is shorter than input note duration might have a role here | 13:07 |
| rgareus | rncbc: that's fine. note-off events are generated in that case | 13:07 |
| rgareus | rncbc: I just checked with jack-keyboard -> jalv.gtk "http://gareus.org/oss/lv2/midifilter#ntapdelay -> jack_midi_dump | 13:08 |
| rncbc | rgareus: so you might have interleaved note-ons and offs ??? | 13:08 |
| rgareus | no | 13:08 |
| rgareus | the plugin is smart enough | 13:08 |
| rgareus | or should be. | 13:09 |
| rgareus | still, dup note-on, or dup note-off would not cause crashes. | 13:10 |
| rncbc | rgareus: but fail in the instrument rendering | 13:11 |
| rncbc | rgareus: ok. i only seem to hear the repeat-time=0.1beat notes when i slow down the tempo bpm eg. 30bpm | 13:12 |
| rncbc | rgareus: maybe im just failing to see how this n-tay thing is supposed to work | 13:13 |
| rncbc | rgareus: but again it doesn't crash on rep-time=0.1 reps=50 on 30..280bpm | 13:15 |
| * rncbc goes lunch | 13:15 | |
| rgareus | rncbc: aah you're right.. there' a bug. | 13:15 |
| rgareus | only the repeats send on/off. | 13:16 |
| rgareus | the actual passed through event is not taken into account | 13:16 |
| *** NickSB2_ has joined #lv2 | 13:16 | |
| rgareus | note-on (pass thru). on, off, on, off, on, off (pass thru), off (close of last repeat) :( | 13:18 |
| *** falktx has quit IRC | 14:00 | |
| *** falktx has joined #lv2 | 14:01 | |
| *** drobilla has joined #lv2 | 15:31 | |
| *** NickSB2_ has quit IRC | 16:11 | |
| rgareus | rncbc: phew. that was more complicated than I thought; fixed the n-tap-delay dup on/off | 16:31 |
| rgareus | drobilla: have got a minute or 5 for ingen? | 16:33 |
| rgareus | drobilla: I'm halfway through debugging "no Atom message sent to UI" issue and want a 2nd opinion before filing a ticket. | 16:34 |
| rgareus | the actual issue: Buffer::update_value_buffer() simply returns because there's no value_buffer allocated for it. | 16:35 |
| rgareus | there's no value_buffer, because for Atom-ports _value_type == 0 | 16:36 |
| rgareus | LV2Block::instantiate() does not bother to check atom:supports and set _value_type to _uris.atom_Object or ... | 16:37 |
| rgareus | but that points to a deeper issue. it seems that in ingen a single atom-port can only every support one type | 16:37 |
| drobilla | rgareus: Atom ports that support a supported value type should have a value and all the stuff that goes along with it | 16:51 |
| drobilla | rgareus: But I haven't tinkered with this stuff in a while and AFAIK nobody else has ever done anything that would rely on it yet... | 16:51 |
| drobilla | rgareus: But if you are thinking about messages, you do *not* want any value stuff, because that port does not have a "value" | 16:52 |
| drobilla | "value" meaning it has some specific individual persistent probably scalar thing | 16:52 |
| drobilla | rgareus: i.e. for messages you don't want to look at that stuff at all | 16:54 |
| drobilla | rgareus: The code that is supposed to do this is PortImpl::monitor | 16:55 |
| rgareus | drobilla: ok, so I'm on the wrong track there. | 16:55 |
| drobilla | if (port is explicitly broadcasted && port is sequence) foreach(ev) send_to_client(ev) | 16:56 |
| rgareus | drobilla: thanks that's helpful. i'll dig a bit furter. | 16:59 |
| * drobilla is going to have to have a lot more 'fun' with value things if this parameter stuff is to work in ingen | 17:09 | |
| *** NickSB2 has quit IRC | 17:22 | |
| rgareus | drobilla: it fails since _monitored is false | 17:33 |
| rgareus | ---------------- | 17:33 |
| rgareus | } else if (_monitored && !buffer(0)->empty()) { | 17:33 |
| rgareus | // Monitoring explictly enabled, send everything | 17:33 |
| rgareus | ---------------- | 17:33 |
| rgareus | changing this to /* _monitored && */ context.notify() is called. and the events there are correct. but it still goes nowhere | 17:34 |
| rgareus | or at least it does not reach suil_instance_port_event() | 17:35 |
| drobilla | That should be set when the property ingen:broadcast is set from the UI. Special key in server/events/Delta.cpp | 17:41 |
| drobilla | (probaby the hairiest part of Ingen, whee) | 17:41 |
| drobilla | bbl | 17:41 |
| *** drobilla has quit IRC | 17:41 | |
| falktx | } else if (_monitored !buffer(0)->empty()) { | 17:43 |
| falktx | |damn keyboard | 17:43 |
| falktx | rgareus: probably should be || instead of && ? | 17:43 |
| rgareus | falktx: I don't think so. I think ingen should set _monitored to true before instantiating the UI. | 17:45 |
| rgareus | falktx: still that's only half of the deal. as the context notifications don't go anywhere. | 17:46 |
| rgareus | Context::emit_notifications is only a midi parser it seems | 17:46 |
| rgareus | the question is how or why it worked in the past. | 17:47 |
| rgareus | though it's probably 2 years since I last checked | 17:47 |
| rgareus | aha, it's easier than that. there's another is_monitored() check. | 17:51 |
| rgareus | simply initializing _monitored to true -> events come through | 17:51 |
| *** deva has quit IRC | 17:55 | |
| *** aombk has joined #lv2 | 18:02 | |
| *** Galik has left #lv2 | 18:37 | |
| *** edogawa has joined #lv2 | 19:04 | |
| *** uncle-j_j1 has quit IRC | 20:31 | |
| *** rncbc has quit IRC | 21:25 | |
| *** ventosus has left #lv2 | 21:30 | |
| *** uncle-j_j has joined #lv2 | 21:32 | |
| *** falktx has quit IRC | 21:42 | |
| *** edogawa has quit IRC | 21:48 | |
| *** falktx has joined #lv2 | 22:08 | |
| *** ricardocrudo has joined #lv2 | 22:18 | |
| *** ricardocrudo has quit IRC | 23:31 | |
| *** NickSB2_ has joined #lv2 | 23:47 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!