BUG: Empty pads, plugins, sample slicing to pads and keys, bogus midi data and strange behavior.

On initial pad view 16 with an empty bank and all settings at default, pad 1, 17, 33, et cetera all the way through page 8 produces note velocity NOTE ON/OFF value 127. NOTE ONs/OFFs for pads 2-16, 18-32, 34-48 et cetera produce independent midi channels 2-16 instead of a single channel and NOTE ON/OFF velocities for 100 instead of 127.

Then Inside keys of page 1-8 base key produces NOTE ON value 100. NOTE OFF value is 127. All other notes are outputted correctly but velocities are at 100. All have independent channels.

Then, move view to 64 view on page 1. Tap a pad. Velocity for all pads across all controls will either become 100 or 127. It is never consistent. Then loading a plugin first and a sample second or the other way around (I’m not sure exactly which it is) on the same pad in bank may produce Backwards note on/off velocities for all keys in that pad especially if you touched an empty pad in keys mode before loading. So note on is 100, note off is 127 for velocity.

Also slicing samples to pads or to keys sets the velocity all wrong. again another 100/127 mess.

The first impression I got in the manual since it’s one of of the things stated is empty pads record MIDI themselves. So what I did was start using them as a tool to capture midi grooves in my head when I didn’t have time to trial samples (had no samples loaded yet, no purchases, whatever) and saved these banks. Now loading a sample on an empty prerecorded pad is always messed up midi velocity or even worse, none of the midi pattern captured correctly in the first place with empty pads. Maybe do to the fact every 16 pads has channels 1-16? It’s all messed up.

It has been like this since at least 3.05 if not the very beginning? Why is velocity 100 and 127 a thing with slicing and/or empty pads? Especially the velocity when slicing. It is not good to make users have to potentially redraw a potential maximum of 64 automations per slice. Also what if a person clears the pad to keep the midi that was captured but then begins to record new Midi on that empty pad without a new sample loaded immediately or when slicing to that pad later? Guess what. Bogus midi!

I will do a video sometime when it isn’t 2 a.m and I’m not upset I had to trash my bank of mental ideas.
Would love at least an explanation to why MIDI is not really useable at all with empty white pads. It doesn’t record right on so many levels and slicing defaults to 100 velocity in automations. Who knows maybe this is the cause of a ton of other problems indirectly related users have had.


  • Failed to mention another thing. If MIDI velocity defaults to 100 when slicing or with just recording empty pads (or fixing midi before loading a samole, if your default gain level settings are a specific amount like -6 or -12 db. You'll get even more confusion.

  • Sure why not I'll add a little bit more. Samples on pads send note off velocities of 127 instead of 0. Isn't this a problem and why we have so many latches everywhere or weird trigger behaviors?

  • Hey @mefisme ! Thanks for the another very detailed bug report!


  • edited February 2018

    @GusGranite @mathieugarcia

    Are these bugs though? Or limitations that need workarounds?

    In a traditional DAW many companies do set velocities at default to 100. Since these other DAWs have a horizontal track structure and automation lanes are either collapsible or on the track themselves, it's much easier to adjust the velocities. This isn't the case with BM3 as it is almost entirely a pad-based super sampler DAW where everything is in modules, panels, separate windows. BM3 also has this global default gain option as well we change very often. And the gain options per sampler in a pad.

    The NOTE OFFs that are at velocities of 127 confuse me completely. I even checked if ADSR had something to do with it. It doesn't seem to. If the idea was to allow effects like reverb to ring out here that should be done during NOTE ON values. This bug implies that when you let go of a pad it sends a NOTE OFF message but could potentially cause the one-shots I've been talking about when your in hold mode or even the weird audio glitches users are experiencing. So this could be something that isn't just empty pads or keys. It could be the culprit to a slew of problems.

    New users unfamiliar with MIDI:
    If you do check how MIDI is running in a particular iOS daw, please be aware MIDI’s middle C is always note number 60 even if the DAW or MIDI application receiving is visually being represented otherwise. Do not let this confuse you. ;)

  • edited February 2018

    Actually, I stand corrected. Note number is always 60 in specification. Value is arbitrary. Fixed top post. This is why we need midi learn everywhere as well in case some third-party developer decides to build an a AU plug-in but doesn't know their MIDI specs. Everyone's going to perceive that something's wrong with a plugin in BeatMaker 3. it may not be.

  • edited February 2018

    Yes... know I type too much versus video. I'm covering alot here. I'm going to summarize the text and then I'll showcase a video to show users what I'm talking about. Point being I do think empty pads need to be opened up just like they are when samples are loaded.

    In other words:

    Allow paging in keys regardless whether or not a sample is loaded or not.
    Allow wheels, rolls, velocity triggers, repeats regardless whether a sample is loaded or not.

    Allow fixed velocity regardless whether a sample is loaded or not. Currently you can set this, but it resets.

    All MIDI should function identically regardless whether samples are loaded or not.

  • edited February 2018

    @GusGranite said:
    Amazing QA!

    Thanks, except it's not QA unless I'm on the beta or internal. Which I'm not. Maybe I should do the beta. I don't want to expose things and make people think BM3 is crap. It's not at all. Bug reports being transparent to users can be a great thing. This is why I like Intua alot. They allow this open community. But not everyone will perceive this as good. It's scary sometimes. These bug reports can cause poor reviews when that shouldn't happen. But we live in a world where everyone likes to give their two cents when they don't know what's fully going on. This is why I only write a review unless I've reached 4-5 star potential. I want apps to succeed. Not fail.

  • @mefisme you should definitely be on the beta team. You obviously know your onions!

Sign In or Register to comment.