Gate Length

[UrbanCyborg]

What is a reasonable length for a gate signal that's a one-shot? For that matter, what would be a max, and where would you consider the minimum? Two samples for a min? Otherwise, it could be confused with a trigger.

Well, and for that matter, I know many modules use a single high sample as a trigger, but I also know some other modules have trouble seeing a single sample sometimes. I figured three samples would be reasonable for a trigger, as any module that couldn't see that was handling its recognition code using a timer.

Thoughts?

Reid

[utdgrant]

What would be the intended purpose of the gate output signal? I think this will help guide your specifications / requirements.

Is there likely to be any requirement for audio-rate operation in the gated module?

Will it be used as the gate signal for an envelope generator? If so, what is the shortest rise time of the attack parameter?

[UrbanCyborg]

Grant, I'm talking the most generic kinds of gates and triggers, the sort, say, that CA modules generate. You should be able to feed them to any input that wants gates or triggers, and have them work. That's why I'm asking; I'm somewhat vague on the specifics. Prior to this, the extent of my involvement with that sort of thing was in my Poly Permuter module; I designed it to accept, theoretically, either triggers or gates as input to its Step jack. What I found in testing, though, was that it wouldn't see triggers, and needed a somewhat longer gate. This is a consequence of how I detected gate/trigger onset; I did the testing for it in the 50 ms timer thread, so it couldn't see triggers, and only saw gates if they were long enough for them to overlap timer notifications. I'd bet there are lots of variations on this sort of thing in many modules, so I'm looking for values as defaults that would work in most instances.

Reid

[ColinP]

Checking for gates or triggers in a timer thread is a really bad idea.

Always do it in the ProcessSample() thread.

The difference between a trigger and a gate is just that trigger detection works on the rising edge.

Here's how I code trigger detection.

Code: Select all

private boolean checkForClockInput()
{
   // check for clock input rising edge
   if( clockIn.IsConnected() )
   {
      // detect rising edge...
      if( clockIn.GetValue() > TRIGGER_THRESHOLD )
      {
         if( clockInDetected == false )
         {
            // rising edge detected
            clockInDetected = true;
            return true;
         }
      }
      else
      {
         // trigger input is low
         clockInDetected = false;
      }
   }
   else
   {
      // no clock input
      clockInDetected = false;
   }
   return false;
}

On outputs - a single sample trigger should work but if you send that to most envelope generator designs they will abort the attack phase after one sample and this confuses many users as they expect something useful to happen.

So one could make an argument that triggers should last say 1 ms (48 samples) as this will at least produce some noticeble effect from your average EG. But it's a messy solution if you want to do complex high frequency logic. Personally I think envelope generators should commit to attack phase completion by default rather than expect trigger duration to compensate for the common user misconception.

[utdgrant]

I always do trigger and gate detection within the ProcessSample function. Polling every 50ms seems like far too wide a window for musical purposes.

That way, you can be consistently tolerant of gate / trigger inputs from any other module.

Unfortunately, you can't really second-guess what signals an external module will be looking for, unless it's explicitly stated in the user guide. If you want to give all third-party modules the best chance of catching a gate signal, keep it high for as long as you can. Also, make sure you leave long enough a gap before attempting to retrigger.

Edit: What Colin said!

[terrymcg]

Gates are long triggers or triggers are short gates.

https://noiseengineering.us/blogs/loque ... s-triggers

The other "traditional" difference is that you might care about both start and end points for gates, but you're usually only interested in the start point for triggers. At the module level, the distinction is going to be functionally driven - does a particular module function need one or the other. FWIW, BCI modules generate 5ms triggers (but will accept shorter or longer ones).

As has already been pointed out, input/output processing (like gate/trigger detection) should be done in/via ProcessSample().

Cheers,
--
Terry McG

[UrbanCyborg]

Thanks for the replies, everyone. Food for thought.

Reid

[utdgrant]

Personally I think envelope generators should commit to attack phase completion by default rather than expect trigger duration to compensate for the common user misconception.

Oh god, no.

No, no, no.

Unconditional completion of the attack phase robs an envelope generator of any expressive 'playability'.

Having an unconditional attack is nice to have as an option but IMO should never be the default. And NEVER, EVER the sole operating mode (as in the VCS3).

I know I'm obsessive about envelopes; we all have our cross to bear.

However, an unconditional attack phase is second only to "Return-To-Zero" on retrigger, in terms of crimes against nature.

[ColinP]

Oh god, no.

No, no, no.

Unconditional completion of the attack phase robs an envelope generator of any expressive 'playability'.

That's presumably because you are looking at things from the perspective that EGs are always being controlled by a human sourced gate. While I'm looking at this from the perspective of EGs being sequenced by a trigger source (which is the most likely focus in a discussion about trigger lengths).

I agree that terminating the attack phase as soon as the gate drops can be very useful from an expressive POV so should definitely be an option. But most EGs don't give one any option - they always terminate. If the option isn't available then I'd prefer attack phase commit for the reason given below

Not having at least the option of attack phase commit can be a real pain in a sequenced setup (something very common in modular as opposed to simulations of vintage synths) because one often needs to use a trigger to gate function in order to get any sound at all. And this isn't a good solution as when the attack rate is varied (perhaps under voltage control) the gate length of the trigger to gate function needs adjusting too.

This is something I've recently had to address in my upcoming N-Step sequencer. N-Step produces four flavors of trigger/gate simultaneously but I still needed to add a LENGTH knob and this suffers exactly the problem described above.

The only way to overcome this is to provide CV control of the length parameter - something which N-Step does, but even this is not an ideal soultion. Although it does give the choice of using one sequencer channel to vary the length step by step - which provides the kind of expressive control you are talking about when an EG terminates its attack phase on early gate drop.

At some point I'm going to produce my own envelope generator as I'm not happy with any currently available in VM.

[utdgrant]

Not having at least the option of attack phase commit can be a real pain in a sequenced setup (something very common in modular as opposed to simulations of vintage synths) because one often needs to use a trigger to gate function in order to get any sound at all. And this isn't a good solution as when the attack rate is varied (perhaps under voltage control) the gate length of the trigger to gate function needs adjusting too.

When I was developing the Big Rat (my first commercial module), I made sure there was a way to force attack phase completion. This is achieved by feeding the 'Square' output back into the gate input, effectively OR'ing the two signals together (in an analogue way). It will 'latch' the input gate signal within two sample periods:

BigRatUnconditionalAttack.jpg (106.45 KiB) Viewed 2864 times

At some point I'm going to produce my own envelope generator as I'm not happy with any currently available in VM.

Awesome! There's always room for a new twist on the EG theme. ESPECIALLY when it's scratching the unique itch of a particular developer.