On Tue, 2012-05-08 at 18:28 +0200, Ralf Mardorf wrote:
> Thank you Paul :)
>
> this explains a lot. The Atari ST usually worked good with some
> equipment here, but IIRC the Prophet Studio 440 didn't work good.
^^^ *chuckle* I guess you know what I
mean ;).
> I al
Thank you Paul :)
this explains a lot. The Atari ST usually worked good with some
equipment here, but IIRC the Prophet Studio 440 didn't work good.
I also tested Linux, but I can't remember what exactly worked and what
didn't work.
Regards,
Ralf
___
Li
On 05/08/2012 05:24 PM, Fons Adriaensen wrote:
> On Tue, May 08, 2012 at 03:50:44PM +0200, Robin Gareus wrote:
>
>> @Paul, Fons,..: does it use a PLL or simply return the difference from
>> clock_gettime() since the beginning of the cycle?
>
> jack_frame_time() reads the current time from Jack's
On Tue, May 08, 2012 at 03:50:44PM +0200, Robin Gareus wrote:
> @Paul, Fons,..: does it use a PLL or simply return the difference from
> clock_gettime() since the beginning of the cycle?
jack_frame_time() reads the current time from Jack's usecs timer,
subtracts the cycle start time estimated by
On Tue, May 8, 2012 at 10:30 AM, Ralf Mardorf
wrote:
> Using MTC with different Linux software and different external hardware
> sometimes doesn't work or only works if one is slave and the other is
> master, but it won't work vice versa. An issue that also sometimes
> happened in the 80s without
On Tue, 2012-05-08 at 10:11 -0400, Egor Sanin wrote:
> I know there's MTC code in xjadeo (and qtractor or some other DAWs, I
> think), but I want a standalone console tool. Admittedly, I haven't
> looked at xjadeo code in detail, I'm trying to wrap my head around the
> concepts first.
Using MTC w
On 05/08/2012 04:11 PM, Egor Sanin wrote:
> On 5/8/12, Robin Gareus wrote:
>> s/drop/skip/
> Yes, correct.
>
>
>> JACK-transport timecode (as returned by jack_transport_query())
>> increases in steps of the period size. It depends on the application
>> what to make with this.
> Yes, exactly, see
On 5/8/12, Paul Davis wrote:
> you cannot assume that there are zero or one SMPTE frames per JACK
> period. if your conversion or your use of the value is based on that
> assumption, it will not work. the SMPTE frame value may change
> anywhere within the JACK period and it may change multiple tim
On 5/8/12, Robin Gareus wrote:
> s/drop/skip/
Yes, correct.
> JACK-transport timecode (as returned by jack_transport_query())
> increases in steps of the period size. It depends on the application
> what to make with this.
Yes, exactly, see below.
> jack_frame_time() OTOH estimates the time an
On Tue, May 8, 2012 at 9:58 AM, Egor Sanin wrote:
[ ... ]
you cannot assume that there are zero or one SMPTE frames per JACK
period. if your conversion or your use of the value is based on that
assumption, it will not work. the SMPTE frame value may change
anywhere within the JACK period and
On 5/8/12, Paul Davis wrote:
> what do you mean by "drop SMPTE frames" ?
>
Yes, I apologize, looking back, the question wasn't very clear.
Picture the following scenario.
I read the current jack frame (at the beginning of the process cycle,
say 'c') and convert it to SMPTE time, the result is
hh
On 05/08/2012 05:07 AM, Egor Sanin wrote:
> Hi folks.
Hi Egor,
> I've got a question about SMPTE frames and jack period size.
> In the "worst case" of 30 frames/second, each frame spans 1/30 seconds.
> Does that mean that if jackd is called such that (period size)/(rate)
> ≥ (1/30) seconds, we wi
On Mon, May 7, 2012 at 11:07 PM, Egor Sanin wrote:
> Hi folks.
>
> I've got a question about SMPTE frames and jack period size.
> In the "worst case" of 30 frames/second, each frame spans 1/30 seconds.
> Does that mean that if jackd is called such that (period size)/(rate)
>> (1/30) seconds, we wi
13 matches
Mail list logo
