Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Quote

    Looking at the diagram for non velocity keyboards it wasn't clear which end was the bass end I also assume that that loop can extend to 128 notes  or you can make a second clone and scan seperately?

    yes, up to 2 keyboards can be scanned separately.

    Alternatively - since no velocity is involved - you could also scan the keyboards as a DOUT_MATRIX. Up to 16 matrices are supported.

    Best Regards, Thorsten.

  2. Yes, by telling the MBNG that a 8x8 DIN matrix is connected, it will scan the inputs and provide them for further event processing.

    In the cfg/tests directory you will find a lot of additional programming examples which might help: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2F

    E.g. this example shows the most simple way to send Note Events from a DIN matrix: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fblm8x8.ngc

    And when you compare this configuration with the detailed description under http://www.ucapps.de/midibox_ng_manual_ngc.html you will notice that there are much more possibilities - the example only gives you a starting point. 

    Best Regards, Thorsten.

  3. The BLM_X is the right choice (and not the KEYBOARD driver)

    Programming Example: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fexamples%2Fblm_x%2F

    Following configuration is required in mios32_config.h:

    // configure BLM_X driver
    #define BLM_X_NUM_ROWS            8
    #define BLM_X_BTN_NUM_COLS        8
    #define BLM_X_LED_NUM_COLS        8
    #define BLM_X_LED_NUM_COLORS      1
    #define BLM_X_ROWSEL_DOUT_SR      1
    #define BLM_X_LED_FIRST_DOUT_SR   2
    #define BLM_X_BTN_FIRST_DIN_SR    2
    #define BLM_X_ROWSEL_INV_MASK     0x00
    #define BLM_X_DEBOUNCE_MODE       1

    Schematic which shows the DIN/DOUT mapping: http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf

    Best Regards, Thorsten.

  4. On 21. März 2016 at 3:42 PM, jjonas said:

    However, I also tested Edit Recording mode a bit more, and found (and this is identical to pre5) that while Edit Recording mode does work in Mono/Poly with both SELECT and GP buttons (like I reported back earlier), this happens only when Fwd is 'on'. If Fwd is 'off' and you try to use Edit Recording mode with Poly, only one note gets recorded.

    should work now (link to pre8 below(

    On 21. März 2016 at 3:42 PM, jjonas said:

    If divider is doubled (speed halved) for the Guide Track, it will proceed only half-way before forcing pattern change. (See this comment and the next one.)

    issue is understood, but change isn't so easy, and will lead to incompatibilities.

    The background: the guide track defines the measure length in 16th notes unrelated to the track divider settings
    Maybe a proper documentation of this imperfection would help instead of an implementation change?

    Quote
    • Muting a track cuts off all playing notes on that track, but muting an individual note layer doesn't do the same for the note that's currently playing in that layer -> hanging notes.

    Noticed in the wish list, but a change won't be so easy...

    2 hours ago, phillwilson said:

    Request 1 - F button functions for live record.

    did you already try the new BUTTON_RECORD behaviour which has been introduced in pre7?

    For me it sounds that it's doing what you've requested

    2 hours ago, phillwilson said:

    2. Request 2 – Transpose tracks being more musically related to the current scale.

    Could you please try following pre-release?

    -> http://www.ucapps.de/mios32/midibox_seq_v4_091_pre8.zip

    The transpose page got a new function >SCALE< which is active when you enter the page.
    Octave is controlled with GP2..8, and the semitone (based on the scale) is selected with GP9..16

    Best Regards, Thorsten.

  5. Hallo,

    Du koenntest die LED zwischen zwei DOUT Pins anschliessen. Ein DOUT Pin sollte auf 1, der andere auf 0 stehen. So kontrollierst Du die Farbe.

    Es waere jedoch besser, wenn Du eine 3-Pin LED nimmst. So koenntest Du die LED auch noch in einer dritten Farbe (Rot+Gruen = Gelb) aufleuchten lassen

    Gruss, Thorsten. 

  6. 1 hour ago, jjonas said:

    Random gate trigger layer: is the chance 50/50 or something else

    yes, the probability is 50:50

    Quote
    • Random value trigger layer: does this randomise all the values in all parameter layers of the step, or just some? Is the random value anything between 0-127, or is the intensity guided somehow?

    it will only randomize the note value between -12/12 semitones

    Quote

    MODE page option 'Sort' for arpeggiator mode: how does it sort the notes? Into an ascending order..?

    Yes, in ascending order

    Quote

    And is the unsorted note order the reverseof the play order, i.e. last played note is "number one" in the arpeggiator track notation?

    yes

    Best Regards, Thorsten.

  7. 19 minutes ago, Lamster said:

    The 1.019 is metioned here in the NG first steps document http://www.ucapps.de/midibox_ng_manual_fs.html

    This page refers to a feature which was introduced with the MIDIbox NG version V1.019 (I added this detail to make it clear)

    20 minutes ago, Lamster said:

    I think more reading and revision is needed on my part while I get my head round the MIOS system. I realised that I can't type anything in the box so forcing single use USB is a problem

    commands have to be entered into the special text box under the terminal window

    Best Regards, Thorsten.

  8. Hi,

    Bootloader V1.018 is fine, where did you find the hint that V1.019 should be used?

    Quote

    I'm "guessing of course" that the NG project replaces the bootloader and is then not being loaded and causing some kind of lock up ?

    No, a MIOS32 application doesn't replace the bootloader, this part resists in a protected range.
    You could upload the application .hex file directly with ST Link, in this case the flash gets the bootloader + application binary
    In both cases MIDI upload should work

    Quote

    Is that 1 ignorable error a factor in this?

    No, the ignorable error really can be ignored, no reason to be worried about that

     

    Questions to you:

    - which Windows version are you using?
    - some Windows versions require the "single_usb" option, see also: http://www.ucapps.de/mios32_bootstrap_newbies.html
    - note that the single_usb option will be overwritten to the default (0) whenever you are overwriting the flash contents with the ST link programmer.

    Proposal for further troubleshooting:

    - flash the MIOS32 bootloader update application again with ST Link
    - activate the single_usb option via MIOS Studio terminal as described in the "newbies" page (search for "single_usb")
    - after "store", reconnect the USB cable
    - wait until Windows found the device
    - re-open MIOS Studio
    - upload the application

    Best Regards, Thorsten.

  9. On 11. März 2016 at 6:49 PM, jjonas said:

    MODE page 'Restart' option: there seems to be some false triggering going on with restart (one key press results in one or more triggerings), as well as short delays in re-starting the track sometimes

    I checked this at my side, the restart option works as expected.

    False Restart triggering might occur if multiple sources control the arpeggiator.
    It's important, that either your external keyboard, or a loopback track controls the T&A bus. They shouldn't control the bus at the same time

    The delay is due to the step synchronisation.

    Best Regards, Thorsten.

  10. On 17. März 2016 at 2:06 PM, doc007 said:

    Since I changed my SD card I can upload MBSEQ_HW.V4 and save it on my sd card to use my wilba's frontpanel. But later if I try for example to change the midi port ( pressed MENU + MIDI and select Midi Router on the left LCD ) I have an error :

    [16338.948] [SEQ_FILE_C] Failed to open/create config file, status: -11
    [16338.949] [SDCARD_ERROR:-11] DFS_OpenFile(..DFS_WRITE..) failed

    What do you think ? hardware or software error ?

    Thanks for the answer

    Could it be, that no session has been created yet?

    On 17. März 2016 at 10:45 PM, EsotericLabs said:

    Feedback on 4.091 beta5, the extended chord table function.

    • configured a track for chords, initialized it, then set the parameter layer to Chrd2 and confirmed with GP button
    • switched to edit mode, stepped though all chords while playing them on my sound card.
    • Technically no issues found, only the 13  chords  (maj13, dom13, min13) are off  - my bad! all '20'  in the extended chord table code should be '21'.

    updated 6 note extended chord table in C code:

    Now also updated in the pre-release below

    On 17. März 2016 at 9:05 AM, k-rAd MB6401 said:

    i'm not sure if i'm the first to find this problem.....

    Drum triggers from analog out  via ch16 will turn off if a delay of "0ms" is selected on all the midi outs in the bpm page.

    In other words I can mute and unmute my 16 DOUT drum triggers by toggling between 0ms and -1ms on any midi out in the bpm page.

    Currently running v 4.089 maybe this is already fixed in v 4.091?

    please try the pre-release below (but I haven't changed anything for the drum triggers...)

    22 hours ago, k-rAd MB6401 said:

    First steps are also not played when midi delay is used. 

    I can't reproduce this, the first steps are played when MIDI delay is used.
    Is this somehow related to the issue that you reported on the 17th march?

    On 19. März 2016 at 8:53 AM, jjonas said:

    One additional note to 4.091 beta: When AStart is 'on', the first played note gets recorded correctly on the active track, but if there are notes in other tracks, the notes in the first steps of those other tracks won't be played.

    I can't reproduce this, the first steps of all other tracks are played in step and live recording mode

    On 17. März 2016 at 2:59 PM, jjonas said:

    Feedback on 4.091 beta. To the extent I tested, everything worked except one thing:

    • I assigned JAM_LIVE and JAM_STEP to the F1–F4 buttons (and disabled the "zero-address" lines for the buttons from elsewhere in the HW setup file). JAM_LIVE has no visible effect, while JAM_STEP takes you to the Jam page, but the Step/Live mode is always what you have chosen manually on the Jam page earlier. In this sense BUTTON_JAM_STEP works like the old BUTTON_RECORD.

    should work in the pre-release below

    3 hours ago, Gridracer said:

    Could it be possible that there is a little failure in the Step_digits shematic?

    http://www.ucapps.de/midibox_seq/mbseq_v4_bpm_digits.pdf

    Step_digits.jpg

    Thanks for pointing this out! The schematic has been fixed.

    On 17. März 2016 at 2:59 PM, jjonas said:

    BTW at some point in the draft manual thread I suggested that the default F1–F4 button functions in the HW setup file should be updated. I'm sorry to flip-flop on this, but since I made that suggestion I found that the Bookmarks page is actually available rather easily with MENU + SELECT, and tap tempo is available similarly with MENU + PLAY. On the other hand, the Track Selection (TRACK_SEL) page is not available easily, so probably it should take the place of bookmarks or tap tempo in the F1–F4 button default options...?

    I changed the Fx assignments again:

       o hwcfg/wilba*/MBSEQ_HW.V4: default F1-F4 assignments changed to:
         F1: Track Select, F2: Live Forwarding, F3: Recording, F4: Save All
    

    Here a link to the pre-release:
    -> (removed obsolete link)
    -> please find pre7 in one of the next postings

    Best Regards, Thorsten.

  11. before we drift into an academical discussion: Sauraean, I added the hooks into the MIOS32_SDCARD driver for you, so that you can experiment at application level w/o touching MIOS32 code.

    The change is available in the SVN repository, please update.

    MIOS32_SDCARD_SectorRead (and SectorWrite) now contain:

      // read 512 bytes via DMA
    #ifdef MIOS32_SDCARD_TASK_SUSPEND_HOOK
      MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, MIOS32_SDCARD_TASK_RESUME_HOOK);
      MIOS32_SDCARD_TASK_SUSPEND_HOOK();
    #else
      MIOS32_SPI_TransferBlock(MIOS32_SDCARD_SPI, NULL, buffer, 512, NULL);
    #endif

    so, once a function for MIOS32_SDCARD_TASK_SUSPEND_HOOK has been assigned, it will be called after MIOS32_SPI_TransferBlock. In addition, MIOS32_SDCARD_TASK_RESUME_HOOK will be called by the DMA callback

    In your mios32_config.h file, add following code:

    extern void APP_SDCARD_TaskSuspend(void);
    extern void APP_SDCARD_TaskResume(void);
    #define MIOS32_SDCARD_TASK_SUSPEND_HOOK APP_SDCARD_TaskSuspend
    #define MIOS32_SDCARD_TASK_RESUME_HOOK  APP_SDCARD_TaskResume

    And somewhere in your app.c file:

    void APP_SDCARD_TaskSuspend(void)
    {
      // suspend task here
    }
    
    void APP_SDCARD_TaskResume(void)
    {
      // resume task here (will be called from DMA callback, it's an ISR)
    }

    Best Regards, Thorsten.

  12. No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file

    Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? 
    In this case, I would expect that the same issue happens with older versions

    Best Regards, Thorsten.

  13. No problem at my side, something is probably wrong in your MBSEQ_HW.V4 file

    Try the original hwcfg/wilba/MBSEQ_HW.V4 file, if you notice the same, then maybe related to a connection issue? 
    In this case, I would expect that the same issue happens with older versions

    Best Regards, Thorsten.

  14. Quote

    The reason I was talking about adding this to the generic MIOS32 SD card functions is that other than the portability issue, I would think that most applications would want the behavior of the CPU being freed while a SD card DMA transfer was in progress.

    I assume that only a minority of applications need this.

    During SD Card transfers FreeRTOS will switch to other higher prio tasks automatically within 1 mS (preemptive multitasking is enabled). If you organize the task priorities accordingly, there isn't a problem with the blocking behaviour. E.g. I don't see a need for MBSEQ, MBNG, MBCV

    Best Regards, Thorsten.

×
×
  • Create New...