Note control delayed with synth `dsaw`

Support, Help & Resources
21

It also appears with the cutoff opt, but note, cutoff and amp are the only opts I tested so far. The delay you see is very close to the one I have, which I coarsely measured in Audacity to be between 0.03 to 0.04 s. Further, this seems independent from the bpm value (here: 60, original project: 125).

Which synth did you use?

22

Just used the program posted above, i.e. dsaw and without the choice in the control line. But with the note option.

23

@Nechoj Can you confirm the consistent note delay on your machine?

24

Yes. I changed the setup to play alternating notes with an octave difference

sca = [:F2, :F3]
live_loop :bass, sync: :tick do
  with_synth :dsaw do
    use_synth_defaults detune: 0, sustain: 8, release: 0, amp: 0.6
    syn = play sca.tick
    sleep 2
    3.times do |n|
      control syn, note: sca.tick
      sleep 2
    end
  end
end

Then we can see the frequency also in my recordings

test4

test5

test6

There are 3 different patterns:

  1. Change from low to high frquency with a delay of at least 1/32 ā€¦ 2/32
  2. Change from high to low frequency with the same delay
  3. Change from high to low frequency with no delay but the low frequency amplitude kindof ramps up.

EDIT: the third pattern probably is caused by the play command without control. No surprise if they would behave differently.

1 Like
25

And the :sine synth does not show this behaviour:

test7

Such transitions are always a bit unsharp. There is the fundamental frequency-time relationsship Ī”t Ī”f=1. Depending on the size of frequency hop there will be a time needed for the transition. But the :sine example shows that this does not explain the problem at hand.

1 Like
26

Apologies for not being more specific earlier. I meant the block_size config option. Try setting it to lower values such as 32 or 16 and see if that makes any difference to the timings.

As far as I understand things at that level, the sound_card_buffer_size will add additional latency to all audio going in and out of the sound card but I believe that latency is more or less constant. Whereas the control messages need to be acknowledged and honoured which can only happen at the audio buffer boundaries within the SuperCollider realtime audio engine.

27

I tried block sizes of 32 and 16, but still no change of the delay.

28

Hmm, Iā€™m really not sure what could be causing your observations. Itā€™s possible that itā€™s something specific either to the design of the synths or the implementation of the so-called ugens that the synths are designed with - this is even more likely the case if youā€™re observing reliably different behaviour across synth types.

Iā€™m not sure what would be the best route to take to look into this more deeply. One option might be to try and replicate this in pure SuperCollider. If you can observe similar behaviour there, then thereā€™s not much we can do downstream here in Sonic Pi land. If you canā€™t replicate it in SuperCollider, then thereā€™s a good chance that somehow Sonic Pi is doing something weird.

Also, could you spend a moment listing which synths youā€™ve tested with and what their specific observed timing behaviours are?

29

I was also thinking about that, but have zero experience with SuperCollider, so it would probably hard to do for me.

Regarding synths, I so far consistently observed delays with saw and dsaw, but not with tb303. Further, @Nechoj reported no delay with sine. I will try to test some more in a systematic way the next days.

Gererally, many thanks for your time spent on this, also to the other thread contributors!