TK.

Hallo, die PitchBend Events werden gesendet, weil die analogen Eingaenge an J2 noch nicht angeschlossen wurden. Alle ungenutzten Eingaenge (A0..A7) muessen auf Masse (=Vs) geklemmt werden. Nun moechtest Du jedoch den ersten Eingang A0 nutzen, also nur A1..A7 auf Masse. Fader Pinbelegung: J2:Vs auf Pin 1 J2:A0 auf Pin 2 J2:Vd auf Pin 3 J14:T0 auf Pin T Gruss, Thorsten.

I've improved the math calculation handling a bit. It's not relevant for that what you are doing, but could be helpful for others in future. Update to v1.032_pre2: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip Now you can add spaces between operands and operator, such as: [LED:2000 / 128] to make the code more readable. And even nested operations are possible, such as: [LED:2000 + [LED:2001 + [LED:2002 + LED:2003]]] Something that could be even more interesting for you is the new "SRIO num_sr=<1..32>" parameter. It allows to reduce the number of scanned shift registers. E.g. let's say you've connected 4 DIN SRs and 2 DOUT SRs. The longest chain are the 4 DIN SRs Accordingly you can set: SRIO num_sr=4 Now your keyboard will be scanned 8 times faster than before! :smile: Best Regards, Thorsten.

I just have added a new parameter to the .NGC file. Just upload this prebuilt binary: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip Now you can reduce the number of scanned SRs with (for example): SRIO num_sr=4 in your .NGC file Best Regards, Thorsten.

Hi Mathis, yes, your assumptions are correct. I just noticed that the number of scanned SRIOs isn't configurable. By default, the MBNG firmware will scan 32 DIN and 32 DOUT shift registers with each update cycle, but I guess that you don't use more than 4 DIN shift registers, which means that if the number would be configurable, so that only 4 SRs are scanned, you would be able to scan the keyboards with an update rate of ca. 0.5 mS You could already try this out by changing the MIOS32_SRIO_NUM_SR value in src/mios32_config.h Best Regards, Thorsten.

First you have to change the value limitation to allow a value entry in the range of 0..255. In the different sections you will find "if" conditions which check for certain numbers, e.g. in section 1..7 it's checked that the value is <= 12 Why? because we want to ensure that it isn't possible to enter a value > 127. A program change ranges from 0..127, values above this range are invalid. Example: If somebody would enter '1', and then a '3' (-> 13), an additional '1' would result into 131 -> invalid value! Therefore only <= 12 is allowed. Now you've to change it in a way that value between 0..255 can be entered, and all other values are blocked. To give you some hints: for ^section 1 it will be <= 25 ;-) Once you are able to enter values between 0..255, replace the MIDI event sending code by: # EXEC button if ^section == 11 # valid number? if LED:2001 == 1 if LED:2000 < 128 # Bank 1 send CC USB1 1 32 0 # Program Change send ProgramChange USB1 1 LED:2000 else # Bank 2 send CC USB1 1 32 1 # Program Change # modulo operation: ensure that PC value is in range between 0..127 send ProgramChange USB1 1 [LED:2000 % 128] endif # next entry will reset the number set LED:2001 2 endif exit endif This could also be simplified with: # EXEC button if ^section == 11 # valid number? if LED:2001 == 1 # Bank = value / 128 send CC USB1 1 32 [LED:2000 / 128] # Program Change # modulo operation: ensure that PC value is in range between 0..127 send ProgramChange USB1 1 [LED:2000 % 128] # next entry will reset the number set LED:2001 2 endif exit endif This code is untested - in case of errors, please first try to debug this by yourself! Best Regards, Thorsten.

Yes, it makes sense to do experiments with the given possibilities. Well, it's limited because in a "Note" MIDI message we can only differ between 128 different notes per channel. Has your keyboard really 256 keys? Or is this because of the unusual matrix mapping... or are we speaking about multiple keyboards? Btw.: since it doesn't provide velocity anyhow, you could alternatively handle it like a common DIN_MATRIX, which gives you a bit more flexibility. E.g. it allows to define individual EVENT_BUTTON for each key, so that you can define dedicated note numbers and MIDI channels. Best Regards, Thorsten.

Yes, you can now add similar commands for any other value, just store them into different LED:xxx numbers (the LED event actually acts as some kind of memory, resp. variables). Then you could also use another LED:yyy to switch the keyboard between the different selection modes. It will result into a lot of "spaghetti code" (.NGR is no elegant programming language, but just a dumb command interpreter), but you will be able to implement this with the given functions. Best Regards, Thorsten.

Hi Mathis, there won't be a generic solution for such a special scrambling, but I could add a simple note mapping function similar to the velocity mapping into the firmware as demonstrated here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fkb_2.ngc Would this solve the problem? Then I could enhance the firmware by this function quickly. Best Regards, Thorsten.

Hi, you could use a MBHP_CORE_STM32F4 + MBHP_MIDI_IO module + a USB Micro-B -> USB 2.0-A adapter See also Best Regards, Thorsten.

This is probably the most tricky script that I ever wrote so far ;-) Try this version: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre1.zip It supports math operations in a .NGR script! :shifty: Configuration example: .NGC: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngc .NGR: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngr .NGL: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngl You can either use buttons connected to DIN shift registers, or you could use a real keypad connected to DIN/DOUT in a suitable DIN_MATRIX configuration (not shown in this example, but it shouldn't be so difficult to configure this...) Best Regards, Thorsten.

Hi, just to ensure: are you using a keyboard with break contacts? If not: please turn off the velocity option with "scan_velocity=0", otherwise no MIDI event will be sent as long as the corresponding break input isn't activated. Best Regards, Thorsten.

Ok, I added some messages, please try this version: -> http://www.ucapps.de/mios32/midibox_seq_v4_086_pre1.zip VelN and VelA will be displayed if the drum track has no velocity layer, but an accent layer VelA (but not VelN) will be displayed if the drum track has a velocity layer and an accent layer Neither VelA nor VelN will be displayed if the drum track has no accent layer If you try to modify a hidden value, a message will inform you about the reason. (please check if they are always correctly displayed) @Gridracer: I also added the "MIDI Learn" function. Press GP12 button in the EVENT page on a drum track. Incoming Notes should modify the drum note The appr. port and MIDI channel has to be configured in the RECORD page (I think it makes sense to use the same configuration for this purpose) I've implemented the MIDI Learn capability in a way that it will be very easy to add similar functions to other pages in future - your input is welcomed! :) Best Regards, Thorsten.

Hi, O1..O6 can be selected under the "VAs" option, see also http://www.ucapps.de/midibox_sid_manual_m.html where you will find the explanation for additional assignments, such as LR, L-, -R won't really work (resp. this will generate funny settings). You would have to assign one instrument to the left SID chip (O1..O3), and the other instrument to the right SID shift (O4..O6) Thats exactly the intention behind the VA (Voice Assignment) rules For a polyphonic sound you would prefer to assign the voice to all voices of the left SID (L-) or right SID (-R), so that up to 3 voices can be played in parallel. Best Regards, Thorsten.

This is not related to a bug, it's a configuration issue. In order to use VelN and VelA, you need a second trigger layer which controls the accent. So, "T" must be 2*64 or 2*128, there are only two configurations for this. In addition, you've to ensure that the parameter layer doesn't control the Velocity (set LayA to Roll or something else - on a freshly initialized track it's Roll) I think that I should hide VelN and VelA (and print a warning instead) whenever these parameters have no effect. Best Regards, Thorsten.

It's not related to a hardware limitation, but due to special software which is required to establish the connection to the hub and to enable the device ports. This isn't straightforward, but it's on my mid term agenda (of course, I would be interested to use a hub as well...) Ok, I will check this sooner or later. My focus was on the SW side, not so much on the HW side yet Best Regards, Thorsten.

It doesn't matter if buttons are directly connected to DINs, or buttons of a keypad matrix would be used - some special routines are required which are not part of the firmware yet. I need some time to find a generic solution for this. E.g. if the .NGR language would allow arithmetic operations, such as the modification of BCD-code digits of an element, then this would satisfy your request and could also be used for other purposes. Best Regards, Thorsten.

This would require some special routines which are not available in the MBNG firmware yet. I fear that there are too many different keypad types which would need to be supported :-/ Best Regards, Thorsten.

I like this idea of a MIDI learn function - added to the Wishlist :smile: In addition following ideas come into my mind: - when you move the GP12 encoder, the note will be played shortly (this will be an optional feature, because some people won't like this) - if the parameter layer of a note or CC type track plays a CC line, GP12 button allows to set the CC from an external keyboard/controller - in EDIT page, select a step with the GP button and the incoming notes, CCs, Pitchbend, etc. will be recorded into this step. Will also allow polyphonic recording like known from the RECORD page and MBSEQ V4L - again this will only be an optional feature, because the external keyboard might be used for playing the instrument of the same track live. Best Regards, Thorsten.

Great that you got it working, looking forward for playing around with your synth app! :-) I gave you access to the Programmers Lounge where you can find more informations about the projects. VBUS: this is what I copy&pasted from the STM32F4 implementation example into mios32_midi.c - it seems that external components are required: void USB_OTG_BSP_DriveVBUS(USB_OTG_CORE_HANDLE *pdev, uint8_t state) { #ifndef MIOS32_DONT_USE_USB_HOST /* On-chip 5 V VBUS generation is not supported. For this reason, a charge pump or, if 5 V are available on the application board, a basic power switch, must be added externally to drive the 5 V VBUS line. The external charge pump can be driven by any GPIO output. When the application decides to power on VBUS using the chosen GPIO, it must also set the port power bit in the host port control and status register (PPWR bit in OTG_FS_HPRT). Bit 12 PPWR: Port power The application uses this field to control power to this port, and the core clears this bit on an overcurrent condition. */ if (0 == state) { /* DISABLE is needed on output of the Power Switch */ GPIO_SetBits(GPIOC, GPIO_Pin_0); } else { /*ENABLE the Power Switch by driving the Enable LOW */ GPIO_ResetBits(GPIOC, GPIO_Pin_0); } #endif } UART (MIDI port) assignments: I can't use STM32F4 USART0 and USART1 because the appr. pins are allocated by other functions. Therefore the MIOS32 specific UART0..3 mappings don't match with the hardware indices. MIOS32 UART2 I even had to use two different USARTS for IN and OUT. See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmios32%2FSTM32F4xx%2Fmios32_uart.c Best Regards, Thorsten.

It isn't so easy to remove menu entries from the main page, but I came to a better idea: a configurable MENU page where you can define the shortcuts that you need. In conjunction with the bookmark page (press MENU+SELECT) you've up to 32 customizable short cuts for the different pages now. So: Topic 1 is implemented Topic 2 is partly implemented (although not like requested, but very useful for most people) -> in V4.085 Best Regards, Thorsten.

Your .syx file works w/o data loss at my side, regardless if send via USB or traditional MIDI. However, I remembered that I wanted to add an optional delay function, because I know that some synths (including MBSID and MBFM) need a delay between the SysEx messages in order to store the received payload before the next message is received. This function is now available in V4.085 - and a little bit more ;-) From the ChangeLog: MIDIboxSEQ V4.085 ~~~~~~~~~~~~~~~~~ o it's now possible to customize the MENU short cut page in MBSEQ_HW.V4 with the new MENU_SHORTCUT parameter. See the templates under hwcfg/*/MBSEQ_HW.V4 for further informations. o the bookmark configuration files (MBSEQ_BM.V4) are using the same page names like MENU_SHORTCUT instead of numbers. The old number scheme will be automatically converted to the new names. o improved keypad (SMS-like) entry of names o SysEx device page allows to specify a delay between SysEx messages which is used when a .syx file contains multiple dumps o each SysEx device page has now a dedicated port/delay configuration which is stored/restored from the /SYSEX/<device>/DEVCFG.V4 file Best Regards, Thorsten.

Ok, so it seems that it works unintentionally - I hope that you won't get an endless feedback, because there is no feedback detection implemented. Best Regards, Thorsten.

I will check the SysEx issue soon - thanks for providing the file! Best Regards, Thorsten.

You've to update the complete repository, not only the application directory. If this doesn't help, download the complete repository into a new directory (maybe you did some local changes?) Best Regards, Thorsten.

The project is in hypersleep mode so that it survives the long journey to a really cool synth for our next generation :rofl: Best Regards, Thorsten.