Discussion: `cut` behaviour for simultaneous events (eg chords)

Questions and Answers
1

Over the years I've often run into issues where I'm executing simultaneous events (like chords with multiple notes) and attempted to use cut in combination with these chords only to find that they are no longer chords because cut limits the simultaneous event grouping to a single sound - eg

d1 $ n ("<af'sixNine'5 f'min11'5>/4") # s "superhoover"

-- vs
d1 $ n ("<af'sixNine'5 f'min11'5>/4") # s "superhoover"
   # cut 1 -- creates a single note

I'm not familiar enough with the internals of superdirt to know whether what I'm asking is impossible - but @julian is there a possibility that the cut behaviour could be modified to allow simultaneous events into the playback when they're on the same cut group?

2

Hi @cleary – I just saw this. The question is more a specification issue, I think. How would we distinguish between events in a chord and other events that just happen to be simultaneous?

Maybe we would need a variant of cut that cuts only across orbits, but not in the same. Would this be the expected behaviour?

3

Hey @julian thanks for the reply -

Expected behaviour would be that if there are:

  • simultaneous events
  • in the same orbit
  • with the same cut group applied

Then all events should be played.

If the events are not simultaneous, then the later events should stop playback of any earlier event that is:

  • in the same orbit
  • with the same cut group applied

If they are not meeting these orbit/cut group conditions then they should not affect each other.

Currently, the behaviour is that only one of the events will play, if there are:

  • simultaneous events
  • in the same orbit
  • with the same cut group applied

Some examples of expected behaviour:

d1 $ note "c'major" # s "superfm" # cut 1
 -- should play 3 notes, [c,e,g]

d1 $ note "c'major a'minor" # s "superfm" # cut 1 # legato 2
-- should play 3 notes, [c,e,g],
-- which are stopped halfway through the cycle by 3 more notes [a,c,e]

d1 $ note "c'major" # s "superfm" # cut 1 # orbit 1

d2 $ s "bd" # cut 1 # orbit 1
-- should play 4 notes, [c,e,g, bd]

d1 $ note "c'major" # s "superfm" # cut 1 # orbit 1

d2 $ note "~ a'minor" # s "superfm" # cut 1 # orbit 1
-- should play 3 notes, [c,e,g], 
-- which are stopped halfway through the cycle by another 3 notes [a,c,e]

d1 $ note "c'major" # s "superfm" # cut 1 # orbit 1

d2 $ note "~ a'minor" # s "superfm" # cut 2 # orbit 1
-- should play 3 notes, [c,e,g], 
-- followed by another 3 notes halfway through the cycle [a,c,e] 
-- which don't affect the first notes because they are in a different cut group

d1 $ note "c'major" # s "superfm" # cut 1 # orbit 1

d2 $ note "~ a'minor" # s "superfm" # cut 1 # orbit 2
-- should play 3 notes, [c,e,g], 
-- followed by another 3 notes halfway through the cycle [a,c,e] 
-- which don't affect the first notes because they are in a different orbit

I'm not sure this is a very good way to explain it, but I hope it's clear :grimacing:

4

Yes, it may affect some existing code, but it makes sense. Can you try this branch?

1 Like
5

Thankyou! This is behaving exactly as I'd hoped! :slight_smile: