I’m currently working on a sync module for use in the DAW plug-in and had a question about timing clocks. The module will output a measure, beat, and tick clock (where a tick is a 24th of a quarter note). Would it be preferable to have the clock outputs as a 50% duty cycle square wave or a pulse. I thought I would make the pulse 1/2 of a tick so that the pulse width would be the same for each clock. This would make the tick clock a square wave.
0 voters
I find square wave to be more useful, but ultimately it’s pretty easy to set the PW with a zero cross and timer node.
It’s pretty much a wash as far as programming effort and CPU load so I thought I would see what people would prefer. I have the basic node working and need to do some testing to ensure it reliably stays in sync. At this point I’m trying to figure out what outputs would be most useful. With more sync technologies in the planning stages, I thought this would be a good time to do some functional testing. Taylor was kind enough to include a transport time node for use in the plug-in and that should be all we need for a basic sync node. I don’t think sync will be a big deal from an implementation point of view, although there could be some latency issues that will need to be addressed, I think the real question is what do you do with the sync data once you have it? I’m hoping that this will help determine what will be most useful before Taylor starts coding.
I thought of another good reason for square wave, most of the current gate sequencers multiply the clock with the sequencer value to create gate length. Keeping it square would mean less rebuilding off my current sequencer library.
That’s exactly the kind of info I was looking for. I was leaning toward square waves, but thought I would ask. Once I finish and post the module I would really appreciate it if you would test it out and let let me know what you think. We have a really good opportunity to influence the implementation of sync in Audulus and it would be great to have some real world examples.
After doing some further testing on the Time node, I don’t think it’s currently possible to use it as a DAW sync. The output of the node has significant noise which makes the timing clocks derived from it unreliable. It “almost” works but not reliably enough to be useful. I think I’ll shelve the project until the plug-in is updated.
I’m guessing something adapted from how HW modular systems do it would work best with the module library? How do sync signals work in eurorack?
Personally I have settled on very short spikes as I can use these to clock the TE Pocket Operators and OP-1 from Audulus. If I had to choose between square and pulse wave I would go for pulse wave because adjusting the pulse width is a quick way to add swing
There is no eurorack standard. 4ms clock dividers and Pamela’s New Workout use 50% pulses but Makenoise use trigs (short spikes).
I should point out that a timer node can convert trigs to 50% PW and vise versa. So for advanced users this is no problem.
There is a swing module in the library that delays every other pulse by an amount you set. It shouldn’t matter to your hardware if it sees a pulse or gate since it just registers the rising edge.
However the way I made the swing module uses a delay, and you mentioning modulating the PW gets me thinking. Right now the PW for clocks modulates the back end of the wave, but I could make a swing module that adjusts the front end, too. Might save a little CPU without the delay node there.
That’s a cool idea, but it would be over-complicating the library clock. The library modules really need to be simple, this allows people to make their own variations.
Simple Swing Clock.audulus (3.0 KB)
I use this as a simple clock with swing, no need for delay nodes here
@afta8 That is a SUPER clever use of the change detector. You literally have it coming and going hahaha!
The thing I like though about the longer gates is that you can easily just go from clock to envelope without needing another translator module in between, or using a specialized envelope that will go through the entire AR period.
@robertsyrett - I wouldn’t be replacing the library clock with a swing clock - it would be its own separate module, probably with swung 1/16th and swung 1/8th outputs or something.
For people on iOS 
@afta8 I gotta say I really appreciate your patch examples. They are always so clear, and built mostly with nodes. It’s a good style.
@robertsyrett, thanks I try to keep it simple 
@biminiroad, yes you would need a timer node to set the note lengths, I tend to use this to drive sequencers which have their own note length controls.
One possible advantages of short pulses is being able to sync Audulus with a DAW by sampling the pulses and sequencing them on 16ths in your DAW and send them to the Audulus input to use as a clock signal. I’m yet to try this though!
I have definitely used a kick drum and an envelope follow/comparison expression to clock Audulus from an external source.
Is that with the AU? I struggle to get it stable. I have an iconnect so should try this with iPad
Don’t worry an update is coming soon along with the AUv3 update. Not sure if it will come out exactly the same time, but the work that goes to AUv3 can be translated to Mac as well.
Great I look forward to it!
I use the ES-8 to interact with the modular, and, before I got a midi to cv module, I would use the kick drum as a clock to sync the rest of the modular to the drum machine (digitakt).
