Thanks alot! Did you get that file that I linked on IRC yesterday? That movie that explained the keyboard problem? Sorry for writing so much, it would be nice if you could edit posts in the forum!!!
Yes I got it! (But I noticed it first after a few hours, I was home for lunch) =)
Great explanation! But I know that thing has been pointed out already, so I guess I should keep better order of the bug reports. heh
I'll promise to upload a fixed version later.
Editing was accidentally disabled in this section but should now work.
Yeah! Now it really works as it should. Great! Good work!
One suggestion to the config -> shortcuts section... I'd really like to be able to copy patterns with shift + f4 and paste with shift + f5. I am pretty used to do that in other trackers... CTRL - C and V works fine but you still have to double click to channel you want to copy to mark it blue.
Ahh new WIP version, really like the changes! I like the way you change values and still being able to press SPACE to enter EDIT mode.
Still while changing octave in the new box in the top, I have to click in the pattern field to start to edit, after changing octave. You could change that to the same buttons as the Speed, Tempo etc. buttons. Arrows up/down. or even 7 diffrent buttons like (looks like there's room for it):
Octave: | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
I wanted to change channel 1, to frame 01. I pressed +, then i realised that i had to go into edit mode. pressed space. then the + was marked, so it changed to frame 01 automaticly... This is because the + and - buttons still is marked and pressing SPACE will push them.
When Expanding and showing more fx's the cursor moves some steps to the right! Should stay in the same place!
Step in "Edit settings" makes the cursor jump steps even when I use the arrowkeys. I prefer to have it the old way. Only jump xx step while inserting a note.
Otherwise! Great update! I really like changing instruments with CTRL + Up/Down!
Jarhmander: I found the problem of DPCM samples, but the NSF compiler was correct. The real problem is that samples can only be stored at certain aligned addresses in NSFs, and using samples that doesn't exactly fit into those will waste some extra space in NSF files.
Normally this isn't a problem, but in this case where 21 samples was used and also filled the whole space, it overflowed the NSF sample area and made the way the tracker stored the samples a shortage.
AH!!!! NOW I UNDERSTAND!!! =D
When the DPCM is about to read a sample to be played, it reads 2 things: the size and the emplacement. Both are 8-bit coded. The first thing I noticed is the size, which is $X1 bytes, or a multiple of 16 plus a (strange) offset byte : samples are size of 17, 33, 65 bytes etc. Why there is an offset I don't know, this is a quite buzzy hardware. And the sample size limit is 4097, so size is encoded 8-bytes, the value is in bound of 16 ( EX: %00001101 means to the 2A03 a sample of 13*16+1 bytes = 209 bytes ), so every time you load a sample there is a potential 15 bytes lost. And for the emplacement, it is 8-bit encoded too, but the value is an address of bound of $40 (64). Two samples of size 33 take the same memory as 2 samples of 17 bytes. So it can be possible that you lose a lot of memory just by ignoring the "gap" between each sample.
Btw a short status report: The new code is almost done, I still have to add code for multiple songs and bank switching and fix a few small bugs, but most songs seems to work correctly now. One new thing is that songs are stored in a more efficient way, some will be down to 50% smaller. The CPU usage has also dropped to around 4-6% (compared to around 15% now)
When everything is done and the tracker is updated I'll post a test version (maybe also release it officially) and then start on VRC6 code (finally).
