Jump to content

TK.

Administrators
  • Posts

    15,193
  • Joined

Posts posted by TK.

  1. Hi,

    GP LEDs are (unfortunately) not free assignable, therefore BLM8X8_DOUT_GP_MAPPING has been introduced to consider different hardcoded options:

    So, from documentation point of view, Option #1 is probably the most save solution because you can compare Wilba's schematic with yours.

    The mapping is implemented in https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_ui.c line #3579 (search for "seq_hwcfg_blm8x8.dout_gp_mapping == 1")

    Best Regards, Thorsten.

  2. Hi,

    yes, meanwhile up to 4 AOUT or AOUT_NG modules can be chained. Module 2..4 can be accessed via MIDI Port 2..4, and each MIDI channel gives you control over 8 CV outputs and 8 gates (-> makes up to 32 CV channels and gates)

    Only the first AOUT_NG module should be connected to a line driver.

    Best Regards, Thorsten.

     

  3. Alright, now I see the problem - the notation for the "Connections to Pins on STM32F4 DiscBoard" has been added by yourself, and I agree, that the data input of the SD Card has to be connected to the serial data output of STM32F4, and vice versa.

    Compare with the MBHP_CORE_STM32F4 schematic: http://www.ucapps.de/mbhp/mbhp_core_stm32f4.pdf

    SDCard J1 DI -> MBHP_CORE_STM32F4 J16 SO (-> PA7)
    SDCard J1 DO -> MBHP_CORE_STM32F4 J16 SI (-> PA6)

    Problem solved :)

    Best Regards, Thorsten.

  4. I wouldn't say it's a bug, it's more like an imperfection. The guide track mechanism only works for a track which plays 16th notes; it just matches the length of this track with the song position, and once reached, it increments the song step.

    There is currently no way to change this without rework at some places where hardcoded dividers are used for the song "ref_step"

    Best Regards, Thorsten.

  5. Hi,

    Quote

    l

    ong time no see :happy: After a long break I unpacked my midiboxes and started making music again with my Seq.

    same at my side :wink:

    Quote

    I want to trigger a guitar instrument and setup the track so that the first 6 note layers represent the six guitar strings. That way it´s relatively easy to translate guitar tabs. Now I´ve noticed that, whenever I enter a note on note layer 2-6, one is also entered on the 1. note layer automatically. I am able to deactivate those afterwards by pulling the note down to --- with the encoder, but this behaviour is quite irritating and the solution is not very comfortable. I´ve never noticed this behaviour in the past because I never used multiple note layers before.

    The default note (C-3) at Layer A is already there, we will hear it once the gate is enabled, which happens automatically by entering a note in any layer.

    Quote

    Is there some way to work around this? It would be ok to make changes to the source code, I can recompile.

    A quick solution would be a hack in seq_par.c, line 579: https://github.com/midibox/mios32/blob/master/apps/sequencers/midibox_seq_v4/core/seq_par.c

    Following condition:

      if( par_layer > 0 && (par_type == SEQ_PAR_Type_Note || par_type == SEQ_PAR_Type_Chord1 || par_type == SEQ_PAR_Type_Chord2 || par_type == SEQ_PAR_Type_Chord3) )
        return 0x00; // Note/Chords are 0 by default if not in Layer A

    could be enhanced, so that it also sets the Note to 0x00 in Layer A

    But there is a big drawback: unfortunately it won't be so easy to introduce an individual default value, e.g. per track, because the SEQ_PAR_InitValueGet() function doesn't get the information, which track should be initialized. And I guess that you would still like to get C-3 per default for other tracks.

    Therefore I recommend, that you configure a track so that all notes in layer A are disabled, and store it as a Preset in the Event menu page, so that this preparation only has to be done once, and the setup can be restored on demand.
    Reminder: in conjunction with the ALL button you could set all 256 steps with a single encoder.

    Best Regards, Thorsten.

  6. You may have noticed, that in the last months I haven’t visited the forum so often anymore.

    Please don’t worry about that, everything fine at my side. :happy:

    Sometimes I need a certain distance to my legacy projects to enjoy other parts of my life, and to explore new fields. Only this way I can stay creative, and I’m sure that with inspirations and motivations that I collect during such a break I will come back sooner or later with some fresh ideas. Last time I did this, I switched from MIOS8 to the MIOS32 platform thereafter :)

    I won’t completely disappear, and from time to time I might sporadically release updates for MIDIbox SEQ and NG - but I won’t spend so much time for user support & development of new feature requests in the next months until I feel that the right time has come to focus on MIDIbox again.

    Until then I’m asking the community to help each other. :happy:

    MIDIbox is definitely not dead, many people still build the projects and get support from experienced forum members, although it became more difficult to get PCBs and parts.

    Last but not least with Peter and Andy we have strong contributors who founded midiphy in 2018 as a sustaining function for „Premium DIY“ products derived from MIDIbox.

    I gave them the right to use the MIDIbox platform commercially outside of the normal MIDIbox license, since they have my full trust that they deliver the best quality and ensure, that their customers won’t be disappointed.

    Recently we came together and talked about how to proceed in the future. Peter and Andy pointed out, that they have to spend a significant amount of their time to provide the service, so I agreed that some contributions can’t be provided as open source anymore, such as the implementation of new major features in existing projects, new MIDIbox based products, documentation updates, customer focused support, etc.

    In other words: to protect midiphy contributions and ensure, that Peter and Andy will be compensated for their efforts, I hereby permit that they can provide MIDIbox derived products as closed source.

    The MIDIbox license otherwise stays unaltered: by default, no commercial use is allowed. Thus, commercial use of MIDIbox software or hardware has to be approved by me on a case-by-case basis. In general, it will only be granted to entities who have worked in the forums for years, have a proven track-record of established projects based on MIDIbox and have shown their ongoing support efforts to users of these projects.

    Best Regards, Thorsten.

  7. Yes, the function is different, see also the MIDI Router documentation under http://www.ucapps.de/midibox_seq_manual_m.html

    Alternatively, also "Track" can be selected as target channel. In this case, incoming MIDI events will be routed to the MIDI port and channel of a track depending on the incoming MIDI channel number.
    Usecase: MIDI events, such as CC or Notes, should be sent from a master keyboard or MIDI controller to synths which are assigned to different port and MIDI channels in the track configuration.
    Just select the track with the MIDI channel on your keyboard/controller, the router will take care that the events reach the right destination.

    I think it makes clear, that incoming MIDI messages won't be forwarded to the tracks, they will be directly sent over the MIDI port + channel of the appr. tracks.

    For the mentioned use case, it would even be counter productive if track mutes would disable this forwarding - just imagine, somebody wants to mute some sequences played by tracks in order to play live over one or more keyboards by using this routing feature  - this wouldn't work anymore.

    Your proposal is something different, and it would fit better as a multi track feature for the Record & Live function, not to the MIDI router.

    Some general changes have to be done in the firmware to allow this - I added it to the Wishlist.

    Best Regards, Thorsten.

  8. Hi,

    yes, you should read 5V on C3, C4 and J2. But based on your measurements the capacitors don't cause the problem (it would be a short, resulting into 0V at pin 1).

    Sounds like a bad solder joint or broken track? What happens if you connect pin 1 and 2 with a short wire?

    Best Regards, Thorsten.

  9. This feature was requested from a user who just wanted to forward MIDI messages to the preconfigured MIDI port/channels of the tracks without further processing, and this is how it's working.

    Your request goes into a different direction, it's more like a multi channel live/recording function - currently we can only record or play live (+ FX) on a single (selected) track. Allowing more channels would lead to higher RAM consumption, but it could be provided as a MIDIbox SEQ V4+ option, only working on a STM32F4.

    I'm unsure how Mutes should be handled in this case. I would expect that independent Mute control would be preferable, e.g. to mute the sequence played on a track when the instrument should be played live, but this contradicts with your request. On the other hand: if separate mutes for this forwarding function are provided, where/how should they be controlled?

    Best Regards, Thorsten.

  10. Hi Richie,

    in MIOS Studio, MBHP_MF_NG configuration tool, please check the MIDI configuration.
    E.g. the "operation mode" defines, what kind of MIDI events are sent, and the "touch sensor mode" defines, under which conditions they are sent.

    Best Regards, Thorsten.

    P.S.: Don't know where to find the MIDI 3 IN/OUT wiring schematics, maybe the forum search function helps.

×
×
  • Create New...