Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Atom piano Roll2 - White screen of death?

Hi

I was using APR2 today inside AUM, and one of the instances I had opened started showing a black screen instead of the piano roll grid. Everything else was visible, but I could not see any of the notes. I closed it, and when I opened it again the whole thing was white. I tried reopening AUM, but to no avail. It is odd that the notes are being triggered, though the screen is still completely white. I did not take a picture of the black screen, but here is the white one. The other instances of APR2 I am running in that AUM project look just fine (I left one visible on the background to show this)

Any idea of how to fix this?

Comments

  • wimwim
    edited July 2021

    Have you tried resizing the window to a different shape? Sometimes that causes AUv3s to re-process things. If that doesn't work, try saving the AUM session, then force-closing AUM and then re opening the session.

  • @wim said:
    Have you tried resizing the window to a different shape? Sometimes that causes AUv3s to re-process things. If that doesn't work, try saving the AUM session, then force-closing AUM and then re opening the session.

    Thanks wim for the reply. I tried resizing the window, but it still shows white (even after saving it and opening it again with the new size). Excuse my ignorance, but I don't know what "force closing" means. Is that the same as closing the app (i.e., swipe up so the app shows in a small window, then swipe up again so it closes)? If that is the case it hat not solved the problem

  • I’ve been noticing this bug lately: takes a moment for Atom 2 windows to load after I duplicate channels.

  • edited July 2021

    Interesting. I didn’t have this happen even once during 10s of hours of beta testing.

    I wonder if, when it happens, if you save the AUM project under a new project name and restart AUM, if everything would be present and working again.

    Another suggestion would be to load a fresh instance of Atom2 on a blank MIDI channel and see if this kickstarts the UI into redrawing itself.

    I know that Blueveek put a ton of effort (very successfully) into reducing RAM and CPU use when the Atom2 UI is closed, and this may be connected to this issue.

    Finally, what iPad, iOS version (beta?), and AUM version (beta?) are you using @cfour ?

  • @cfour said:

    ... I don't know what "force closing" means. Is that the same as closing the app (i.e., swipe up so the app shows in a small window, then swipe up again so it closes)? If that is the case it hat not solved the problem
    Yeh, that's what I meant. Sorry it didn't help. Rebooting your device is always a good thing to try as well.

    I assume things like zooming gestures, tapping various parts of the screen, etc. have been tried.

    I wonder if changing the stylesheet from another instance might do something.

    The pattern(s) from that instance should be available from a new instance. Maybe you could open a new instance and grab that pattern into it.

  • edited July 2021

    Good suggestion Wim.

    Worst case scenario, you should be able to extract the MIDI into a new instance of Atom2 using the layers panel.

  • Thanks for the help!

    So far nothing has worked.
    @tk32 I tried saving it with a different name and added a new instance of APR2 as well, but it did not fix this problem. My AUM is version 1.3.10, the iPAD is an iPAD pro (3rd generation), ios 14.6. No Beta version as far as I can tell.

    @wim I did try gestures, and changing the stylesheet from another instance, but that windows is still white. The best yet incomplete option so far is to grab the midi data from the layers, the problem is that I can only see one clip belonging to that instance (that is, only the first pattern from that instance is shown). I would be thus missing the other two patterns. Not that I have there the 9th Symphony, but still it would be good if there was a way to recover all of it in case this happens again (and many more patterns were involved)

  • @cfour is the white instance correctly responding to pattern change events? If so, you could use another instance of atom to record the output of the white instance rather than trying to use layers.

    How long are the patterns in the white instance? How were they created? Lots of cc/mpe data? If they’re ginormous then atom might just be taking it’s sweet time rendering.

  • @tk32 hey, ever notice this? After long-pressing in a selection the loop markers change and then Atom doesn’t want to let you change them back.

    Honestly my long presses are usually due to me not being fast enough to start dragging the selection so changing the loop markers is less than useful. Being able to change them back would be nice though.

  • @tk32 and another one that I haven’t been able to reproduce reliably yet. Sometimes the layers panel isn’t rendered properly. It takes up half to three quarters of their vertical height. When this happens all the tap targets are wrong so you end up selecting the layer two above where you were tapping. Reloading the ui resolves the problem at least.

  • I have had a small bug with the time line playing bar running from the very left edge before the icons and the piano keys on the left
    The sound was correct but annoying
    Happened twice, I resized the window but it didn’t solve the problem
    But very rare, and certainly doesn’t stop me from using this awesome tool
    Just thought I would report it

  • @xor said:
    @cfour is the white instance correctly responding to pattern change events? If so, you could use another instance of atom to record the output of the white instance rather than trying to use layers.

    How long are the patterns in the white instance? How were they created? Lots of cc/mpe data? If they’re ginormous then atom might just be taking it’s sweet time rendering.

    Thanks for the reply. If I remember correctly I had 3 patterns there. An 8 bar pattern (that is still being played, despite the screen being white) and two other patterns that were 4 bar long from what I can recall. Nothing fancy, actually these are simple midi lines (not even chords). Actually I would love to know how to fix this in case it happens again, I wouldn´t mind too much losing those two extra patterns. But it does make me weary of depending too much on APR2 (as is the case right now)

    I tried your suggestion of recording what was there to a new instance of APR2, but those patterns were set for a PC switch source. I usually use the "note" switch to change patterns. Not sure how to go about with changing patterns using that PC switch. Tried triggering a second instance of APR2 that has the "launch PC" set to different numbers, but nothing happens (only the first pattern is being played)

  • @cfour said:

    @xor said:
    @cfour is the white instance correctly responding to pattern change events? If so, you could use another instance of atom to record the output of the white instance rather than trying to use layers.

    How long are the patterns in the white instance? How were they created? Lots of cc/mpe data? If they’re ginormous then atom might just be taking it’s sweet time rendering.

    Thanks for the reply. If I remember correctly I had 3 patterns there. An 8 bar pattern (that is still being played, despite the screen being white) and two other patterns that were 4 bar long from what I can recall. Nothing fancy, actually these are simple midi lines (not even chords). Actually I would love to know how to fix this in case it happens again, I wouldn´t mind too much losing those two extra patterns. But it does make me weary of depending too much on APR2 (as is the case right now)

    I tried your suggestion of recording what was there to a new instance of APR2, but those patterns were set for a PC switch source. I usually use the "note" switch to change patterns. Not sure how to go about with changing patterns using that PC switch. Tried triggering a second instance of APR2 that has the "launch PC" set to different numbers, but nothing happens (only the first pattern is being played)

    If you have Mozaic you can use something like https://patchstorage.com/elektron-pattern-changer/ to send pc messages to atom. There’s also a note-to-pc script on there somewhere.

    Streambyter can change cc into pc and I’d guess notes to pc too.

    I’ve never run into a permanent white screen in atom. That’s why I was wondering how much midi was in your instance. Have you tried plugging the iPad in, disabling auto lock and leaving AUM and the white atom open overnight? It may be that it’s just taking a very long time to render your pattern.

  • I wonder if @blueveek would be able to figure out something about what is triggering the issue from looking at the AUM project -- I don't know if there is any way to extract the Atom instance's data from the file. Maybe?

  • @xor I could try leaving it opened. It is strange since there is not a lot of data (at least it is pretty much the same as in the other instances of APR2 that are able to open). For this project most of the APR2 instances open with a white screen the first time they are opened. Then they open immediately. But there is one instance (the one I am talking about) that is always white.

    @espiegel123 That would be great!

    Here is a video I just made about this. As you can see all of the APR2 open except one that is left with a white screen

Sign In or Register to comment.