<div dir="ltr"><div><i><br></i></div><i><div><span style="color:rgb(80,0,80);font-style:normal">On 30.11.18, Hanspeter Portner wrote:</span><i><br></i></div></i><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>In a given run(LV2_Handle instance, uint32_t nframes) method you are only<br></i><i>allowed to send events for frames 0 up to (nframes-1). If you need to delay your<br></i><i>events (and the scheduled event time is >= nframes), you need to store your<br></i><i>events and dispatch them at a later call to run().</i></blockquote><div><br></div><div>Perfect explanation, that clarifies why that did not work properly.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>As you support time:Position events on your input event port, you most probably<br></i><i>want to store incoming events with their respective musical/beat time in the<br></i><i>scheduler structure instead of the frame time.<br></i><i>E.g. if the tempo doubles (via host/user invertion) while your events are<br></i><i>waiting for dispatch in your scheduler structure, they'd automatically be<br></i><i>dispatched at double the speed, too.</i></blockquote><div><br></div><div>Yes, that makes sense. I've been having some synchronization issues with </div><div>beat time so have considered using the sample rate, last known tempo and time sig </div><div>to calculate the beat from the midi event timestamp. As you have pointed out, that </div><div>could present issues if I am queuing events for output so I will use beat time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>E.g. you want some infrastructure you can push newly receive events to and pop<br></i><i>previous events destined for dispatch in this run() cycle.</i></blockquote><div><br></div><div>Yes, so from the perspective of LV2 convention... is an array of structs acceptable in the </div><div>context of run(), or better to use something like atom:Tuple for this?<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 1, 2018 at 12:15 AM Hanspeter Portner <<a href="mailto:dev@open-music-kontrollers.ch">dev@open-music-kontrollers.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30.11.18 13:14, Dan H wrote:<br>
> Hi all<br>
> <br>
> I can't find much in the way of 'midi in-midi-out' examples to follow, so hope<br>
> someone here can help.<br>
> Let's say I have an LV2 plugin with an in-port buffer of type atom:Sequence<br>
> supporting midi:Event and time:Position, and I have an out-port buffer also of<br>
> type atom:Sequence. In the context of run(), I receive an incoming midi event at<br>
> frame# 96000 and I want to delay the output of that event by n frames. Is there<br>
> an 'LV2' way to queue events and manage the timing and order of atoms in a<br>
> sequence already implemented in the API? <br>
<br>
No<br>
<br>
> or do I need to find a way to do in c<br>
> code ... eg; waiting for nframes to arrive before forging the event atom?<br>
<br>
Yes (better use beat time, though, see below)<br>
<br>
> I have tried simply using: lv2_atom_forge_frame_time(&self->forge,<br>
> ev->time.frames + n) when forging the event, but that does not produce the<br>
> desired result.<br>
<br>
In a given run(LV2_Handle instance, uint32_t nframes) method you are only<br>
allowed to send events for frames 0 up to (nframes-1). If you need to delay your<br>
events (and the scheduled event time is >= nframes), you need to store your<br>
events and dispatch them at a later call to run().<br>
<br>
E.g. you want some infrastructure you can push newly receive events to and pop<br>
previous events destined for dispatch in this run() cycle.<br>
<br>
As you support time:Position events on your input event port, you most probably<br>
want to store incoming events with their respective musical/beat time in the<br>
scheduler structure instead of the frame time.<br>
<br>
E.g. if the tempo doubles (via host/user invertion) while your events are<br>
waiting for dispatch in your scheduler structure, they'd automatically be<br>
dispatched at double the speed, too.<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.lv2plug.in" target="_blank">Devel@lists.lv2plug.in</a><br>
<a href="http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in" rel="noreferrer" target="_blank">http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dan Hobday<br>E: <a href="mailto:madautodev@gmail.com" target="_blank">madautodev@gmail.com</a><br></div></div></div></div>