Tidal doesn't use control bus mappings

[matthewkaney]

While testing #1027, I discovered that current Tidal (1.9.4) isn't correctly using the control busses allocated SuperDirt, but is instead just always using busses 0-127. This usually isn't a problem, since most users just run SuperDirt on its own and it gets allocated that block of busses, but if you allocate more busses than that (for example by running SuperDirt.start multiple times), then the control bus indices out of sync and don't work correctly.

To reproduce:

1. Evaluate the following code in SuperCollider to start a SuperDirt server. Because 20 separate control busses are allocated first, SuperDirt gets the next set of 128 busses (20-147).

   (
   s.reboot {
       s.options.numBuffers = 1024 * 256;
       s.options.memSize = 8192 * 32;
       s.waitForBoot {
           ~otherBusses = Bus.control(s, 20); // Allocate some control busses
           ~dirt = SuperDirt(2, s); // Set up superdirt
           ~dirt.start(57120, 0 ! 12);
           s.dumpOSC(1); // Turn on server OSC dumping for test
       };
   };
   )

2. Start up Tidal, and evaluate the following line:

   import Control.Concurrent.MVar

3. Now, evaluate the following line in Tidal. It should print out an array starting with 20 ([20, 21, 22, ...etc]), demonstrating that Tidal received the correct bus mappings from SuperDirt.

   readMVar (sBusses tidal)

4. Now, evaluate the following pattern in Tidal:

   d1 $ s "supersquare" # n "c4" # lpfbus 0 "[80 8000]*4"

The correct behavior would be to produce a pulsing tone because of the alternating filter cutoff. However, SuperDirt is listening for input on control bus 20 (the 0th bus allocated to SuperDirt), but Tidal is sending its control messages to control bus 0 on the server. Because of this, the tone should be barely audible as it has a default filter cutoff of 0hz (I believe). SuperCollider should also be dumping OSC messages to the console that confirm this:

[ "#bundle", timestamp,
  [ "/c_set", 0, value ]
]

[yaxu]

I believe this was fixed in #1051, thanks to @matthewkaney !