Loopy Pro: Create music, your way.

What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

AUM sending bad MIDI clock?

2»

Comments

  • j_liljedahlj_liljedahl

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

  • no1normalno1normal

    @ElectroHead said:

    but with parts on the OT, one AUM project can serve a complete preset manager for multiple tracks (whole set) with seemless program changes (obviously no project change / reconfiguring of AU's in AUM and outputs without interruption).

    >

    Hey dude, sorry the eves drop but that sounds pretty cool. Please can you expand a bit on the set up for this? ( how do you set this up on the OT and what needs to be done in AUM? )

    Are you playing back full tracks in AUM from the file player, or changing presets on various AUV3 synths using program changes?

    Cheers

  • rs2000rs2000

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

  • wimwim

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks - yes, I'll recreate what I did later today and let you know if the behavior is still there or not.

  • rs2000rs2000

    @wim said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks - yes, I'll recreate what I did later today and let you know if the behavior is still there or not.

    Oops - I shall not read hastily :D

  • wimwim
    edited November 2019

    @rs2000 said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

    Here’s a session with a simple benchmark program. The first Mozaic script sends cc #20 values from 0 to 127 at a configurable interval. The results can be captured in the second Mozaic script log, or in Midi Monitor.

    I found that in Audiobus no cc values are lost even down to 1ms in either monitor. In AUM MIDI Monitor starts to drop values at around 20ms. The Mozaic monitor can go down to 3ms in AUM without dropping anything, but below that drops a few in the middle or drops all above about 80.

    I hope it helps. If you’d like me to try something else, please let me know. iPad Air 2, iOS 12.3.1, latest AUM.

    https://www.dropbox.com/s/064fgibzj9lgpkx/Test MIDI CC Processing.aumproj?dl=0

  • ElectroHeadElectroHead

    @no1normal said:

    @ElectroHead said:

    but with parts on the OT, one AUM project can serve a complete preset manager for multiple tracks (whole set) with seemless program changes (obviously no project change / reconfiguring of AU's in AUM and outputs without interruption).

    >

    Hey dude, sorry the eves drop but that sounds pretty cool. Please can you expand a bit on the set up for this? ( how do you set this up on the OT and what needs to be done in AUM? )

    Are you playing back full tracks in AUM from the file player, or changing presets on various AUV3 synths using program changes?

    Cheers

    I don't have any playback of files in the project I described. All iOS synth and fx presets are saved as AUM presets. Any parameter in AUM can be cc controlled, channel volume, fx send level etc. So with the Octatrack, when you change part, the OT sends out PC messages and all the default cc values for the new part (for tracks with no note messages - e.g. fx, place a trigerless trig - no cc data need be entered - at the beginning of the seq to activate the new part settings). Map presets to PCs and ccs to parameters in the AUM Midi Control pages. Think carefully about where to assign cc parameters on the OT i.e. get in the habit of assigning attack and decay to, say, controllers 9 and 10 for every synth. I have the assignable cc's on the first midi parameter page assigned to volume, pan, fx send 1, fx send 2.

    With AUM, the only way to save changes to presets is to overwrite! So I recommend keeping preset names very short.

  • ProcessaurusProcessaurus

    @rs2000 Do you have MidiBus? It is a utility that, in addition to sending high quality midi clock, it can be used to test the quality of received midi clock, from other apps, or hardware- how much the bpm jitters, and other errors.

    You could test AUM’s clock internally, within iOS, or test your midi interface as well, by using a midi cable to loop the output back to the input, and using midibus to check the clock quality on the interface input.

    Could help diagnose the problem, at least.

  • j_liljedahlj_liljedahl

    @wim said:

    @rs2000 said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

    Here’s a session with a simple benchmark program. The first Mozaic script sends cc #20 values from 0 to 127 at a configurable interval. The results can be captured in the second Mozaic script log, or in Midi Monitor.

    I found that in Audiobus no cc values are lost even down to 1ms in either monitor. In AUM MIDI Monitor starts to drop values at around 20ms. The Mozaic monitor can go down to 3ms in AUM without dropping anything, but below that drops a few in the middle or drops all above about 80.

    I hope it helps. If you’d like me to try something else, please let me know. iPad Air 2, iOS 12.3.1, latest AUM.

    https://www.dropbox.com/s/064fgibzj9lgpkx/Test MIDI CC Processing.aumproj?dl=0

    Thanks! This helps a lot. Here's what's happening: The MIDI is not dropped by AUM, it's received from the sending AU and passed on to the receiving AU just as it should. See this log:

    84697923206.0 0001: 3 bytes (AUv3 MIDI receive)
 B0 14 00
84697923206.0 0045: 3 bytes (AUv3 MIDI receive)
 B0 14 01
84697923206.0 0089: 3 bytes (AUv3 MIDI receive)
 B0 14 02
84697923206.0 0133: 3 bytes (AUv3 MIDI receive)
 B0 14 03
84697923206.0 0177: 3 bytes (AUv3 MIDI receive)
 B0 14 04
84697923206.0 0221: 3 bytes (AUv3 MIDI receive)
 B0 14 05
84697923462.0 0009: 3 bytes (AUv3 MIDI receive)
 B0 14 06
84697923462.0 0053: 3 bytes (AUv3 MIDI receive)
 B0 14 07
84697923462.0 0097: 3 bytes (AUv3 MIDI receive)
 B0 14 08
84697923462.0 0141: 3 bytes (AUv3 MIDI receive)

    Where the first big number is the time of the current render cycle. The smaller big number is the frame offset for the event within the current render cycle. As you see it's all OK. So, as far as I can tell AUM does pass the MIDI along, with correct timestamps, but something happens on the way from there (perhaps in iOS itself, or the plugin?). I'm sending the MIDI with weakSelf->_midiBlock(AUEventSampleTimeImmediate + ev->timestamp, 0, ev->length, ev->data); where timestamp is the smaller big number above (frame offset). Maybe @Michael is doing something else in AB3?

  • j_liljedahlj_liljedahl

    @j_liljedahl said:

    @wim said:

    @rs2000 said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

    Here’s a session with a simple benchmark program. The first Mozaic script sends cc #20 values from 0 to 127 at a configurable interval. The results can be captured in the second Mozaic script log, or in Midi Monitor.

    I found that in Audiobus no cc values are lost even down to 1ms in either monitor. In AUM MIDI Monitor starts to drop values at around 20ms. The Mozaic monitor can go down to 3ms in AUM without dropping anything, but below that drops a few in the middle or drops all above about 80.

    I hope it helps. If you’d like me to try something else, please let me know. iPad Air 2, iOS 12.3.1, latest AUM.

    https://www.dropbox.com/s/064fgibzj9lgpkx/Test MIDI CC Processing.aumproj?dl=0

    Thanks! This helps a lot. Here's what's happening: The MIDI is not dropped by AUM, it's received from the sending AU and passed on to the receiving AU just as it should. See this log:

    84697923206.0 0001: 3 bytes (AUv3 MIDI receive)
 B0 14 00
84697923206.0 0045: 3 bytes (AUv3 MIDI receive)
 B0 14 01
84697923206.0 0089: 3 bytes (AUv3 MIDI receive)
 B0 14 02
84697923206.0 0133: 3 bytes (AUv3 MIDI receive)
 B0 14 03
84697923206.0 0177: 3 bytes (AUv3 MIDI receive)
 B0 14 04
84697923206.0 0221: 3 bytes (AUv3 MIDI receive)
 B0 14 05
84697923462.0 0009: 3 bytes (AUv3 MIDI receive)
 B0 14 06
84697923462.0 0053: 3 bytes (AUv3 MIDI receive)
 B0 14 07
84697923462.0 0097: 3 bytes (AUv3 MIDI receive)
 B0 14 08
84697923462.0 0141: 3 bytes (AUv3 MIDI receive)

    Where the first big number is the time of the current render cycle. The smaller big number is the frame offset for the event within the current render cycle. As you see it's all OK. So, as far as I can tell AUM does pass the MIDI along, with correct timestamps, but something happens on the way from there (perhaps in iOS itself, or the plugin?). I'm sending the MIDI with weakSelf->_midiBlock(AUEventSampleTimeImmediate + ev->timestamp, 0, ev->length, ev->data); where timestamp is the smaller big number above (frame offset). Maybe @Michael is doing something else in AB3?

    BTW, it's quite interesting that the two MIDI receivers does not drop the same events or in the same amount. I've confirmed that AUM sends exactly the same MIDI (and all 128 messages) to both of them.

  • j_liljedahlj_liljedahl

    @j_liljedahl said:

    @j_liljedahl said:

    @wim said:

    @rs2000 said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

    Here’s a session with a simple benchmark program. The first Mozaic script sends cc #20 values from 0 to 127 at a configurable interval. The results can be captured in the second Mozaic script log, or in Midi Monitor.

    I found that in Audiobus no cc values are lost even down to 1ms in either monitor. In AUM MIDI Monitor starts to drop values at around 20ms. The Mozaic monitor can go down to 3ms in AUM without dropping anything, but below that drops a few in the middle or drops all above about 80.

    I hope it helps. If you’d like me to try something else, please let me know. iPad Air 2, iOS 12.3.1, latest AUM.

    https://www.dropbox.com/s/064fgibzj9lgpkx/Test MIDI CC Processing.aumproj?dl=0

    Thanks! This helps a lot. Here's what's happening: The MIDI is not dropped by AUM, it's received from the sending AU and passed on to the receiving AU just as it should. See this log:

    84697923206.0 0001: 3 bytes (AUv3 MIDI receive)
 B0 14 00
84697923206.0 0045: 3 bytes (AUv3 MIDI receive)
 B0 14 01
84697923206.0 0089: 3 bytes (AUv3 MIDI receive)
 B0 14 02
84697923206.0 0133: 3 bytes (AUv3 MIDI receive)
 B0 14 03
84697923206.0 0177: 3 bytes (AUv3 MIDI receive)
 B0 14 04
84697923206.0 0221: 3 bytes (AUv3 MIDI receive)
 B0 14 05
84697923462.0 0009: 3 bytes (AUv3 MIDI receive)
 B0 14 06
84697923462.0 0053: 3 bytes (AUv3 MIDI receive)
 B0 14 07
84697923462.0 0097: 3 bytes (AUv3 MIDI receive)
 B0 14 08
84697923462.0 0141: 3 bytes (AUv3 MIDI receive)

    Where the first big number is the time of the current render cycle. The smaller big number is the frame offset for the event within the current render cycle. As you see it's all OK. So, as far as I can tell AUM does pass the MIDI along, with correct timestamps, but something happens on the way from there (perhaps in iOS itself, or the plugin?). I'm sending the MIDI with weakSelf->_midiBlock(AUEventSampleTimeImmediate + ev->timestamp, 0, ev->length, ev->data); where timestamp is the smaller big number above (frame offset). Maybe @Michael is doing something else in AB3?

    BTW, it's quite interesting that the two MIDI receivers does not drop the same events or in the same amount. I've confirmed that AUM sends exactly the same MIDI (and all 128 messages) to both of them.

    Another update: I made a test AUv3 plugin, and it got all 128 messages as expected, with correct timestamps, at an interval of 1ms. A bit weird if there's a bug in both Mozaic and MIDI Monitor regarding this, but this was the results of my test. I'll ask @brambos to show me his MIDI reception code...

  • brambosbrambos

    I'm investigating this issue. Right now it looks like it's not an issue with AUM, but an iOS behavior: as far as I can tell now the CoreAudio/CoreMIDI framework discards MIDI messages sent during heavy CPU load.

    In other words: whenever there's a sudden CPU spike the MIDI messages sent during that buffer process may get lost (I'm not getting buffer-timeout warnings, when it happens but iOS may treat it as such). Messages queued for later are unaffected.

    I'm still digging deeper and it's a tentative conclusion for now, but it doesn't look like AUM is to blame.

  • rs2000rs2000

    @brambos said:
    I'm investigating this issue. Right now it looks like it's not an issue with AUM, but an iOS behavior: as far as I can tell now the CoreAudio/CoreMIDI framework discards MIDI messages sent during heavy CPU load.

    In other words: whenever there's a sudden CPU spike the MIDI messages sent during that buffer process may get lost (I'm not getting buffer-timeout warnings, when it happens but iOS may treat it as such). Messages queued for later are unaffected.

    I'm still digging deeper and it's a tentative conclusion for now, but it doesn't look like AUM is to blame.

    To make absolutely sure, I've done a few tests using a solid USB MIDI interface (Roland UM-One mk2) and to avoid any other influences and get halfway precise jitter measurements, I've recorded the serial MIDI data from the UM-One with a 192kHz audio interface.
    Well, I can at least say that the MIDI clock coming from AUM looked perfect.
    Nonetheless there must be an issue when the Digitakt is involved.
    I have yet to find the actual cause of the problem. Will try filtering MIDI active sensing messages, try other gear etc. when I have the time.

  • SevenSystemsSevenSystems

    @brambos said:
    but an iOS behavior: as far as I can tell now the CoreAudio/CoreMIDI framework discards MIDI messages sent during heavy CPU load.

    "behavior" would certainly get the "Euphemism of the Year" award if that's actually the case 😮

  • brambosbrambos
    edited November 2019

    @SevenSystems said:

    @brambos said:
    but an iOS behavior: as far as I can tell now the CoreAudio/CoreMIDI framework discards MIDI messages sent during heavy CPU load.

    "behavior" would certainly get the "Euphemism of the Year" award if that's actually the case 😮

    Yes, this one had me pulling my hair out before I noticed a pattern. I have only tested with AU MIDI being sent between plugin instances, so between standalone apps it possibly/probably doesn't happen.

    But at least one thing is certain: something is gobbling up MIDI messages while they travel from one place to the next, and it doesn't look like it's AUM (in Audiobus 3 I get the exact same issue).

  • cronycrony
    edited November 2019

    I guess it's a different issue, but might be related ?

    As a user, I can say that into AUM at some point, midi connections get some kind of a "reset".
    Also seems particularly destructive on my 4 in/ 4 out midi interface which get 0 links suddenly...
    The only difference with the other midi device is that my midi interface Miditech midiface 4x4 is constantly sending Active Sense FE messages, but AFAIK, it's better to have that signal.
    As I'm redirecting a lot of stuffs, I wonder if multiple Active Sense messages might collide and blown the midi
    Other midi external controllers are doing fine after this "reset".
    It happens randomly, but I get also some weird CPU spikes also (from 70 to 150% during a second) completely random.

    The spikes were there before (with an iPad pro 11") but midi disconnections seems started around 6 months ago. (might be before, not sure as my preset has also evolved a lot during this period, and it took me some time to find out...)

    The thing is that on my other iPads, my other midi interface are not sending or receiving this message.
    The only iPad getting these reset is receiving from 3 midi in this message...

    Could it be possible to have AUM blocking this messages by default to see if it has an impact in my workflow ?
    Or it has absolutely no impact, and it's an IOS bug ?
    My midi interface is having an issue ?...well...

  • rs2000rs2000

    @brambos said:
    ...
    But at least one thing is certain: something is gobbling up MIDI messages while they travel from one place to the next, and it doesn't look like it's AUM (in Audiobus 3 I get the exact same issue).

    Update: Since the MIDI clock sent by AUM seems to be tight, my next try was to use a hardware USB MIDI interface and the Digitakt 5-pin MIDI ports instead of the Digitakt's USB MIDI.
    And guess what?
    Exactly the same issue! From time to time (maybe one out of five), when starting the AUM transport, Viking synth plays notes much too late.
    The Digitakt follows AUM's clock perfectly and sends MIDI notes back to AUM in-time so it must be something with incoming MIDI Notes being forwarded to Viking too late sometimes.
    Interesting detail: When Viking plays too late, the delay remains constant while playing, as if I had added a 200ms (rough estimate) audio delay.

    @j_liljedahl
    So I've done the exact same test in Cubasis:
    Cubasis sends MIDI clock to Digitakt, Digitakt sends its sequenced MIDI notes back to Cubasis which hosts the friendly Viking.
    This time, Viking always plays the way it should. Every time I start the transport in Cubasis, Viking will play with the same tiny latency. No surprising delays.

    So I'd say it's neither an issue with the MIDI interface, nor an issue with iOS.

  • wimwim
    edited November 2019

    @brambos said:

    @SevenSystems said:

    @brambos said:
    but an iOS behavior: as far as I can tell now the CoreAudio/CoreMIDI framework discards MIDI messages sent during heavy CPU load.

    "behavior" would certainly get the "Euphemism of the Year" award if that's actually the case 😮

    Yes, this one had me pulling my hair out before I noticed a pattern. I have only tested with AU MIDI being sent between plugin instances, so between standalone apps it possibly/probably doesn't happen.

    But at least one thing is certain: something is gobbling up MIDI messages while they travel from one place to the next, and it doesn't look like it's AUM (in Audiobus 3 I get the exact same issue).

    I never get this issue in my tests in Audiobus or Ape Matrix. I’m assuming that’s because you’re doing heavier testing than I am and have better tools. But my experience is far from exactly the same. I can 100% pass on Audiobus or Ape and 100% fail in AUM. I guess it must just be a case of different degrees of the same issue though.

  • cronycrony
    edited November 2019

    Well, hmm, sorry, I found out (maybe..) that my issue was related to using an USB C 3 ports (to get the iPad pro charging) in cascade with a USB 3 to connect my midi gears.
    It seems it might just be some micro electric interruptions or something like that...

    Anyway, I think I may have solved my problem ordering this:
    https://www.amazon.fr/gp/product/B07V6Q873S/ref=ox_sc_act_title_2?smid=A2SBSMJWADKVNX&psc=1

    I hope it's not just audio but a regular USB C port to connect my usb hub with this cable:
    https://www.amazon.fr/gp/product/B00UXKTJE0/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

    I don't know about midi clock, but yeah after 3/4 mins it starts to drift...

  • rs2000rs2000

    @j_liljedahl said:

    @j_liljedahl said:

    @j_liljedahl said:

    @wim said:

    @rs2000 said:

    @j_liljedahl said:

    @wim said:
    My guess at what is happening here is AUM struggling to keep up with the midi load. I discovered when I was testing Mozaic scripts that AUM tends to drop midi messages when too many come in too fast. I could repeat this 100% of the time, while the same tests succeeded in other hosts.

    Is this something you can reproduce still with the current app store version of AUM? If yes, please send me a demo session file and I'll look into it.

    Thanks @j_liljedahl, I've just sent you the file I've recorded the video with.

    Here’s a session with a simple benchmark program. The first Mozaic script sends cc #20 values from 0 to 127 at a configurable interval. The results can be captured in the second Mozaic script log, or in Midi Monitor.

    I found that in Audiobus no cc values are lost even down to 1ms in either monitor. In AUM MIDI Monitor starts to drop values at around 20ms. The Mozaic monitor can go down to 3ms in AUM without dropping anything, but below that drops a few in the middle or drops all above about 80.

    I hope it helps. If you’d like me to try something else, please let me know. iPad Air 2, iOS 12.3.1, latest AUM.

    https://www.dropbox.com/s/064fgibzj9lgpkx/Test MIDI CC Processing.aumproj?dl=0

    Thanks! This helps a lot. Here's what's happening: The MIDI is not dropped by AUM, it's received from the sending AU and passed on to the receiving AU just as it should. See this log:

    84697923206.0 0001: 3 bytes (AUv3 MIDI receive)
 B0 14 00
84697923206.0 0045: 3 bytes (AUv3 MIDI receive)
 B0 14 01
84697923206.0 0089: 3 bytes (AUv3 MIDI receive)
 B0 14 02
84697923206.0 0133: 3 bytes (AUv3 MIDI receive)
 B0 14 03
84697923206.0 0177: 3 bytes (AUv3 MIDI receive)
 B0 14 04
84697923206.0 0221: 3 bytes (AUv3 MIDI receive)
 B0 14 05
84697923462.0 0009: 3 bytes (AUv3 MIDI receive)
 B0 14 06
84697923462.0 0053: 3 bytes (AUv3 MIDI receive)
 B0 14 07
84697923462.0 0097: 3 bytes (AUv3 MIDI receive)
 B0 14 08
84697923462.0 0141: 3 bytes (AUv3 MIDI receive)

    Where the first big number is the time of the current render cycle. The smaller big number is the frame offset for the event within the current render cycle. As you see it's all OK. So, as far as I can tell AUM does pass the MIDI along, with correct timestamps, but something happens on the way from there (perhaps in iOS itself, or the plugin?). I'm sending the MIDI with weakSelf->_midiBlock(AUEventSampleTimeImmediate + ev->timestamp, 0, ev->length, ev->data); where timestamp is the smaller big number above (frame offset). Maybe @Michael is doing something else in AB3?

    BTW, it's quite interesting that the two MIDI receivers does not drop the same events or in the same amount. I've confirmed that AUM sends exactly the same MIDI (and all 128 messages) to both of them.

    Another update: I made a test AUv3 plugin, and it got all 128 messages as expected, with correct timestamps, at an interval of 1ms. A bit weird if there's a bug in both Mozaic and MIDI Monitor regarding this, but this was the results of my test. I'll ask @brambos to show me his MIDI reception code...

    Have you tested your AUv3 receiver with MIDI coming from external gear?
    Maybe you're expecting timestamps where there aren't any?

  • cronycrony

    Ok, my conclusion to all this, with my set:
    It's IMPOSSIBLE to have a stable clock if you're at 256 in latency in AUM and having other devices to sync with, no matter what.
    It starts to be really fine (to my ears) at 128.
    Can't reach 64 as it's too CPU consuming.

  • j_liljedahlj_liljedahl

    @crony said:
    I guess it's a different issue, but might be related ?

    As a user, I can say that into AUM at some point, midi connections get some kind of a "reset".
    Also seems particularly destructive on my 4 in/ 4 out midi interface which get 0 links suddenly...
    The only difference with the other midi device is that my midi interface Miditech midiface 4x4 is constantly sending Active Sense FE messages, but AFAIK, it's better to have that signal.
    As I'm redirecting a lot of stuffs, I wonder if multiple Active Sense messages might collide and blown the midi
    Other midi external controllers are doing fine after this "reset".
    It happens randomly, but I get also some weird CPU spikes also (from 70 to 150% during a second) completely random.

    The spikes were there before (with an iPad pro 11") but midi disconnections seems started around 6 months ago. (might be before, not sure as my preset has also evolved a lot during this period, and it took me some time to find out...)

    The thing is that on my other iPads, my other midi interface are not sending or receiving this message.
    The only iPad getting these reset is receiving from 3 midi in this message...

    Could it be possible to have AUM blocking this messages by default to see if it has an impact in my workflow ?
    Or it has absolutely no impact, and it's an IOS bug ?
    My midi interface is having an issue ?...well...

    What is this "reset" you're talking about? I'm not sure I understand.

  • j_liljedahlj_liljedahl

    @rs2000 said:

    @brambos said:
    ...
    But at least one thing is certain: something is gobbling up MIDI messages while they travel from one place to the next, and it doesn't look like it's AUM (in Audiobus 3 I get the exact same issue).


    Update: Since the MIDI clock sent by AUM seems to be tight, my next try was to use a hardware USB MIDI interface and the Digitakt 5-pin MIDI ports instead of the Digitakt's USB MIDI.
    And guess what?
    Exactly the same issue! From time to time (maybe one out of five), when starting the AUM transport, Viking synth plays notes much too late.
    The Digitakt follows AUM's clock perfectly and sends MIDI notes back to AUM in-time so it must be something with incoming MIDI Notes being forwarded to Viking too late sometimes.
    Interesting detail: When Viking plays too late, the delay remains constant while playing, as if I had added a 200ms (rough estimate) audio delay.

    @j_liljedahl
    So I've done the exact same test in Cubasis:
    Cubasis sends MIDI clock to Digitakt, Digitakt sends its sequenced MIDI notes back to Cubasis which hosts the friendly Viking.
    This time, Viking always plays the way it should. Every time I start the transport in Cubasis, Viking will play with the same tiny latency. No surprising delays.

    So I'd say it's neither an issue with the MIDI interface, nor an issue with iOS.

    I'm pretty sure there are some improvements that can be made in AUM for this kind of use case. One issue is that incoming external MIDI events can never be delivered in time, because the next available audio buffer cycle will already be too late. So one must add a constant latency to minimize jitter (=random delay). And this latency must be subtracted from the outgoing MIDI clock time, so the external HW sequencer runs a bit ahead of time. But then, what happens if the same sequencer also sends notes to an external HW synth? The iPad audio output will be late compared to the direct HW synth. If that HW synth would then be fed back into AUM, it could compensate there, but not if the HW synth and iPad output was mixed in an external HW mixing console.

    There are no easy solutions, and it would require some user settings to adjust compensation at different points depending on the actual setup.

  • cronycrony

    @j_liljedahl said:

    @crony said:
    I guess it's a different issue, but might be related ?

    As a user, I can say that into AUM at some point, midi connections get some kind of a "reset".
    Also seems particularly destructive on my 4 in/ 4 out midi interface which get 0 links suddenly...
    The only difference with the other midi device is that my midi interface Miditech midiface 4x4 is constantly sending Active Sense FE messages, but AFAIK, it's better to have that signal.
    As I'm redirecting a lot of stuffs, I wonder if multiple Active Sense messages might collide and blown the midi
    Other midi external controllers are doing fine after this "reset".
    It happens randomly, but I get also some weird CPU spikes also (from 70 to 150% during a second) completely random.

    The spikes were there before (with an iPad pro 11") but midi disconnections seems started around 6 months ago. (might be before, not sure as my preset has also evolved a lot during this period, and it took me some time to find out...)

    The thing is that on my other iPads, my other midi interface are not sending or receiving this message.
    The only iPad getting these reset is receiving from 3 midi in this message...

    Could it be possible to have AUM blocking this messages by default to see if it has an impact in my workflow ?
    Or it has absolutely no impact, and it's an IOS bug ?
    My midi interface is having an issue ?...well...

    What is this "reset" you're talking about? I'm not sure I understand.

    It's like my midi interface is disconnected for 1 second, then reconnected.
    Obviously all internal midi connections in AUM are gone.
    That's what I call a "reset".
    But I'm 90% sure now it's a stupid cheap USB C adaptor that is used only for charging connected in between my "clean" powered usb hub 3 with all my external midi gears to it that is causing this...
    The weird part is that only the 4 midi in/out midi links into AUM are broken, other controllers and internal midi connections set (like Quneo, Faderfox etc...) are perfectly fine even after that "reset".

    So might be the USB C adaptor (just bought the pricey, second hand, Apple original one to make sure), or my midi interface as it's the only gear that get that, or, unlikely the connection between the sound card and the usb hub.

    Anyway, nothing to do with midi clock... :D

  • rs2000rs2000

    @crony said:
    It's like my midi interface is disconnected for 1 second, then reconnected.
    Obviously all internal midi connections in AUM are gone.
    That's what I call a "reset".
    But I'm 90% sure now it's a stupid cheap USB C adaptor that is used only for charging connected in between my "clean" powered usb hub 3 with all my external midi gears to it that is causing this...

    I had such behavior long ago with a faulty iTrack Dock. A Focusrite technician said it was the Lightning connector's fault. They replaced the whole box though.

  • rs2000rs2000

    @j_liljedahl said:

    @rs2000 said:

    @brambos said:
    ...
    But at least one thing is certain: something is gobbling up MIDI messages while they travel from one place to the next, and it doesn't look like it's AUM (in Audiobus 3 I get the exact same issue).


    Update: Since the MIDI clock sent by AUM seems to be tight, my next try was to use a hardware USB MIDI interface and the Digitakt 5-pin MIDI ports instead of the Digitakt's USB MIDI.
    And guess what?
    Exactly the same issue! From time to time (maybe one out of five), when starting the AUM transport, Viking synth plays notes much too late.
    The Digitakt follows AUM's clock perfectly and sends MIDI notes back to AUM in-time so it must be something with incoming MIDI Notes being forwarded to Viking too late sometimes.
    Interesting detail: When Viking plays too late, the delay remains constant while playing, as if I had added a 200ms (rough estimate) audio delay.

    @j_liljedahl
    So I've done the exact same test in Cubasis:
    Cubasis sends MIDI clock to Digitakt, Digitakt sends its sequenced MIDI notes back to Cubasis which hosts the friendly Viking.
    This time, Viking always plays the way it should. Every time I start the transport in Cubasis, Viking will play with the same tiny latency. No surprising delays.

    So I'd say it's neither an issue with the MIDI interface, nor an issue with iOS.

    I'm pretty sure there are some improvements that can be made in AUM for this kind of use case. One issue is that incoming external MIDI events can never be delivered in time, because the next available audio buffer cycle will already be too late. So one must add a constant latency to minimize jitter (=random delay). And this latency must be subtracted from the outgoing MIDI clock time, so the external HW sequencer runs a bit ahead of time. But then, what happens if the same sequencer also sends notes to an external HW synth? The iPad audio output will be late compared to the direct HW synth. If that HW synth would then be fed back into AUM, it could compensate there, but not if the HW synth and iPad output was mixed in an external HW mixing console.

    There are no easy solutions, and it would require some user settings to adjust compensation at different points depending on the actual setup.

    What surprised me is that in the same setup, Cubasis didn't show this behavior at all. And the delay time, when it occurs, is definitely longer than 256 audio samples.
    I have a variety of hardware machines with MIDI clock, if you want, you can prepare a TF build with different adjustable buffers, higher debug level and I'll test again.
    The offset between early audio from hardware and AUM wouldn't be so much of an issue because it's comparatively small and if I really cared, I'd add my little stereo delay stomp box after the hardware. Did that with Gadget and BM3 already because they both don't have latency correction taking the audio buffer into account. Perfect sync.

  • [Deleted User][Deleted User]
    edited November 2019

    currently I have to use midi clock out from AUM and like @rs2000 I actually need some kind of latency trimming option to help with syncing. @j_liljedahl

    Maybe the OP title can be modified also?

  • rs2000rs2000

    @[Deleted User] said:
    currently I have to use midi clock out from AUM and like @rs2000 I actually need some kind of latency trimming option to help with syncing. @j_liljedahl

    I hope he's investigating the inconsistent start behavior and considering positive and negative MIDI clock offset adjustment that can be saved per session. Feedback and other experiences are very welcome.

Sign In or Register to comment.

© Vanilla Keystone Theme 2024