Random flats (♭) appearing that don't do or mean anything

So I was trying to find a workaround for a different bug, that being 11th, 13th, etc. chords displaying 6 or 7 notes but not actually playing 6 or 7 notes (edit: sometimes it does though?), and at some point noticed this:

I don’t know what exactly I pressed to cause it as I was just clicking around, but if it shows up again I’ll try to provide more details. The chords don’t sound or display any differently. Although somehow I got a bᵒ♭♭♭♭♭♭♭ in my score (that also sounds like a normal bᵒ:

If I change that chord, the ♭s stay in the name but everything else works normally.

Thank you for reporting this. I have never seen this before. Yes, it would be nice if you can find some steps to reproduce it, in the case you ever see it again.

About the other “bug”:
Our harmony instruments have different voicings. Some like the “Full Chord” ones are playing all chord notes and a root/bass note while others are restricted to play only three notes which makes sense for rich Synthi sounds which would sound muddy if they are playing too many notes at the same time or right Piano patches etc.

I’m sorry that it’s a bit unclear which voicing an instrument patch is using. I think Ryan has a vision of letting the user select the voicing method for each instrument but this has never been a priority as we would need to change the whole band browser UI for this to happen.

Ok here are some steps:

Enable ♭5 on a major or diminished triad, or ♯5 on a minor triad, then toggle add9, add11, and add13 a few times. One or more of those three will add either one or two extra ♭s or ♯s to the interface each time it is toggled.

This bug likely isn’t encountered often. I had been working through a MIDI dump of chord voicings in a depth first search of all the chord properties trying to work out if you were taking into account avoid notes from jazz or something. Thanks for explaining about voicing differences per instrument. Are there other voicings or just those two? Which notes have priority - bass, third, and highest? Are avoid notes or other factors considered?

I like your take on songwriting with the band browser. It is fast at generating usable backing tracks so you can just focus on getting ideas down. Having a bunch of premade basslines is really handy. It would be awesome if it let you see, edit, and create new voicings (FR: and patterns/phrases/arpeggios) to fine tune perfect starter MIDI tracks, so I hope you do decide to build that at some point. You could probably even sell addon packs of presets in different styles.

Thanks for the steps. I could easily reproduce it and added it to my list.

Yes, there are basically four combinations of open, compact with three-note and full voicings. All voicings are created in a way that the top note of those chords is staying in the same position as closely as possible. I think third has seventh have the highest priority in three note voicings.

I agree, that sometimes you want go in deeper and change the actual notes of all those patterns. But this is lots of work and we would need to find a way to make it really easy and to not loose the easy way of creating something fast in Hookpad.

Here’s another one:

Create a diminished 7th chord and toggle no5 a few times, and a bunch of extra right parentheses get added to the interface.

Screenshot 2023-04-24 165736

Thanks a lot for reporting!

For some reason I thought this had been fixed, but I just encountered it again. Unfortunately I don’t have concise steps right now but maybe my explanation will provide some clues where to look.

Screenshot 2024-04-05 000028

When I added a chord in front (any chord it seemed), the extra flats moved one chord back:

As I kept adding chords in front, it continued to move the extra flats backwards, but only for chords added within the previous four measures. The result was that, in this case, the extra flats were always on the sixth chord past the beginning of measure 21. When I deleted all but five chords in that four measure segment, so there was no sixth chord, the extra flats disappeared and did not return even after undoing. There were more chords later in the project, but the extra flats seemed to be tied to that four bar segment.

I would offer the file, saved while the flats were sill visible, but it renders correctly after reopening. I have it if you want it though.

Hi and thank you for the bug report. I was able to fix this issue, it should be fixed after the next update.

1 Like

Got some more for ya.

Screenshot 2024-04-24 153943

  1. File > New
  2. Borrow From > Har. Minor
  3. Insert i chord
  4. Borrow From > Har. Minor
  5. Insert iv chord
  6. Change project key
  7. Scale Change Type > Relative
  8. Lydian
  9. Scale Change Type > Parallel
  10. Locrian
  11. Scale Change Type > Relative
  12. Lydian
  13. Scale Change Type > Parallel
  14. Phrygian
  15. Scale Change Type > Relative
  16. Lydian

There are other nearby keys/modes that have this same bug but on different chords, but you can probably find them from here.

Hahaha. How did you even find that? Thank you for the bug report! I’m on it.

Eh you know, just making a chart of all the chords in all harmonic modes between all flats and all sharps lol. I think these are right on the border where they turn to double sharps. These flats might actually be correct here – 11 flats is enharmonically equivalent to one sharp!

Apparently this bug is still a thing. After entering a #vob7 in D# minor and then switching the key to relative Lydian I got this:

The worst part isn’t even the spelling, but rather the fact that Hookpad randomly labels a fully diminished chord as a dominant seventh. The paino playback is still correct though.

This seems to reliably happen with chords where the root note is an enharmonic equivalent of the first scale degree and spelled with sharps (e.g. B# in C major). This happens in every mode of every key and Hookpad will always label the chord as a dominant seventh regardless of the chord type. I’ve seen this happen on other scale degrees as well, but it doesn’t seem to happen as reliably.







You were totally right. We’re saving the fingerprint of the borrowed scale. And that specific combination of relative and parallel key changes produced a something like -11 which resulted in 11 “b” accidentals instead of one “#”.

It should be fixed with the next update. It might be that if you do the process of relative and parallel changes for some 20+ times again that the fingerprint of the borrowed key is producing negativ numbers again, but I don’t think this is a real case scenario anymore.
Please let me know if you find something else like this.

Regards!
Dennis

1 Like

I totally realize how impractical and contrived the situation I was describing above might seem, but believe it or not, this actually happened to me while transcribing a song. The song contains a bunch of fully diminished seventh chords on various scale degrees that don’t resolve upwards by half step, so labeling them as viio7/x would be incorrect.

Granted #vob7 is horrible spelling, but viob7 is really complicated to enter in minor keys (probably even impossible in a lot of keys) and I just wanted to get on with the transcription, so I decided to pick the easier spelling for the time being and rack my brains over how to enter viob7 once I’m done transcribing.

While I agree that changing the key 20+ times might not seem like a real case scenario, I think it’s actually not that unrealistic given how ridiculously hard it is to access some of the supermodal chords, especially if you want to maintain sensible spelling.

I realize that this is not a top priority right now, but I think this is something that should be adressed at some point. For example if all supermodal chords were available via the search bar, that would prevent people from chosing unnecessarily complicated routes for borrowing them and thus encountering bugs like this one.

1 Like