26 Mar
2011
26 Mar
'11
4:08 p.m.
Hi everybody,
I have a question.
I'm trying to figure out how to deal with transport locate changes
in my arpeggiator "flarps". I am generating MIDI events only when
necessary, so I'm not able to rewind the state of the program.
I only keep track of Note-off messages, because they can be sent
out in the future, to allow overlapping notes. All the MIDI notes
are calculated relative to each other. So I keep track of time
internally.
So I only need to know the first frame of the period,
when somebody does a jack_transport_locate, and I need to know
when this happens so I can initialize the program state.
My question is, if it would be acceptable to use the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
Is there a more preferable way to do this, or should I do major
redesign, and use the time jack provides with each period directly.
I would be very glad with any of your insights or suggestions.
greetings,
lievenmoors
26 Mar
26 Mar
4:18 p.m.
On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors <lievenmoors(a)gmail.com> wrote:
Hi everybody,
I have a question.
I'm trying to figure out how to deal with transport locate changes
in my arpeggiator "flarps". I am generating MIDI events only when
necessary, so I'm not able to rewind the state of the program.
I only keep track of Note-off messages, because they can be sent
out in the future, to allow overlapping notes. All the MIDI notes
are calculated relative to each other. So I keep track of time
internally.
So I only need to know the first frame of the period,
when somebody does a jack_transport_locate, and I need to know
when this happens so I can initialize the program state.
My question is, if it would be acceptable to use the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
its entirely appropriate.
Is there a more preferable way to do this, or should I
do major
redesign, and use the time jack provides with each period directly.
if you can do this in a way that still more or less meets the realtime
constraint:
T = F(nframes) + C
(that is, time per process cycle is a linear function of the nframes
value, plus a constant)
then simply doing it in every process call is fine. if not, then use
the sync callback.
4:45 p.m.
Hi Paul,
Thanks for your reply.
I'm not sure my program would satisfy the realtime constraint.
But I'll have a look at both options again...
Greets,
lievenmoors
On Sat, Mar 26, 2011 at 11:18:20AM -0400, Paul Davis wrote:
On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors
<lievenmoors(a)gmail.com> wrote:
Hi everybody,
I have a question.
I'm trying to figure out how to deal with transport locate changes
in my arpeggiator "flarps". I am generating MIDI events only when
necessary, so I'm not able to rewind the state of the program.
I only keep track of Note-off messages, because they can be sent
out in the future, to allow overlapping notes. All the MIDI notes
are calculated relative to each other. So I keep track of time
internally.
So I only need to know the first frame of the period,
when somebody does a jack_transport_locate, and I need to know
when this happens so I can initialize the program state.
My question is, if it would be acceptable to use the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
its entirely appropriate.
Is there a more preferable way to do this, or
should I do major
redesign, and use the time jack provides with each period directly.
if you can do this in a way that still more or less meets the realtime
constraint:
T = F(nframes) + C
(that is, time per process cycle is a linear function of the nframes
value, plus a constant)
then simply doing it in every process call is fine. if not, then use
the sync callback. 
7:50 p.m.
On Sat, Mar 26, 2011 at 04:45:51PM +0100, Lieven Moors wrote:
Hi Paul,
Thanks for your reply.
I'm not sure my program would satisfy the realtime constraint.
But I'll have a look at both options again...
using the sync callback to detect a skip in the transport is
not adequate usage of it.
an arpegiator is NOT a slow sync client. so... do not use the sync_cb !!!!
Greets,
lievenmoors
On Sat, Mar 26, 2011 at 11:18:20AM -0400, Paul Davis wrote:
--
torben Hohn
On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors
<lievenmoors(a)gmail.com> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev Hi everybody,
I have a question.
I'm trying to figure out how to deal with transport locate changes
in my arpeggiator "flarps". I am generating MIDI events only when
necessary, so I'm not able to rewind the state of the program.
I only keep track of Note-off messages, because they can be sent
out in the future, to allow overlapping notes. All the MIDI notes
are calculated relative to each other. So I keep track of time
internally.
So I only need to know the first frame of the period,
when somebody does a jack_transport_locate, and I need to know
when this happens so I can initialize the program state.
My question is, if it would be acceptable to use the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
its entirely appropriate.
Is there a more preferable way to do this, or
should I do major
redesign, and use the time jack provides with each period directly.
if you can do this in a way that still more or less meets the realtime
constraint:
T = F(nframes) + C
(that is, time per process cycle is a linear function of the nframes
value, plus a constant)
then simply doing it in every process call is fine. if not, then use
the sync callback.
10:02 p.m.
On Sat, Mar 26, 2011 at 2:50 PM, torbenh <torbenh(a)gmx.de> wrote:
On Sat, Mar 26, 2011 at 04:45:51PM +0100, Lieven Moors
wrote:
i didn't interpret his question as meaning that, but yeah, OK.
Hi Paul,
Thanks for your reply.
I'm not sure my program would satisfy the realtime constraint.
But I'll have a look at both options again...
using the sync callback to detect a skip in the transport is
not adequate usage of it.
27 Mar
27 Mar
12:23 a.m.
On Sat, Mar 26, 2011 at 07:50:12PM +0100, torbenh wrote:
On Sat, Mar 26, 2011 at 04:45:51PM +0100, Lieven Moors
wrote:
That's what I suspected...
I guess I will have to learn how to be a good slave :-)
Thanks,
lieven
Hi Paul,
Thanks for your reply.
I'm not sure my program would satisfy the realtime constraint.
But I'll have a look at both options again...
using the sync callback to detect a skip in the transport is
not adequate usage of it.
an arpegiator is NOT a slow sync client. so... do not use the sync_cb !!!!
Greets,
lievenmoors
On Sat, Mar 26, 2011 at 11:18:20AM -0400, Paul Davis wrote:
--
torben Hohn On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors
<lievenmoors(a)gmail.com> wrote:
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev Hi everybody,
I have a question.
I'm trying to figure out how to deal with transport locate changes
in my arpeggiator "flarps". I am generating MIDI events only when
necessary, so I'm not able to rewind the state of the program.
I only keep track of Note-off messages, because they can be sent
out in the future, to allow overlapping notes. All the MIDI notes
are calculated relative to each other. So I keep track of time
internally.
So I only need to know the first frame of the period,
when somebody does a jack_transport_locate, and I need to know
when this happens so I can initialize the program state.
My question is, if it would be acceptable to use the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
its entirely appropriate.
Is there a more preferable way to do this, or
should I do major
redesign, and use the time jack provides with each period directly.
if you can do this in a way that still more or less meets the realtime
constraint:
T = F(nframes) + C
(that is, time per process cycle is a linear function of the nframes
value, plus a constant)
then simply doing it in every process call is fine. if not, then use
the sync callback. 
26 Mar
26 Mar
9:40 p.m.
On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors <lievenmoors(a)gmail.com> wrote:
My question is, if it would be acceptable to use the
sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
I probably don't fully understand the problem, but I would expect an
arpeggiator to make use of the tempo and BBT info in the jack
transport state struct (I forget all the actual structure/field names)
so that the arpeggios are played in sync with other clients.
27 Mar
27 Mar
12:36 a.m.
On Sat, Mar 26, 2011 at 04:40:03PM -0400, Paul Coccoli wrote:
On Sat, Mar 26, 2011 at 11:08 AM, Lieven Moors
<lievenmoors(a)gmail.com> wrote:
Yes, that's the piece my program is missing.
Until now I've been generating the BBT info
(or part of it) within the program itself,
but without being a good slave, and without
having a timebase callback.
I'll have to figure this out...
Thanks for the reply,
lievenmoors
My question is, if it would be acceptable to use
the sync callback
to do this, because strictly speaking, my client wouldn't be a
slow sync client.
I probably don't fully understand the problem, but I would expect an
arpeggiator to make use of the tempo and BBT info in the jack
transport state struct (I forget all the actual structure/field names)
so that the arpeggios are played in sync with other clients.
4948
days inactive
4948
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Lieven Moors -
Paul Coccoli -
Paul Davis -
torbenh