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?10 votes
    1. Using long audio clips in the sampler (> 1 minute)
      10.00%
    2. Doing lots of successive trims and waveform edits
      10.00%
    3. Loading (or unloading) an AUv3 plugin
      10.00%
    4. Undo/Redo
        0.00%
    5. Adding (or deleting) a Bank
      30.00%
    6. Recording automation
      10.00%
    7. I don't remember the specifics
        0.00%
    8. I honestly can't remember the last time I had a crash
      30.00%

Comments

  • edited August 14

    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 14

    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 14

    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 24

    @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 6:48AM

    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!

Sign In or Register to comment.