Turns out I don’t grasp fl.future properly either (in addition to fl.chain). I’m trying to use it to schedule ticks from a ‘beat’ ‘tracker’, and am a very confused person.

  1. In mode relative , what are we relative to? The help file says an incoming frame, but the object seems to be behaving relative to the last time it triggered. Run this a bunch of times see FUT climb in the Max console:

  1. In mode absolute I don’t understand the conditions under which fl.future thinks it worthwhile to output. As before, run the below a bunch of time (well ,2). First time is what I expect, second time I only get one output.


In other news, the modes abs/rel of fl.chain seem to work precisely the opposite way round to what I’d expect, so perhaps there is a larger problem with my grasp of fl timing

Last week Alex and I were discussing some documentation stuff and I remarked that fl.chain~ does fl.future~'s job and more so perhaps its worth just fl.chaining if you want some temporally connected frame trigger magic.

My understanding is that in relative mode the timings are relative to the source frame’s arrival. So if it arrives at 100, and the numbers you give it are 1 and 2 you get frame’s triggered at 100, 101, 102. The absolute mode is asking you trigger in time compared to the arrival of the frame, but accumulating the values. When I think about the naming though, you are totally right and they seem to make not much sense until you see the modes at work. I think relative makes sense if you think about it being relative to the trigger frame, but absolute might be better renamed to something like “accumulative”. I’m not sure. Alex is doing object review now so I would let him know!

What is it that you’re trying to do? You are of equal or greater savviness in FrameLib land to myself, but perhaps a fresh set of eyes and ears can help you down your beat tracking path.

This thing comes up with (absolute) times for the next tick, but seems to want to revise these times based on incoming pulses. I don’t think either future or chain will let me schedule something, and then override it. This is the paper I’m implementing:

Although, now I think about it, this is probably a misreading of the paper, because what if the newly scheduled time was in the past? Eh? What then?

I’m not sure it works well enough to be worth sharing the patch in progress just yet. There’s been a lot of fl almost doing what I need, but not quite with this one

Okay so when you say absolute timings do you mean, now + time passed?

Some time since DSP started. There’s an initial period estimate, which is when the first beat is scheduled for, and then each beat after that is offset by the period (which is adapting).

So - it looks like fl.future~ needs a reset method, which is why you get different results after the first run - other than that absolute mode runs as expected. Relative mode seems a bit broken. I’m taking a look on the dynamic-contexts branch.

OK - looks like the reset is the only bug but the timings are in samples by default. This object may still disappear but at least is fixed up for now.

1 Like