Shop Learn
Propeller GUI touchscreen and full color display - Page 12 — Parallax Forums

Propeller GUI touchscreen and full color display



  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 05:33
    Extra NAND?

    You mean AND. 74HC08

    Oops - try this zip, left out the new SD driver
  • average joeaverage joe Posts: 795
    edited 2012-05-13 05:38
    I'm short on the `08's so I used an `00. I'd draw it, but I'm not good @ascii, and too lazy to open eagle.. Here's the fix. Stock board, cut trace between ORs. Each out to input of first `00. Out of first `00, into second `00 *inverter* both inputs. Should work the same, MAYBE one more gate latency?? Sorry about the multiple edits, but I don't want to clog this thread. Maybe a different *troubleshooting?* thread?

    Seems everything works, even though it's broken? I don't get it.;..
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 06:03
    The latency through the nand shouldn't matter as that is just comparing the group selects. The or is the one where latency would matter as that is the clock.

    Just a thought - all unused gates have inputs tied high or low.
  • average joeaverage joe Posts: 795
    edited 2012-05-13 06:07
    EH, the ORs are NANDed together, and then NANDed again... So yes it is involved in the clock. Seems everything is being drawn to the display, just something is going wrong. I will play with the register settings for write cycles and such as I now suspect this is the issue. Everything's on the screen like it should be, the screen just corrupts drawing it?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 06:13
    Hmm, that sounds a bit confusing. Can you draw that up by any chance?
  • average joeaverage joe Posts: 795
    edited 2012-05-13 06:49

    Ok, here's what's on the board...Still does not explain the issue. Seems ram works fine? almost always.
    It seems like the LCD registers are becoming corrupted? I really need to play with the LCD registers because I think it's the issue. When I added a 5 second pause AFTER screen initialization, after the "glitch" everything works properly, just display is corrupted. When re-initializing the display throughout, it works somewhat.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 07:16
    Ah, that might explain a few things. AND and OR in the wrong order.

    See attached. Replace the AND with your NAND then another to invert.
    700 x 336 - 26K
  • average joeaverage joe Posts: 795
    edited 2012-05-13 07:23
    Ok, I guess I will try that out. Still not sure how that could be the issue. It appears ram operation is correct, other than !the screen being written to! while transferring ram.. The timeouts should keep the display writes from interfering with memory operation. I only hooked that up the way I did because that was the easiest way to do it. Logically the same?

    I need to take a break from the HW end, but I will try photoshopping some background images up that I think will be handy ;)
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 07:35
    You are right, the logic is the same. But there might be a problem with gate delays - your circuit has 3 gates between the clock and the output whereas mine has just one - the OR gate.

    I don't know if that is the issue or not. But it might be.
  • average joeaverage joe Posts: 795
    edited 2012-05-13 07:47
    I agree about the extra clock delay. The reason I have not been to concerned with this is the ram operation appears correct. Everything is written to ram, and seems to be where it should be. The issue is : for some reason: when writing to ram: data is also written to the display? Not sure how MUCH data, but obviously enough to corrupt the Register settings. When the screen is re-initialized, the data that was previously drawn to the screen is correct! I will step through the PASM to find this.

    On a more positive note. For my grovebox idea, I've found my starting point.

    I need to double check BUT, I think there's something going on when switching between group0 and group1. Sure would explain a lot!

    If having 2 different screens wasn't challenging enough, I think the SD card could be suspect...
    I happened upon it by chance.
    PUB LoadBMPtoRamdisk(stringptr) | width,height,w,i       ' load and display a bitmap file
    ' scroll down about 1/3 of the way for the header formats
    ' get the width, height
    ' store these as 2 longs at the beginning of the ram file
    ' the bitmap format starts at the last row and works up so need to reverse the order              
    ' on the ram store a 0x36 byte header - the bitmap header but put in the filename at location 0
    ' this becomes a rudimentary file system that can be searched to find pictures
        propfont_out("1")                                        ' for debugging display something while load in pictures
        propfont_out("2")                                    ' for debugging display something while load in pictures
        fat.readdata(@sdbuffer,$36)                          ' get the header 0x36 hex bytes
        width := sdbuffer[$12] + sdbuffer[$13] << 8         ' only read in two bytes as never will be >64k wide or high
        height := sdbuffer[$16] + sdbuffer[$17] << 8
        w := width * 3                                      ' this number of bytes per row, and round up to nearest 4 bytes et 327 goes to 328 The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.
        w +=3                                               ' add 3 and
        w &= %11111111_11111111_11111111_11111100           ' round down
        repeat i from 0 to 11                               ' add the file name at the beginning of the header
          sdbuffer[i] := byte[stringptr][i]
          docmd("S",@sdbuffer,RamDiskPointer,$36)           ' store header to ram
       i := $36 + RamDiskPointer + ((height - 1) * width) ' start + header and on the last row and work back
       crlf                                    ' for debugging display something while load in pictures
        repeat height
          fat.readdata(@sdbuffer,w)                         ' read in the first row
            pause1ms(2_00)    'added to debug and found if I slowed down
            hex(i,8)                'right here, things seem to run okay.
           pause1ms(2_00)    'might mean the sd card is to slow to keep up with loop?
          HubToRam(i,width)                                 ' send to ram
          i -= width                                        ' subtract the width, move up the picture
       ' deadend
       propfont_out("4")                                     ' for debugging display something while load in pictures
       propfont_out("5")                                        ' for debugging display something while load in pictures
        RamDiskPointer += $36 + (width * height)        ' increment the ramdiskpointer for next picture
        RamDiskFiles += 1                                 ' increment number of entries in the ram disk
       propfont_out("6")                                     ' for debugging display something while load in pictures
    Seems to be running like a champ, although really slow. I don't want to interrupt this now but if it works it points a finger at the sd card. *?I THINK?*
    JUST CRASHED :( Damn I thought I had it! It's tricky to find because it's buried in a loop, and slowing things down make it move around. I will "append" my wife's board *again* and try that. Fingers crossed the 3 gates is it, although I'm skeptical.

    I do have a work around that seems to get me by for now. The trick is to re-initalize the screen after doing the load
    PUB PlaySynthesizer | xval,yval,portsw,note ' see next routine for automatic tunes
        synth.start(21, 23)                                 ' start the synth
        portsw := false                                     ' portamento off
        PWinit := 255                                        ' synth settings all 0-255
        pwmRate := 12
        decRate := 200                                      
        susLevel := 255
        filter := 16
        portamento := 6  
        Clearscreen(%00000000_00000000)                     ' 
        LoadBMPtoRamdisk(string("synth2.bmp"))             'screen crashes HERE!
        LoadBMPtoRamdisk(string("synoff.bmp"))              ' switch off
        LoadBMPtoRamdisk(string("synon.bmp"))               ' switch on with led
        LoadBMPtoRamdisk(string("synknb.bmp"))              ' slider knob
        LoadBMPtoRamdisk(string("synslbk.bmp"))             ' slider background
          SsdInit                                                               'and this fixes it
  • average joeaverage joe Posts: 795
    edited 2012-05-13 23:07
    Hey doc, I just wanted to let you know that I still have not figured this out. Still need to modify one of the boards to test if the 3 gates are the issue but I doubt that is it. *I really hope I'm wrong though.* The workaround does seem to get me by for now. I tried turning the "display off" before loading ram and then re-init, so this way the screen doesn't freak out. Still not operating properly though. As long as you re-init the screen after loading all BMP's to ram, everything else seems to work? Points a finger at HUB to RAM, but then again LOREM loads a text file to ram if I understand this correctly? I need to play around and see if it's just one register that is being affected, or if it's random.

    I have not figured out the LCD_RD problem. I'm thinking of: cut +3.3v to /RD trace *if possible, I have not checked* use an OR from pin ?31? and group 1 to read. Then back to RTFM. Seems like a ton of work :( I know I'm beating a dead horse, but I really STRONGLY feel on future versions it would be VERY benifical to have access to the RD line. Could be as simple as a 2 pin header with +3.3v and /RD. Not sure how you think the best way to implement it is, but some way to get data from the screen, if only for debugging and possibly using external logic, would save me a BUNCH of time.

    *Half-way through my development with directly connected display I hacked access to /RD through eeprom line and was able to figure out the "screen freak" in about 10 minutes. My old driver had problems if you tried to "push" the timing any further, causing the previously written data to corrupt. I THINK something similar is going on here, probably switching from the LAST screen write and writing the RAM address into the screen. It seems like the write is ?"$0001,$xxx0"? (oscillator off?)
    I apologize for using the term "screen freak" but I have no better way to describe this. I'll keep trying to get the utube video up.

    Now, the brighter side. I've been playing with the synth all day, showed the entire family and thoroughly annoyed everyone! I'm so happy to have this running. Now I want to hook 2 boards together, and use one without a screen? Not really sure what to do with this, but the 2 props idea has been bugging me for a while.

    More importantly, I'm trying to figure out how to: isolate the EEPROM from the circuit. I want to use the eeprom pins to talk to the ez-lcd301 I have "2x async serial" but don't want to corrupt the eeprom. Or do I even need to worry about this? Best idea I have is to use a `4066 but not sure where to drive it from? Any thoughts?

    I will also finish up those BMP files I was talking about. I'm a bit intimidated by the project I just started. The MC-303 is quite a complex unit. It would help if I ACTUALLY had one, although I keep thinking about grabbing the PDF and going from there.

    Thank you SO MUCH! I had given up on humanity and you have restored my faith! Good people do exist. :D

    As a note, the propPlug can be placed in the empty MAX3232 and use 2 jumpers *1 for gnd, 1 for reset. This is very easy to do. There is still a bug I have found, if the propPlug is plugged in, the ram holds data after unplugging the power! Seems the voltage bleed from the RX pin on the prop to 3.3v supply is high enough to support NV operation. It can be confusing if you're not expecting it, LOL! The only reason I chose the propPlug is: even on my desktop HARDWAR serial port the 3232 has problems communicating. Prop Lost, Prop Not found... With the cheap usb to serial I have, it's almost unusable. The propPLUG works flawlessly, other than a few bugs. These could be fixed, but once again it may be easier to just work-around for now. How hard is it to unplug the PropPlug AND power to reset RAM?
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-13 23:21
    So is it working now? Or - which bits are not working if you have the synth working?

    Some more boards arrived today - these have the fix with the and/or gates so I might unsolder one of the earlier ones and recycle some parts and maybe send you a working one so you can then do some swaps back and forth with your various parts.

    Re isolating the eeprom, maybe you could devote one line to serial data in, and for serial data out, use one of the spare pins in group 2, and buffer bytes for output until group 2 is enabled? Should only be a few lines of spin and some existing objects.

    Also the dual screen board started being made today. No reason we can't think about networking boards together using the serial ports.

    Have you seen that recent thread where some clever boffin has put a hammond organ in the propeller? He is using a real midi keyboard. I don't think he has released the source code but if he does, he says he is using all 8 cogs but one cog is probably for the serial midi driver, and you could instead use that cog to run the display and put some knobs and sliders on the display and control an organ that way. All sorts of possibilities abound!

    the ram holds data after unplugging the power!

    You can always wipe the ram with a routine called at startup. Might be 200-300ms?
    With the cheap usb to serial I have, it's almost unusable.

    There is a bug in the timing of the proptool reset. It crept in about 3-4 years ago and there are some early versions of the proptool around that work with virtually any cheap USB to RS232 adapter. Getting this bug fixed may be tricky, but one workaround is probably to port things over to C with jazzed's simple IDE where you would have more control over such timing issues as you can email the author directly.
  • average joeaverage joe Posts: 795
    edited 2012-05-14 00:11
    The issue is still transferring BMP to RAM. Seems LOREM works fine and this loads txt to RAM so should cause glitch too but does not! Just turn off the screen, load the BMP's to RAM, and re-init screen. It's not a biggie right now, with more important fish to fry I've wasted enough time trying to pin-point the gremlin. Everything works, just have to re-init screen after loading. It doesn't matter if it's before or after screen draw.

    I brought up the RAM issue so it's noted between the two of us, and possibly documented for the future. I was expecting the RAM to be blank, so finding data where there should be none was troubling. Once I figured it out though :D

    I like the idea for using a group output. Solves the problem, although it means I can use the EzLCD or spare board. *I have parts for 2 boards but only 1 screen :(
    I will be soldering up a fix shortly to rule out the 3-gate problem. In my mind it just doesn't explain the issue. I also pulled the memory chips and verified addresses were valid so once again it does not seem to be the culprit.

    Nice to hear that the problem is with the propTool. I've been a faithful user just because I had issues WAY back getting others to work. I will be grabbing SimpleIDE in a few :D
    I like the possibilities available for sound generation on the propeller chip and it just keeps getting better and better. I think in a few months we will actually have a tool to USE these sound generators to ACTUALLY MAKE music! C IS "THE NEXT STEP!" I'm grinning like a fool. Just imagine, 3 boards, 4 touchscreens, 2-16bit hardware DACs, and an 8 channel audio mixer! Could make some CRAZY stuff possible! Running SidSynth on one board with the "GUI-Link" and "GUI-master" doing a hammond B3 AND hardware SAMPLE BASED board for drums, and samples. I know a few dj's that would KILL for something this powerful, not a LAPTOP PC, and under $1,000!
    Okay, feet are planted back on the ground now. Time to feed the baby and get him tucked in for the night. Then re-modify a board to be identical to yours, other than the screen. I have 2 different runs of counters, one with BEST timing numbers, one with WORST. *who's counting anyways?* Thought it might be handy to try a couple different manufactures with different timings. *Both behave the same BTW* ALL of my new 74series are NXP. The alternate 161's are TI.

    Take care Doc, and THANKS AGAIN!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-14 01:18
    Cool idea re DJs. What sort of things do they want? Backing beats? Sound effects?

    Under $1000? I'd be hoping for round $50 including a box, maybe a little more if you go for a diecast aluminum box or something that can handle a stage environment. (I could get my wife to field test them on her primary school music students!)

    Ok re the display - I've ordered some the same as yours, and if I get a board made up with one of my displays and send it over then we can work on getting a common platform that works.

    Meanwhile, do you think sampling .wav files would be useful? We are storing 16 bits in the ram chips so that would naturally work out nicely with .wav samples. Move a group of samples into hub as needed then output them. Possibly even move them from ram to the audio out on the fly - it should be fast enough. Take a 16 bit value, change the pwm output on the audio pin(s), wait a bit, get the next sample. If you pull the data off the ram in groups of, say, 256 words, then you could buffer them into hub and start to think about true polyphonic sounds. Eg 10 drum sounds, grab 256 values for drum 1 at what ever point in time that sound is, then change the 161 to the next instrument, get 256 of those. Then another mixing cog has 10 circular buffers of 256 each and mixes them and turns into a pwm. You could even mix each with a R and L component so the drumkit works in stereo.

    By doing things in blocks you don't need much hub ram for the buffers - maybe 10x256 words = 1280 longs.

    This could be a completely new and nifty use for your 161 counters.
  • average joeaverage joe Posts: 795
    edited 2012-05-14 01:39
    Hmm, very nice idea! I want to keep cost down and the idea I was citing was extreme. I think I've been talking about entry level @ under a hundred bucks. Wav files would be a HUGE bonus. The higher the sample rate, the better. Approaching CD-quality or oversampling would be best, but I think there are ways around this. I like the idea of using the props "internal" dacs but have not ruled out using a couple PCM54's and a few latches to have a SIMPLE, 16-bit, stereo dac that could run directly from ram. *this is what I REALLY would like to play with* As far as it goes, I know the hardware is there one way or another to do REAL, sample-based synthesis. I have a few ideas for a synth board that includes 2-16bit dacs, 2 differential LPFs, 2 HPFs, and 2 VCA's. I've never had the processor power, or memory to justify drawing it up. Now though, I think we have a PERFECT candidate!
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-14 02:18
    Yes I was thinking DACs initially, but then I realised you only have one voice at a time. If you move the data into hub though, you can do many voices and mix them on the fly as well. I'm not sure this has been possible up to now as you can't fit much inside 32k hub, but 512kilowords at 44khz is 10 secs of sound, so you can have quite a few drum samples right there, or probably an octave of real piano samples. And you can always be pulling samples off the SD card in the background as well. Once the display is set up, just occasionally check for touches to the screen, and most of the time you can be moving sounds out. Ultimately it turns into a pwm signal once all the voices have been mixed.

    Hmm- we have fonts. Why not music notes as well? Then you can display the music as it plays. Maybe off a midi file or something.
  • average joeaverage joe Posts: 795
    edited 2012-05-14 02:27
    OOOOkay.. So made necessary revisions and still the same bug. I wish I had an 08 to make SURE it's not the problem. Once again I don't think it is. Oh well. Bigger fish to fry :D
  • average joeaverage joe Posts: 795
    edited 2012-05-15 02:46
    Not a big update, but I made a BMP for transport control. It has Record and Stop which could be removed if not needed. There's "locating" pixels that need to be removed and each button chopped for redraws. I'm using black and white to experiment with the compare and data-mask functions of the display. I don't have anything working yet but I thought I'd share the progress!

    Original file can be found here :
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-15 02:56
    Looking good. Masking can get a bit complicated as you need two images - the image and the mask. It might be easier just to redraw the background, then draw the new foreground image. Eg the switch in different positions.

    I have been thinking about an idea where you push a tiny slider or switch like on your bitmap, and up pops a much bigger version of the same slider that is the full size of the display. Much easier to use with a finger rather than a stylus. When the finger is removed it redraws then entire picture with the switch or slider in the new position.
  • idbruceidbruce Posts: 6,171
    edited 2012-05-15 03:55

    It must be nice to have such a dedicated assistant. Wish I had one :)

    I must admit that I have not been following this thread as closely as I once did, so I must ask you, "How's the project coming along?".

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-15 04:09
    Thanks idbruce. Project is coming along well. Lots of programs working including a working synth. Some hardware issues to sort out but hopefully soon something that is good enough for a project kit. Post #292 was the last cool demo. Now back to the grind of building stuff behind the scenes ready for another demo video.

    @joe, a link to Rayman's midi synth

    I've got some ideas to pull together. Take rayman's inline code for the wavetable and replace with a .wav file from a sd card. Take his inline music code and replace with a .mid file on an sd card. Add more voices and store them in ram. Mixing of several voices on the fly at different volumes. And put music on the screen as it plays. Plus a little music editor.

    That should keep us busy for a bit...
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-15 07:12
    Displaying music is going to be fairly easy. There are music fonts

    Put the unzipped lass60.ifn on the sd card. Use that website to decode the ascii characters to notes.

    Add this little bit of spin to display this music
    PUB Music                                               ' use Lassus font, and use font smoothing and supersampling. 60 points works. Modify chr 45 manually (bar line) as width is 6 but advance is 5
         ILISetcursor(0,0)                                  ' sets curx to  zero and cury to zero
         SetOrientation(false)                              '
         ILIloadfont(string("Lass60.ifn"))                  'load font
         ClearRectangle(curx,cury,screenwidth,screenheight,BackFontColor)  ' clear screen
         ILIPrintString(string("`",203,"+++8-****-FF/="))   ' line of treble clef music
         ILIPrintString(string("1",164,"cb-0v-HJKLSSSS-i=")) ' line of bass clef music    
         repeat                                             ' end program

    So if we have a midi file, you can take each note, work out its ascii equivalent using a 256 byte array lookup table, work out the length of the note, and display it. In 4/4 time add in rests and display as crotchet, quaver, minim etc.
    640 x 480 - 42K
  • average joeaverage joe Posts: 795
    edited 2012-05-15 17:33
    Awesome work doc! Lately I've been trying to figure out midi sequencing. Nothing should be too difficult, I just don't know where to start. The first "sequencer" portion I would like to get going is pretty basic. A way to record midi notes in realtime *step sequencing is #2 on my list* then edit and play them back. I've had MANY software sequencers and several hardware sequencers as well. I really loved my Roland MV-30 and I think we could make our controller fairly comparable. Note, the price of the MV-30 was $2795 on release! :

    My thought is to start with loading a midi-file and trying to play it back. I'm just not sure the best way to handle the midi data. Load chunks into hub from SD? Load full file to ram and buffer to hub? And then recording? I am also wondering about how to "timestamp" the midi data. I am fairly sure this must be done to offer editing functions. The more I think about this part of the project, the more I think C will be the answer. Got SimpleIDE installed and checked it out a bit. I need to run through your xmm hardware thread again to get things running.

    I like having note fonts! Now to get all the different ways of notating music to work! I think the big ones are in the bag now. The most useful to me will be "EventList". see example,r:1,s:0,i:74

    Then would be "PianoRoll". see example :,r:1,s:0,i:74

    It sounds like "StaffView" is pretty much in the bag. see example :,r:0,s:0,i:74&tx=106&ty=54

    It would also be nice to have GuitarChords lookup and possibly a Guitar Tab window. Cheater sheet music is about as far as my sight-reading skills go. There are a BUNCH of windows I would like to script. Pixel art takes time though...
    The "masking" technique that I wanted to try involved changing the registers for RAMwriteDataMask(1and 2). From my understanding, if we use these settings with a B\W image, we could easily change icon color. I wanted to make the Record icon RED when recording. Play Green when running, yellow when paused, red when stopped. Should work in theory, I just need to try it. Perhaps later tonight. :D
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-15 18:28
    C ultimately will be useful but right now it is stuck with not being able to read and write the SD card. That is my poor understanding of C probably, but even a one line fopen is not working. There is a thread about this in the C forum.

    So I'm going to keep working in Spin for the moment.

    I'm doing a crash course in midi and music. Yikes, I'm even digging out my Grade 2 music theory books from when I was a kid!

    I downloaded anvil studio View/Composer and you can grab a note and drop it on the music staff. Or click the keyboard and it puts that note on the staff. That could be replicated very easily on the propeller for a simple music editor. Just a few buttons.

    More complex is thinking about file formats. Storing the music as lassus font data is not a completely crazy idea - all the information is there and you can even copy the text string into a word processor and print out the sheet music with no editing needed.

    However, a .mid file is the standard and so I think it better to work with .mid files. So I'm studying Rayman's simple midi demo.

    I'm a bit confused about a few things. For instance, say you play a piano note and then another piano note. Is the first note still decaying in the background? If so, you need mixing of notes within one channel and that will require a bit more complex pasm code. But it will give much more realistic sounds - a complex overlay of multiple chords and instruments rather than a tinny single-note monophonic organ effect. So I guess we have to think about real time mixing of waveforms. That involves taking a waveform and multiplying by a volume value, and adding to an output waveform. The adding bit is easy, but the volume bit needs a multiplication and that might slow things down in pasm. I am pondering things like log/antilog to do the volume rather than a multiply.

    Next thing is editing. Big files would go in external ram. I think we need a couple of library functions added. First, I am treating fonts as 'special' in the ram disk, and so I need to code them so they can be added and removed the same as bitmaps. Then you could put multiple fonts in the ram disk. If you can do that, then add any type of file, including binary and text files. So you can request blocks of data from the ram disk and move to hub and work with large files. It is exactly the same code you need for a text editor and we probably need one of those too so I may as well go and code all that. Plus, there is the "insert" problem - you have a 100k file and you insert one character at the beginning. So you need to then read the entire file through a hub buffer and shuffle everything up one. Or maybe store in a cache and do as a group? In any case, whether editing text, or music in "lassus" format or in .mid format, one needs an insert. So that needs to be coded as well.

    And then I think the display plus ram driver can be turned into an object.

    Once it is an object, then you can use the same object in multiple files - eg the calculator can become a separate program (like the way the movie player is a separate program) and use the same common object.

    Re chords - would you do that with a number of midi tracks running in parallel or is it one midi track?

    Re editing, I'm going to work with an external midi editor for the moment. I've used anvil to make a midi file with one note and am decoding it in a hex editor to see what it looks like.
  • average joeaverage joe Posts: 795
    edited 2012-05-15 18:56
    Dr_Acula wrote: »

    Re chords - would you do that with a number of midi tracks running in parallel or is it one midi track?

    Re editing, I'm going to work with an external midi editor for the moment. I've used anvil to make a midi file with one note and am decoding it in a hex editor to see what it looks like.

    There's a few different ways we could do cords. I like the idea of virtual tracks... Say you have a 16 track sequencer, maybe 17 (1 track for automation, tempo, ?Lyrics? etc.) 1 track per midi channel. Then each of the 16 "Channel Tracks" could have X number of "Virtual Tracks." Each with solo, mute, record, maybe other cool stuff. Having virtual tracks makes things really easy, and very flexible.
    That really doesn't answer your question though. In traditional midi files, you have 1 track containing ALL notes or ? tracks containing each channel *Format 0 or 1* Chords ARE 1 track. *usually*
    I will see if I can dig up MIDI file spec. I doubt it will be very useful for implementing a sequencer with editor. Inserts are a problem and need to be addressed, although I'm not sure how. I use external editors but would like to make this an "independent platform" eventually. I think we will need our own format for editing.

    When I get a chance I will look at the C thread. My hardware issue is an annoyance but I will script my workaround in. Need to see if I can figure out what register is to blame. Might point out the issue, might not.

    Just checked the transport on my display and it looks really good, now to play with masking! So, I've been trying to figure this out, should be :
      start_ram                                             ' start the external ram / display driver in a cog
      Change161(0)                                          ' reset all the 161 counters to zero
      SelectMemGroup                                        ' select group1
      Start_ILI9325                                         ' start the display. Don't clear screen as this uses ram commands and these might not be working yet
      SetOrientation(true)                                  '  in portrait (true) or landscape mode (false), must be before clearscreen otherwise don't know screensize   
      Clearscreen(RGBtoWord(0,0,0))                         ' clear screen to black - uses the display driver above 
      Propfont_string(string("SD"))                     ' string to send, uses internal prop font so can see something if the SD fails to mount   
      fat.fatEngineStart( _dopin, _clkpin, _dipin, _cspin, _wppin, _cdpin, _rtcres1, _rtcres2, _rtcres3)
      fat.mountPartition(0)                                 ' mount the sd card
      ClearRamdisk                                        ' clear ram disk for pictures not on the desktop
      LoadBMPtoRamdisk(string("Trans.bmp"))             ' a button 84x30 in size
      Clearscreen(RGBtoWord(0,0,0))                         ' clear screen to black - uses the display driver above 
      ''draw Red
      ILIcmd(REG_RAMWRITEDATAMASK1,$00ff)                               ' set mask to write Red, no Green
      ILIcmd(REG_RAMWRITEDATAMASK2,$00ff)                               ' set mask to not write Blue
        ''draw Green
      ILIcmd(REG_RAMWRITEDATAMASK1,$ff00)                                ' set mask to write Green, no Red
      ILIcmd(REG_RAMWRITEDATAMASK2,$00FF)                               ' set mask to not write Blue  
        ''draw Blue -OK
      ILIcmd(REG_RAMWRITEDATAMASK1,$FFFF)                              ' set mask to write no Green, no Red
      ILIcmd(REG_RAMWRITEDATAMASK2,$0000)                               ' set mask to write Blue

    This actually draws greyscale Transport, Yellow transport, no transport and blue transport. Blue is the only one that works properly. Not sure why. I tried playing around but could not figure this out. Transport is RGB:888 if that matters. Should be taken care of in loadBmp?

    This should display a Black and White transport on top, red transport below, green below that, and finally blue.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-05-15 23:28
    With all the problems with your display I though I might download the datasheets for the new display. They say on the website that the controller has been changed and there is a link to the C code which is the same as the one I posted a while back but I only posted the init routine, not the full program. So it might be back to the drawing board for me too when the new displays arrive. C code below. I note a 1ms delay between each startup instruction. The previous controller did not need that.
    No comments in the code but I guess when the whole display is under $20 including the touchscreen and SD card holder that is what you get :)
    #include <reg51.h>
    /* [url][/url] &#38632;&#20141;&#30005;&#23376;
    &#20195;&#30721;&#27979;&#35797;&#29615;&#22659;:JME-2&#26680;&#24515;&#26495;+1T&#25351;&#20196;&#21608;&#26399;&#30340;STC&#21333;&#29255;&#26426;&#65288;51&#20869;&#26680;STC12LE5A60S2)+33M&#26230;&#25391;	  &#21333;&#29255;&#26426;&#24037;&#20316;&#30005;&#21387;3.3V
    &#25511;&#21046;&#32447;&#65306;RS-P3^5;    WR-P3^6;   RD-P3^7;   CS-P1^0;   REST-P1^2;
    &#25968;&#25454;&#32447;: DB0-DB7&#20381;&#27425;&#36830;&#25509;P0^0-P0^7;  DB8-DB15&#20381;&#27425;&#36830;&#25509;P2^0-P2^7;
    D_CLK-P1^7;  D_CS-P1^4;  D_DIN-P3^0;  D_OUT-P3^1;  D_PENIRQ-P3^4;
    #define  LCD_DataPortH P2     //&#39640;8&#20301;&#25968;&#25454;&#21475;
    #define  LCD_DataPortL P0     //&#20302;8&#20301;&#25968;&#25454;&#21475;,&#35831;&#30830;&#35748;P0&#21475;&#24050;&#32463;&#19978;&#25289;10K&#30005;&#38459;,&#19981;&#23452;&#22826;&#23567;&#65292;&#26368;&#23567;4.7K,&#25512;&#33616;10K.
    sbit LCD_RS = P3^5;  		 //&#25968;&#25454;/&#21629;&#20196;&#20999;&#25442;
    sbit LCD_WR = P3^6;		  //&#20889;&#25511;&#21046;
    sbit LCD_RD =P3^7;		     //&#35835;&#25511;&#21046;
    sbit LCD_CS=P1^0;		//&#29255;&#36873;	
    sbit LCD_REST = P1^2;	      //&#22797;&#20301;   	
    void delayms(int count)  // /* X1ms */
            int i,j;
    void Lcd_Write_Com( int  DH)	 //&#21629;&#20196;
    	LCD_CS =0;	 
    	LCD_CS =1;	
    void Lcd_Write_DATA(int DH)	//&#25968;&#25454;	
    	LCD_CS =0;	  				
    	LCD_CS =1;	
    void Lcd_Write_Com_Data( int com1,dat1)	//&#21629;&#20196;&#25968;&#25454;&#19968;&#36215; 
    void Address_set(unsigned int x1,unsigned int y1,unsigned int x2,unsigned int y2)
    void Lcd_Init(void)
        Lcd_Write_Com_Data(0x0000,0x0001);    delayms(1);  //&#25171;&#24320;&#26230;&#25391;
        Lcd_Write_Com_Data(0x0003,0xA8A4);    delayms(1);   //0xA8A4
        Lcd_Write_Com_Data(0x000C,0x0000);    delayms(1);   
        Lcd_Write_Com_Data(0x000D,0x080C);    delayms(1);   
        Lcd_Write_Com_Data(0x000E,0x2B00);    delayms(1);   
        Lcd_Write_Com_Data(0x001E,0x00B0);    delayms(1);   
        Lcd_Write_Com_Data(0x0001,0x2B3F);    delayms(1);   //&#39537;&#21160;&#36755;&#20986;&#25511;&#21046;320*240  0x6B3F
        Lcd_Write_Com_Data(0x0002,0x0600);    delayms(1);
        Lcd_Write_Com_Data(0x0010,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0011,0x6070);    delayms(1);        //0x4030           //&#23450;&#20041;&#25968;&#25454;&#26684;&#24335;  16&#20301;&#33394; 
        Lcd_Write_Com_Data(0x0005,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0006,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0016,0xEF1C);    delayms(1);
        Lcd_Write_Com_Data(0x0017,0x0003);    delayms(1);
        Lcd_Write_Com_Data(0x0007,0x0233);    delayms(1);        //0x0233       
        Lcd_Write_Com_Data(0x000B,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x000F,0x0000);    delayms(1);        //&#25195;&#25551;&#24320;&#22987;&#22320;&#22336;
        Lcd_Write_Com_Data(0x0041,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0042,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0048,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0049,0x013F);    delayms(1);
        Lcd_Write_Com_Data(0x004A,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x004B,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0044,0xEF00);    delayms(1);
        Lcd_Write_Com_Data(0x0045,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0046,0x013F);    delayms(1);
        Lcd_Write_Com_Data(0x0030,0x0707);    delayms(1);
        Lcd_Write_Com_Data(0x0031,0x0204);    delayms(1);
        Lcd_Write_Com_Data(0x0032,0x0204);    delayms(1);
        Lcd_Write_Com_Data(0x0033,0x0502);    delayms(1);
        Lcd_Write_Com_Data(0x0034,0x0507);    delayms(1);
        Lcd_Write_Com_Data(0x0035,0x0204);    delayms(1);
        Lcd_Write_Com_Data(0x0036,0x0204);    delayms(1);
        Lcd_Write_Com_Data(0x0037,0x0502);    delayms(1);
        Lcd_Write_Com_Data(0x003A,0x0302);    delayms(1);
        Lcd_Write_Com_Data(0x003B,0x0302);    delayms(1);
        Lcd_Write_Com_Data(0x0023,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0024,0x0000);    delayms(1);
        Lcd_Write_Com_Data(0x0025,0x8000);    delayms(1);
        Lcd_Write_Com_Data(0x004f,0);        //&#34892;&#39318;&#22336;0
        Lcd_Write_Com_Data(0x004e,0);        //&#21015;&#39318;&#22336;0
    void Pant(unsigned int color)
    	int i,j;
    	  for (j=0;j<240;j++)
    	Lcd_Init();   //tft&#21021;&#22987;&#21270;
    	Pant(0xf800); //&#32418;&#33394;
    	Pant(0X07E0); //&#32511;&#33394;
    	Pant(0x001f); //&#34013;&#33394;  
  • average joeaverage joe Posts: 795
    edited 2012-05-15 23:44
    The init sequence looks good to me. I comment out portions to save time since POR settings usually work. Right now I'm doing Init in 2 parts, see code below. Still have not figured out my BMP issue, everything SHOULD work right. Funny I can mask off blue like predicted but others don't seem to work. All I can think of is something is getting lost somewhere along the way. I'll see what I can figure out... Note, I tried commenting out the 1ms delay and it makes no difference on my display. Maybe spin is too slow to matter..
    OOK. Found something out... FOR SOME REASON my glitch is Oscillator being turned off.
    PUB FixGlitch
        ILIcmd($0000,$0001)      'Turn Oscillator on                                POR-$0000
    New observation, it appears when sending writemask1, lowbyte is not sent properly?
    operates the same as

    OK, I think the BMP is to blame. White is not $FF_FF_FF, need to check to make sure.

    Nope, not the case.. This code emits FFFF like it should...
        repeat height
          fat.readdata(@sdbuffer,w)                         ' read in the first row
            repeat n from 0 to 256
              if rambuffer[n] <> 0  
          HubToRam(i,width)                                 ' send to ram
          i -= width                                        ' subtract the width, move up the picture
    Now to check that the output of mask commands are correct... I'm baffled as to what's going on. I can mask to yellow, or blue. Not what I was hoping to do really... I wanted Red and Green... The 2 I can't get working.
  • average joeaverage joe Posts: 795
    edited 2012-05-16 06:27
    Well, I pulled the old hardware out and verified the gremlin MUST be in the screen. Write masking performed exactly the same on both hardware. Blue works good, Red and Green are masked together. I will order a new display now that I know! Could you post your supplier?

    RTFM's and your screen doesn't have compare and mask from what I can tell. I don't get resize and ?? *something else* Unfortunately you can't test, but THEORETICALLY, we will be able to create a black and white image, then set display mask when updating to change the color of the white. Still have not figured out the "compare" registers? I'm about to order a display, given the 2 weeks *or so* it will take to get here!
  • Ahle2Ahle2 Posts: 1,160
    edited 2012-05-16 09:14
    Have a look at TinySynth for an example of how to generate a logarithmic envelope without any lookup tables or multiplications.

    For applying an envelope to a square wave, there's no need for any multiplications whatsoever. In my soon updated version of TinySynth, I can do triangles, saw waves and noise with logarithmic volume envelope.... and still no multiplications or lookups. ;)

    Too bad these "tricks" can't be applied to samples. :(

  • Ahle2Ahle2 Posts: 1,160
    edited 2012-05-16 09:36
    Have a listen at,, to hear how the updated version of TinySynth sounds like.
    (Download the wav files and have a look at the waveforms, no multiplications or lookups!)

    Btw, adding polyfony isn't very hard. I would guess that up to 8 channels will yield a quite okeyish sample rate of around 100 kHz.

Sign In or Register to comment.