Poll of possible crash triggers (please help us by adding yours)

To all BM3 users,

I would like to try building a clearer picture of which particular actions in BeatMaker3 are more likely to result in crashes, and would appreciate the community's help in gathering useful data for this purpose.

There seems to be some misinformation amongst the community about BM3 that suggests it might be less reliable/stable than it really is (in my experience) - especially with the recent updates, which seem very stable to me - so I would like to try to zero-in on any specific crashes that users still experience from time to time.

Speaking personally, I can't remember the last time BM3 crashed on my iPad Pro. I've learned which plugins are less stable than others, and which actions are slightly 'riskier', so I've now learned to manually save my projects before doing something which may have triggered a crash in the past.

If I've missed anything from the list, please add the details in a reply.

Thanks for your help :)

Poll of potential BM3 crash triggers
  1. The last time you experienced a crash, can you remember what you were doing that may have caused it?12 votes
    1. Using long audio clips in the sampler (> 1 minute)
      16.67%
    2. Doing lots of successive trims and waveform edits
        8.33%
    3. Loading (or unloading) an AUv3 plugin
        8.33%
    4. Undo/Redo
        0.00%
    5. Adding (or deleting) a Bank
      33.33%
    6. Recording automation
        8.33%
    7. I don't remember the specifics
        0.00%
    8. I honestly can't remember the last time I had a crash
      25.00%
«1

Comments

  • edited August 2019

    From conversations with many BM3 users, it appears that a small number of users are having a worse experience than others. It could be specific 'troublesome' plugins, it could be a particular action or sequence of actions, or it could be a RAM issue. It does appear that iPad Pro users (like myself) report far less crashes than those on regular and legacy iPad devices.

    The poll above is designed to see if we can spot patterns of actions that may be triggering crashes.

    If anyone reading this is a regular BM3 user and has experienced a crash recently (in the latest version, 3.0.12), I would appreciate you submitting the details above and in a reply.

    I use BM3 happily every day, and can't remember the last time I had a crash, so let's try to sort facts from fiction :)

  • Is it possible to make the poll accept multiple options? I triggered this tk32's initiative by my post in AB forums and I mentioned all the options as the possible reasons for a crash and all of them are probably equally relevant...

  • Thanks @skrat

    I tried to support multiple entries, but it would involve making a separate poll for each answer (which is not ideal).

    Feel free to post more detailed responses in a reply

  • edited August 2019

    Recently I realized that simply scrolling the AUfx list (probably more at high cpu levels) seems to be a bit crash prone for me. Not even loading the aufx themselves, just browsing the list. (Always while playing)

  • I don't have super deep specifics but a few scenarios where I've bumped into issues lately.
    These happen mostly when something is playing back...

    Add/Remove Bank (which may or may not have contained multiple plug-ins and effects).
    Feels like the bank is 'deleted' before all plug-ins and other resources (open files etc.) are successfully unloaded or closed... (Could be related to generic resource allocation?).

    Doing extensive trim and sample editing.(again mostly while stuff is playing).

    Undo can also be 'shaky' if the sample/samples have already been saved to a new location and the 'undo buffer' points to another file...(I seldom use undo...).

    So to 'work around' the issues, I usually stop the transport before doing more in depth edits and 'save' when my gut tells me things may go haywire...

    Also replacing samples while a sequence is playing can cause some 'instability' (Ie. replace a sample while it's being played back by the sequencer).

    That's about it...

  • edited August 2019

    Excellent post @samu - I can always count on you to be scientific in your analysis B)

    There definitely seems to be a common factor that making significant changes (eg deleting banks, changing the plugin stack) to a project during playback is generally a bad idea.

    I've trained my muscle-memory to instinctively stop the track and hit quick-save before taking any actions I consider major. I do feel that once you adopted a small amount of caution, you can happily go forth and experiment without anxiety.

  • I never hit stop to do anything. I just save often, 'collect samples' on occasion, save new iterations and avoid having more than 64 slices on a wav, as that is a guaranteed crash for me (if I audition them by double tapping). Other than that, do I crash? Yah, but out of the past 50 hours use I have crashed maybe ten times and that is primarily when experimenting with strange/new AUs or hitting high CPU levels, or forgetting an IAA in the background.

  • I always stop the transport before loading samples or AUv3s, or doing any destructive edits. Only using BM3 around ~20 hours a week recently, and it can go several days without a crash, but some days it crashes several times an hour mostly due to impatience.

    Last time 2 or 3 times BM3 crashed for me:
    When adding/deleting a bank with many samples using realtime time-stretching or any of the other realtime sample tools. The session was just two sample banks, no AUs. The 1st bank (with all the realtime tools) was an older one, loaded as a reference for the 2nd bank, which was being created when the crashes occurred. Though I tend to cram lots of samples into single banks.

    What I learned to avoid:
    Many problematic AUs.
    Stop the transport. (Anyone remember the pre-Elektron days? Always had to stop it in order to do anything.)
    Letting BM3 and iOS fully save before doing any destructive edits or using undo.
    Save often when using scene mode. Move everything to song mode sooner.
    When using audio tracks, avoid scene mode.

  • @samu said:
    I don't have super deep specifics but a few scenarios where I've bumped into issues lately.
    These happen mostly when something is playing back...

    Add/Remove Bank (which may or may not have contained multiple plug-ins and effects).
    Feels like the bank is 'deleted' before all plug-ins and other resources (open files etc.) are successfully unloaded or closed... (Could be related to generic resource allocation?).

    Doing extensive trim and sample editing.(again mostly while stuff is playing).

    Undo can also be 'shaky' if the sample/samples have already been saved to a new location and the 'undo buffer' points to another file...(I seldom use undo...).

    So to 'work around' the issues, I usually stop the transport before doing more in depth edits and 'save' when my gut tells me things may go haywire...

    Also replacing samples while a sequence is playing can cause some 'instability' (Ie. replace a sample while it's being played back by the sequencer).

    That's about it...

    Good point with playback on, I completely forgot about this aspect but it seems like it is very important factor that increases the chances for a crash. Good to know to avoid them...

  • My last consistent crash was when using a sample longer than 1 min. Crashed everytime after loading this sample into sampler. I cut the sample down to shorter length and the crashing stopped.

  • @cthulufunk said:
    My last consistent crash was when using a sample longer than 1 min. Crashed everytime after loading this sample into sampler. I cut the sample down to shorter length and the crashing stopped.

    Thanks for posting.

    Two quick questions...

    1. Did you slice the audio, or run the transient detection on it?
    2. Was the sample loaded into RAM (disk streaming: off) or was it streaming from disk?
  • edited August 2019

    @tk32 said:

    Two quick questions...

    1. Did you slice the audio, or run the transient detection on it?
    2. Was the sample loaded into RAM (disk streaming: off) or was it streaming from disk?
    1. There was one slice I believe, mapped to 2 pads. I used the Divide slicing feature,
    2. Loaded that sample again to check and it default loads with Disk Streaming: On.
      I’m still pretty new to BM and never mess with that setting.

    I’m on the iPad Pro 2, Model MPDY211/A if that helps. I’m loving BM3, blows away hardware I spent 30x as much on.

  • edited August 2019

    Ok.

    In my experience, Soft-slicing (see explanantion further down) with disk streaming ON does not play nicely together and is probably what made bm3 unstable. Even if it's just one slice.

    In your situation, I would advise the following...

    1. Use the "slice to pads/layers" command so that your long sample is divided into smaller chunks that can be triggered without slices.

    Or

    1. Load the whole sample into RAM so that bm3 can jump around the wave as you trigger each slice without straining your iPad disk access speed.

    Soft-slicing is where you create the slice markers but then leave the original sample in place and don't chop it into smaller pieces. You could also call it non-destructive slicing and I think it was only intended to use on samples that can be fully loaded into RAM (such as a drum loop). It's an incredibly powerful feature, but when you use it on very long samples (say >30 seconds), which would normally play by streaming from disk, asking bm3 to jump between slice markers whilst streaming will make things less stable. Bm3 lets you add slices to disk-streaming samples (without warning against it), but it's probably not a good idea if you want to avoid crashes.

    Hope this helps.

  • @tk32 said:
    Ok.

    In my experience, Soft-slicing (see explanantion further down) with disk streaming ON does not play nicely together and is probably what made bm3 unstable. Even if it's just one slice.

    In your situation, I would advise the following...

    1. Use the "slice to pads/layers" command so that your long sample is divided into smaller chunks that can be triggered without slices.

    Or

    1. Load the whole sample into RAM so that bm3 can jump around the wave as you trigger each slice without straining your iPad disk access speed.

    Soft-slicing is where you create the slice markers but then leave the original sample in place and don't chop it into smaller pieces. You could also call it non-destructive slicing and I think it was only intended to use on samples that can be fully loaded into RAM (such as a drum loop). It's an incredibly powerful feature, but when you use it on very long samples (say >30 seconds), which would normally play by streaming from disk, asking bm3 to jump between slice markers whilst streaming will make things less stable. Bm3 lets you add slices to disk-streaming samples (without warning against it), but it's probably not a good idea if you want to avoid crashes.

    Hope this helps.

    Slice to pads will cause issues especially if the disk streaming is on for the source sample prior to slicing as that setting will propagate to all the sliced pads.

    Even the 'soft slicing' will cause issues if disk streaming is left ON :(
    (Why read the file from 'Disk' when it can be kept in RAM?).

    So when ever multiple rapid accesses of a file are needed its better to disable disk streaming and keep all the samples in RAM as long as possible.

    If I recall correctly there is a setting in BM3 as to how much Ram it allocates? (32MB or so?).

    Don't know if Intua still 'Do an Akai' and convert all the loaded samples to 32-bit floats to save CPU which will eat more RAM(Most of the time double the size of the loaded sample depending on source bit-depth and sample-rate).

    I think that as the amount of Ram in iOS devices go up it should be pretty safe to allocate a larger chunk of RAM for samples...

    Considering that 10MB is around 1 minute of stereo sound 32MB is 3 minutes of audio and that should be plenty for samples unless using extreme splits and layers are needed. (In those cases I'd use an external AUv3 synth anyway and record the results to an audio track if CPU starts to choke).

    Regarding Ram allocation, disk-streaming for audio-tracks and RAM for samples should be the logical solution...

    That's my current take on it, I seldom reach even 64MB of samples when creating stuff...
    (That's curiously enough the limit of the Digitakt too).

    Cheers!

  • edited August 2019

    @samu makes some great points (as usual)

    I previously suggested that slicing to pads might solve the issue, but he's right that this process replicates the same sample to each pad and simply moves the start and end markers for each instance.

    The 'best' solution, therefore is either...

    Trim the parts of the sample you don't need then load the whole thing into ram

    Or...

    Slice to pads, then open each pad, trim the audio, and make sure it's not disk streaming.

    Extra work? Yes. Worth the effort for stability and flexibility? Absolutely

  • Lately I’ve been crashing most often when going into the layer effects of a pad loaded with a sample over 1 minute long. That being said, I don’t know for sure that it’s exclusive to >1min samples. I’ll have to start keeping closer track on future crashes.

  • @KurrentlyKorg said:
    Lately I’ve been crashing most often when going into the layer effects of a pad loaded with a sample over 1 minute long. That being said, I don’t know for sure that it’s exclusive to >1min samples. I’ll have to start keeping closer track on future crashes.

    This is interesting. Do you know if your 1 minute sample is loaded into RAM? (in the sample editor check if disk streaming is ON or OFF)

    If disk streaming is set to on, try setting it to OFF and see if adding layer FX still causes issues.

  • @tk32 said:

    @KurrentlyKorg said:
    Lately I’ve been crashing most often when going into the layer effects of a pad loaded with a sample over 1 minute long. That being said, I don’t know for sure that it’s exclusive to >1min samples. I’ll have to start keeping closer track on future crashes.

    This is interesting. Do you know if your 1 minute sample is loaded into RAM? (in the sample editor check if disk streaming is ON or OFF)

    If disk streaming is set to on, try setting it to OFF and see if adding layer FX still causes issues.

    1 minute samples fit into ram quite easily (1 minute mono ~5MB unless auto converted to 32-bit floats).

    I recall there was a threshold at which BM3 automatically turned on disk-streaming when loading samples even if there was no real need to do so. (The limit was also fairly low, like ~2-5MB or so?!).

    I try to keep disk-streaming turned off as much as possible to keep things stable.

  • For me anything....BUT it’s not a complete crash, it’s more like zhzhzzhzh....hkggkgkhkhkg...... no sound....gkhkh....hphph.... no sound................————————
    Or when I start playback of a saved proj it waites about 20 sec. before it starts playback.
    Or it can work Ok.
    And it’s all with the same project and no changes to it. Go figure. : /

  • edited September 2019

    @vov

    When you load a project, you have to wait for all plugins to initiate. Depending on the number (and size) of the plugins this can take up to 5+ seconds.

    Unfortunately bm3 doesn't warn you that it's loading things in the background, but if you try to start playback before the process is finished... Crackle/Crash city.

    If you want to be sure bm3 has finished loading plugins, my tip is to tap the browser hamburger button immediately after loading a project. The browser window won't open until all plugins have loaded (at which point, you know it's safe to start playback).

  • When you are in the bank screen and the song is playing, if you switch to a new bank then BM3 will always crash for me. My workaround for this is to switch banks from the mixer screen them so back to the bank screen.

  • edited September 2019

    @Michael Lawrence said:
    When you are in the bank screen and the song is playing, if you switch to a new bank then BM3 will always crash for me. My workaround for this is to switch banks from the mixer screen them so back to the bank screen.

    Woah weird, never had that. What device/iOS?

  • @Audiogus said:

    @Michael Lawrence said:
    When you are in the bank screen and the song is playing, if you switch to a new bank then BM3 will always crash for me. My workaround for this is to switch banks from the mixer screen them so back to the bank screen.

    Woah weird, never had that. What device/iOS?

    It happened on my 2016 iPad pro 12.9" and also my 2018 iPAD pro 12.9".

  • edited September 2019

    @Michael Lawrence said:

    @Audiogus said:

    @Michael Lawrence said:
    When you are in the bank screen and the song is playing, if you switch to a new bank then BM3 will always crash for me. My workaround for this is to switch banks from the mixer screen them so back to the bank screen.

    Woah weird, never had that. What device/iOS?

    It happened on my 2016 iPad pro 12.9" and also my 2018 iPAD pro 12.9".

    I have the same problem on my 2016 iPad Pro 12.9"

  • @tk32 said:
    @vov

    When you load a project, you have to wait for all plugins to initiate. Depending on the number (and size) of the plugins this can take up to 5+ seconds.

    Unfortunately bm3 doesn't warn you that it's loading things in the background, but if you try to start playback before the process is finished... Crackle/Crash city.

    If you want to be sure bm3 has finished loading plugins, my tip is to tap the browser hamburger button immediately after loading a project. The browser window won't open until all plugins have loaded (at which point, you know it's safe to start playback).

    Checked your hypothesis, but no, I can toggle the browser on/off and press the play button after this and still there will be no sound or garbled sound afterwards.
    Latest iPad Pro here, I think it’s not a good model for music.

  • I usually experience it when adding or deleting a bank but it’s usually when I’ve had it looping for a while and have a lot going on. I also only have an Air 1 so I’m sure that doesn’t help

  • edited September 2019

    @vov

    Maybe I remembered the trick wrong. I'll test it again this evening.

    In any case.. I always suggest waiting 4+ seconds after loading a project before you start playback or trigger any plugin notes

  • @tk32 said:
    @vov

    Maybe I remembered the truck wrong. I'll test it again this evening.

    In any case.. I always suggest waiting 4+ seconds after loading a project before you start playback or trigger any plugin notes

    Thanks. It helped a bit. So your theory’s at least partially correct, only I can toggle browser while it’s loading. But it still makes such funny noises sometimes I thought only analog equipment full of mice could produce. Just got it now by switching from mixer to bank view while playing. I wish I could share it with you, but I don’t see how to attach a video on this forum.

  • I can’t even playback a sample sometimes. Need to reload the app.

  • @vov I usually get that if I'm running too many heavy AU plugins and/or with my buffer setting too low. Sometimes it's a particular AU that just crapped out.

Sign In or Register to comment.