TK.

Hi, GP LEDs are (unfortunately) not free assignable, therefore BLM8X8_DOUT_GP_MAPPING has been introduced to consider different hardcoded options: Option #1 (Wilbas frontpanel) can be derived from following schematic: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=wilba_mb_seq:wilba_mbseq_pcb.pdf Source Code shows following mapping: // BLM_X DOUT -> GP LED mapping // 0 = 15,16 1 = 13,14 2 = 11,12 3 = 9,10 // 4 = 1,2 5 = 3,4 6 = 5,6 7 = 7,8 Option #2 (Antilogs MBSEQV4L SRIO Panel) schematic: http://wiki.midibox.org/doku.php?id=seq_v4l_mk._ii&s[]=antilog Option #3 (Antilogs MBSEQV4 Panel) - can't find the schematic. Source Code shows following mapping: // BLM_X DOUT -> GP LED mapping // left/right half offsets; green,red // 0 = 8,9 1 = 11,10 2 = 13,12 3 = 15,14 // 4 = 40,41 2 = 43,42 3 = 45,44 4 = 47,46 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.

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.

I think that the right fix would be in the mk_syx.pl script to copy $event_2 into $event_3 (which was always 0 for program changes), because this is the value which is picked up by MIDIbox64 2.4f Here the appr. change: https://github.com/midibox/mios8/commit/d32c65cf38aa874d04f6880a769ac174dbe46d72 Best Regards, Thorsten. P.S.: great frontpanel! :)

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.

Last time I worked on this was 2012, so 10 years ago... ;-) MIDI_EVNT1 is a predefined value from the configuration, while MIDI_EVNT_VALUE is a variable coming from a controller (pot, encoder, button, ...) What kind of controller are you using to send the program change event? Best Regards, Thorsten.

Hi, nothing special needs to be considered at the HW side, but it's important that you upload an application which supports SD Cards, such as MIDIbox NG. Best Regards, Thorsten.

These are digital IO pins, I guess that they are only used to check for full left/full right turns. Good enough for DJ fake pots! Best Regards, Thorsten.

PIC18f452 has only 8 analog inputs as you can read in the data sheet: https://ww1.microchip.com/downloads/en/DeviceDoc/39564c.pdf Are you sure, that there is no chip such a 4051 multiplexer (which is not an ADC, such a "switch") between pots and analog inputs? Best Regards, Thorsten.

This could only be provided as an option, because other people (like me) would very likely prefer to display velocity the way it's implemented - yes, not great if LayerA doesn't play a note (but the velocity is still displayed at the right upper corner for the selected step) Best Regards, Thorsten.

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.

Hi, same at my side 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. 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.

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. 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. 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.

Great that it's working now, but further diagnosis is difficult remotely (maybe a picture helps) Best Regards, Thorsten.

Yes - did you ever try the "Live Forwarding" feature of the Jam page? Best Regards, Thorsten.

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.

No SSL so far - thanks for the reminder! Best Regards, Thorsten.

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.

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.

Yes, this makes a difference, because the ADC channels have to be selected differently in the firmware. Here a build for PIC18F4685 - untested (hope that it works): http://www.ucapps.de/mbhp/mbhp_mf_ng_v1_005_pic18f4685.zip Best Regards, Thorsten.

I found this firmware in my backups, the link is working again Best Regards, Thorsten.

It took a bit longer than expected, but finally we've a new forum software and also the gallery should work again Yes, I'm definitely interested on "reporters" for the wordpress blog; let me update the installation, thereafter I can give you access :) Best Regards, Thorsten.

Very cool transparent case! :) Best Regards, Thorsten.

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.

Unfortunately gallery rebuild times out, and it requires a forum update: https://invisioncommunity.com/release-notes/ Will check it later this week - updating the forum SW is on my backlog anyhow (since several years ;) Best Regards, Thorsten.