Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. On 25.11.2016 at 9:31 AM, EsotericLabs said:

    Another small suggestion for the chord handling is as follows:

    I've to spend some thoughts about this.
    The request makes sense, but to ensure compatibility a new parameter layer type for this kind of Chord handling has to be introduced.

    This means that instead of only 32 chords in Chord1, and 32 additional chords in Chord2 mode, we would have up to 128 chords available - ideas how to fill the space? ;-)

    On 4.12.2016 at 8:31 AM, mongrol said:

    I'd like to request an item for the wishlist to help with Song composition.

    Added to wish list - makes sense, but will need some time to implement this

    On 13.12.2016 at 6:43 AM, v4 said:

    there is a bug in Transpose that can be reproduced by setting force to scale to Arabian for a track and hitting G# or A# in the Transposition menu. verified on two machines in 4.091 and the latest beta.

    I will check this with high priority

    On 14.12.2016 at 6:46 AM, lobit said:

       Im going to post this here only because Ive been dreaming of this  (modulate step trigger advancement from another track)

    especially interesting if you could not only advance but transpose with the modulator track

     sh101/jx3p style sequencing 

    Still on the wish list, but lower priority compared to other (especially easy to implement) requests

    On 17.12.2016 at 0:17 PM, latigid on said:

    Can support for jog shuttles be implemented?

    Could be implemented, but I have to experiment with this hardware before I can give a final confirmation

    Best Regards, Thorsten.

  2. I think that additional buttons will be required, maybe above the Jog Shuttle.

    They would allow to switch the keyboard into different modes, such as

    • 1 button to select the "normal layout", the 4th row (which is not available on Wilbas frontpanel) is used to select tracks
    • 1 button so that the 4th row is used for mutes
    • 1 button so that the 4th row is used to select parameter layers
    • 1 button so that the 4th row is used to select trigger layers
    • 4 buttons to switch to BLM mode and to select the 4x16 segment
    • maybe some spares if space is available

    Best Regards, Thorsten.

  3. I remember that I ordered this chip some time ago to work on a Dual-MBHP_IIC_MIDI board, but I'm still unsure if it's worth to work on this. Implementation, documentation and support effort is higher than the benefit (at least at my side)

    Actually it would be nice if somebody else could implement an alternative solution, do all the required testing and give long-term support.

    Best Regards, Thorsten.

  4. I'm in contact with the designer.

    The good news: he plans a public release of all sources, which means that it will be possible to change the HW interface so that it can be directly connected to the core w/o need for serial shift registers! :happy:

    It might even be possible to use a bigger FPGA for the emulation of 8 SIDs, all connected to a single SPI which will be the best way how to control the SIDs from a MBHP_CORE_STM32F4 module.

    Best Regards, Thorsten.

  5. 43 minutes ago, latigid on said:

    I assume that WS2812B will use too much memory? That would be an easier way to do it if there are decent mounting strategies. There are also newer APA102 LEDs that run over SPI (clock and data) -- easier to manage?

    WS2812B is possible for V4+, but the LEDs consume so much power that the device can't be supplied from a USB cable (strongly recommended todays!)

    Best Regards, Thorsten.

  6. Encoders are important for fast parameter changes with a single hand.

    Here an alternative idea for a FP layout:

    mbseqv4newfp.thumb.png.a7a2caf925061c97f

    However, a potential issue with the adafruit pads is the spacing between the pads: it doesn't allow to add labels

    But labels are essential for intuitive usage!

    Best Regards, Thorsten.

     

     

  7. Hopefully it will be possible to find a more detailed datasheet.

    Maybe it isn't related to current draw, but to a configuration option.

    This is based on speculation, but worth to check (because I've no other idea): according to the website this display supports different protocols such as 6800, 8080 and SPI.
    The 8080 protocol is required, if 6800 is selected instead, a short circuit would happen between the parallel connected data busses during read operations, and this could cause a malfunction (e.g. core reboot)

    With some luck you will find some bridges on the PCB which show the configurable options on the silk screen.

    Best Regards, Thorsten.

  8. So, you mount the 4 PICs of the non-working board into the other board, and CAN communication is working there? This is an important information!

    Concerning continuity checks: remove the PICs while checking it.
    Compare with this interconnection diagram: http://www.ucapps.de/midibox_sid/mbsid_v2_communication.pdf
    And this schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf

    Expectations:

    • pins #36 of the PICs (RB3) are directly connected together.
      They should show continuity to each other.
      No continuity to ground (Vs)
      No continuity to 5V (Vd)
      But should show 1k resistance to Vd
    • pin #35 of the PICs (RB2) should show
      No continuity to ground (Vs)
      No continuity to 5V (Vd)
      continuity to pin #36 only if the negative probe is connected to pin #35, and the positive probe to pin #36 (due to the diode)

    Results?

    Best Regards, Thorsten.

  9. Synced pattern changes should work again with this version:
    -> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre7.zip

    Background why this happened: last week I analyzed the stack usage and found out, that in worst case a stack overrun could happen while playing MIDI events or operating with the CS. I gave the appr. tasks more memory, and reduced memory for the pattern handler. By doing so, I overlooked that during a pattern change more memory will be allocated than expected.

    With the last changes the pattern task became obsolete, giving more memory for the other tasks (and a bit more memory for additional features :)

    I hope that with pre7 everything is working like before (or even better ;-)

    Best Regards, Thorsten.

  10. 1 hour ago, u-link said:

    Wow, that was quick! Thanks a lot, I will try it out asap, hopefully tomorrow. You are of course right, if you use groove patterns for velocity control, you want to keep it. I never did that up to now. What about keeping velocity control, but automatically ditching swing for non-standard (ie: non-16ths) sub div? While I am not sure I understand your suggestion correctly, I don't think it would do the trick. Imagine two tracks with different sub div sending to the same receiver, this would still lead to flams, no?

    You've to enable the "sync to track" option for both tracks, and they have to run with the same divider, then it will work! :)

    Here the new version:
    -> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre5.zip

    21 minutes ago, EsotericLabs said:

    for drum tracks, there are 1024 bytes for parameters and 2048 bits for triggers , is that correct? Less instruments allow longer parameter and trigger patterns, is my understanding correct?

    You are right, I corrected the max. trigger layer lengths of the two additional drum modes that you introduced accordingly in pre5

    Best Regards, Thorsten.

  11. Alright, here some updates:
    -> http://www.ucapps.de/mios32/midibox_seq_v4_092_pre5.zip
    /edit: corrected to newer link

       o new drum configurations: 4*16/2*64, 4*16/1*128, 4*16/1*256
    
       o new track mode configuration option: "Note"
         Allows to specify, if the transposer should take the last or first
         played note (previously it always played the last note)
    
       o individual steps of CC, PitchBender, Program Change and Aftertouch
         layers can now be disabled so that they won't play.
         Turn the encoder to the rightmost position (value 128)
    
         Also the init value has been changed: for these layers, the steps
         are now disabled by default.
         For CCs please change the init value by yourself in the UTIL->OPT
         page (option #12: Initial CC value)
    
       o new behaviour of CLEAR button in recording mode:
         it clears the selected step only (not the entire pattern).
         During live recording it will clear the "played" steps so long the
         button is pressed.
    
       o new CC functions which can be configured in MIDI->ExtCtrl.:
         o Play/Stop: allows to assign the PLAY button to a CC
         o Record: allows to assign the RECORD button to a CC
    

    @EsotericLabs: thanks a lot for testing!
    G1T2 was playing the last note of the note stack. Since G1T1 played a chord into the transposer but, it was off the root note.
    In the new version you are able to specify that the first note should be played.
    Select Track #2, change to the MODE page and press GP button #9

    @u-link:

    - request #1 implemented (I also needed it ;-)
    - request #2 was already implemented (there is a BUTTON_RECORD and LED_RECORD option in the MBSEQ_HW.V4 file, please update your file according to the templates under hwcfg/*)
    However, Play/Stop and Record can now also controlled via CC (e.g. to control these functions from a foot switch)
    - request #3: implemented (yes, it makes sense)


    - request #4: statement & question:
    I'm using custom groove patterns to vary the velocity, here I would like to control each 16th
    In addition, since groove patterns can be applied globally, you want to define them independent of the track divider

    However, what I could add is an option which allows to synchronize the groove pattern to the track step instead of the global step. Would this satisfy your request?

    Best Regards, Thorsten.

×
×
  • Create New...