Marxon

Programmer
  • Content count

    474
  • Joined

  • Last visited

Posts posted by Marxon


  1. Problem solved! :happy:

    I found a tool called PICPgm which supports my old Willem parallel port programmer  (the manufacturer software doesn´t support 18F4685)

    and burned my PIC without any problems.

    Have a nice day!

     

    Best regards

    Marxon


  2. Hi,

     

    this topic is a bit older but i'm facing the same ID problem with my G540 programmer.

    There is also no option in software to reconfigure the programmer so that only the first 4k block will be overwritten.

    On 27.10.2013 at 8:21 PM, TK. said:

    It could be, that your programmer doesn't clear the ID bits - in this case, the wrong baudrate will be selected.

    Since the baud rate is set COM, would it not be possible to upload the workaround somehow via a LTC module?

    Thanks for your help.

     

    Best regards

    Marxon


  3. Hi FantomXR

    try if this works like you expect.

    The channel select buttons will run a script (to activaon press

    .NGC

    #CH2
    EVENT_BUTTON id=1 hw_id=1 	type=Meta  meta=runsection:1 	range=127:0	button_mode=OnOff	
    EVENT_BUTTON id=2 hw_id=1 	type=Meta  meta=runsection:2	range=0:127	button_mode=OnOnly
    #CH3
    EVENT_BUTTON id=3 hw_id=2 	type=Meta  meta=runsection:3    range=127:0	button_mode=OnOff	
    EVENT_BUTTON id=4 hw_id=2 	type=Meta  meta=runsection:4	range=0:127	button_mode=OnOnly
    
    EVENT_KB id=1 hw_id=1 type=NoteOn  chn=1
    EVENT_KB id=2 hw_id=1 type=NoteOn  chn=2
    EVENT_KB id=3 hw_id=1 type=NoteOn  chn=3
    

    .NGR

    #CH2
    if ^section == 1
          LOG "CH2 deactivated"
          set_active (id)KB:2 0
    	  endif
    if ^section == 2
          LOG "CH2 activated"
    	  set_active (id)KB:2 1
    	  endif
    #CH3
    if ^section == 3
          LOG "CH3 deactivated"
    	  set_active (id)KB:3 0
    	  endif
    if ^section == 4
          LOG "CH3 activated"
    	  set_active (id)KB:3 1
    	  endif

     

     


  4. Hi sprintf,

    unfortunately it is not possible to mix display types.

    AFAIK Hawkeye and nILS made a working SSD1322 and SSD1325 driver for theire projects.

    If you really want to use different displays, you can connect them to multiple cores.

     


  5.  Hi Midiboxers,
     
     while i was tinkering with my midiboxes i wondered if it would be possible
     to use a Midibox NG to simulate a encoder. Something like an "encoder generator" simply by using a Dout board and a .NGR script.
     Some quadrature encoder signal may could be generated like this:

     if ^section == 1
      set LED:0 0
      delay_ms 2
      set LED:1 0
      delay_ms 2
      set LED:1 1
      delay_ms 2
      set LED:2 1
      delay_ms 2
      set LED:0 0
      delay_ms 2
      set LED:1 1
      delay_ms 2
      endif
     


    I guess connecting DOUT pins directly to the encoder inputs on the destination device
    requires some kind of adjustment but should work too?

    What do you think?
    Is something like that in genaral possible?

    Best regards
    Marxon


  6. Hi Novski,

    thanks for your suggestion!
    Your inverted range get me on the right path.
    Last night I did not come up with the idea.
    This is working:
      

    ### BUTTON PRESS
    EVENT_BUTTON id=1   hw_id=3 type=Meta  range=127:0   button_mode=OnOff   meta=runsection:1
    ### BUTTON RELEASE
    EVENT_BUTTON id=2   hw_id=3 type=Meta  range=0:127   button_mode=OnOnly  meta=runsection:2

    It allows to run two different scripts on button press and button release.

    Until now i used a if/then statement in my .NGR script wich was probably not very CPU friendly.

    ### .NGC
    EVENT_BUTTON id=1   hw_id=1 type=Meta  range=0:127   button_mode=OnOff  meta=runsection:1
    ### .NGR
    if ^section == 1
    	if (id)button:1 == 0
    	    LOG "BUTTON RELEASE"
    	else
    	    LOG "BUTTON PRESS"
    	endif
    endif

     

    Best regards
    Marxon


  7. Hi Thorsten

    You are genius!

    After more than three years reminding you,

    you come up with it without warning on a sunday afternoon. :)

    I would love to test it right now unfortunately i am already on the way to work.

    But it looks exactly like what i've wanted.

    Really great!

    Thank you!

    Best regards

    Marxon


  8. Thank you Thorsten!
    A friend has my first FM synth so i couldt not check how i wired it there.
    I edited the cs_menu_io_tables.inc so that the pin order matches the "MIDIbox FM CS DOUT map" schematics.
    (It is just a other pin calculation, so please do not laugh)
     

    DIO_M_COL_ENTRY MACRO sr0, pin0, sr1, pin1, sr2, pin2, sr3, pin3, sr4, pin4, sr5, pin5
        db    ((7 - pin0) + 8*(sr0-1)), ((7 - pin1) + 8*(sr1-1)), ((7 - pin2) + 8*(sr2-1)), ((7 - pin3) + 8*(sr3-1)), ((7 - pin4) + 8*(sr4-1)), ((7 - pin5) + 8*(sr5-1))
        ENDM
    
    DIO_M_ROW_ENTRY MACRO sr_in, pin_in, sr0, pin0, sr1, pin1, sr2, pin2, sr3, pin3
        db    ((7 - pin_in) + 8*(sr_in-1)), ((7 - pin0) + 8*(sr0-1)), ((7 - pin1) + 8*(sr1-1)), ((7 - pin2) + 8*(sr2-1)), ((7 - pin3) + 8*(sr3-1))
        ENDM

    cs_menu_io_tables.inc


    There is also a writing mistake about the CAN bus pins in the setup*.asm files:

     

        ;; if 1: pin RB2 and RB3 are used for CAN bus
        ;;       MBHP_OPL3 data pins #2 and #3 have to be connected to PIC pin RB1 and RB2
        ;;       (available at J5:A6 and J5:A7)


    Correct is:

     

     ;; if 1: pin RB2 and RB3 are used for CAN bus
        ;;       MBHP_OPL3 data pins #2 and #3 have to be connected to PIC pin RE1 and RE2
        ;;       (available at J5:A6 and J5:A7)    

     

    Best regards

    Marxon


  9. Hi again!

     

     

    It seems that the DOUT pins of the matrix get mirrored somehow.
    In my Midibox FM i connected

    LED column 1    SR 3    Pin 4
    LED column 2    SR 3    Pin 5
    LED column 3    SR 3    Pin 6
    LED column 4    SR 3    Pin 7
    LED column 5    SR 2    Pin 0
    LED column 6    SR 2    Pin 1
    LED row    1    SR 2    Pin 5
    LED row    2    SR 2    Pin 4
    LED row    3    SR 2    Pin 3
    LED row    4    SR 2    Pin 2
    

    but in cs_menu_io_tables.inc i have to define it:

    DIO_M_TABLE
        ;; --> DIN <-- pins of the 6 column select buttons
        ;;         Col1 SR/Pin, Col2 SR/Pin,  Col3 SR/Pin,  Col4 SR/Pin,  Col5 SR/Pin,  Col6 SR/Pin
        DIO_M_COL_ENTRY  3, 6,        3, 5,         3, 4,         3, 0,         3, 1,         3, 2
    
        ;; --> DOUT <-- pins of the 6 LED columns
        ;;         Col1 SR/Pin, Col2 SR/Pin,  Col3 SR/Pin,  Col4 SR/Pin,  Col5 SR/Pin,  Col6 SR/Pin
        DIO_M_COL_ENTRY  3, 3,        3, 2,         3, 1,         3, 0,         2, 7,         2, 6
    
    
        ;; --> 1*DIN/4*DOUT <-- pins of the 4 row select buttons
        ;;         DIN SR/Pin,  Row1 SR/Pin,  Row2 SR/Pin,  Row3 SR/Pin,  Row4 SR/Pin
        DIO_M_ROW_ENTRY  3, 3,        2, 2,         2, 3,         2, 4,         2, 5
    
    

     

     


  10. Hi all!

    I am a confused about the FM led wiring.

    In the DOUT schematic the intrument and operator LEDs are connected to-SR2 D6 and SR D7.

    It is not possible to change the pin configuration for these LEDs in „cs_menu_io_tables.inc“.

    But here SR2 D6 and SR D7 are assinged to matrix Col1 Col2 instead.

    Which configuration is correct?

    Best regards

    Marxon


  11. Now you have a similar situation like before.

    Leave out the rgb parameter in the led event because it is already forwarded by the button event

    and by what you said, it seems that the forwarded value has a lower priority.


  12. After i had recap the issue, I remembered having a similar problem in the past.

    The solution is that each dout_matrix has always 16 entries.
    Hence it does not make sense to use all of the 16 pattern positions in my 8x5 matrix.
    So i changed led pattern. 
    LED_MATRIX_PATTERN n=1  pos=0  pattern=0000000000000000
    LED_MATRIX_PATTERN n=1  pos=1  pattern=1000000000000000
    LED_MATRIX_PATTERN n=1  pos=2  pattern=1000000000000000
    LED_MATRIX_PATTERN n=1  pos=3  pattern=1100000000000000
    LED_MATRIX_PATTERN n=1  pos=4  pattern=1100000000000000
    LED_MATRIX_PATTERN n=1  pos=5  pattern=1110000000000000
    LED_MATRIX_PATTERN n=1  pos=6  pattern=1110000000000000
    LED_MATRIX_PATTERN n=1  pos=7  pattern=1111000000000000
    LED_MATRIX_PATTERN n=1  pos=M  pattern=1111000000000000
    LED_MATRIX_PATTERN n=1  pos=8  pattern=1111100000000000
    LED_MATRIX_PATTERN n=1  pos=9  pattern=1111100000000000
    LED_MATRIX_PATTERN n=1  pos=10  pattern=1111110000000000
    LED_MATRIX_PATTERN n=1  pos=11  pattern=1111110000000000
    LED_MATRIX_PATTERN n=1  pos=12  pattern=1111111000000000
    LED_MATRIX_PATTERN n=1  pos=13  pattern=1111111000000000
    LED_MATRIX_PATTERN n=1  pos=14  pattern=1111111100000000
    LED_MATRIX_PATTERN n=1  pos=15  pattern=1111111100000000
    Now all leds are scaled linear over the hole controller range. 
    But one problem remains: 
    There are still "gaps" at the cc values 26, 52, 78 and 104.
    Any ideas?