Strange behaviour of Trig1.ar duration input

Questions
#1

I have noticed that several audio rate ugens sample some of their inputs at control rate, i.e. use only the first sample of the signal per block. Is there some system to this behaviour? Is this documented anywhere? It really gets into the way when working with triggers at audio rate. Consider the following example:

(
Server.default.waitForBoot({
    play({
        var trigger;

        trigger = Impulse.ar(ControlRate.ir() + 1);
        Trig1.ar(trigger, trigger * 0.001) * 0.1
    });
});
)

This works as expected if we do not add the 1 to the ControlRate.ir() because then the trigger rate is in sync with the control rate, but under any other circumstances, the results are pretty unpredictable.

Am I missing a point here? Is there some good reason for this behaviour, or is it simply a bug? Some ugens, such as Latch.ar work as expected, i.e. sample their input when the trigger occurs.

#2

Unfortunately, there exist a lot of similar ar/kr inconsistencies, expected rates are usually not mentioned in the help files. I’m afraid this is an iceberg topic …

Looking up Trig1 at the github issue tracker, I was surprised to read an old report of mine :slight_smile:

Not exactly the same, but it contains also a possible workaround with ToggleFF that you could try.

Another thread with Trig1:

Personally, I’ve mostly been lucky with the usage of Duty, TDuty and ToggleFF for ar manipulations.

#3

This is really helpful, thank you very much!