I am not able to reproduce this behavior. I created a two-line project, added I, ii, iii, IV, V (each 4 beats) on line 1, then added I on line 2. Then I dragged the end of line 1 to shrink it to five measures. When I click play, it sounds fine. Anything I should try differently to reproduce this bug?
I also cannot reproduce this behavior. Would you mind posting a screenshot of the rest notes/rhythms you had that caused this behavior?
We’ve moved to using mp3s for the default piano from WAV files in order to have faster loading times. Unfortunately, the mp3 decoding introduces some dead space which seems to be causing some small shifts in timing. If we can’t find a satisfactory fix to this problem we may go back to the WAV files.
When the ‘o’ is tapped very quickly, multiple overlays may open at the same time and even the Cancel button won’t have any effect.
This bug happens to occur only in 3/4 or 6/4 time.
- After playing with the cursor on the melody track and the piano view enabled, some notes remain on the piano that do not get erased when the song is played again, but with the cursor residing on the chord track.
- If the Theorytab contains rows that are not entirely filled with chords, playing the song (using Space instead of ‘P’) will cause the cursor to stop at the corresponding duration made up by all chords and rest chords.
- After an invalid .hkt file is loaded, Hooktab refuses to load most data from other Theorytabs on both the local and cloud storage.
- In public Theorytab pages, when a Theorytab is played with looping enabled, the cursor stays at the end of the Theorytab after the first loop.
- [Fixed] Is it a feature or a bug to be able to transfer Theorytabs containing no asociated YouTube video?
- When the palette is on a row which will be gone after loading a new Theorytab (e.g. the palette is on the 3rd row and an analysis with 2 rows is loaded), the entire editor’s spacing becomes glitched until the palette is repositioned.
- More about the piano desync: in particular, the sample used near C6 has a significant leading silence. EDIT: As does the sample used between F#4 and B4.
- The stray notes continue to appear in this syncopated rhythm and I have no idea whether this is the same issue that is supposed to have been fixed according to the change log.
This now has a better fix. Typing “o” now closes the open tool, once it has been opened. More details in this release are shown in the Hookpad changelog
Tested, still does not work if the “o” key is repeated too often. The second press or something hides the modal dialog, but further presses continue to create new dialogs and lock up the editor as before. I have to remove these HTML blocks myself to resume my work.
Thank you, again, for pointing this out. This bug has been fixed.
Sorry, I prematurely posted. I thought my first fix would work but it didn’t. I had to implement a new strategy. I just pushed the new code.
Thank you for the extra clarification - I’m able to reproduce the bug. We are working on a fix.
Definitely a bug. This has been fixed. Thank you for pointing it out!
- The load button now does not work at all in version 1.2.1.
- The chord chart page uses the old version of Hookpad, and it also always uses the popular style Roman numerals in the chart. Example
- When the cursor is at the beginning of a row on any non-empty chord track, pressing “Record” will move the cursor to the first measure not fully containing chords rather than wait at the beginning for one measure.
Thank you. This has been fixed. Didn’t actually try loading a project after the last fix.
- Copying a note or chord from a Theorytab and then pasting it in another one with a different time signature can glitch up the cursor position when the paste is repeated, and this can create rests or chords of negative duration when Hookpad automatically pads the empty space during saving. This bug most likely caused this to happen.
It is taking me forever to SAVE a file. This is my first theory tab, and the SAVE function is taking forever to load.
@MarkDundoreMusik did this resolve itself? I just wanted to follow up and see whether this was a momentary glitch with site slowness or something different.
Saving is lightning fast for me at the moment.
When i try to add a rest note and change its length with the alt key, it messes up the already inputted notes, like this: http://i.imgur.com/WDvP2Ep.gif
@emod thanks for the report and the great visual making it obvious what you are describing. It seems to be happening when the last note in your melody bumps up against the end of the line and goes past. We have checks in place to have the drag stop at this point and one of those must be failing.
Do you see this behavior whenever you alt-drag a note this way (such that the end note goes past the line), or is it just happening in certain circumstances? I did a quick check and couldn’t reproduce on my end.
The bug seems to disappear once the project has been saved and reopened. I’ve rebult the project from scratch and while the bug could not reproduced using the same method with the rest note, it appears when alt-dragging certain other notes ( http://i.imgur.com/L8yV3rL.gif ). Whats also peculiar is that I cannot paste one half of the melody into the other empty half of the project, which should fit exactly, however I am able to copy and paste the whole melody excluding the very last note ( http://i.imgur.com/VH9nsxS.gif ).
@emod you said that when you started a brand new project and rewrote the same chords and melody that you can get the same issues to appear.
Can you send me a link to the project causing you the problems?
Do other projects do the same thing or is it just this particular one?
What type of computer and web browser are you on?