is this constraint confirmed anywhere - this seems like a bad choice - i understood that there was only one checkbox for both transport/clock messages (which was a deviation from the older machines)
but having tried this on the Mk1s i can see that if the receiving device is expecting transport(and clock, seemingly implicitly for DT) then the device will engage transport but simply wait for clock too, rather than use its own clock settings
That would be a much better fallback position, i can’t believe that in the absence of any clock it doesn’t do this, this makes the decision to combine these two settings rather limiting imho, i’m super surprised it works this way
if the receiving device is only expecting transport the two will play but possibly at different tempos as no clock is shared
The FR for this should be separate checkboxes, surely it is an easy ask - but the next best option would be to use internal clock in teh absence of any arriving
The behaviour that @Eb82 is experiencing differs from teh analogs in that they respond to teh play message, but cannot proceed, they then timeout after 10/20 seconds and pause, whereas it sounds like the DT algo is to use internal clock as a fallback- it’s just waiting too long clearly
This clearly creates a headache for DT users
FWIW an option for those prepared to blow their warranty (at your own risk etc etc) would be to breakout a single pole switch option from the pcb tracks for the play and stop switches - it surely should be an easy mod although locating the output jack(s) could be tricky - but a single (small) TRS could probably do it and allow two momentary switches to be connected via a splitter cable, just a thought