Duggle

Thanks for the hint! It caused me to look at the size of another queue in my app which made a difference. However it did not come fully good until I disabled debug messages as you suggested. I had been using #define MIOS32_MIDI_DEBUG_PORT UART0 which I didn't would be a problem but it clearly is/was. I'm now thinking about how I increase the (data buffer) capacity for debug messages. My app is not resource heavy and I'm using an F4 core, so there should be plenty available.

My MIO32 application is failing when the host computer sends too much USB sysex to my F4 core at application startup. I have tried to increase MIOS32_USB_MIDI_RX_BUFFER_SIZE to 0x400 and MIOS32_USB_MIDI_DATA_IN_SIZE to 128 (256 and the USB of the core basically stops working) This has not changed the behaviour... I'm not sure what I'm doing but I would like to increase the USB midi data rx buffer. Thanks for any help.

The usual way is to have the shift registers close to where their io is needed. This minimises interconnects and tracks. The high speed serial wires can be kept reliable and quiet with source impedance matching resistor on the clock line IIRC.

good now. WooHoo! thanks for the tip!

I'm developing a midi monitor that listens to 4 of USB MIDI Ports. So I'm using MiosStudio for debug messages on UART0. I'm made a code change to my app which has stopped USB from working (I changed buffer sizes). Anyhow, to upload fixed code I am trying to upload on the UART0 connection and I have always found that MiosStudio complains that it cannot contact the bootloader even though the query message always works. Is this expected? Is so is there a way to rebuild the bootloader to enable UART0 bootloading? I suppose I can reset the core using ST Link but I hope I don't have to!

Like I said the previous index of blue led is addressed. I'm not saying there's a bug in the repo, because I used it fine in the recent past. The problem affects both WS2812_LED_SetRGB(led,2,val), and WS2812_LED_GetRGB(led,2,val) i.e getting and setting the Blue led. To make things work right I have made the following changes to ws2812.c (to get me out of trouble...) if( colour == 0 ) colour_ix = 2; else if( colour == 1 ) colour_ix = 0; else if( colour == 2 ){ colour_ix = 1; led++; } else return -2; // unsupported colour i.e increment led for the blue (and only blue) LED. in both the Get and Set function. This is obviously a problem of my own making but I can't see what i could have done to cause it! :-)

I'm away from my usual development computer so I've set up all the tools on my laptop and compiled an app that I'm developing. In this new context I'm finding that the blue colour component is showing on the previous LED in the chain. extern "C" void APP_Init(void){ // mled.test(); // Initialise all LEDs MIOS32_BOARD_LED_Init(0xffffffff); WS2812_Init(0); WS2812_LED_SetRGB(10,0,100); WS2812_LED_SetRGB(10,1,000); WS2812_LED_SetRGB(10,2,100); So here we see LED #9 is blue and LED #10 is red. This also happens with WS2812_LED_SetHSV(..). I'm left with the fact that it seems to be a problem in the driver that wasn't in my other setup which I don't have access to ATM. Any help appreciated!

Thanks TK. That is understandable, It would be nice to have in this specific instance but straight forward to do without as well.

Using ENC command it is possible to specify which DIN pins of which Shift Register an encoder is wired to. Is it possible to do this with buttons? You see I'm assembling a large array of encoders that have push switches, and to rationalise (neaten) the wiring I would like the encoder pins and its push switch pin to use adjacent pins on the DIN Shift Register(s). Thanks for any hints!

That's great news. I suspect the problem I have between GM5 and Midibox NG is something different. I'll need to revisit it. Do you know which field(s) need to be different between the 2 cores?

AFAIK the solution is not so simple as changing some data in the bootloader, but I can be wrong.

I have had a very similar problem between a midibox core and my GM5 under windows 7 that I never solved. Also had the same problem under windows 10 IIRC. Seems really sad to have to buy a new USB OEM midi interface if I want to connect a midibox on the same computer! Sorry I can't help, but I would love a fix for this also...

OK, I've stripped the alternate ngc to the absolute minimum: RESET_HW LCD "%C" ENC n=1 sr=5 pins=0:1 type=non_detented EVENT_ENC id= 1 hw_id= 1 fwd_id=LED_MATRIX:17 bank=1 fwd_to_lcd=1 chn=2 type=CC range=0:127 offset=0 ports=1000010000000000 led_matrix_pattern=3 cc=17 offset=-64 syxdump_pos=1:17 label="^Osc1Shp" Encoder #1 outputs data on CC#17 on channel 1. Any help appreciated.

Hi, thanks, yes there is: ROUTER n= 1 src_port=IN1 src_chn=17 dst_port=OUT2 dst_chn=17 ROUTER n= 2 src_port=IN2 src_chn=17 dst_port=OUT1 dst_chn=17 ROUTER n= 3 src_port=IN3 src_chn=17 dst_port=OUT4 dst_chn=17 ROUTER n= 4 src_port=IN4 src_chn=17 dst_port=OUT3 dst_chn=17 ROUTER n= 5 src_port=USB1 src_chn=17 dst_port=OUT2 dst_chn=17 ROUTER n= 6 src_port=IN2 src_chn=17 dst_port=USB1 dst_chn=17 Nodes 5 and 6 are the only ones that are important at the moment. The value 17 means all channels passed and none translated IIRC.....

I'm talking about MIDI events channel number, not ports. In the config, as shown above, the CC should happen on midi channel 2, but its seen to be on channel 1.

I'm loading an alternative NGC with all controls set to channel 2: here's an example: EVENT_ENC id= 5 hw_id= 5 fwd_id=LED_MATRIX:25 bank=1 fwd_to_lcd=1 chn=2 type=CC range=0:127 offset=0 ports=1000010000000000 led_matrix_pattern=3 cc=40 syxdump_pos=1:40 label="^Fil1Freq" I'm only seeing events on channel 1 on MiosStudio as well as the synth and also on midibox SCS midimontor. My first thought was the channel is being overridden by a global setting but the manual says this feature is not implemented yet. Has anyone noticed this issue?

Following on from this discussion some time ago: I'm wondering whether perl is still the recommended language for such a purpose. What about python, or any others? The M4 language is pretty archaic (could be called a "dead" language). It has served it's purpose but to continue working with it seems a bit naff when I could learn something with a whole lot more potential. For example it cannot do things which then require external executables such as sed and dos batch files etc. Gets messy. I'm imagining something that would make working with large configuration projects more manageable plus be cross platform...

LOAD <setup> Switch to another setup (.NGC, .NGS, .NGR, ... files) So <setup> is filename without extension and all .NGC .NGR, etc that match will be loaded?

So is it possible to load an alternative .NGC from a run section in an .NGR? Thanks

Is it supported to have the channel of a CC (or Polypressure) event represented by a variable. The application is to be able to change the channel destination of an encoder CC event to a different voice in a synth editor. It is possible to adjust the same parameter with a sysex short message where the voice is addressed by a part# field in the sysex string but it will mean a lot of work (re)writing a very large configuration. What about port? What would be the way of selecting a different port for messages. The application is to have another same kind of synth on an alternative port (e.g Virus B on Uart1 and a Virus C on Uart2) and switch the editor between them.

It should be quite doable to convert this project to F4. I have some of the old core32 board, so I could build the original project to test it. I would have to build the interface circuit like what you posted. I could then adapt it for the F4 which I also have. Like you, I have other projects so this would have to wait some time for me to progress it. My thoughts are to buy an RGB LED lamp (50Watts or similar) from Ebay which are pretty cheap. The idea I have is to create an application so that the LED lamp shines the colour of the selected track from an Ableton Live session to enhance a live performance. If I get time to spend on understanding the similarities/differences in peripheral libraries re uart, I shall post back to this thread.

I don't have time to research things. I do have an interest in a Midibox DMX controller but I have other things to do atm. So all I can do to try help the effort is suggest the kinds of things that I would do if I was undertaking your task. If you want the code to run on an F4 that was implemented on an F10x then make sure the low level peripheral libraries are compatible (ie the same) or what the differences are. The fact that the only compile errors relate to changed constants indicates the underlying hardware has differences. Usually the newer chip has enhanced functions that the older chip's peripherals don't support so the names of constants get changed to cater for the more diverse functionality offered in the newer microcontroller. Rest assured that the newer chip will be able to do what the older chip does in a very similar if not identical way. You may be able to identify the constants that provide the same functionality (with slightly different text/spelling) in the peripherals as the old one. These will be found in the equivalent headers that support the F4 instead of the F10x.

You would need to set the appropriate environment variables for the F4. Make sure the midi uart is different from the DMX one. Have you tried to build?

Please bear in mind that in 2009 there was only one "core32" which was the STM32F10x. (I can see from the image of J11E above that you are looking at an F4). This implementation uses low level library routines to access a uart for the DMX port. In your case this would have to be adapted (presumably to F4 that you want to use). Unfortunately I don't think STM32F10x midibox core PCBs are available anymore. If you are a very keen constructor and a have a JTAG interface for programming a bootloader you can buy chips and chip carrier PCBs (at very low cost) and make your own core circuit board. In this app there isn't much I/O to connect so the board would not be overly complicated. Sorry I cant help any more than this.

This a mios32 app not a midibox ng configuration. It doesn't use midi UART but analog ins (faders) to control DMX channels. The DMX module seems to use uart1 for dmx. So basically get your DMX channel data from midi events on another midi UART(instead of analog Ins) and transmit via the DMX module just like the example.