Jump to content

Karg

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Karg

  1. Solved the first of my problems:

    Quote

    When I enter step triggers, the sequencer starts to play the sequence. It is not in live mode. I would love to turn that off again.

    Turns out it was the AStart setting in the Jam page. Have not used the Jam page often yet, so I was not aware of that setting.

     

    Unfortunately, the issue with changing the step, instead of page persists on the cursor buttons.

     

  2. Hello,

    puh, I accidentally must have enabled some setting parameters. Yet, I do not know which ones, and do not find it in the manual. Maybe someone here knows how to turn everything back to (my) normal:

    When I enter step triggers, the sequencer starts to play the sequence. It is not in live mode. I would love to turn that off again.

    Similarly, the forward/backward keys only move to the next/prev step. Formerly it was flipping the whole page (e.g. from Steps 1..16 to 17..32).

    Any help appreciate...

    Thanks,

    Karg

  3. 5 hours ago, slo said:

    What worked for me was because I’m using a powered hub to power the seq I had to remove the data pins from the port that powers the seq. I’m suspecting the hub was generating some interference on these lines and corrupting the OTG input.

    Hope that helps

    While I am still struggling to understand how the OTG mode really works, the issue indeed was on the MPC side (it simply cannot transmit MIDI through the USB B port).

    Thanks for all replies :)

  4. Hi,

     

    unfortunately, I am stuck right now. How do I address Midi devices connected to USB OTG (currently Midibox Seq4+, latest firmware).

    I manage to send MMC message (currently MPC Live), but have not managed to receive them. Similarly, I do not manage to receive notes, and whatever I try to send to the Seq does not show up on the Midi Monitor.

     

    In this context, I also do not really understand yet which port to set on the instrument pages to send notes over the OTG port.

     

    After several round of trying different things/devices, searching the manual, etc I thought I post my question here.

     

    Thanks a lot in advance!

     

    Cheers,

    Karg

  5. Hi,

    I understood there will be another update after the matrix launch (any ETA yet?).

    While I use the LoopA more and more, there is one feature missing that continuously holds me back. I am not sure if it has been requested yet, but I can well image a general interest: File/Project Names!! :)

    Would be so great if that can be included. A very simple version would do the job, imho. Like one encoder for letter position, one to change character up/down. Maybe even using all four encoders with position, uppercase, lowercase, special character.

    Just a thought.

    :)

  6. Good morning,

    by any chance, does someone know a good alternative to the ALPS STEC12E08 rotary encoder which is panel mountable (thread + screw), but with similar properties (durability, steps, switch, etc)?

    I tried checking directly on the Alps homepage, but was lost in all their versions sooo quickly...

    Thanks a lot in advance.

     

    Best,

    Karg

  7. Hello,

    I would like to give my application MIOS32 File Browser capabilities. Having not found much information about this, I just started playing around a bit:

    Reading other peoples source codes, my impression is that the corresponding code is in terminal.c (LoopA and Seq4 code - is my impression correct?). Thus, I have begun by adding

    	TERMINAL_Init(0);

    into my APP_Init routine. Further, I added several programming models to my Makefile:

    ################################################################################
    # Include source modules via additional makefiles
    ################################################################################
    
    # sources of programming model
    include $(MIOS32_PATH)/programming_models/traditional/programming_model.mk
    
    # application specific LCD driver (selected via makefile variable)
    include $(MIOS32_PATH)/modules/app_lcd/$(LCD)/app_lcd.mk
    
    # MIDI Router (and port handling)
    include $(MIOS32_PATH)/modules/midi_router/midi_router.mk
    
    # MIDImon
    include $(MIOS32_PATH)/modules/midimon/midimon.mk
    
    # UIP driver
    include $(MIOS32_PATH)/modules/uip/uip.mk
    
    # UIP Standard Task (with DHCPC + OSC server and client)
    include $(MIOS32_PATH)/modules/uip_task_standard/uip_task_standard.mk
    
    # generic sequencer modules
    #include $(MIOS32_PATH)/modules/sequencer/sequencer.mk
    
    # MIDI file Player
    #include $(MIOS32_PATH)/modules/midifile/midifile.mk
    
    # FATFS Driver
    include $(MIOS32_PATH)/modules/fatfs/fatfs.mk
    
    # FILE Access Layer
    include $(MIOS32_PATH)/modules/file/file.mk
    
    
    # USB Mass Storage Device Driver
    include $(MIOS32_PATH)/modules/msd/msd.mk
    
    # common make rules
    # Please keep this include statement at the end of this Makefile. Add new modules above.
    include $(MIOS32_PATH)/include/makefile/common.mk

    and also put the MUTEX routines into mios32_config.h:

    // map MIDI mutex to UIP task
    // located in app.c to access MIDI IN/OUT mutex from external
    extern void APP_MUTEX_MIDIOUT_Take(void);
    extern void APP_MUTEX_MIDIOUT_Give(void);
    extern void APP_MUTEX_MIDIIN_Take(void);
    extern void APP_MUTEX_MIDIIN_Give(void);
    #define UIP_TASK_MUTEX_MIDIOUT_TAKE { APP_MUTEX_MIDIOUT_Take(); }
    #define UIP_TASK_MUTEX_MIDIOUT_GIVE { APP_MUTEX_MIDIOUT_Give(); }
    #define UIP_TASK_MUTEX_MIDIIN_TAKE  { APP_MUTEX_MIDIIN_Take(); }
    #define UIP_TASK_MUTEX_MIDIIN_GIVE  { APP_MUTEX_MIDIIN_Give(); }

    Similarly, I have the following in my app.c:

    /////////////////////////////////////////////////////////////////////////////
    //! functions to access MIDI IN/Out Mutex
    //! see also mios32_config.h
    /////////////////////////////////////////////////////////////////////////////
    void APP_MUTEX_MIDIOUT_Take(void) { MUTEX_MIDIOUT_TAKE; }
    void APP_MUTEX_MIDIOUT_Give(void) { MUTEX_MIDIOUT_GIVE; }
    void APP_MUTEX_MIDIIN_Take(void) { MUTEX_MIDIIN_TAKE; }
    void APP_MUTEX_MIDIIN_Give(void) { MUTEX_MIDIIN_GIVE; }

    Yet, I still get the following error messages, and have not found a solution yet.

    Quote

    app.c:339:37: error: 'MUTEX_MIDIOUT_TAKE' undeclared (first use in this function)
    app.c:339:37: note: each undeclared identifier is reported only once for each function it appears in
    app.c: In function 'APP_MUTEX_MIDIOUT_Give':
    app.c:340:37: error: 'MUTEX_MIDIOUT_GIVE' undeclared (first use in this function)
    app.c: In function 'APP_MUTEX_MIDIIN_Take':
    app.c:341:36: error: 'MUTEX_MIDIIN_TAKE' undeclared (first use in this function)
    app.c: In function 'APP_MUTEX_MIDIIN_Give':
    app.c:342:36: error: 'MUTEX_MIDIIN_GIVE' undeclared (first use in this function)

    I hope I am not on the completely wrong path for the MIOS32 File Browser implementation :)

     

    Cheers,

    Karg

  8. 22 hours ago, latigid on said:

    I can't offer an explanation that would have a problem isolated to SW18. If there was an issue with 165 ICs, then the whole column wouldn't work. If there was an issue with transistors on the sink side, then the whole row of four wouldn't work.

    My immediate guess would be that the diode is soldered the wrong way around or with cold joints. Could also be a faulty diode, but it's very unlikely.

    Thanks again! That hint pointed into the right direction. I exchanged the diode last night and then the switch worked :)

    Unfortunately, I directly experience the next problem. In this context, my appologies for bothering you so much. I have not fully understood yet how the wiring works, thus I am constantly fishing in the dark with my troubleshooting attemts and eventually run out of reasonable ideas. Your help is greatly appreciated!!

    The next (and hopefully) last problem is, after soldering the MEC/Leds the latter don't light up on both LeMEC boardsn when performing the l_seq.ng testing. I discovered it right after exchanging the diode last night, and have tried to isolate the exact problem since then. What I have done so far:

    • Confirmed orientation of major parts, including LEDs
    • Resoldered most connections
    • Testing in MIOS Studio: l_seq.ng:
    1. MEC swithes are all recognized
    2. full Jog section works, including 16x8 matrix
    3. ngr set led:XXXX 127 switches all Flux LEDs on (checked by bridging the cathodes)
  9. 25 minutes ago, latigid on said:

    Check the connection made with a MEC switch. It is marked on the silkscreen as 'sink bridged by switch' or similar. The problem would be the same for all SW17-20. Test for continuity over that line and insert a bridge wire or solder the switch in if needed. 

    Are any other switches not functioning? 

    I don't fully understand :(

    However, if I use a wire to connect the "sink bridged by switch" with the pin in the right bottom corner of a MEC switch, I typically get the "keypressed" response in MIOS Studio.

    However, with this test as well, I do not get this for SW18. All other swotches are working well (MEC and Matias).

  10. Troubleshooting round two.

    I am a lot closer to finishing the build, and just have performed all tests described in the build video 2 around 1:30-1:40. All tests were successful but one:

    the MEC switch SW18 on one of the LeMEC boards (R, the larger one) does not respond. I took the switch out and shortened the pads to rule out a defective switch already. Further, I have traced the diode next to it to pin4 on IC3. Judging with my multimeter, this conenction seems good. My plan was to trace the other pins of SW18 of the working board, to then compare with the non-functional one, but I am failing to correctly trace them. Any hints towards the right direction?

     

     

×
×
  • Create New...