What's the best way of delaying a Gate signal?

Question

I've been working on a sound where several gate signals are logically combined (AND-ed using "*") but the gates are updating at slightly different times so I'm getting a kind of clocking error and not the behaviour I wanted. I can fix this by adding a small delay to one of the gates.

I've been using the "turnOnAfter:...for:"  message, but I don't really want to specify the "for:" argument, I just want to delay the gate signal and preserve its original length, or rather not have to worry about its length.

I couldn't see what message would be best to delay a gate by around 0.001 s or so.

Answer 1

Not sure how your Sound looks but if you paste a constant into another constant you get a 0.001 s delay. That might be both the source and the solution for your problem: Paste the gate signal you want to delay in another constant and you should be fine. I've attached an example of this.

If you are after aligning gates with each other you should check the alignGateWith: message (alignWith: might be helpful as well).

Let me know how it goes :)

http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=14432682245890072999

Comments

Thanks! That's really helpful.

When you say "paste a constant into another constant", I imagine you mean select a sound in the signal flow diagram and paste it into a parameter of another sound and it shows a small pale rectangle. But is this the same as using an event hotvalue?

For instance say I've got a STGC like:
GeneratedEvent: !Gate1
Value: 1 bpm: 1 s

And then I've got another STGC like:
GeneratedEvent: !Gate2
Value: !Gate1

Is !Gate2 going to be 0.001s behind !Gate1, or is that only going to be the case if I cut and paste the first sound into the second sound's Value parameter?

---

Yes, that's what I meant. Did you click the link and downloaded the Sound? What I described is in there.
No, I guess when using STGCs they will all evaluate at the same time..

I think it's best to upload your Sound as SSC suggested ;)

Answer 2

How are you generating the gates that you are ANDing together? Are they from STGCs? Incoming OSC messages? The general rule-of-thumb would be to try to derive all gates from the same "clock". Please describe how the gates are generated or, better yet, attach a Sound demonstrating the behavior.  It would be best to avoid adding any kludge delay at all(!)

Comments

Here's the sound.

RhythmicSamplePlayer Example

The main clock is a STGC called RhythmGate with the Value: !Gate bpm: !BPM

Let me try and explain the desired behaviour. There is an array of 48 values which represent a sequence of Index values for the multisample player. The sound sequences through this array in order.

There is also a second array of "rhythm" values which all have the value 1 or 0.

The clock cycles through the rhythm array. If the current rhythm value is 1 then the sample player will play and the sample array will advance one step. If the rhythm value is 0 then the sample player will not play and the sample array does not advance. So the zeros in the rhythm array effectively represent rests.

Originally there was only one clock signal (ArrayGate). Both the Position and RhythmPosition STGCs used this clock to advance their genereated event value which are the indexes into the sample and rhythm arrays.  But it didnt' work properly. 

The Position STGC has the following value:
Value: (!Rhythm * (!ArrayGate * (1 - !ClockDisable))) nextIndexMod: 48 reset: !Start

What would happen was that a single 0 in the rhythm array would have no effect - a sample would play as if it was a 1 and the sample array position would advance. If there were two consecutive 0s in the rhythm array then it would act as if it was a 1 and a 0, in other words the first 0 would act like a 1, but the second 0 would act like a rest.

It seemed like the !Rhythm and !ArrayGate signals were out of sync a little bit so !Rhythm was still 1 from the previous clock cycle when !ArrayGate triggered.

As you can see the way I've got round it is I've created two clock signals, !ArrayGate and !RhythmGate, where !ArrayGate is delayed behind !RhythmGate using this expression in its value parameter: !RhythmGate turnOnAfter: 0.002 s for: ((!BPM bpm s) / 2)

---

In your Sound, you have a chain of STGCs where the generated !RhythmGate generates !RhythmPosition which generates !Rhythm which generates !Position which generates !Index. Also, !RhythmGate generates !ArrayGate which is also used in generating !Position.

This means that when !RhythmGate turns on, there is a cascade of changes to those other EventValues, all occurring at slightly different times, making it difficult to know when all of the expressions have reached their final values.

One way to deal with this kind of timing problem is to *change* the values and *use* the values on separate edges of the clock.

For example, you could use !RhythmGate to change the values (for example, with nextIndexMod: as you do now) and use (1 - !RhythmGate) in the Gate of the Multisample.