TK.

Yes, this one should work Here the interconnections: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=neonking:ssd1322-pinout.jpg In order to select the display in MIOS32, upload the Bootloader Update Application and enter: set lcd_type GLCD_SSD1322 set lcd_num_x 1 set lcd_num_y 1 set lcd_width 256 set lcd_height 64 store Thereafter upload the MIDIbox NG application again -> display should show some meaningful messages Best Regards, Thorsten.

Hi, in the last days I troubleshooted the MIDIbox SID panel with the latest CTRLR sources which are available on Github. This resulted into: a solution for newer Macs with Apple Silicon: https://github.com/RomanKubiak/ctrlr/issues/560#issuecomment-1771700555 a small source code change to get the "ui" flag working again because my panel relies on this feature, which vanished some years ago for whatever reason: https://github.com/RomanKubiak/ctrlr/pull/573 some LUA script changes to get the panel compatible I will do some testing in the next days to ensure that all parameters are working, and I have to find a way to build AUs However, I will only be able to provide a MacOS version. PC users might be interested on the "fixed version" as well. Therefore the question: has anybody the knowledge to build CTRLR with my source code changes on a PC? Best Regards, Thorsten.

There is hope! Two days ago a new JUCE version has been released with an interesting message: #if ((defined (MAC_OS_X_VERSION_MIN_REQUIRED) \ && MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_VERSION_13_0) \ || (defined (__IPHONE_OS_VERSION_MIN_REQUIRED) \ && __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_15_0)) // This is an error because the linker _will_ produce a binary that is // broken on older platforms static_assert (std::string_view (__clang_version__) != std::string_view ("15.0.0 (clang-1500.0.40.1)"), "The new linker introduced in Xcode 15.0 will produce " "broken binaries when targeting older platforms.\n" "To work around this issue, bump your deployment target to " "macOS 13 or iOS 15, re-enable the old linker by adding " "'-Wl,-ld_classic' to your link flags, or update to Xcode " "15.1.\n" "Once you've selected a workaround, you can add " "JUCE_SILENCE_XCODE_15_LINKER_WARNING to your preprocessor " "definitions to silence this warning."); #endif #endif So, here a new binary build with latest JUCE and -Wl,-ld_classic flags, let me know if this works: -> http://www.ucapps.de/mios_studio/MIOS_Studio_2_4_9_r3.app.zip Best Regards, Thorsten.

Hi Zam, thanks for the feedback - although it worries me ;) The crash report indicates that something is going wrong before the actual application code has been started. I haven't seen this before, and therefore don't have a solution (yet). What would be interesting: what happens if you start MIOS Studio from a terminal: MIOS_Studio.app/Contents/MacOS/MIOS_Studio --batch Best Regards, Thorsten.

Older versions can be found in the archive: http://ucapps.de/mios32/backup/ Best Regards, Thorsten.

In the past I requested to use gcc-arm-none-eabi-4_7-2013q3-20130916 for compiling MIOS32 applications to ensure that there are no unexpected incompatibility issues. This version is still recommended (although it's already 10 years old) and can be downloaded from: http://www.midibox.org/mios32_toolchain/ However, newer machines might not run with these binaries anymore, such as Apple Silicon based Macs. Therefore I tried the latest arm-gnu-toolchain-12.3 which can be downloaded from: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads and can confirm, that this version is working fine without adaptions :) Best Regards, Thorsten.

Under http://ucapps.de/mios_studio.html we can now find a re-released version for MacOS which natively supports Intel and Apple Silicon (M1, M2, ...) based HW without the need to run Rosetta2 This change required to switch to the latest JUCE 7.0.7 version However, there are no functional differences, and especially no new MIOS Studio features (currently nothing new planned for this tool) Best Regards, Thorsten.

I remember that I added STM32F1 support on a "good will basis" without continuous testing, therefore it's not officially available (means: you've to try it, and if it doesn't work anymore, roll back to a working version) Limitations: only 24k instead of 64k configuration memory (.NGC file) .NGR files are directly processed from SD Card and not from RAM, which means that such scripts are much slower - however, as long as NGR files are not processed by your use case, or only sporadically used, no real impact on the overall performance only 1 DIO port: // STM32F1: J5A+J5B // STM32F4: J5A+J5B, J10A, J10B // LPC17: J5A+J5B, J10, J28 only 6 (instead of 8) direct AIN inputs only 3 UART based MIDI IN/OUT (instead of 4) Best Regards, Thorsten.

It looks correct when I compare with the code, and actually it seems that the comment is wrong: // 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 should be: // BLM_X DOUT -> GP LED mapping // left/right half offsets; green,red // 0 = 9,8 1 = 11,10 2 = 13,12 3 = 15,14 // 4 = 41,40 2 = 43,42 3 = 45,44 4 = 47,46 So, 0 and 4 follow the same "swapped order" like other Duo-coloured LEDs. do you agree? Some additional hints: the relation between row M1..M8/column 0..7 and the 74HC595 output pins can be confusing - many people connected the pins in mirrored order in the past - be careful about that, otherwise the GP pin assignments have to be changed in the source code (-> you will need a local build). Wilbas schematic is a good reference in which order data lines have to be connected 1st and 2nd color (typically "red" and "green") can be swapped during runtime in the Options page for all other LEDs the assignment doesn't matter because they are free configurable in the MBSEQ_V4.HW file - you can try out once the front panel is working Best Regards, Thorsten.

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.