Frequent Writer
  • Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Duggle

  • Rank
    MIDIbox Guru
  • Birthday 01/01/1970

Profile Information

  • Gender Not Telling
  1. [SOLVED] Multiple MIDIbox cores in windows

    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?  
  2. [SOLVED] Multiple MIDIbox cores in windows

    AFAIK the solution is not so simple as changing some data in the bootloader, but I can be wrong. 
  3. [SOLVED] Multiple MIDIbox cores in windows

    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...
  4. Global MIDI Channel

    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.
  5. Global MIDI Channel

      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.....
  6. Global MIDI Channel

    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.  
  7. Global MIDI Channel

    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? 
  8. script code generation

    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... 
  9. MIDIbox NG Release + Feedback

    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?
  10. Set variables question

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

    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.
  12. Midi-in-Core > DMX-out Converter

    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.
  13. Midi-in-Core > DMX-out Converter

    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.
  14. Midi-in-Core > DMX-out Converter

    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?  
  15. Midi-in-Core > DMX-out Converter

    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.