Page 1 of 2

Transport CV out triggers

Posted: Wed Aug 31, 2022 1:38 pm
by Waverley Instruments
Wondered if anyone could help with specifics on these. The docs say:

Play- Transmits a 5V trigger when play mode is initiated in DAW host software.
Stop- Transmits a 5V trigger when stop mode is initiated in DAW host software.


I'm guessing a set number of frames is sent? Anyone know how many?

I'm trying to simulate the triggers exactly for testing purposes, otherwise it's a bit of a faff and fiddle testing in an actual DAW.

Thanks, -Rob @ WI

Re: Transport CV out triggers

Posted: Wed Aug 31, 2022 5:05 pm
by utdgrant
Both last exactly one sample period.

......., 0V, 0V, 0V, 0V, 0V, 5V, 0V, 0V, 0V, 0V, 0V,......

I sent the PLAY and STOP outputs directly into the Main L&R audio outs, then recorded the output whilst being driven by Reason 12. I don't know if it's any different for other DAWs.

Regards,
Grant

Re: Transport CV out triggers

Posted: Wed Aug 31, 2022 5:06 pm
by Waverley Instruments
Just a little update on this in case anyone's interested. This seems to work...

Send a single +5V pulse / sample to a trigger out jack when you want to fire the trigger, otherwise send zeros.

On the receiving end, I think it's worth handling multiple frames of +5V, so you'd probably want a flag or something that resets when the trigger in falls to zero again.

Re: Transport CV out triggers

Posted: Wed Aug 31, 2022 5:06 pm
by Waverley Instruments
Ah thanks Grant! Our replies almost sync'd up there! :D

Re: Transport CV out triggers

Posted: Thu Sep 01, 2022 2:19 am
by terrymcg
Waverley Instruments wrote: Wed Aug 31, 2022 5:06 pm Send a single +5V pulse / sample to a trigger out jack when you want to fire the trigger, otherwise send zeros.
IMO, this is rude ;)

It works, but in "real world modular" no trigger is that short.

I aim to be accepting single cycle triggers, but generating 5ms ones.
On the receiving end, I think it's worth handling multiple frames of +5V, so you'd probably want a flag or something that resets when the trigger in falls to zero again.
Exactly. :)

Cheers,
--
Terry McG

Re: Transport CV out triggers

Posted: Thu Sep 01, 2022 7:46 am
by utdgrant
terrymcg wrote: Thu Sep 01, 2022 2:19 am I aim to be accepting single cycle triggers, but generating 5ms ones.
There's a module for that already...

Re: Transport CV out triggers

Posted: Fri Sep 02, 2022 4:34 pm
by Aarnville
It's true that in the hardware world short trigger lengths can be an issue but in the VM world any module with a trigger input should be checking the signal every sample period so a trigger signal that only lasts one sample will always work. However, the engineer in me can't bear that thought of that so most of my trigger outputs tend to be 1ms in length!

Re: Transport CV out triggers

Posted: Fri Sep 02, 2022 8:32 pm
by UrbanCyborg
Seems like the safer option, so long as it's not so long as to trigger anyone's gate-detect mechanism.

Reid

Re: Transport CV out triggers

Posted: Sat Sep 03, 2022 4:39 pm
by Waverley Instruments
Aarnville wrote: Fri Sep 02, 2022 4:34 pm It's true that in the hardware world short trigger lengths can be an issue but in the VM world any module with a trigger input should be checking the signal every sample period so a trigger signal that only lasts one sample will always work. However, the engineer in me can't bear that thought of that so most of my trigger outputs tend to be 1ms in length!
Not that I suspect anyone would be able to tell the difference, but would 48 consecutive triggers of one sample, be counted as one trigger, or 48? :?

I guess it depends who's on the receiving end... In my case, first +5V I get is counted as a trigger and a flag gets set to ignore subsequent +5Vs until I see a 0V. And I'm checking every sample period in ProcessSample().

Re: Transport CV out triggers

Posted: Sat Sep 03, 2022 5:12 pm
by Aarnville
Waverley Instruments wrote: Sat Sep 03, 2022 4:39 pm
Aarnville wrote: Fri Sep 02, 2022 4:34 pm It's true that in the hardware world short trigger lengths can be an issue but in the VM world any module with a trigger input should be checking the signal every sample period so a trigger signal that only lasts one sample will always work. However, the engineer in me can't bear that thought of that so most of my trigger outputs tend to be 1ms in length!
Not that I suspect anyone would be able to tell the difference, but would 48 consecutive triggers of one sample, be counted as one trigger, or 48? :?

I guess it depends who's on the receiving end... In my case, first +5V I get is counted as a trigger and a flag gets set to ignore subsequent +5Vs until I see a 0V. And I'm checking every sample period in ProcessSample().
It's the transition that is the trigger so if you start by sending out a 0V level, then change it to 5V and leave it there forever it will trigger something once and only once. At least that's my understanding of it. It's this sort of stuff that CA could do with including in their dev kit documentation - a "best practice" list.

The other thing you have to decide is how to handle a trigger input if the very first sample of it is 5V. Do you trigger immediately or do you wait for it to go below whatever threshold you have set? I do the latter and use a threshold of 2.5V but I know other modules that use 1.0V. I guess this all adds to the wonderful randomness of playing with modular stuff.