Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Hi,

     

    are you using the correct SysEx strings for MBSID V1 (!) as documented here?

    -> http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsynthesizers%2Fmidibox_sid_v1%2Fdoc%2Fmidibox_sid_sysex_implementation.txt

     

     

    is there something wrong in that there is no Save menu on my LCD? All the other menu options are there.

     

    Are you using a 2x20 or 2x16 LCD?

    The SAVE item is the last one in the menu. If you are using a 2x16 LCD, you won't see it.

     

    Best Regards, Thorsten.

  2. Some time ago I also spent some thought on this - at least it's feasible, the topic is on my agenda :)

     

    It requires that the .NGR parser transforms the commands into byte code. With this kind of compression huge scripts could be processed with very high speed.

     

    Do I understand you correctly that you would like to implement this? :)

     

    Best Regards, Thorsten.

  3. The RI_N support for IIC_MIDI is in a bad state - actually I never adapted to LPC17 because the way how the port & pin is specified doesn't work for a LPC17, and I haven't adapted for STM32F4 because I knew that this configuration needs to be changed.

     

    I think that some generic MIOS32_* functions are required to configure IO pins, so that the IIC_MIDI driver could just pass the port "number" and pin number

     

     

    What are the Port and Pin Names ?

     

    The intention was to make this free configurable.

    It's a very app specific configuration, because there are no dedicated pins for the RI_N signals, so that the app developer has to decide which spare pins could be used for that purpose.

     

    Best Regards, Thorsten.

  4. It seems that there is a contradiction:

     

    EVENT_BUTTON id=72  type=CC chn=5 cc=7
    EVENT_RECEIVER id=8 fwd_id=sender:8 type=CC chn=5 cc=7

    BUTTON:72 and RECEIVER:8 listen to the same CC number (cc=7, chn=5)

     

    BUTTON:72 will get the received value

    Thereafter RECEIVER:8 forwards to all (hw_id)SENDER:8

     

    EVENT_SENDER id=13 hw_id=8 if_equal=0   fwd_id=sender:9 type=Meta meta=RunSection:2
    EVENT_SENDER id=14 hw_id=8 if_equal=127   fwd_id=sender:10 type=Meta meta=RunSection:3
    

    SENDER:13 forwards to SENDER:9 if the received value was 0

    SENDER:14 forwards to SENDER:10 if the received value was 127

     

    EVENT_SENDER id=15 hw_id=9 if_equal=button:72:127   fwd_id=LED:47:127 type=Meta meta=RunSection:1
    EVENT_SENDER id=16 hw_id=9 if_equal=button:72:127   fwd_id=LED:48:0
    

    SENDER:15 and SENDER:16 listen to (hw_id)SENDER:9 (which forwarded if the received value was 0)

    But: they will only react if BUTTON:72 is 127 - but the MIDI event set BUTTON:72 to 0 before

     

    Same for SENDER:17 and SENDER:18

    EVENT_SENDER id=17 hw_id=10 if_equal=button:72:0 fwd_id=LED:47:0 type=Meta meta=RunSection:1
    EVENT_SENDER id=18 hw_id=10 if_equal=button:72:0 fwd_id=LED:48:127
    

    They only react if BUTTON:72 is 0, but it has been set to 127 via MIDI before.

     

    Best Regards, Thorsten.

  5. Hi,

     

    I strongly recommend you to organize the buttons in a 8x8 DIN matrix, and the LEDs in a 8x16 DOUT matrix (for 128 LEDs) + 8x8 matrix (for the remaining LEDs)

     

    This will also solve the current consumption issue, because with 8 rows the current consumption is (appr.) divided by 8

    16 rows are not recommended -> LEDs not bright enough

     

    The 8x8 DIN matrix will allocate 1 DIN SR and 1 DOUT SR

    The 8x16 DOUT matrix will allocate 3 DOUT SRs

    The 8x8 DOUT matrix will allocate 2 DOUT SRs

     

    The LED rings will require another 8x16 matrix: +3 DOUT SRs (note: 16 LEDs are max. supported)

    Encoders require +1 DIN SR

     

    Makes: 2 DIN SRs and 9 DOUT SRs, accordingly one MBHP_DINX4 and three MBHP_DOUTX4

     

    - Can I connect encoder pins and push buttons to the same DIN module?

     

    yes

     

     

    - Does this design seem feasable?

     

    This is actually a very simple design; of course it's feasible :)

     

    Best Regards, Thorsten.

  6. Ok, here the recommended solution:

     

      EVENT_RECEIVER id=1 fwd_id=sender:1 type=CC chn=5 cc=1
    
    # run section 1, switch on LED 33, switch off LED 34
      EVENT_SENDER id=1 hw_id=1 if_equal=0   fwd_id=LED:33:127 type=Meta meta=RunSection:1
      EVENT_SENDER id=2 hw_id=1 if_equal=0   fwd_id=LED:34:0
    # run section 2, switch off LED 33, switch on LED 34
      EVENT_SENDER id=3 hw_id=1 if_equal=127 fwd_id=LED:34:127 type=Meta meta=RunSection:2 
      EVENT_SENDER id=4 hw_id=1 if_equal=127 fwd_id=LED:33:0
    

    the receiver forwards the received values to all senders which are matching with hw_id=1

    The senders only react on a matching value (if_equal=<value>)

     

    The value forwarding to a non-existing event (LED:33:x and LED:34:x) will only work with this new pre-release:

    http://www.ucapps.de/mios32/midibox_ng_v1_033_pre5.zip

     

    I also fixed the DELAY_MS parameter, delay should be handled properly now (it was running twice the speed before if MBNG was showing the main screen on LCD)

     

    Best Regards, Thorsten.

×
×
  • Create New...