TBD-16 Simulator / Development Environment

FAQ / Support
1

This is to get feedback on our Simulator and Development tooling for the TBD-16.

4 Likes
2

Hi, I’m having trouble compiling the simulator on a mac (newish, Apple silicon, M3). I can dump more messages here, but the essentials seem to be:

“_jack_set_xrun_callback”, referenced from:
RtApiJack::probeDeviceOpen(unsigned int, RtApi::StreamMode, unsigned int, unsigned int, unsigned int, unsigned long, unsigned int*, RtAudio::StreamOptions*) in librtaudio.a2
ld: symbol(s) not found for architecture arm64
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

EDIT: please move this to its own topic if needed, I couldn’t see how to do that.

EDIT 2: Fixed it for myself, PR raised at fix(simulator): disable RtAudio JACK backend on macOS arm64 by baob · Pull Request #18 · dadamachines/ctag-tbd · GitHub

1 Like
3

Hi there.
I have merged your PR and did a couple more fixes.
Hopefully everything is smooth now.

1 Like
4

Cool, this works!

Couple of gotchas

  1. cmake version available through Ubuntu default apt is 3.28.3, apparently boost requires cmake > 3.30 (build step complained about a missing policy). I grabbed the official binaries but there are other workarounds
  2. Not hearing anything because my system default sound card was a strange choice (ie Ubuntu picked a strange sound card choice as standard out), changing that to my external card and I had sound :slight_smile:
5

Moved:

Regarding development for this unit - the current json based API supports setting a single track number for the plugin.

Would you be interested in changing that to be either an array of up to n track ids, or even better 1-n plugin categories (Lead, Bass, Drum, etc)?

6

Amazing to have a simulator for this! I’ve been able to build my first engine! GitHub - charlesvestal/dada-nusaw at feature/nusaw · GitHub (It’s an implementation of the JP-8000 Supersaw algorithm, as detailed in various recent talks and research).

In doing so, I ran across a few simulator issues, but wanted to check if they were just me-gotchas or something that would be useful upstream.

  1. rackgen.js doesn’t emit stereo dispatch. New machines need their out[BUF_SZ] renamed to _out_stereo[BUF_SZ*2] and the dispatch swapped to mixRenderOutputStereo. Would a “stereo”: true descriptor flag be welcome?
  2. rackgen.js doesn’t patch GetRoutingSnapshot(). rack-lint fails with “voice has no matching entry in routing registry” until you hand-add emitBool(“chN_”, chN_.enabled); in the right per-track block.
  3. rackgen.js uses mui.params[desc.track] as if it’s track N’s container in mui-GrooveBoxRack.json, but that array is a flat list of groups (mixer + machine groups across all tracks), not track-indexed. My machine on track 8 (desc.track=8) got pushed into mui.params[8] which is ch3_ds_group so the WebUI rendered it nested under CH03 SNARES.
  4. tbd-sim defaults to --device 0 regardless of whether that device has output channels. The sim auto-enables --output mode when duplex is missing, but doesn’t pick a device with usable output: silent boot on macOS where device 0 is often a DisplayPort monitor. Falling back to the first device with outputChannels > 0 would be safer.
  5. Super small, but the generated member declaration in ctagSoundProcessorGrooveBoxRack.hpp uses tab indentation (3 tabs) inside a file that’s space-indented (4 spaces). Looks misaligned in any editor.

Lastly, it would be nice to have some sort of performance profiling/target here. I’m really shooting in the dark as to what might load on real hardware.

Happy to file each as a separate PR if these are real, or to be told “that’s known, here’s the workaround” :slightly_smiling_face:

One more note: I’m using Claude heavily for this. I’m reading and validating as I go, and these were real things I had to work around, but happy to dial back if AI-assisted contributions aren’t welcome here.

3 Likes