with a 50% PW you should be able to make an upbeat by inverting the signal.
Looks like @biminiroad set that up as a run gate. You can throw a flip flop in front of that to change it to a toggle:
flip flop.audulus (3.9 KB)
O, I know. The point was just about layout limitations – what features could be replaced with others.
1 Like
I’ve thought bought building an add-on module for the longer periods.
1 Like
That’s a nice idea.
1 Like
I added a beat output because a 1/4 note isn’t necessarily the beat. If your time signature is 6/8 for example then an eighth note is the beat. I tried to build a clock that would allow for more uncommon time signatures.
1 Like
I took another look at the clocks this morning to see if I could lower the CPU load. I built one with basically the same outputs as the reface version without the swing but with the capability to sync to a beat clock.
I also cleaned up the V3.0 version I posted yesterday.
File replaced see below:
Comparing the 3 clocks, the original reface is the most efficient but doesn’t have the ability to sync to an external beat, the straight time version I built is not as efficient because of the additional logic required to sync to an external source and the one with swing is the worst for CPU because of the swing and time signature logic.
The issue with syncing the original reface version is if you send a sync pulse to each phasor every beat, then all the phasors with a period greater than the beat (1/2 note, whole note, 2 bars etc.) will resync before they reach the end of their cycle. I experimented with a multiphasor design capable of handling an external beat clock, but in the end the single phasor design was more efficient.
Actually, if you are willing to sacrifice the variable pulse width and just have a narrow (1/128th) clock pulse for each output, it could probably be built more efficiently, but it wouldn’t be as flexible.
Strictly speaking the only thing that should matter on a clock is the timing of the lead edge of the clock pulse. The pulse width shouldn’t matter as long as the pulse is long enough to act as a trigger. In practice clocks are often used as a square wave LFO so a variable pulse width can be handy.
1 Like
It’s interesting how exciting a logical strategy can be, until you encounter some feature limit. Easy to forget that the original strategy was just itself a response to some earlier feature limit.
I need a bulletproof clock like everyone needs a set of utensils. I wish I was at pace with the programming enough to work on it. Probably a theoretically fascinating project down there on the front lines.
That it can be a slave and produce all the time divisions and take a start pulse, I think, is a good blend of basic functions for the sake of stability. 
Needs a reset output though.
What’s happening here? I see you are feeding a 1/4 note pulse to the input to get a sync, but what’s ‘ext’?
I was trying to indicate that the input can be used either for a single sync pulse or for an external beat clock. The sync/ext input is always active. When the ext toggle is off the clock uses the BPM setting of the knob, but will still sync to a pulse on the input. When the external toggle is on, the clock disconnects the BPM knob, calculates the BPM of the external signal and uses it. By setting the BPM knob to match the DAW and turning on the ext toggle, the clock will start at approximately the right BPM setting and as soon as the zero crossing circuit gets a frequency, it will use that instead of the knob setting. It should make the tracking tighter.
A reset would be simple to add, but I didn’t actually see much need. The reface clock produces a 10 ms pulse on the reset output when either start or reset goes high. Since my design is intended to be started with a gate pulse rather than by holding the start input high, you can use the same pulse sent to run as your reset signal.
I tested a pulse only design yesterday and it was a bit more efficient than the reface version, but not enough to make it worth giving up the flexibility. It’s probably better to stick with a single design (or two) if possible.
I’m curious why you feel a need for the long period outputs (2 bars, 4 bars etc.) If you’re using them to trigger various sections of the patch, you might want to have a look at the transport collection I put together. It’s designed to automate sections of a patch. It’s modular and has components for producing clocks, start and reset signals etc. The master clock in the collection doesn’t currently have an external beat clock sync, but it could be added without too much trouble.
1 Like
One of the challenges here is the curating. There are drawers with tools yet to be enjoyed everywhere. I don’t think the transport collection is a suitable substitute for longer period outputs, for a number of reasons – mostly preferential.
I need to be organized, and I need to be able to keep track of things. I think there is a way to approach patches where you are building a machine like song. But there is also the approach of fitting electronic music production techniques into Audulus. I like both approaches. In the use case I am currently working with, I am syncing a bunch of devices using Ableton Link. It is nice to know at a glance where things are at. That Master Clock sometimes works like a scoreboard. It is also a complete object I can grab and build with instead of slowing down.
At the same time, I already see tools in the Transport Collection that will work way better than “subtractive mixing.” I am excited to get into triggering some isolated events.
1 Like
I can see the appeal of having a single object. The concept of the transport collection was to have a “timing” bus that could easily be routed to various parts of a patch to keep various elements in sync. For a useable bus you need at least a clock and a reset. Since I had a quad signal line available, I chose to include a count of the beats elapsed from the start of the clock and a “start” signal that could be used to trigger patch elements. The various routing modules that provide switching, delays and looping aren’t actually necessary to use the transport as a simple timing bus. Only the master clock and the interface are really required. I’m currently making some changes to the collection, but I’ve already updated the master clock for external sync. Here’s the new clock and the 2 interface modules if you’re interested in giving them a try.
Basic transport.audulus (272.7 KB)
1 Like
I should be absolutely clear: The quality of tools people have made around here are amazing. It is not easy to keep up with it all. 
So I have been treating the forum as a kind of memory bank where I move between threads as my competence with synthesis gets better. It’s a long road but I am really having a blast!
2 Likes
It’s really all about workflow to use an overused term. I think the thing I like most about Audulus is it doesn’t force you into any particular approach. If the transport doesn’t make sense with your particular creative process, by all means use something that does! I certainly won’t be offended. As you say it’s tough to keep up with it all which is why I mentioned it in the first place. Eventually I hope to make the Transport a single point for syncing regardless of the source. I’m hoping A4 will add MIDI sync, DAW transport integration and Ableton Link at some point.
2 Likes
I got some time to hook the new master clock up. Seemed like it behaved well taking a midi note from Korg gadget as a clock sync. I am really looking forward to putting these tools through the paces this week. Thanks again.
2 Likes
Okay so I am thinking that maybe the clocks should take a 16th note sync, instead of a quarter. Any thoughts?
Looks like it was a reface standard as well. 
Also, I think my best results were with PWM on the Master Clock v1.1 cranked hard left #=10.
With another device running at 120, it jumps roughly b/w 117 and 121. In a sense, it almost just needs to ‘sample’ more frequently, I would think.
In the meantime, I simplified things and substituted clock dividers and multipliers coming straight from a MIDI signal. I think, for clocks, steady midi notes off of bluetooth might be an issue.
update:
When I give it the hit hat test (running hats on 16ths), taking a midi blutooth note from gadget over to Audulus, if I go straight from a midi note module to a hi hat module, the match seems tighter than through the Master 1.1. So I am wondering if there should be a 4th clock – The MIDI Slave clock. This would reduce cpu by only dealing with the direct midi note as the primary pulse in Audulus, but at the same time, provide all of the measures. Is that an easy cut and paste?
Update 2:
After an hour or two of fiddling, I can’t get the 16th hats to lock in. Not sure what the issue is. Seems to drift out back in every few bars by a tiny amount. Maybe I need to figure out the most stable master…
2 Likes
I don’t know if using a 16th would make any difference. You could try it by leaving the ext toggle off and sending a 16th to see if it tracks better. With the toggle off it will sync but won’t adjust the BPM setting. If so, I can change the logic by dividing the zero crossing output by 4 to match the 16th instead of a 1/4. The zero crossing detector isn’t perfectly accurate in any case so it may not make a big difference. If you leave the external toggle off the clock will be perfectly stable since it’s running off a digital oscillator. I’m not sure how tight the MIDI processing is in Audulus but it could be part of the problem. Bluetooth generally has a fair bit of latency so it’s possible that it also might be contributing to the issue. Can you try it hardwired?
The problem with clocks is that there is no easy way to generate a higher frequency signal from a lower one. Going in the other direction is simple. So if you have a 16th pulse, you can easily get 16ths, 8ths, quarters etc. but not 32nds or 64ths. The MIDI beat clock uses 24 ppqn (pulses per quarter note) so you can get 1/4 = 24, 1/8 = 12, 1/8t = 8, 1/16 = 6, 1/16t = 4 and 1/32 = 3
All of this is really a band-aid to deal with the lack of any real sync mechanism in Audulus. Hopefully A4 will include MIDI sync as well as maybe Ableton Link and DAW transport clock in the AU.
I think that one the one hand, some of this is complex. There are a lot of factors. Kind of need to skip around…
Sometimes what I’ll do is forgo the creative stuff and just become a sound person with the idea that the show must go on. So I just stripped down a patch to the clocking mechanics and got some hi-hats ready in Korg Gadget, Audulus, and on an elektron sequencer. I think the hi hat test is good, because you can hear them phasing. IF you can’t hear the hi hats phasing, I figure at that point – for my purposes – it doesn’t matter, good enough.
– bottom line is, with the routing I had going, I am happy with how tight I could get a recording.
If anyone cares, here are some things that I found important.
- I am running Ableton 9. I think there might be a useful option in Ableton 10.
I did not make use of this, but I would be interested to know about it. Should I upgrade? 9 only has “show link toggle,” but not a “start/stop sync on” option.
-
Because there is a MIDI Link clock running, there is always a transport bar cycling independent of all devices, on all devices. It is like having a person counting 1,2,3,4; and, to join in, all devices must start at 1. (Where is this signal? Can we hack it? It seems like if we can get midi over bluetooth into Audulus already, can’t we somehow detect the Link transport/clock?)
Work-wise, a laptop running Ableton, starts the record. This is key, because it means that when you record your jam, the file will be quatized on the beat. So you can do this intense recording of 4 or 5 peices of gear at once, but then you can go straight into Ableton and add anything to the track after (or while recording), and everything is in time. Again, very important to see you that finished recoding has you kick drum landing perfectly on the Ableton audio grid. -
One of the sound sources is N.I. Traktor. So full complete tracks can be mixed/looped/etc., on the fly. One nice thing, is that Traktor has a bar that both indicates and allows for adjusting any drifting for beat matching. I can double click that sync button to snap it back immediately, or I can cheat the bar slowly back to center.
–Hardwiring: Here’s maybe the nuance. Send a hardwire clock by tying Ableton to the Elektron Analog Four (they are joined with a usb cable). The A4 has MIDI Clock out, so the signal from the A4 gets passed on to mBrane (Yarns, eurorack) through a midi cable. mBrane then produces two outputs. 1. a start/stop transport. 2. A steady clock. Both are MIDI converted to CV. Then I can plug those pulses into the ES-8 and get that pulse straight into Audulus.
Whatever relationship between Ableton Live and the Analog Four, it seems like it grounds the situation, so that Audulus is doing no calculations, but only receiving a pulse.
On the other hand Gadget (which is Link enabled) can provide MIDI out to Audulus over bluetooth. Not only does this make it possible to sequence Audulus with MIDI, but also control a modular synthesizer from Gadget with MIDI converted to cv and gate.
The main point is to separate clock duties and MIDI duties, so that the clock is ran hard and the MIDI notes and gates pass through the ether (over bluetooth).
Again, can we hack the Link signal somehow?
The Link option you are referring to is for Ableton Link not MIDI. Link is Ableton’s answer to keeping stuff in sync. It has it’s own protocol and doesn’t use MIDI. The Start/Stop sync option in Live 10 controls whether Live sends and receives a start and stop to or from other connected link devices. Link gets it’s timing from the first device that sends a start signal. It doesn’t really have a “master” as such.
At this point there’s no way to directly access the Link signal. The protocol is open so potentially @Taylor could add the necessary code to Audulus to receive the signal. I requested the Link documentation and SDK from Ableton and it doesn’t look too difficult.
It’s important that there is only a single “master” clock running so you should probably set it up so that everything is clocked from Live ether using MIDI or Link. Link clocks from the first device to start so you should start Live’s transport to start the session rather than starting a different device. Since you have some devices that aren’t Link enabled it might be better to stick with MIDI sync only so you only have a single sync source.
I posted this some time ago and thought you might find it interesting:
1 Like
Looks like a great thread. I have to pull myself away for a bit, I will dig into it though. You know, I feel like what I did with the routing was actually a success. So I think it’s important to hesitate there and kind of have a “wow” moment.
For anyone else I would say be forewarned about all of the tiny factors that can have you scratching your head for an hour. Like:
Did you plug usb hub and the camera connection kit into the iphone in the right order?
Did Audulus just crash again?
Did Gadget just drop the bluetooth connection between devices?
Did your sound card somehow become disengaged in Ableton?
Etc…
So, one of the nice bits about the reface library is, like I mentioned, complete objects. It is impossible to avoid troubleshooting, so working with complete objects helps the mind eliminate factors when working with visual node based logics. So it is less a matter of getting the patches right, as it is getting the modules to be fool proof, standardized, etc. There are still so many little things I have to watch out for (converting gates to triggers, etc., etc,.).
So, again, I will continue to work on this, just have other responsibilities…
1 Like