Pulse sync

fubbi

I am using pulse and wave generators with tap tempo a lot. I have the feeling that they drift a little back and forth and have occasional hickups. Could it be?

DusX

I believe this is something that is being looked into with the upcoming addition of timecode.

mark

Dear @fubbi,

To test this, I created a MIDI track in Digital Performer that sent a single MIDI note at a rate of 60 bpm. I then used a Note On Watcher and a Tap Tempo actor to measure the tempo of those incoming MIDI notes. It was extremely precise, with errors ranging from approximately 0.1%. As I changed the tempo in Digital Performer, the BPM measured by Tap Tempo changed accordingly.

Then I added code to the Wave Generator so that it would measure the times between output when set to a square wave, i.e, whenever the value went from 0 to 100 or from 100 to 0\. The Wave Generator rate was set to '1 sec', meaning that the transition from 0 to 100 or vice-versa would happen every 0.5 seconds (500 mS). This is the output, showing the delta time between changes, and the over time since the Wave Generator was started.

04:53:37.113 - WaveGen: 0.499988 Sec - Since Start = 1.003084 Sec.

04:53:37.613 - WaveGen: 0.499830 Sec - Since Start = 1.502913 Sec.

04:53:38.134 - WaveGen: 0.521338 Sec - Since Start = 2.024251 Sec.

04:53:38.613 - WaveGen: 0.478856 Sec - Since Start = 2.503108 Sec.

04:53:39.113 - WaveGen: 0.499997 Sec - Since Start = 3.003105 Sec.

Here's some data from six minutes later

04:58:36.113 - WaveGen: 0.500194 Sec - Since Start = 300.003081 Sec.

04:58:36.613 - WaveGen: 0.500013 Sec - Since Start = 300.503094 Sec.

04:58:37.113 - WaveGen: 0.499915 Sec - Since Start = 301.003009 Sec.

As you can see, the error for each output is approximately +/- 1 millisecond, or 0.2%. The accumulated error over six minutes as 3 milliseconds, or 0.001%.

Admittedly, low cycle rates will affect these measurements, at least in terms of the error of the periodicity. But I am confident they would not change the accumulated error because of the way I'm calculating it.

So, these empirical tests would not seem to support your feeling. Is there any further information you can provide to help show us the problem in action?

Best Wishes,

Mark

Michel

@mark @fubbi

As long as you only test the accuracy of the pulse and wave generators its true, they are quite precise, but if scrolling the patch or moving actors it definitely starts to get out of sync. We were talking in Berlin about this, I think in future we have to put these time based actors to a separate thread.

Best Michel

Michel

@mark @fubbi

a screenshot of the drift.

fubbi

Thanks for diving in so deep. I just catch it visually sometimes. Both on the trigger output "x" and in whatever visual I am triggering.

I just filmed the trigger X and counted the frames in premiere, and they were inconsistent. The distance between the triggers varies a little bit. Admittedly, filming on an iphone might bring its own variation into the mix. I wish I could test it accurately somehow.

I think @michel is right, it could be other things in the patch. A thread of its own sounds right.

garretlinn

Hi All

so what was the end thought on this ?

I am using Pulse Generator and am also seeing the irregularities

in my case I am trying to drive a frame by frame animation (PNGs)

and the pulse is not reliable for 24 Hz (I can see the frame timings are off)

It does seem like the pulse is good as long as I have no input (or editing being done)

in my case I'm getting external inputs to change sequences of images

so the patch runs great as long as I don't touch (use)

but after changing values it the runs wonky and mis-timed

so as we don't have timecode yet

should I make a dummy MOV file and sync triggers to that?

or

Use an external MTC source?

or perhaps someone has a really better idea?

what is best practice to work around the pulse drift?

thanks in advance

(hi @fubbi )

Garret

garretlinn

OK I'm back

looks like the solution for me is

https://sononum.net/horae

a mac internal timecode generator $ but nice and works easy

but I'd still be very happy to know how other people deal with this task

thanks

G

DusX

Another option, is to use Javascript to drive the animation based on time.

You can write code that will move your png X% of the stage per second. (much like pixel per second)

I don't have a basic example available, unfortunately. This was something I taught in the Javascript classes in Berlin this summer.

I will prepare a tutorial and sample patch sometime soon. Hopefully that will be useful.

garretlinn

I've only started looking at the Javascript actor

so a tutorial would be great both for this solve

but also for javascript in general

(e.g. is there a way to use external Javascript Animation Libraries to do tweening?)

thanks!

G

DusX

You can use external libs, but many will reference built-in browser features (the DOM).

Purely math based libs are ideal for integration.

I will discuss this in the tutorial.

You can see an example of using the box2d physics engine in Isadora here:

https://www.youtube.com/watch?v=nGRrwlWq14E

That is the most complex external lib I have worked with in Isadora so far.

It offers a lot, and I think it works well in Isadora. So I will share those files as well.

bonemap

@DusX that is brilliant! Have you tried anything with naviar - stokes or other fluid dynamics by any chance? We are part way through developing a naviar-stokes plugin and have it running through QC at the moment.