[LV2] LV2 atom:Sequence question

[Dan H]

*On 30.11.18, Hanspeter Portner wrote:*
>
>
> *In a given run(LV2_Handle instance, uint32_t nframes) method you are only*
> *allowed to send events for frames 0 up to (nframes-1). If you need to
> delay your*
> *events (and the scheduled event time is >= nframes), you need to store
> your**events and dispatch them at a later call to run().*


Perfect explanation, that clarifies why that did not work properly.


> *As you support time:Position events on your input event port, you most
> probably*
> *want to store incoming events with their respective musical/beat time in
> the*
> *scheduler structure instead of the frame time.*
> *E.g. if the tempo doubles (via host/user invertion) while your events are*
> *waiting for dispatch in your scheduler structure, they'd automatically be**dispatched
> at double the speed, too.*


Yes, that makes sense. I've been having some synchronization issues with
beat time so have considered using the sample rate, last known tempo and
time sig
to calculate the beat from the midi event timestamp. As you have pointed
out, that
could present issues if I am queuing events for output so I will use beat
time.


> *E.g. you want some infrastructure you can push newly receive events to
> and pop**previous events destined for dispatch in this run() cycle.*


Yes, so from the perspective of LV2 convention... is an array of structs
acceptable in the
context of run(), or better to use something like atom:Tuple for this?

On Sat, Dec 1, 2018 at 12:15 AM Hanspeter Portner <
dev at open-music-kontrollers.ch> wrote:

> On 30.11.18 13:14, Dan H wrote:
> > Hi all
> >
> > I can't find much in the way of 'midi in-midi-out' examples to follow,
> so hope
> > someone here can help.
> > Let's say I have an LV2 plugin with an in-port buffer of type
> atom:Sequence
> > supporting midi:Event and time:Position, and I have an out-port buffer
> also of
> > type atom:Sequence. In the context of run(), I receive an incoming midi
> event at
> > frame# 96000 and I want to delay the output of that event by n frames.
> Is there
> > an 'LV2' way to queue events and manage the timing and order of atoms in
> a
> > sequence already implemented in the API?
>
> No
>
> > or do I need to find a way to do in c
> > code ... eg; waiting for nframes to arrive before forging the event atom?
>
> Yes (better use beat time, though, see below)
>
> > I have tried simply using: lv2_atom_forge_frame_time(&self->forge,
> > ev->time.frames + n) when forging the event, but that does not produce
> the
> > desired result.
>
> In a given run(LV2_Handle instance, uint32_t nframes) method you are only
> allowed to send events for frames 0 up to (nframes-1). If you need to
> delay your
> events (and the scheduled event time is >= nframes), you need to store your
> events and dispatch them at a later call to run().
>
> E.g. you want some infrastructure you can push newly receive events to and
> pop
> previous events destined for dispatch in this run() cycle.
>
> As you support time:Position events on your input event port, you most
> probably
> want to store incoming events with their respective musical/beat time in
> the
> scheduler structure instead of the frame time.
>
> E.g. if the tempo doubles (via host/user invertion) while your events are
> waiting for dispatch in your scheduler structure, they'd automatically be
> dispatched at double the speed, too.
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>


-- 
Dan Hobday
E: madautodev at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20181201/cc3baee9/attachment.html>