Using "cut" across different orbits

Questions and Answers
1

Hi all,

When I first started using Tidal, the different cut groups worked irrespective of orbit. So, in the following example, "bd" and "sine" would cut each other off, even though they are routed to different channels:

d1 $ stack [
    s "bd" # orbit 0 # cut 1,
    s "sine" # orbit 1 # cut 1,
]

As Tidal works now, you can only achieve the same effect if you put the two on the same orbit, which makes pattern interference much trickier if you want a multichannel output at the same time.

Does anyone know if there's a way of accessing the old functionality, and/or is there any mileage in adding global cut groups that work irrespective of orbit?

Many thanks,

Pete.

2

Welcome @petethomasmusique, how long have you been using Tidal? I was under the impression that orbits and cut groups always worked this way in superdirt but could be wrong. @julian might be able to confirm.
By multichannel output to you mean multi-track output to e.g. a DAW, or are you using a soundsystem with multiple speakers?

3

@yaxu Maybe since 2018...

And yes, my workflow is to send a multi-track output to a DAW for mixing / editing etc. @julian am I making this up in my mind? And would it be possible / not too much of a headache to implement a global cut group system?

4

Something like # gCut 1 or # globalCut 1

5

It is intended behaviour that you can cut across orbits, and I think it always has been the default. At the moment, the easiest way to separate the cuts is to assign different orbits to different cut groups.

Of course one could calculate the cut group id from a combination of orbit and the cut argument. That would be a new feature, and we'd need to think about how not to break other's code.

6

Thanks for your reply Julian. cut doesn't currently work across orbits. For example,

d1 $ stack [
    s "sine ~" # orbit 0 # cut 1,
    s "~ sine" # orbit 1 # cut 1
]

wouldn't work as they're on different orbits. It's the ability to use cut across orbits that I'm after, rather than separating orbits into separate cut groups. I'm sure this did work at some point in the past...

7

Ah yes, you are right. I overlooked that at some stage we made everything orbit-local. It would surely be possible to cut across as it used to be, but it might be awkward to maintain the extra complexity. A bit easier would be to specify the orbit with which you want to cross-cut, something like:

d1 $ stack [
    s "sine ~" # orbit 0 # cut 1,
    s "~ sine" # orbit 1 # cutOrbit 0 # cut 1 
]
8

Ah yes that would work great. Does that functionality currently exist or would you need to add it?

Thanks for your help with this.

Pete.

9

As it was easy to implement, I couldn't resist. It should be accessible in the latest development branch. You still have to add the # cutOrbit argument to tidal. Let me know it it works.

10

A.maz.ing!

Thanks Julian. I've installed Superdirt as a quark so it's still a bit of a mystery to me. I can see it in my ...Library/Application Support/SuperCollider/downloaded-quarks/SuperDirt. I can see a .git directory there. I assume it just functions like a normal git project and I can just checkout the development branch in there?

Will try out tonight. Thanks again - a small change maybe but one that makes lots possible for me!

Pete.

11

Hmm doesn't seem to be working. Have checked out the develop branch in SuperDirt added let cutOrbit = pI "cutOrbit" in Tidal and run this code:

d1 $ stack [
    struct "t f" $ s "bev" # orbit 0 # cut 1,
    struct "f t" $ s "bev" # orbit 0 # cut 1
  ]

As expected each line cuts off the other. Then I ran:

d1 $ stack [
    struct "t f" $ s "bev" # orbit 0 # cut 1,
    struct "f t" $ s "bev" # orbit 1 # cut 1
  ]

As expected cut no longer works across orbits. Then I ran:

d1 $ stack [
    struct "t f" $ s "bev" # orbit 0 # cut 1,
    struct "f t" $ s "bev" # orbit 1 # cutOrbit 0 # cut 1
  ]

The first line plays, but the line with the cutOrbit parameter stops playing. Any thoughts? Thanks in advance!

Pete.

12

Ah yes, there is (as usual) something about this that I've missed. This gave me a hint of how to simplify the cut mechanism on the sclang side.

I've made a branch, because this is a larger change.

you should be able to check it out by somethng like:

git fetch
git checkout topic-simplify-cuts

Will need some testing, but my first tests are ok:

-- should not cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 2,
      struct "f t" $ s "sitar" # orbit 0 # cut 1
    ]

-- should not cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 1,
      struct "f t" $ s "sitar" # orbit 1 # cut 1
    ]

-- should cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 1,
      struct "f t" $ s "sitar" # orbit 0 # cut 1
    ]

-- should cut (OK)
d1 $ slow 1.5 $ stack [
    struct "t f" $ s "sitar" # orbit 0 # cut 1,
    struct "f t" $ s "sitar" # orbit 1 # cutOrbit 0 # cut 1
  ]

  -- should not cut (OK, but note the difference: this doesn't cut its own track anymore)
  d1 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 1,
      struct "f t" $ s "sitar" # orbit 1 # cutOrbit 0 # cut 2
    ]
13

One note: this branch still sends the cut messages to the server, so if you have multiple instances of superdirt running on the same server, it won't work properly (you can cut between them …).

14

Brilliant.

Thanks Julian. I'll check that branch out and give it a spin.

Pete.

15

I have found it rather awkward that the orbits cut one way and not the other. I'll propose something simpler and closer to what you originally suggested.

16

OK, I've made it work another way. Needs further testing.


let cutAll = pI "cutAll"

-- should not cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 2,
      struct "f t" $ s "sitar" # orbit 0 # cut 1
    ]

-- should not cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 1,
      struct "f t" $ s "sitar" # orbit 1 # cut 1
    ]

-- should cut (OK)
d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cut 1,
      struct "f t" $ s "sitar" # orbit 0 # cut 1
    ]

-- should cut (OK)
d1 $ slow 1.5 $ stack [
    struct "t f" $ s "sitar" # orbit 0 # cutAll 1 # cut 1,
    struct "f t" $ s "sitar" # orbit 1 # cutAll 1 # cut 1
  ]

  -- should not cut (OK)
  d1 $ slow 1.5 $ stack [
      struct "t f" $ s "sitar" # orbit 0 # cutAll 1 # cut 2,
      struct "f t" $ s "sitar" # orbit 1 # cutAll 1 # cut 1
    ]
17

Yes! This is great. Makes good sense now. This also works:

-- first should cut itself only, second should be cut by first (OK)
d1 $ slow 1.5 $ stack [
    struct "t f" $ s "sitar" # orbit 0 # cut 1,
    struct "f t" $ s "sitar" # orbit 1 # cutAll 1 # cut 1
  ]

Thanks Julian. Putting it to good use right now.

18

Good! Try hard to break it, so we can be sure that it'll work. Also need to test negative cut values.

19

Here is the pull request: Simplify cuts by telephon · Pull Request #252 · musikinformatik/SuperDirt · GitHub

And, again, the branch ist here: GitHub - musikinformatik/SuperDirt at topic-simplify-cuts

Has it worked in the meantime?

2 Likes
20

merged to develop, I hope all works fine.