Quite some time has passed since Hookpad 2 was released, and there are some performance issues and some pretty frequent bugs that I find hard to believe no developer has encountered. I run into them very frequently. These happen both in Chrome and Firefox.
Play/pause and looping. Very, very buggy in general. I can’t even count the amount of times that the play/pause cycle gets “stuck” in playmode when nothing is actually playing, and viceversa. It’s especially frequent when controlling play/pause with the spacebar, and also when looping is enabled, forcing you to grab the mouse and manually click the play/pause button a bunch of times until it regains it’s sanity.
Magic chord/magic bass. Very useful features, especially magic bass, but again very buggy. The auto-playing preview mode, which can’t be disabled as far as I can see, messes up the play/pause cycle really frequently, going as far as forcing you to save and reload the page to be able to continue working, because it gets the song stuck in pause mode or in a paused play mode that you cannot get out of. Also, magic chord sometimes reports “no chords found for this chord-scale combination” for very common combinations, but when you refresh the page and try again, it actually finds them. If for some reason it doesn’t manage to communicate with the API, it should say so, instead of misleading you into thinking that it did a search but didn’t find anything. Makes you second guess the message and forces you to refresh to see if it’s actually true this time.
Inaccurate clicking. This one is especially infuriating if you like to rearrange stuff with the mouse, and it was also present in Hookpad 1. Clicking with the mouse to select and/or drag notes and chords, a lot of times simply doesn’t register or registers incorrectly, selecting instead nearby notes that weren’t clicked, or notes that are far away, or simply not selecting anything at all. I’m talking about stuff that is sometimes 15-20 pixels away from where you actually clicked. Very frustrating.
Any kind of mouse dragging actions, whether they’re about repositioning notes, resizing them, repitching them, etc. is a huge performance drain. It slows everything down to a crawl. It feels as though the redrawing rate of the app drops tremendously, and any kind of soft, nuanced interaction becomes really sluggish and inaccurate as a result. I’m using Hookpad with a i7 4790K CPU, it’s not exactly a slow computer.
Audio playback of the virtual instruments is sluggish. I just use the piano, I don’t even use complex mixing arrangements with lots of different virtual instruments. Notes get “stuck” frequently and it generally feels as though they have a hard time keeping up, especially when using polyphony and complex arrangements, leading to frequent of mis-timed note playback and audio clicks. This compounds with the play/pause bugs, which frequently lead to notes getting stuck in “on” mode, leading to stuck, infinite piano notes that only stop playing when resuming playback.
All of these issues are very, very frequent. They’re constant annoyances when working on any kind of arrangement. Is anything being done about them? Like I said, it’s been a long time…
I appreciate the efforts at any rate.
Edit: I’ve noticed a significant amount of the slowdowns take place when mousing over a chord or note and the resize “handlebars” overlay appears. Not even clicking, just hovering causes a huge slowdown. To reproduce it, simply arrange any number of 1-measure chords in a row, play the song, and hover the mouse over the chords back and forth. Watch how the playhead starts getting stuck all over the place. Something strange is going on there.
Is it being supported at the moment, noticed the last blog post was last year?
I subscribed a couple of days ago to try it out thinking it looks a great tool but I can’t get the youtube link button to appear. Tried on my my Mac and windows with a couple of browsers, has it been removed or something?
Was hoping the import midi would work better too, some amazing features but feels half finished.
Thanks for the comments and sorry for missing this original post. Let me address them individually:
Audio Playback: This should be greatly improved actually. Within the last month or so we implemented a big rewrite of the audio engine which uses a lot less resources. It was definitely the case previously that if you made a mix to complex audio playback could stutter. It shouldn’t do this anymore (have you tried using more complex mixes recently?).
Mouse Drag redraw: We are currently heads down working on a rewrite of the rendering engine to try to improve speed. We have already pushed some of the changes but expect to have improved framerates and response rates soon.
Inaccurate clicking: it’s possible this will get fixed with the redraw engine fixes (could it be lag causing your problems here?). If you have a simple reproducible way of reproducing an error from a blank canvas we will get that fixed right away.
Regarding playbackstuff and magic chord/bass: I’ll see if I can reproduce these. Are you on a mac or a pc btw?
I appreciate the response, Dave. I agree with @HertzDevil, these progress reports are appreciated. Not to put too fine a point on it, but visible improvement and reports of it taking place behind the scenes are part of the reason we pay for the service.
In response to the points you addressed:
Audio playback: an easy-to-reproduce bug is that whenever playback is started, a few samples from what it feels like the last-played audio play for an instant, causing a very audible “pop” any time any sound is played (playing the whole song, selecting individual notes, changing their pitch, etc.) Just hitting play/pause quickly is enough to reproduce it. I can make a video with it if you need it. Notice how the “pop” occurs even when starting playback from a silence, as soon as the playhead arrives at the first note and it is played out loud.
Mouse drag redraw: it’s nice to hear it’s being worked on. It’s one of the most annoying issues when you feel like working with the mouse, it affects every action you try to take.
Inaccurate clicking: I’m convinced this is related to the fact performance drops dramatically whenever any “resizable” element is moused over. Some clicks and other actions simply don’t register if their key-down or up events take place during those stutters. In some cases this leads to certain actions happening “forever” until the key is pressed again and the key-up event fires again, or sometimes, forever until the page is refreshed. In other cases, it leads to actions not registering. That’s my hypothesis, anyway.
Playback stuff and magic chord/bass: shouldn’t be too hard to reproduce. I literally just ran into both issues on my first attempt to reproduce them. The magic chord/bass pause button instantly sets the playback in a broken state (UI says the song’s playing, but it’s paused).
@CDEFGAB, regarding the “audio playback” bug, could you send us a brief video showing what you’re experiencing? I’m not sure I completely understand.
Regarding updates, we’ll be better about posting on our blog along with the release notes so you all can both know what we’re working on and also what you can expect from various releases. As @dave said, this next version of Hookpad (we hope to release in a couple days) contains major updates of the drawing engine that should significantly improve performance of the app. The previous major update (2.4) addressed some major performance issues with our audio player, so please let us know if you are continuing to experience issues with playback.
We’ll try to disseminate this info in more places (maybe we’ll even tweet it @HertzDevil). We have tried to be good about posting updates to this page though:
I’ve made a video. I edited the melody to include no rests or silences at all between the notes, to show that when silences don’t happen, everything plays smoothly without pops or clicks.
@CDEFGAB, thanks for the video. We’ve confirmed that we can reproduce this bug, although for whatever reason it seems to only be affecting Firefox. Trying to figure out what’s going on and will keep you posted.
Long story short, we’ve found discrepancies in the way that Firefox and other browsers have implemented WebAudio which was leading to some unexpected behavior in FF. Specifically there appears to be a bug where gain nodes in FF do not always report their correct gain values, which makes it impossible for us to match levels between certain transitions which lead to pops in some cases.
We have implemented a workaround for the pops that would occur in FF when entering notes/chords or starting playback as shown in the video above, which will be pushed with Hookpad v2.6.0 shortly.
We’ve also changed the behavior of Hookpad playback when a performance is stopped to allow samples to continue playing their release tails rather than abruptly stopping them. This behavior is more consistent with modern DAWs and in our opinion improves the experience of playback.
I gotta say: congrats! I’m using Hookpad and it feels so much more snappier than it used to. Great job, it’s a much better experience all around.
Edit: my previous words don’t do justice to how much better it runs. It’s snappier than some full-fledged DAWs! The programmer in me has to know: what was it?! I’m sure it was a bunch of optimizations and not just the one thing, but I’ve noticed the dreaded drag-handlebars are gone among other things.
@CDEFGAB, glad to hear it! The UI performance improvements came from two things.
we heavily memoized creating the middle layer we call the “representation”. The representation is essentially a giant nested structure of colored rectangle objects: {x: 10, y: 20, width: 50, height: 12, color: "#ff00ff"} and some organizational constructs (line, for example) generated from the raw music data store, and some layout constants and settings. The entire representation has to get recomputed for every state change, which can be expensive (100s of ms for a large project). So we refactored the representation into hierarchical set of pure function calls and memoized each one. Now for the majority of simple operations like adding a note or chord, 99% of the calculation of the representation returns answers from the memo.
We made extensive use of shouldComponentUpdate in our React views (we use React for updating the DOM). We probably could have used React.PureComponent instead of React.Component but it would have been a substantial refactor of props so we decided to implement custom shouldComponentUpdate for each view. One trick here is we created a performant serializer for Immutable.js data structures that allowed us to generate unique hashes for every Chord, Note, etc. We pass this hash into every leaf of the React layer and use it in shouldComponentUpdate. We use Immutable.js as our data store, which is usually great for React, but because we have this unique “representation” middle layer, (we have to do all layout ourselves, where most React apps use CSS and standard HTML for layout), we don’t get the automatic win from React.PureComponent
This doesn’t cover everything we did, but these two things are responsible for the majority of the performance improvements in 2.6.0
Appreciate the writeup, I’m working on a React side project myself and properly structuring everything so that the state changes trigger the “chain” of updates in the right sequence to make everything performant can be a real piece of work sometimes. Never used it to just update parts of the DOM selectively, so I can’t speak to that.
I’m sure you’re already aware but TypeScript is amazing, can’t recommend it enough. As a backend dev I used to hate JS and now I only disdainfully dislike it. Slightly.
At any rate and in all seriousness though: congrats. It’s very snappy! A much improved experience.
Reading the above comments leads me to ponder, “In a perfect world.”
While I agree that bugs are annoying and commend those prepared to raise and articulate issues, I have come to accept the system - warts and all.
In music we strive for absolute perfection, but reality persuades us to be a little more realistic. Nonetheless, the more I work with Hookpad the better I get. Am now discovering a few workarounds of my own.
