2011-01-23T17:51:08+00:00 lifetype-1.2.10_r6971 http://blog.synthings.com/rss.php?blogId=1&profile=atom Copyright (c) jason tag:blog.synthings.com,2011-01-23:39 2011-01-23T17:51:08+00:00

I decided to have a short day - I finally had some feedback from my Eagle PCB search site for some ideas and I thought I would look into it. I did get a fair amount done though - placing the ...

jason Syth Tracker I decided to have a short day - I finally had some feedback from my Eagle PCB search site for some ideas and I thought I would look into it. I did get a fair amount done though - placing the patterns, and displaying them. I started with the basic "create the first pattern for a voice" code, which is simply creating the first element into each array: The bottom one actually has a repeat (of 3 - it, plus two others). I've modelled this slightly after Logic The repeated sections didn't look very clear, so I added a stripe in the background colour on the left, and also changed the left line of a pattern to a dithered version of background/foregroud colors. It looks good with colours too: I decided to rewrite the keyboard entry so it's two dimensional, rather than two clicks. The rotary encoder selects along the rows, and the left and right buttons switch between each row. This now removed the need for the code to do a nested field selection. And then it was time to have more patterns on the same line. This took a while to perfect - you can overlap patterns (the current pattern will stop playing, and the overlapped pattern will continue). The main problems I had was in the memory accessing. This is what it looks like: I then started work on saving tunes (I can then create some pre-canned examples for subsequent tests, rather than having to insert patterns all the time - "Pattern 17" is a test pattern). But mid-way through the code modifications to allow the tunes, patterns and samples to be saved, I got the email about the Eagle search - so stopped. This is the memory prior to building with save code: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x13b4 0x1d8e (7566) .const 0x15b4 0x2978 0x3e34 (15924) .text 0x3f2c 0xcd26 0x133b9 (78777) .dinit 0x10c52 0x2a0 0x3f0 (1008) .text 0x10ef2 0x1792 0x235b (9051) .isr 0x12684 0x2 0x3 (3) Total program memory used (bytes): 0x1b6c9 (112329) 42% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03854ee04d3aa7d3 0x11ec 0 0x200 (512) _038570704d3aa7d3 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0xf4 (244) .nbss 0x19f4 0 0xd4 (212) .ndata 0x1ac8 0 0x22 (34) .nbss 0x1aea 0 0x2a (42) .ndata 0x1b14 0 0x12 (18) .nbss 0x1b26 0 0x34 (52) .ndata 0x1b5a 0 0x8 (8) .nbss 0x1b62 0 0x12 (18) .ndata 0x1b74 0 0x2 (2) .nbss 0x1b76 0 0x4 (4) .ndata 0x1b7a 0 0x4 (4) .nbss 0x1b7e 0 0x2 (2) .ndata 0x1b80 0 0x2 (2) .data 0x1b82 0 0x106 (262) .dconst 0x1c88 0 0x8 (8) .data 0x1c90 0 0xc (12) .bss 0x1c9c 0 0x4 (4) .data 0x1ca0 0 0x2 (2) .heap 0x1ca2 0 0x2000 (8192) Total data memory used (bytes): 0x34a2 (13474) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1ca2 0x2000 (8192) stack 0x3ca2 0x435e (17246) Maximum dynamic memory (bytes): 0x635e (25438) tag:blog.synthings.com,2011-01-22:38 2011-01-22T22:28:51+00:00

Well, I've had a few days off from this project - preparing for a week off work to take a micro milling machine and turn it into a CNC version (which will be used to make the lid for this ...

jason Syth Tracker Well, I've had a few days off from this project - preparing for a week off work to take a micro milling machine and turn it into a CNC version (which will be used to make the lid for this project). But today was quite productive - although I still haven't quite got as far as placing patterns on the screen. The first thing I did today was try to work out why I was getting bad data transfers between the PIC and FPGA - which seemed to be getting worse (and was starting to get very irritating). I took the base board off the top board, and I saw that the contacts weren't very clean. Either the surface had become scratched way, or there was dirt on it. Luckily cleaning them with a PCB polishing block made them nice and shiny - and I haven't had problems since. Next, I changed the numbering for the events in the main editor top and bottom, and I added the scroll bar into it (which involved finishing the horizontal scrollbar code). I also added in some of the tune meta-information - the name, composer, length, events per beat and beats per bar. However, I still wanted to know the bar (and beat numbers) - so I extended the view menu to allow me to select whether I wanted to show the event number, beat:bar or beat:bar:event offset: I then added an initial tempo value: Editing these values was the next order of the day - and getting the screen to update after doing it. This is with 4 events per beat, and 8 beats per bar (so effectively 32 events per bar): Odd numbers can also be chosen (although the horizontal grid is set to a multiple of 16 - I won't be changing that!): This is with 16 events per bar, and enabling the event offset in the time index: As a bit of a distraction (while looking for some CNC bits I've lost), I modified the case I wanted to use to allow the screen to fit: This was done by cutting part of the top rail down: However, it needs to be cut down some more as the pixels aren't central. I then wanted to have the capability to delete patterns if you'd created one. And also ask the user if you really wanted to: I decided to allow the user to select what foreground colour to use for the pattern text, by adding a second colour option at the top: And it was now time to actually begin the code to insert patterns into the tune. I extended the memory code to allow me to treat each object as a stream, and only pull off information that I needed as I go along. This is used by the tune plotting code (and will also be used by the playing code). When you go into the pattern, it tells you what the current pattern is, where it is, how long it is, whether it's looped or not, and the voice number. If no pattern is selected, then it's blank: I then needed a way to show the current position for placing the pattern. I decided that the horizontal lines between voices would be a very good place, since I wouldn't need to worry too much about redrawing the segments when the user scrolls. Two white lines are used to show the start and end of the pattern: The rotary encoder is used to move the pattern left and right (and the bottom display updates to show the position): If you go off the edge of the screen, it automatically scrolls back a few events: Finally, I needed a menu to allow you to select how you want the pattern to be looped (as well as some other controls): All that's left to do is actually do the insertions. In theory the plotting code is all done (it may need some tweaks). And that was a lot for one day - and the new memory size shows it: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x13b8 0x1d94 (7572) .const 0x15b8 0x2946 0x3de9 (15849) .text 0x3efe 0xc956 0x12e01 (77313) .dinit 0x10854 0x29e 0x3ed (1005) .text 0x10af2 0x17c4 0x23a6 (9126) .isr 0x122b6 0x2 0x3 (3) Total program memory used (bytes): 0x1b114 (110868) 42% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03854ee04d3aa7d3 0x11ec 0 0x200 (512) _038570704d3aa7d3 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0xf0 (240) .nbss 0x19f0 0 0xb0 (176) .ndata 0x1aa0 0 0x22 (34) .nbss 0x1ac2 0 0x4c (76) .ndata 0x1b0e 0 0x12 (18) .nbss 0x1b20 0 0x2a (42) .ndata 0x1b4a 0 0x8 (8) .nbss 0x1b52 0 0x1a (26) .ndata 0x1b6c 0 0x2 (2) .nbss 0x1b6e 0 0x4 (4) .ndata 0x1b72 0 0x4 (4) .nbss 0x1b76 0 0x2 (2) .ndata 0x1b78 0 0x2 (2) .data 0x1b7a 0 0x106 (262) .dconst 0x1c80 0 0x8 (8) .data 0x1c88 0 0xc (12) .bss 0x1c94 0 0x4 (4) .data 0x1c98 0 0x2 (2) .heap 0x1c9a 0 0x2000 (8192) Total data memory used (bytes): 0x349a (13466) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1c9a 0x2000 (8192) stack 0x3c9a 0x4366 (17254) Maximum dynamic memory (bytes): 0x6366 (25446) Over 6K added! tag:blog.synthings.com,2011-01-17:37 2011-01-17T22:58:12+00:00

Okay, so this wasn't strictly the tune editor - however, it is finishing the work from yesterday making the scrolling selection tools use a common framework. The file dialog was changed ...

jason Syth Tracker Okay, so this wasn't strictly the tune editor - however, it is finishing the work from yesterday making the scrolling selection tools use a common framework. The file dialog was changed to use it - and I also read in the sample's description while scanning the directory. This does slow it down a bit though. This is the largest directory - which needs 3 scrolls. I then created a generic scrollbar set of functions to show the current position. This is the sample selection dialog: It works when there's less rows available than on the screen: And when you need to scroll: I may use this for the pattern editor, and maybe the tune editor (as a horizontal scroll bar - which the code partially caters for - it's written, but #defined out). And because the file selection code now uses the common scroll selection, the code ended up smaller (even with the code for the scroll bar). Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x13a2 0x1d73 (7539) .const 0x15a2 0x26dc 0x3a4a (14922) .text 0x3c7e 0xc492 0x126db (75483) .dinit 0x10110 0x258 0x384 (900) .text 0x10368 0xf8c 0x1752 (5970) .isr 0x112f4 0x2 0x3 (3) Total program memory used (bytes): 0x19971 (104817) 40% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03774ee04d2cd01c 0x11ec 0 0x200 (512) _037770704d2cd01c 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0xc2 (194) .ndata 0x1a48 0 0x20 (32) .nbss 0x1a68 0 0x28 (40) .ndata 0x1a90 0 0x24 (36) .nbss 0x1ab4 0 0x2a (42) .ndata 0x1ade 0 0x8 (8) .nbss 0x1ae6 0 0x1a (26) .ndata 0x1b00 0 0x2 (2) .nbss 0x1b02 0 0x4 (4) .ndata 0x1b06 0 0x4 (4) .nbss 0x1b0a 0 0x2 (2) .ndata 0x1b0c 0 0x2 (2) .data 0x1b0e 0 0x106 (262) .dconst 0x1c14 0 0x8 (8) .data 0x1c1c 0 0xa (10) .bss 0x1c26 0 0x4 (4) .data 0x1c2a 0 0x2 (2) .heap 0x1c2c 0 0x2000 (8192) Total data memory used (bytes): 0x342c (13356) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1c2c 0x2000 (8192) stack 0x3c2c 0x43d4 (17364) Maximum dynamic memory (bytes): 0x63d4 (25556) When I'd finished the initial work, I did look at the ROM usage - it was 104334 bytes, so I'd saved almost 1.2K. tag:blog.synthings.com,2011-01-16:36 2011-01-16T23:35:27+00:00

I got a little distracted today with car stuff, so I didn't do as much work as I wanted. However, I did create a generic interface for selecting a variable amount of objects. There's a ...

jason Syth Tracker I got a little distracted today with car stuff, so I didn't do as much work as I wanted. However, I did create a generic interface for selecting a variable amount of objects. There's a number of UI elements which do roughly the same work - selecting a file from the file system, selecting a sample, and I added selecting a pattern. When I'd just finished the pattern code, I decided that these three need to be merged into one. Since the pattern selection code was the only one that scrolled properly, I decided to use that as a basis. I extended it to allow me to select how many lines you want to have, and you pass in function pointers for drawing the line, and another one for selection changes (so any meta-data could be updated). This is what the pattern selector looks like: And scrolled down: And the sample selector now looks like this: I'll add in the sample's length in the selection bar, and also a scrollbar. I ran out of time today to do the file selection, but I'll do that tomorrow. Although I'd removed the sample selection code, the amount of code added for the generic selection was larger (the sample selection code didn't need to worry about scrolling). Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x1376 0x1d31 (7473) .const 0x1576 0x26fa 0x3a77 (14967) .text 0x3c70 0xc822 0x12c33 (76851) .dinit 0x10492 0x252 0x37b (891) .text 0x106e4 0xe10 0x1518 (5400) .isr 0x114f4 0x2 0x3 (3) Total program memory used (bytes): 0x19c71 (105585) 40% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03774ee04d2cd01c 0x11ec 0 0x200 (512) _037770704d2cd01c 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0xc2 (194) .ndata 0x1a48 0 0x20 (32) .nbss 0x1a68 0 0x18 (24) .ndata 0x1a80 0 0x24 (36) .nbss 0x1aa4 0 0x2a (42) .ndata 0x1ace 0 0x8 (8) .nbss 0x1ad6 0 0x1a (26) .ndata 0x1af0 0 0x2 (2) .nbss 0x1af2 0 0x4 (4) .ndata 0x1af6 0 0x4 (4) .nbss 0x1afa 0 0x2 (2) .ndata 0x1afc 0 0x2 (2) .data 0x1afe 0 0x106 (262) .dconst 0x1c04 0 0x8 (8) .data 0x1c0c 0 0xa (10) .bss 0x1c16 0 0x4 (4) .data 0x1c1a 0 0x2 (2) .heap 0x1c1c 0 0x2000 (8192) Total data memory used (bytes): 0x341c (13340) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1c1c 0x2000 (8192) stack 0x3c1c 0x43e4 (17380) Maximum dynamic memory (bytes): 0x63e4 (25572) Note that before I did the refactoring, the code size was over 106,000 bytes, so I have saved some. tag:blog.synthings.com,2011-01-15:35 2011-01-15T23:21:57+00:00

Today, I went in a bit of a circle with the memory allocation for the tune. I started off in two minds as to the best approach for this. I need to have it quick to update in the screen, ...

jason Syth Tracker Today, I went in a bit of a circle with the memory allocation for the tune. I started off in two minds as to the best approach for this. I need to have it quick to update in the screen, and easy to insert events in the middle of the data. I've got 32K of SRAM assigned to the tune arrangement, and only 6K of RAM in the PIC to hold it in (this memory is given to the pattern editor when you're editing the pattern). I could split the memory into 16 equal chunks (one for each voice), but then I'd limit myself to 512 pattern events per voice (each pattern placement takes 4 bytes - two for the start location, and another two for the pattern number) - and if you were doing an 8 voice tune, that's half the memory wasted. I initially decided to have all the tune pattern arrangement to be linear, and sorted by the play time, so drawing the pattern would be easy. In order to make it easy to insert items in memory, I would split the 32K into 256 128-byte chunks, and use a double-linked list to make it easier to insert data in the middle of other data. Memory would get fragmented, so a defragmentation scheme was done. While writing the insertion code, I decided that this was way to complicated. I had a 128-byte memory allocation routine in the pattern editor, and another one in the tune - both doing similar, yet different things. I then decided to merge the memory chunks together (they were already immediately after each other), and have the pattern and tune use a common memory allocation system. The memory code was removed from the pattern editor, and placed in its own memory handler, and I changed the memory code to have a concept of objects. An object would be a pattern, or a voice line in the tune editor. An object would need a number of blocks depending on how much memory the object needs. Each block allows 124 bytes of data (the other 4 are used to link to the next block, the parent object, and how many bytes are used in the block. The memory transfer (load and save) functions were a bit more lower level than the pattern ones (which needed to insert the pattern name, length and colour in the first block). This meant that the pattern save and load now needed to compress and decompress while knowing that the pattern information needed to be at the start of the memory block. On startup, the tune editor would create 16 objects - none of which would use any memory. When you create a new pattern, then a new object is created. As an extension, if a new pattern is created, and you abort without saving, then it'll free the object back. With the new memory arrangement, there's 3360 available blocks and objects (which is up from the 3072 patterns). I can increase this slightly (there's an area of memory used to store the object start addresses, and I've got more memory allocated there than I need). The displaying of the tune will be a little more complex than before, but hopefully it shouldn't be too bad. The memory footprint hasn't changed that much (an extra 136 bytes of ROM, and 32 bytes of RAM): Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x136e 0x1d25 (7461) .const 0x156e 0x26d6 0x3a41 (14913) .text 0x3c44 0xc4be 0x1271d (75549) .dinit 0x10102 0x24c 0x372 (882) .text 0x1034e 0xde0 0x14d0 (5328) .isr 0x1112e 0x2 0x3 (3) Total program memory used (bytes): 0x196c8 (104136) 39% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03774ee04d2cd01c 0x11ec 0 0x200 (512) _037770704d2cd01c 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0xa0 (160) .ndata 0x1a26 0 0x20 (32) .nbss 0x1a46 0 0x38 (56) .ndata 0x1a7e 0 0x22 (34) .nbss 0x1aa0 0 0x1c (28) .ndata 0x1abc 0 0x8 (8) .nbss 0x1ac4 0 0x1a (26) .ndata 0x1ade 0 0x2 (2) .nbss 0x1ae0 0 0x4 (4) .ndata 0x1ae4 0 0x4 (4) .nbss 0x1ae8 0 0x2 (2) .ndata 0x1aea 0 0x2 (2) .data 0x1aec 0 0x106 (262) .dconst 0x1bf2 0 0x8 (8) .data 0x1bfa 0 0xa (10) .bss 0x1c04 0 0x4 (4) .data 0x1c08 0 0x2 (2) .heap 0x1c0a 0 0x2000 (8192) Total data memory used (bytes): 0x340a (13322) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1c0a 0x2000 (8192) stack 0x3c0a 0x43f6 (17398) Maximum dynamic memory (bytes): 0x63f6 (25590) Tomorrow, I'll need to start arranging the pattern - and maybe have a go at loading and saving whole tunes. There's nothing worse than creating a wonderful test tune and not being able to save it... tag:blog.synthings.com,2011-01-13:34 2011-01-13T23:33:41+00:00

I actually managed to sort out the scrolling later that evening - it didn't take that long to realise what I'd done wrong. Yesterday I had a break - my new micro milling machine had arrived, and ...

jason Syth Tracker I actually managed to sort out the scrolling later that evening - it didn't take that long to realise what I'd done wrong. Yesterday I had a break - my new micro milling machine had arrived, and I wanted to have a play. This will be used to cut out the panels when I've got the hang of it. So tonight I wanted to add in a zoom capability, so you could zoom in and out. With the current zoom, you couldn't see a 64-pattern section on the screen in one go. This actually ended up being quite complicated getting the scrolling to work at all the zooms. For simplicity, I've got 3 zooms, and they're 1x (where 1 pattern line is 1 pixel wide), 2x (2 pixels wide), and 4x (yes, 4 pixels wide). The zoom last night was 4x. This is at 4x (default), showing the start (line 17) and end (line 81): And at 2x and 1x respectively: I don't have a concept of "tune length" yet, so you can keep on scrolling right... ...until you wrap around the integer value for the bar: The patterns will be displayed in their respective colours, but also will have the name of the pattern for ease of visibility. Here is the pattern name at the three zoom factors: A final effect I wanted to add was a different background indicator for each bar. Since bars can be an arbitrary length, the user will be able to select the different shades to be every n lines. This is at every 32 lines: It scrolls... ...and zooms: The only problem is that it isn't very clear in these screenshots. The display has a different colour display range to my monitor (and probably your monitor), and it's actually quite clear. This is what it roughly looks like when I tweak the levels for the screenshot: I decided to lighten up the background anyway - and also give it a different colour. The same went for the grid lines and also the background to the line position. I removed some debugging code, and the new linker output is: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x136e 0x1d25 (7461) .const 0x156e 0x26f6 0x3a71 (14961) .text 0x3c64 0xc450 0x12678 (75384) .dinit 0x100b4 0x24a 0x36f (879) .text 0x102fe 0xdd8 0x14c4 (5316) .isr 0x110d6 0x2 0x3 (3) Total program memory used (bytes): 0x19644 (104004) 39% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03774ee04d2cd01c 0x11ec 0 0x200 (512) _037770704d2cd01c 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0x9e (158) .ndata 0x1a24 0 0x1e (30) .nbss 0x1a42 0 0x18 (24) .ndata 0x1a5a 0 0x22 (34) .nbss 0x1a7c 0 0x1c (28) .ndata 0x1a98 0 0x8 (8) .nbss 0x1aa0 0 0x1e (30) .ndata 0x1abe 0 0x2 (2) .nbss 0x1ac0 0 0x4 (4) .ndata 0x1ac4 0 0x4 (4) .nbss 0x1ac8 0 0x2 (2) .ndata 0x1aca 0 0x2 (2) .data 0x1acc 0 0x106 (262) .dconst 0x1bd2 0 0x8 (8) .data 0x1bda 0 0xa (10) .bss 0x1be4 0 0x4 (4) .data 0x1be8 0 0x2 (2) .heap 0x1bea 0 0x2000 (8192) Total data memory used (bytes): 0x33ea (13290) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1bea 0x2000 (8192) stack 0x3bea 0x4416 (17430) Maximum dynamic memory (bytes): 0x6416 (25622) Tomorrow, I'll start using real patterns. tag:blog.synthings.com,2011-01-11:33 2011-01-11T23:40:31+00:00

Today was the start of the tune editor (aka pattern arranger). This will be unlike a Tracker, and more like a sequencer. Patterns will be placed on a grid, and can be moved around fairly ...

jason Syth Tracker Today was the start of the tune editor (aka pattern arranger). This will be unlike a Tracker, and more like a sequencer. Patterns will be placed on a grid, and can be moved around fairly arbitrarily. Since this the main interface, there's a bunch of menus at the top to do the main functions: However, the real editing will be in the middle of the screen (the bottom will be for giving information about the tune, such as the memory utilisation and the tune's meta-information such as name, author). I've put in a fake pattern for the moment, which starts at position 17 (it's not a bar number - it's an event number), and runs for 64 events - so ends on event 81: Unfortunately, scrolling back doesn't quite work yet: I'm using the BLT to do scrolling (and also the background drawing - I'm really pleased I implemented it now!), and it may not be erasing the area correctly. That'll be something for tomorrow to do. I have now reached the 100K limit - in fact, it went quite over it, but mainly because I needed to enable the large_code option because it's got too big: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x136e 0x1d25 (7461) .const 0x156e 0x2708 0x3a8c (14988) .text 0x3c76 0xc2c4 0x12426 (74790) .dinit 0xff3a 0x248 0x36c (876) .text 0x10182 0xdd8 0x14c4 (5316) .isr 0x10f5a 0x2 0x3 (3) Total program memory used (bytes): 0x1940a (103434) 39% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03774ee04d2cd01c 0x11ec 0 0x200 (512) _037770704d2cd01c 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0x9e (158) .ndata 0x1a24 0 0x1e (30) .nbss 0x1a42 0 0x18 (24) .ndata 0x1a5a 0 0x12 (18) .nbss 0x1a6c 0 0x1c (28) .ndata 0x1a88 0 0x16 (22) .nbss 0x1a9e 0 0x1a (26) .ndata 0x1ab8 0 0x2 (2) .nbss 0x1aba 0 0x4 (4) .ndata 0x1abe 0 0x4 (4) .nbss 0x1ac2 0 0x2 (2) .ndata 0x1ac4 0 0x2 (2) .nbss 0x1ac6 0 0x2 (2) .data 0x1ac8 0 0x106 (262) .dconst 0x1bce 0 0x8 (8) .data 0x1bd6 0 0xa (10) .bss 0x1be0 0 0x4 (4) .data 0x1be4 0 0x2 (2) .heap 0x1be6 0 0x2000 (8192) Total data memory used (bytes): 0x33e6 (13286) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1be6 0x2000 (8192) stack 0x3be6 0x441a (17434) Maximum dynamic memory (bytes): 0x641a (25626) tag:blog.synthings.com,2011-01-10:32 2011-01-10T22:32:56+00:00

Today was the final day of main work on the pattern editor - tidying up bits and pieces, starting with the updating of the pattern when you change the number of lines. This took about 3 ...

jason Syth Tracker Today was the final day of main work on the pattern editor - tidying up bits and pieces, starting with the updating of the pattern when you change the number of lines. This took about 3 minutes to do. Next, I wanted a colour editor for the pattern, so you can quickly get a gauge for the pattern on the tune editing screen. For simplicity, I displayed all the colours, and you can use the rotary encoder to move between the colours. It takes a few turns to get to the other side, but it's functional. So, here is the colour editor when you first open it (it's the first time I've got all 256 colours on the screen at once - in a meaningful way [i.e. not random data]): And then selecting the red colour: And finally submitting the colour: The final thing I wanted to achieve was the scroll bar. It's also a fairly simplistic approach - the height of the scroll bar does not change; instead it shows you the rough position of where you are: If there's only one row, then it's in the middle: And it also works if you've got 256 rows (after a quick recompile to use longs instead of ints): There was one other thing I wanted to check - that it can edit multiple patterns, and you can switch between them. It did, and worked fine. I still haven't reached the 100K code size yet: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x136e 0x1d25 (7461) .const 0x156e 0x268e 0x39d5 (14805) .text 0x3bfc 0xb9a0 0x11670 (71280) .dinit 0xf59c 0x232 0x34b (843) .text 0xf7ce 0xda2 0x1473 (5235) .isr 0x10570 0x2 0x3 (3) Total program memory used (bytes): 0x1852b (99627) 38% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _035f4ee04d299d91 0x11ec 0 0x200 (512) _035f70704d299d91 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0x9e (158) .ndata 0x1a24 0 0x1e (30) .nbss 0x1a42 0 0x18 (24) .ndata 0x1a5a 0 0x12 (18) .nbss 0x1a6c 0 0x1c (28) .ndata 0x1a88 0 0x8 (8) .nbss 0x1a90 0 0x1a (26) .ndata 0x1aaa 0 0x2 (2) .nbss 0x1aac 0 0x4 (4) .ndata 0x1ab0 0 0x4 (4) .nbss 0x1ab4 0 0x2 (2) .ndata 0x1ab6 0 0x2 (2) .data 0x1ab8 0 0x106 (262) .dconst 0x1bbe 0 0x8 (8) .data 0x1bc6 0 0xa (10) .bss 0x1bd0 0 0x4 (4) .data 0x1bd4 0 0x2 (2) .heap 0x1bd6 0 0x2000 (8192) Total data memory used (bytes): 0x33d6 (13270) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1bd6 0x2000 (8192) stack 0x3bd6 0x442a (17450) Maximum dynamic memory (bytes): 0x642a (25642) Tomorrow, I'll start work on the tune editor. That'll take a few days to do... P.S. I also did a bit of research for SYNTHINGS 2 - mainly the screen. I'd like to have a 480x272 touch screen... tag:blog.synthings.com,2011-01-09:31 2011-01-09T22:32:08+00:00

I've combined two days into one, since the first day there wasn't a lot to show for it - I spent most of it refactoring where playing of notes was to be performed in preparation for the tune ...

jason Syth Tracker I've combined two days into one, since the first day there wasn't a lot to show for it - I spent most of it refactoring where playing of notes was to be performed in preparation for the tune playroutine. This meant that the pattern editor didn't get a lot of work done on it, except you could scroll through the pattern and it would play the notes that was in the pattern. Also, I planned what the effects are - based on Desktop Tracker. The second day was when it started to take a bit more shape. The first thing I did was get the pattern compression code working: the pattern editor uses an uncompressed format for ease of data manipulation (each line consumes 10 bytes of data). When compressed, each line will take between 0 and 11 bytes of data depending on what the line is doing (I am aware that 11 is more than 10!). When the pattern is compressed, it is then put into the allocated chunks when you want to store/save the pattern. When that had been written, I wrote the decompressor - that takes the compressed data and expands it into the more manageable format. This did take a couple of iterations for the compressor/decompressor to work. I think I could get it slightly more compressed, but the code complexity goes up a bit. I also decided that I wanted to have the RS232 port emulate the user interface - so I don't actually need to touch the device itself. It also allows me to define other operations as well (such as deletion of the current field data directly from the keyboard, rather than having to go through the menu). Scrolling up and down can also be performed without having to select the line as the current editing field. I may make a device to send these via MIDI (and merge from a MIDI keyboard at the same time). Then, it was a case of "filling in the blanks" for the menu, and also the current status display. I've not taken screenshots until the end though. So, here's what the editor looks like: The bottom of the screen shows the current status. From left to right: Step mode (if on, pressing a MIDI key automatically scrolls down to the next line) Sample mode (if on, pressing a MIDI key automatically sets the sample to the current sample) The current sample The current sample can be "--" - in which case, it will leave the sample as the previously one played. The menu has changed too: I did move the "End edit" option to the top. If you select "Insert row", you get an additional menu: Likewise, if you select "Delete row", then it'll ask you if you want to decrease the size. Selecting the "Set sample mode" turns the sample mode on/off. Here it is turned off: And with step mode: The last three menu options allow you to select a MIDI note which will perform a scroll up, scroll down or clear the current events. Since SythTracker has a 63-note range, if you have more keys than that, you can select some that will not be playable in SythTracker to perform these functions. I've got a 25-key, a 61-key and an 88-key MIDI keyboard. Currently, I'm only using the 25-key one for testing. Clearing the current field has a special context if you've currently got the line selected - this clears the entire row. Otherwise, it'll clear the currently selected field (if you have one of the effects fields selected, then both of the relevant effects fields are cleared). Selecting a sample uses the same dialog as before - except you've got an option to select none: And this looks like: The colours are the same as the sample selection dialog, so the none one will be in blue, a sample which has data is in orange, and a sample which has no data is in grey. I've almost reached the 100K size for the ROM: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x136e 0x1d25 (7461) .const 0x156e 0x2664 0x3996 (14742) .text 0x3bd2 0xb89c 0x114ea (70890) .dinit 0xf46e 0x232 0x34b (843) .text 0xf6a0 0xc32 0x124b (4683) .isr 0x102d2 0x2 0x3 (3) Total program memory used (bytes): 0x1813e (98622) 37% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _035f4ee04d299d91 0x11ec 0 0x200 (512) _035f70704d299d91 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x314 (788) .ndata 0x1900 0 0x86 (134) .nbss 0x1986 0 0x9e (158) .ndata 0x1a24 0 0x1c (28) .nbss 0x1a40 0 0x18 (24) .ndata 0x1a58 0 0x12 (18) .nbss 0x1a6a 0 0x1c (28) .ndata 0x1a86 0 0x8 (8) .nbss 0x1a8e 0 0x1a (26) .ndata 0x1aa8 0 0x2 (2) .nbss 0x1aaa 0 0x4 (4) .ndata 0x1aae 0 0x4 (4) .nbss 0x1ab2 0 0x2 (2) .ndata 0x1ab4 0 0x2 (2) .data 0x1ab6 0 0x106 (262) .dconst 0x1bbc 0 0x8 (8) .data 0x1bc4 0 0xa (10) .bss 0x1bce 0 0x4 (4) .data 0x1bd2 0 0x2 (2) .heap 0x1bd4 0 0x2000 (8192) Total data memory used (bytes): 0x33d4 (13268) 43% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x1bd4 0x2000 (8192) stack 0x3bd4 0x442c (17452) Maximum dynamic memory (bytes): 0x642c (25644) Tomorrow, there'll be a little bit of finishing for the pattern editor (the colour editor needs to be done, and I need to make it so when you change the pattern length, it's reflected in the pattern below it). tag:blog.synthings.com,2011-01-07:30 2011-01-07T23:40:02+00:00

Today was a bit more work on the pattern editor, but also on the rotary encoder (again!). I started by adding a pop-up menu if you had pressed the rotary encoder when you hadn't highlighted the ...

jason Syth Tracker Today was a bit more work on the pattern editor, but also on the rotary encoder (again!). I started by adding a pop-up menu if you had pressed the rotary encoder when you hadn't highlighted the line position, and I found that I needed to redraw the back of the lines, as I hadn't done that before. However, I found that this new rotary encoder had a large amount of bounce in it when you pressed it. Large enough for my 763Hz filter to occasionally pick up two switch presses. So I needed to add in a digital filter into it to eliminate bounce. Luckily, one of the Verilog designs I had tried to fix the rotary encoder (before I reverted it back to my own design) had an example of a fairly simple digital filter, and while it wasn't exactly what I needed, it did form the basis. It's actually fairly obvious. reg [ 3 : 0 ] filtered_key; always @ ( posedge clk ) filtered_key = { filtered_key [ 2 : 0 ] , key } ;   wire filtered_value; assign filtered_value = ( filtered_key == 4 'b1111 ) ; This means that the signal filtered_value will only be a 1 if the previous 4 values were 1. I added this to the 763Hz counter, and that solved the bounce. And then it was back to the pattern editor. After adding the code in to display the pattern values, I added in the code to allow the rotary encoder to set the values. This is what it looks like when you've changed all four effects, have put a note and a sample in, and the brought up the menu: The menu may change later on, but you'll be able to enable the automatic stepping if you press a MIDI key down, whether the sample value is stored or not (if it isn't, the previous sample is used), a MIDI key which is used to scroll up and down (so you don't need to use the rotary encoder all the time) - although I may look at some of the control codes. Maybe even the pitch bend wheel could be used for this... And I decided that this menu should appear even if you had the line number as the currently selected field - which is why there's an "End edit" menu option. This might be moved to the top. The "Clear field" option will be used to clear the current note, or disable the effect that's in place. (Note than an effect of 00, and data byte 00 is a null effect). The last linker output for today was: Program Memory [Origin = 0x200, Length = 0x2aa00] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x200 0x1200 0x1b00 (6912) .const 0x1400 0x2522 0x37b3 (14259) .text 0x3922 0xa5c8 0xf8ac (63660) .dinit 0xdeea 0x1d2 0x2bb (699) .text 0xe0bc 0xccc 0x1332 (4914) .isr 0xed88 0x2 0x3 (3) Total program memory used (bytes): 0x1614f (90447) 34% Data Memory [Origin = 0x800, Length = 0x7800] section address alignment gaps total length (dec) ------- ------- -------------- ------------------- .nbss 0x800 0 0x9ea (2538) .ndata 0x11ea 0 0x2 (2) _03604ee04d23a5fe 0x11ec 0 0x200 (512) _036070704d23a5fe 0x13ec 0 0x200 (512) .nbss 0x15ec 0 0x190 (400) .ndata 0x177c 0 0x86 (134) .nbss 0x1802 0 0xb6 (182) .ndata 0x18b8 0 0x2a (42) .nbss 0x18e2 0 0xe (14) .ndata 0x18f0 0 0x8 (8) .nbss 0x18f8 0 0x1a (26) .ndata 0x1912 0 0x2 (2) .nbss 0x1914 0 0x4 (4) .ndata 0x1918 0 0x4 (4) .data 0x191c 0 0xbc (188) .dconst 0x19d8 0 0x8 (8) .data 0x19e0 0 0x6 (6) .bss 0x19e6 0 0x4 (4) .data 0x19ea 0 0x2 (2) .heap 0x19ec 0 0x2000 (8192) Total data memory used (bytes): 0x31ec (12780) 41% Dynamic Memory Usage region address maximum length (dec) ------ ------- --------------------- heap 0x19ec 0x2000 (8192) stack 0x39ec 0x4614 (17940) Maximum dynamic memory (bytes): 0x6614 (26132)