<div dir="ltr">>>> Hanspeter Portner wrote:<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>>> Dan H wrote:<br>>> Yes, so from the perspective of LV2 convention... is an array of structs<br>>> acceptable in the context of run(), or better to use something like <br>>> atom:Tuple for this?<br>><br>> Hanspeter Portner wrote:<br>> Use whatever fifo-like structure that suits your use case. Just make sure it is<br>> appropriate to be used in an audio thread, e.g. it needs to be lock-free,<br>> wait-free, realtime-safe, etc.<br><br>I have solved this with the info on this thread. I should also mention I found this <br>somewhat useful as an example: <a href="https://github.com/x42/midifilter.lv2">https://github.com/x42/midifilter.lv2</a><br>Many thanks</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Dec 2, 2018 at 9:26 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 01.12.18 09:05, Dan H wrote:<br>
> /<br>
> /<br>
> /<br>
> On 30.11.18, Hanspeter Portner wrote:/<br>
> /<br>
> /<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<br>
> 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>
> <br>
> Perfect explanation, that clarifies why that did not work properly.<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>
> //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>
> <br>
> Yes, that makes sense. I've been having some synchronization issues with <br>
> beat time so have considered using the sample rate, last known tempo and time sig <br>
> to calculate the beat from the midi event timestamp. As you have pointed out, that <br>
> could present issues if I am queuing events for output so I will use beat time.<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>
> <br>
> Yes, so from the perspective of LV2 convention... is an array of structs<br>
> acceptable in the <br>
> context of run(), or better to use something like atom:Tuple for this?<br>
<br>
Use whatever fifo-like structure that suits your use case. Just make sure it is<br>
appropriate to be used in an audio thread, e.g. it needs to be lock-free,<br>
wait-free, realtime-safe, etc.<br>
<br>
> On Sat, Dec 1, 2018 at 12:15 AM Hanspeter Portner <<a href="mailto:dev@open-music-kontrollers.ch" target="_blank">dev@open-music-kontrollers.ch</a><br>
> <mailto:<a href="mailto:dev@open-music-kontrollers.ch" target="_blank">dev@open-music-kontrollers.ch</a>>> wrote:<br>
> <br>
> 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<br>
> event at<br>
> > frame# 96000 and I want to delay the output of that event by n frames. Is<br>
> 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>
</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>