Re: [Jack-Devel] JackTransport vs VST ppqPos

JACK cannot compute BBT based times. So i am not sure what you are
proposing. Would it be more clear if I read the patch? (I have limited
computing capabilities right now, so I haven't looked at it).


On Thu, May 16, 2013 at 12:39 AM, Pawel <[hidden]> wrote:

> Is there any good reason to not sync BBT with frames ?
>
> I made patch for jack_transport example client (actually it remove some
> unnecessary code ;-)
>
> ... but I just realized that there is always one way for compute BBT - so
> Jack should do this by self, and master client should change these values:
>                 pos->beats_per_bar = time_beats_per_bar;
>                 pos->beat_type = time_beat_type;
>                 pos->ticks_per_beat = time_ticks_per_beat;
>                 pos->beats_per_minute = time_beats_per_minute;
>
>
> What do you think ?
>
> P.
>
> Dnia Środa, 15 Maja 2013 10:59 Paul Davis <[hidden]>
> napisał(a)
> > ticks are intentionally integral, following a tradition that has
> developed in most (all?) MIDI sequencers over the last 20 years. the
> program defines N ticks per beat. 1 tick is the smallest absolute unit of
> musical time expressible with this series of time units - there is no
> concept of 0.5 ticks. typical values for ticks per beat are 1920, 3840 and
> so on - numbers with huge numbers of integer factors so that all common
> musical beat subdivisions can be expressed *without* floating point and
> with absolute precision. it is true that at the implementation level, this
> type of design is tricky to get right - you must be very, very careful with
> rounding. but it is not an accident that this is uint32_t and no value for
> "ticks" visible to a caller should ever be non-integral.
> >
> > On Wed, May 15, 2013 at 12:31 AM, Pawel <[hidden]> wrote:
> > > Dnia Niedziela, 12 Maja 2013 11:45 St&eacute;phane Letz <[hidden]>
> napisał(a)
> > > >
> > >  > Le 9 mai 2013 ? 03:22, Pawel <[hidden]> a &eacute;crit :
> > >  >
> > >  > > Hi,
> > >  > >
> > >  > > I discover strange problem while improving JackTransport support
> in FSTHost.
> > >  > >
> > >  > > Most VST plugins while trying to synchronize with host usually
> ask for such things:
> > >  > > 1) tempo ( == jack_pos.beats_per_minute)
> > >  > >
> > >  > > 2) ppqPos - which I understand like "current quarter note" ==
> current jack_pos.beat.
> > >  > >
> > >  > > 3) barStartPos .. ok, this one is not a subject in this case ;-)
> > >  > >
> > >  > > 4) samplePos == jack_pos.frame
> > >  > >
> > >  > > 5) sampleRate == jack_pos.frame_rate
> > >  > >
> > >  > > The problem is which pppPos. There are two ideas how to compute
> this:
> > >  > >
> > >  > > 1) Using BBT (which should be a preferred option here, right ?)
> > >  > > double ppqBar = (jp.bar - 1) * jp.beats_per_bar;
> > >  > > double ppqBeat = jp.beat - 1;
> > >  > > double ppqTick = (double) jp.tick / jp.ticks_per_beat;
> > >  > >
> > >  > > ppqPos = ppqBar + ppqBeat + ppqTick;
> > >  > >
> > >  > > 2) Using sample rate / current frame / tempo - this is a standard
> way in VST world. We count how much samples is in quarter note (beat) ..
> > >  > >
> > >  > > double ppq = jp.frame_rate * 60 / jp.beats_per_minute;
> > >  > > ppqPos = jp.frame / ppq;
> > >  > >
> > >  > > The problem is that .. this second counter "hurry" (sorry can't
> find better word for this issue in english ;-)
> > >  > > I made really simple , example app for observe this issue - it is
> included in FSTHost repository:
> > >  > > http://sourceforge.net/p/fsthost/code/HEAD/tree/trunk/jt-test.c
> > >  > >
> > >  > > Frame: 0013314048 | Bar: 0068 | Beat: 3 | Tick: 1680 | CBFF:
> 277.38 | CBFBBT: 270.88
> > >  > > Frame: 0013410304 | Bar: 0069 | Beat: 1 | Tick: 1600 | CBFF:
> 279.38 | CBFBBT: 272.83
> > >  > > Frame: 0013506048 | Bar: 0069 | Beat: 3 | Tick: 1500 | CBFF:
> 281.38 | CBFBBT: 274.78
> > >  > > Frame: 0013602304 | Bar: 0070 | Beat: 1 | Tick: 1420 | CBFF:
> 283.38 | CBFBBT: 276.74
> > >  > > Frame: 0013698560 | Bar: 0070 | Beat: 3 | Tick: 1340 | CBFF:
> 285.39 | CBFBBT: 278.70
> > >  > > Frame: 0013794304 | Bar: 0071 | Beat: 1 | Tick: 1240 | CBFF:
> 287.38 | CBFBBT: 280.65
> > >  > > Frame: 0013890560 | Bar: 0071 | Beat: 3 | Tick: 1160 | CBFF:
> 289.39 | CBFBBT: 282.60
> > >  > >
> > >  > > Please look that after a while CBFF > CBFBBT, and trend is that
> difference will grow. I tested this with either Hydrogen and jack_transport
> as master. The funny thing is that - when I skip location to for example in
> jack_transport:
> > >  > > jack_transport> stop
> > >  > > jack_transport> locate 0
> > >  > > jack_transport> locate 51111111
> > >  > > jack_transport> play
> > >  > >
> > >  > > CBFF and CBFBBT back to normal (almost) .. aha - so we know that
> formulas are good - and problem is in Jack.
> > >  > > Frame: 0051936967 | Bar: 0271 | Beat: 2 | Tick: 1184 | CBFF:
> 1082.02 | CBFBBT: 1081.62
> > >  > > Frame: 0052033223 | Bar: 0271 | Beat: 4 | Tick: 1104 | CBFF:
> 1084.03 | CBFBBT: 1083.58
> > >  > >
> > >  > > This was tested only with Jack2 (1.9.8 and 1.9.9.5).
> > >  > >
> > >  > > Any ideas ?
> > >  > >
> > >  > > Best Regards
> > >  > > Pawel / Xj
> > >  > >
> > >  >
> > >  >
> > >  > JACK does not do anything regarding those values: the timebase
> master *client* is responsible to update extended position information,
> counting beats, timecode, etc. (see :
> http://jackaudio.org/files/docs/html/transport-design.html)
> > >  >
> > >  > I don't see any specific issues here on OSX testing either with
> jack_transport or Ardour as timebase master (well I see CBFBBT value
> staying the same while CBFF moving with jack_transport  at very low tempo
> like 1 or 2)
> > >  >
> > >  > Can you try with Ardour also?
> > >  >
> > >  > St&eacute;phane
> > >  Thanks for answer Stephane.
> > >  Meantime I dig a little and I think that found a reason of this
> issue, If you look on this line from transport.c (jack_transport example
> client):
> > >  pos->tick += nframes * pos->ticks_per_beat * pos->beats_per_minute /
> (pos->frame_rate * 60);
> > >
> > >  IMHO it mean "how many ticks are in current period". If nframes is
> 256 and frame rate is 96k  and BPM is 5 (or less) you got 0.928798 ... but
> pos->tick is uint32_t .. so you actually got 0 ;-). OFC this is related to
> your settings and that's way YMMV. Well ... in some cases jack_transport
> will not push BBT at all ;-)
> > >
> > >  The problem is in Transport design itself - because BBT master works
> always in current cycle space/context - I mean - it  doesn't look at the
> history (anyway it can't if we want to have tempo changes, right ?), and
> because ticks are uint32_t  we will have always some rounding.
> > >
> > >  The most simple way to fix this that I see is push tick to double -
> but this probably made some compatibility issues :(
> > >
> > >  Or maybe someone have better idea - maybe we can use pos->frame to
> adjust pos->tick in next frame ?
> > >
> > >  Pawel / Xj
> > >
> > >
> > >  
> > >  Jack-Devel mailing list
> > >  [hidden]
> > >  http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
>
> 
> Jack-Devel mailing list
> [hidden]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>

1368692594.19456_0.ltw:2, <CAFa_cKkkj3kMsVCtYAquHRqQ7KzBFpUJgUmExfTmuM0esAY_vA at mail dot gmail dot com>