Dear forum,

I'm trying to write my first external which is intended to synchronize a sequencer patch to ardour, via jack_transport.

My sequencer has a timecode granularity of 240 tick per beat, so I'd like the external to check if audio frames match a timecode, and if yes, to send this timecode through an outlet.

I started by modifying [jackclock] to get the first frame number of each audio cycle.
http://www.nicolasbouillot.net/blog.php?id=11

I have an equation for converting frame numbers to timecodes, function of sample rate, bpm and granularity, as well as a matching condition in case the timecode would fall between two frames.

What I need help for is figuring out how to, cycle by cycle, for each frame matching a timecode, output the timecodes in synchronization with their frames through a non-signal outlet.

In other words, how can I make an external output float messages at timings function of sample indexes in a cycle ? Is this even possible ?

Thanks for any clue.

Hello kyro,

Messages are scheduled inbetween audio blocks, it is not possible to interrupt an audio block (64 samples by default) to send a message.

The regular method to send a message from within a signal perform loop, is by scheduling the message with a call to clock_delay(). You could store the exact sample index in a the class struct member and send it with the message, in case you go back from message rate to signal rate later, and need sample-precise indexing.

An example of sample-precise indexing is in [slicerec~] and [sliceplay~] code included here:

http://www.katjaas.nl/slicejockey/slicejockey.html#downloads

Katja

>>
Messages are scheduled inbetween audio blocks, it is not possible to interrupt an audio block (64 samples by default) to send a message. <<

wow, you learn something new every day, cheers katja :0)

Oh. Which means I can't have a smaller timecode resolution than ~1.33 ms... Thank you very much for your answer, katjav. I had a look at slicerec~ source right before starting this thread, but understood nothing. After you explanation on clock_delay (and hours of trial and errors, but mostly errors) I think I finally got the point.

• First, in the perform loop I should fill a buffer with absolute sample index values for the current cycle. Like your "while(blocksize--)" part;

• Then I should check each sample of this buffer with an analysis function, which in case of matching would call clock_delay() to trigger a message;

And back to pd I would loose all the precision due to message scheduling... I'd better write an abstraction that would trigger simulaneously all timecodes expected in the cycle, instead of a c external involving pd audio and jack api notions.