AUM MIDI CLOCK IN

rs2000

@iamspoon said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Superb, I think it’s the best quality MIDI sync implementation I’ve ever seen.
Far superior to any software clock slaving I’ve used (such as within Ableton) and at least as reliable as the clocks in most of my music hardware (and much more stable than some!)

The way Michaels engine analyses and smooths out any jitter/inconsistency in the incoming clock is pretty remarkable in my experience.

Ymmv etc

+1 😊

palms

@Michael said:

@rs2000 said:

@palms said:

@rs2000 said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

I agree with all points. 👍🏼
Ableton slave clock sync is a bad reference anyway because it has a much too large clock averaging window. There's an unofficial hack to reduce the averaging window size to make it more usable... Ableton have obviously tried to stay super-safe with three *ondoms.

ahhh! I didn't realize that, but it explains a lot. Any idea why Live uses such a large averaging window?

No. I do feel like asking them though.

@0tolerance4silence said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

Haven't tried it myself but it could improve things...
Have you tried switching apps via midi commands?

I've tried that, but it doesn't solve the central problem: AB3 does not update midi clock while running in the background. So if for example, I change the tempo, the change isn't realized until I bring AB3 to the foreground.

@Michael: Do you know about this?

Huh... No, that’s the first time I’ve heard of that. Can you tell me a bit more about the setup?

@Michael sorry, Tried this when SYNC IN was first implemented a while back and it was behaving weirdly. I just tried it again without involving AUM and it seems to work just fine. Super solid, even in the background. I suspect the problem to be with ableton Link.

I'm using a Squarp Pyramid sequencer, hoping to sync everything to the main brain.

AUM pops up in the list of clock destinations in the sync settings in AB3, but of course it can really only connect via Link. I set AB3 up to receive clock from the Pyramid, enabled Link, and then enabled Link in AUM. Back when I initially tried this, Sync was tight when AB3 was running on top, but when I switched to AUM, it would lag and if I changed the tempo, it wouldn't properly refresh until I switched back to AB3. I gave up and switched back to Midi Link Sync because it worked well enough and I was in the midst of a big project and didn't want to spend time troubleshooting. The downside of Midi Link Sync is that it doesn't recognize start/stop commands whereas AB3 does.

Just now Linking them again in this way, it certainly works better than the last time I tried it, but not as tight as native Clock IN in AB3. For some reason, Link will intermittently lose connection between the two apps. Once in a while "0 links" flashes at the top of the window (in AUM) and things get off until it establishes a connection again. When Link is working, there is a noticeable lag when changing tempo via the sequencer.

TLDR: AB3 sync in works fine, it's link that seems to be throwing a wrench into things. If AUM implemented sync in the way AB3 has, my problem would be solved :-)

dreamsaremaps

With that cleared up it sounds like AB3’s midi sync in code would be really wonderful for AUM!

sovietpop

So , some good news
AUM is a fantastic app really but with midi sync in , (to me) the Ipad become a musical instrument that can be integrated with hardware ! If its done im selling my Octatrack

supadom

@rs2000 said:

@iamspoon said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Superb, I think it’s the best quality MIDI sync implementation I’ve ever seen.
Far superior to any software clock slaving I’ve used (such as within Ableton) and at least as reliable as the clocks in most of my music hardware (and much more stable than some!)

The way Michaels engine analyses and smooths out any jitter/inconsistency in the incoming clock is pretty remarkable in my experience.

Ymmv etc

+1 😊

Yes, totally. @Michael has tightened that screw to perfection, I have no issues with sync between AB and Hardware.

wim

@palms - FWIW, I always turn off Link notifications for new apps. They're distracting. I mention it though because it's an easy thing to try to see if it improves the situation any.

BroCoast

I am syncing AUM via AB3 & Link with hardware MIDI clock no problem. It's as tight as any app that can slave to clock.

Still I get better results using Link and sending out MIDI notes (converted to gate) syncing analog clock than anything slaved to MIDI clock.

palms

@sovietpop said:
So , some good news
AUM is a fantastic app really but with midi sync in , (to me) the Ipad become a musical instrument that can be integrated with hardware ! If its done im selling my Octatrack

Exactly! AUM with sync in, paired with Drambo would be a dream come true!

@BroCoast said:
I am syncing AUM via AB3 & Link with hardware MIDI clock no problem. It's as tight as any app that can slave to clock.

If I can figure out why Link keeps dropping out for me, I will switch to this method for the time being. Seems "good enough".

Would be nice to have the option within AUM without having to run extra apps in the background. The fewer steps of fiddling with things before getting to the making music part, the better. It's why I gravitated to AUM in the first place. AB3 usually takes several more steps for things like midi learn and setting up midi channels etc. Plus the ease of routing midi and audio is next level.

Still I get better results using Link and sending out MIDI notes (converted to gate) syncing analog clock than anything slaved to MIDI clock.

Sounds like a smart setup. Can you elaborate on this?

j_liljedahl

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

My guess is that AB3 stops running when going to background because you have no apps/plugins loaded in it, so it thinks it's idle. Try adding some small dummy IAA app to keep it running?

j_liljedahl

@rs2000 said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

I agree with all points. 👍🏼
Ableton slave clock sync is a bad reference anyway because it has a much too large clock averaging window. There's an unofficial hack to reduce the averaging window size to make it more usable... Ableton have obviously tried to stay super-safe with three *ondoms.

Never heard about this, do you have a link where one can read more?

rs2000

@j_liljedahl said:

@rs2000 said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

I agree with all points. 👍🏼
Ableton slave clock sync is a bad reference anyway because it has a much too large clock averaging window. There's an unofficial hack to reduce the averaging window size to make it more usable... Ableton have obviously tried to stay super-safe with three *ondoms.

Never heard about this, do you have a link where one can read more?

Yes:
https://help.ableton.com/hc/en-us/articles/209770945-Fluctuating-BPM-when-running-Live-as-MIDI-sync-Device
"-MidiClockSlave=g" in Options.txt works the best for me although it's much worse than Groove Rider on iOS, for example.

palms

@j_liljedahl said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

My guess is that AB3 stops running when going to background because you have no apps/plugins loaded in it, so it thinks it's idle. Try adding some small dummy IAA app to keep it running?

Thanks for the suggestion @j_liljedahl as I noted in a subsequent post, this problem seems to have been fixed in AB3 since I tried it a while ago. Sync stays synced now. I'm currently testing this setup with my hardware. Would still be preferable to not have to run a seperate app that eats precious cpu

wim

@j_liljedahl , if you're considering midi clock slave, can you pretty please consider implementing Song Position Pointer (SPP)? 🙏🏼

That would provide a huge missing piece for many of us, and would be a huge differentiator for AUM as an iOS host.

j_liljedahl

@rs2000 said:

@j_liljedahl said:

@rs2000 said:

@palms said:

@j_liljedahl said:

@wim said:
Audiobus does slave to clock and it bridges clock to Link, which AUM can follow. I’ve heard some people say the timing isn’t tight enough, but it might be worth trying.

I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

lol, then that would work perfectly for me . AB3 has a very good clock sync (weirdly, tighter and less glitchy than ableton in my tests when changing tempo),
the problem I was having with AB3's clock is that when I switch to AUM in the foreground (since I'm only using AB3 for the sync) it gets screwy. As long as I don't put AB3 in the background it works perfectly.

Since I don't have any reason to run AUM in the background, it should work just fine :-)

I agree with all points. 👍🏼
Ableton slave clock sync is a bad reference anyway because it has a much too large clock averaging window. There's an unofficial hack to reduce the averaging window size to make it more usable... Ableton have obviously tried to stay super-safe with three *ondoms.

Never heard about this, do you have a link where one can read more?

Yes:
https://help.ableton.com/hc/en-us/articles/209770945-Fluctuating-BPM-when-running-Live-as-MIDI-sync-Device
"-MidiClockSlave=g" in Options.txt works the best for me although it's much worse than Groove Rider on iOS, for example.

Thanks! Oh, I misunderstood and thought you were talking about Link, not Live.

thedragonegg

@j_liljedahl said:
I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Please we need this. I'd be happy with it being an expensive in-app purchase to support the development.

rs2000

@thedragonegg said:

@j_liljedahl said:
I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Please we need this. I'd be happy with it being an expensive in-app purchase to support the development.

AUM neither does time stretching nor pitch shifting of audio tracks so adding MIDI clock slave sync should be much easier than what Intua did in BM3 or what @Michael did in Loopy HD.

mlau

@thedragonegg said:

@j_liljedahl said:
I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Please we need this. I'd be happy with it being an expensive in-app purchase to support the development.

👍

j_liljedahl

@rs2000 said:

@thedragonegg said:

@j_liljedahl said:
I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Please we need this. I'd be happy with it being an expensive in-app purchase to support the development.

AUM neither does time stretching nor pitch shifting of audio tracks so adding MIDI clock slave sync should be much easier than what Intua did in BM3 or what @Michael did in Loopy HD.

AUM does adjust playback rate of FilePlayers to sync with the current tempo. Actually this is where most trouble can happen, because any jitter will sound like tape warble..

rs2000

@j_liljedahl said:

@rs2000 said:

@thedragonegg said:

@j_liljedahl said:
I can almost guarantee that any MIDI clock slaving I implement will work very much as well or bad as the one in Audiobus, since I'm planning to use Michaels MIDI sync engine

Please we need this. I'd be happy with it being an expensive in-app purchase to support the development.

AUM neither does time stretching nor pitch shifting of audio tracks so adding MIDI clock slave sync should be much easier than what Intua did in BM3 or what @Michael did in Loopy HD.

AUM does adjust playback rate of FilePlayers to sync with the current tempo. Actually this is where most trouble can happen, because any jitter will sound like tape warble..

Yes but this is re-pitching, not pitch shifting and it's a rather simple resampling algorithm.
If you have fluctuating LINK members, the pitch will fluctuate just as much - it's only that LINK forces the developer to use a rather stable and precise system clock while it seems that MIDI clock quality has widely different quality implementations in different iOS apps, probably for the lack of knowledge about proper mechanisms like thread prioritization.
Have you tried my suggestion with Ableton Live as a clock receiver?
And have you tried BeatMaker 3 as a clock receiver?
Groove Rider is another great working example (use sample mode = LOOP and Re-Pitch=ON).
Most people will use clock with stable sources I think (There's a lot of hardware out there today!) and not run into to many problems if [Status] Start/Stop/Continue is implemented.

And yes, that's what slave clock support comes with: A smoothing algorithm and offset correction like in the working apps we know, plus the user's responsibility to deliver halfway stable MIDI clock pulses.

McD

ATTENTION: What follows is an attempt at humor. You do not have to find it funny.

I feel bad that @j_liljedahl had to go an update his FX to AUv3's just to pay the rent on his yurt in the time of a pandemic and all we could do is pick away at the MIDI slaving issue.

If you just stay inside AUM you will never have any problems. All your trouble will melt away and you can sell off all that external stuff and buy the AU3FX apps.

Maybe, he's doing the AU3FX apps as a palette cleanser before attacking the MIDI slave issue like a piece of tough jerky.

Anyway, we'll find something else to harp on anyway because we are all "app breakers". And AUM is really just another app. An app that eats all the other apps... or should if we'd stop finding these nasty "bugs".

thedragonegg

I understand the attempt at humor and I'll comment.

My intention is not to harp at @j_liljedahl but to say that I am happy to pay him for MIDI Clock Sync to both support him and the development of AUM.

Audiobus 3 and AUM are incredible software systems and I'd like to support their development with purchases to support the developers and aid us all in creativity.

Many of us I'm sure have no interest in staying in AUM exclusively and Ableton Link while useful does not replace MIDI Clock Sync.

I have no expectations of any timeline or action and I appreciate the work @j_liljedahl and Michael are doing.

honkimon

I am perfectly happy with having AUM as the master clock for a lot of setups. Unfortunately my main setup uses a Roland MC-707 as a sort of co-pilot main brain and the 707 is notorious for being a garbage midi slave in general.

I do however have a configuration that works for me:

1. Open AB3
2. Go to settings
3. Disable Ableton Link
4. In settings go to sync settings > MIDI Clock Sync > Choose your source and destination
5. Go to Midi Open your source in the first block and AUM in the third block
6. Open AUM from within AB3. Turn off ableton link if on.
7. Now when you hit play on your hardware device it should trigger AUM to play.

Here's the part that can be a pain if you're not into manual labor. I manually set the tempo speed in AUM to match my hardware. And if I ever need to start / stop on my hardware I have to remember to rewind the playhead AUM before I start again. I've just sort of gotten used to doing it this way because it's the only solution for me that works if I want to use any of the fun midi sequencers in AUM and have them synced to my MC-707.

I've tried some of the other solutions mentioned in this thread and older threads but they all seem to fail or go out of sync.

rs2000

@honkimon Funny, the MC-707 is the only hardware device I know that supports but fails syncing to MIDI clock properly.
You could try to replace AUM with Drambo, it's not the same but it can slave to MIDI clock quite well.

OscarSouth

@rs2000 said:

@j_liljedahl said:

@ltf3 said:
Very few apps have a MIDI clock in ... even on the desktop! I don’t think it’s a good enough source (resolution and the way it’s transmitted ie - stability ) to actually clock anything... particularly when you bring digital audio into the mix, which all DAW’s do.

Hardware device to device tempo settings and song position are fine and that’s what MIDI clock was designed for... as soon as you add it to a software environment with non real-time serial operating systems ( Mac, iOS and Windows ) plus a host of hardware variables ... ugh ... no developer wants to take that on!

Of the apps that do have Clock In, my experience with getting them to even ‘think’ they are following a clock has been dismal.. let alone getting one to actually keep time!

Abelton Sync seems to be the best... although think having apps runnin inside hosts as AU 3 might be the answer in the end.

Exactly this!

@sovietpop said:
So i guess IOS just cant really be used with hardware when you need stable midi sync ?

Of course it can! But the knowledge how to implement it well seems to be rare amongst iOS developers.
Good examples for apps that follow external MIDI clock precisely:
Audiobus 3 (with positive and negative latency correction)
Loopy HD (will also time stretch audio when the bpm changes)
Groove Rider (with positive and negative latency correction, still my reference for MIDI Clock)
Beatmaker 3 (no latency correction but it slaves to clock better than Ableton Live)
KORG Gadget (no latency correction either).

This much I know: Proper slaving to MIDI clock requires a high-priority, precision timer just as much as Ableton LINK and some intelligent clock smoothing to make the incoming MIDI clock usable.

We have apps that do this reliably since the iPad 1 on iOS 4.3 CoreMIDI (MoDrum, FunkBox, Genome MIDI, Samplr with hardware clock, and a few others).

I’ve used both AudioBus3 and BeatMaker3 at different times to sync iOS to hardware and then different hardware to iOS. Always worked flawlessly for me. AudioBus3 is the best MIDI experience on iOS for sync IMO — 2nd level of hardware syncs better to AB3 than to the first layer of hardware.

Jimantronic

@j_liljedahl Is some version of midi slave sync still on the cards for AUM?
I would echo what the others have said that I'd be totally happy with an IAP extra charge for this functionality. I would imagine for most people with lots of external hardware any additional cost you would charge would be insignificant compared to the rest of their setup.

0tolerance4silence

+1 on any Kyma IAPs
btw. dev mentioned here several times that midi clock handling will be reworked. Including multiple destinations and midi clock input support.
Probably the current state of iOS doesn’t help devs moving forward with their plans...

rs2000

@0tolerance4silence said:
+1 on any Kyma IAPs
btw. dev mentioned here several times that midi clock handling will be reworked. Including multiple destinations and midi clock input support.
Probably the current state of iOS doesn’t help devs moving forward with their plans...

So why have other iOS developers done it in their apps many years ago?

0tolerance4silence

@rs2000 said:

@0tolerance4silence said:
+1 on any Kyma IAPs
btw. dev mentioned here several times that midi clock handling will be reworked. Including multiple destinations and midi clock input support.
Probably the current state of iOS doesn’t help devs moving forward with their plans...

So why have other iOS developers done it in their apps many years ago?

Not sure what do you mean, or if it’s rhetorical question?

wim

@rs2000 said:

@0tolerance4silence said:
+1 on any Kyma IAPs
btw. dev mentioned here several times that midi clock handling will be reworked. Including multiple destinations and midi clock input support.
Probably the current state of iOS doesn’t help devs moving forward with their plans...

So why have other iOS developers done it in their apps many years ago?

It's not something he wanted to do in the first place. He is bending to popular request. It's hard to prioritize something that your heart's not into when you have a mountain of other things pulling on your time. It can also be a lot of work to re-architect for something that an app wasn't designed from the ground up to accommodate.

rs2000

@wim said:

@rs2000 said:

@0tolerance4silence said:
+1 on any Kyma IAPs
btw. dev mentioned here several times that midi clock handling will be reworked. Including multiple destinations and midi clock input support.
Probably the current state of iOS doesn’t help devs moving forward with their plans...

So why have other iOS developers done it in their apps many years ago?

It's not something he wanted to do in the first place. He is bending to popular request. It's hard to prioritize something that your heart's not into when you have a mountain of other things pulling on your time. It can also be a lot of work to re-architect for something that an app wasn't designed from the ground up to accommodate.

I would agree if AUM didn't support Ableton LINK but it does.