Jump to content

FantomXR

Members
  • Posts

    1,035
  • Joined

  • Last visited

  • Days Won

    22

Posts posted by FantomXR

  1. 1 hour ago, TK. said:

    I guess that you want to send text from one MIDIbox to the display of another MIDIIbox w/o the need to specify the text as hex numbers?

     

    No, not really. I want to send a text message from my DAW to the MIDIbox. ;) 

  2. Hey people,

    some of you already know that I'm very interested in getting the keyboard-handling as smooth as possible. Some of you also know too that the higher scanrate of the KB-app allows a much higher velocity-resolution than in NG. NG is very limited in this case and only allows a few (like 10-20) velocity-values. What I'm trying to achieve is, to modify NG in that way that the scanrate of the digital I/Os respective the I/Os where the keyboard is connected to is higher to get a better velocity resolution. The reason for that is, that NG allows a much easier way to modify the keyboard parameters and also due to the SD-card it's very easy to make a backup of your configuration. I had it now a few times, that (for whatever reason) MB_KB was reset. 

    So I took a closer look at the source code of what is going on under the hood in NG. As far as I can see the Period-Scanning is in both apps NG and KB 1ms. 

    I'd like to know what blocks NG to give the digital I/O scanning a higher scanrate. Are there any other routines running in background that I can simply disable if I don't need them? I'll do some test the next days but if anyone can give some hints on this, I'd be happy to read them! ;-)

    Thank you very much!

    Best,
    Chris

  3. Hey people,

    I have another question on this... I don't have any displays here to test... so I thought asking may be faster ;-)
    Is it possible to send pure text to the displays without converting them into hex first? If yes, how would this be done?

    Thanks!
    Chris

  4. I have another bug report. It's about the NRPNs. As far as I understand a NRPN contains at least three different CCs:

    CC#98 = NRPN number
    CC#99 = NRPN "bank"
    CC#6   = NRPN value

    So if I set nrpn=20, it sends CC#98 20, CC#99 0 and CC#6 depending on the value of the controller. If I go over 127, CC#99 changes to 1 and CC#98 counts again from 0. That makes totally sense. But! If I go over 256, CC#99 stays at 1 and doesn't count up to 2. 

    Or do I overlook something?

  5. I just noticed, that the cable that goes from PA2 to PA3 is equipped with a 220Ohm resistor. I do not use a buffer. So the only differences we have are the applications and the 1k pullup to 5V. I don't have the tools to build this small setup here. But I'll try to test as soon as possible. 

  6. There is only one cable that connects both cores. This goes from PA2 to PA3. It's about 10cm. But I didn't use a pullup. Just a straight connection. I will try with using the pullup (as the MIDI standard dictates ;-) ).

    Maybe it's a problem with combining different apps... we should check with TK. 

  7. On 21.12.2016 at 10:51 AM, TK. said:

    E.g. 10 times faster, which would mean that MIDI events are sent within 100 uS instead of 1 mS

     

    This is what I meant ;-)

    Alright... here is my result:

    I made a direct connection between two cores like @Zam suggested. PA2 to PA3. One core runs MB_KB, the second core runs MB_NG. The connection is in one direction only: Out from KB to in of NG. No optocoupler used here. 
    I opened the mios32_config.h like @TK. suggested and added the lines. I compiled different versions like Zam with 312k, 625k, 1000k. Of course the applications in my test run the same baudrates.
    First test was with 312.5k. Didn't test yet under heavy circumstances. Just tested if notes come through. They do... works good for now. Than I went over to 625k. Here it stopped working. When pressing my keys, the NG receives random pitchbends and program changes. Also the console says:

    [765645.838] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x20

    Than I tried to modify both applications and add a buffer of 255. But this didn't change anything. I didn't test another baudrate yet because if this is not working I don't think that higher rates will work. So for now my conclusion is: 10x speed seems to work fine. Above that it get's unstable in my environment.

  8. Thanks for checking that! I'll do a test with 20x speed and will check if everything works at my side! I'll report later today.

     

    @Zam: Thorsten wrote some posts above, that 10x speed means 1ms... so if you are at 20x it should be about 0,5ms. 

  9. 45 minutes ago, TK. said:

    Or do you mean LED rings, which are assigned to various banks, but not to the selected bank?
    Then I guess that they won't show the updated value until the assigned bank will be selected

    Yes. That's what I meant. Simple example:

    LED ring 1 CC1 bank = 1

    LED ring 2 CC2 bank = 2

    if my software now sends both values for CC1 and CC2 only the selected bank gets updated. The unselected bank doesnt. If I switch to the unselected bank it shows the old value. If I than turn the controller in my software, the LED ring jumps to this value. 

  10. 1 hour ago, TK. said:

    Are you using the set_lock command in your .NGR script?

    No, I don't use that. 
    Hm... strange. At least the LED rings do not update. I didn't doublecheck with the controllers itself. I'll investigate .... 

     

    Thanks for adding the load command!! ;-)

  11. Hey people,

    I have a question regarding banks:
    I have my workstation set up with different banks (see the other thread Story of keyboard build). The idea was, to assign the banks to different controllers in my live-host on my computer. So f.e. the first bank controls the volumes, the second bank controls the drawbars, etc.
    Now it's the case, that every patch in my live-host contains different settings for drawbars and volumes of course and when I select this patch all these values are send out by the live-host to the MIDIbox. The "problem" is that the MIDIbox only listens to that bank, that is selected and the other banks do not change their values. Is there a workaround for that so that the MIDIbox listens on all banks for value-changes?

    Thanks,
    Chris

  12. Dear TK,

    sure! It's not a problem now calling it manually :-)

    But I have another question: I have some LED-rings here and I'd like to use one of these LEDs as status-LED for the switch of the encoder. I configured the encoder like this:
     

    EVENT_ENC      id=1    fwd_id=LED_MATRIX:8    type=NRPN   chn= 1 nrpn=301 range=  0:127 led_matrix_pattern=1

    And the switch like this:

    EVENT_BUTTON id=101 hw_id=32 fwd_id=LED:1127 radio_group=1 button_mode=OnOnly range=1:1

    The switch itself is working but as soon as I move the encoder the switch-LED goes off. I thought it has something to do with the led-matrix-pattern. But as you can see the last LED is not adressed here:

    LED_MATRIX_PATTERN n= 1  pos= 0  pattern=0100000000000000
    LED_MATRIX_PATTERN n= 1  pos= 1  pattern=1100000000000000
    LED_MATRIX_PATTERN n= 1  pos= 2  pattern=1101000000000000
    LED_MATRIX_PATTERN n= 1  pos= 3  pattern=1111000000000000
    LED_MATRIX_PATTERN n= 1  pos= 4  pattern=1111010000000000
    LED_MATRIX_PATTERN n= 1  pos= 5  pattern=1111110000000000
    LED_MATRIX_PATTERN n= 1  pos= 6  pattern=1111110100000000
    LED_MATRIX_PATTERN n= 1  pos= 7  pattern=1111111100000000
    LED_MATRIX_PATTERN n= 1  pos= 8  pattern=1111111101000000
    LED_MATRIX_PATTERN n= 1  pos= 9  pattern=1111111111000000
    LED_MATRIX_PATTERN n= 1  pos=10  pattern=1111111111010000
    LED_MATRIX_PATTERN n= 1  pos=11  pattern=1111111111110000
    LED_MATRIX_PATTERN n= 1  pos=12  pattern=1111111111110100
    LED_MATRIX_PATTERN n= 1  pos=13  pattern=1111111111111100
    LED_MATRIX_PATTERN n= 1  pos=14  pattern=1111111111111101
    LED_MATRIX_PATTERN n= 1  pos=15  pattern=1111111111111101

     

    Do you know what I'm doing wrong?

  13. Ah okay! Is it possible to load another NGC by pressing a button? :)

    The reason why I ask: I now had a few times the strange behaviour that my default.ngc was partly overwritten by the "stock" default.ngc, that MIOS installs when no default.ngc is available. I don't know where that comes from. Using another NGC is just a workaround.

  14. Hey people,

    in this thread I'll post time after time updates about my latest keyboard build. Also I'll use this thread to publish eagle-PCB-layout-files and schematics. But please be patient. Uploading and documenting all that stuff is highly time consuming and it's right before christmas.

    So far everything works great, but the work under the hood was really time consuming because I used a lot of modules... some available from Tim, some I did on my own. I think modules are great if you need high flexibility... and all the modules are working perfectly. But if it comes down to save space and wiring, modules are a mess. Anyway... here we go:

    So I was tired using a laptop, a soundcard, tons of cables and all that stuff on stage. So I thought: What if I put the computer into the keyboard? It was quite successful. I used an Mini-ITX mainboard from Gigabyte, an i5-3570k (I'd go with a better i7 if I hadn't had that i5 before) with a low profile cooler. The mainboard is equipped with 16GB of RAM. Also I integrated two Samsung SSDs with 500GB each. The whole thing is powered through a Seasonic SS250U power supply. 
    As soundcard I use a PCIe card from RME HDSPe AiO. Because this only has two audio in/outs, I also bought two expansion-board that gives me another four in and outs. The first two analog-outs are going through a self-made DI-box with high quality LEHLE-transformer... absolutely great stuff. This DI-box features also a 20dB PAD and a GND-lift. 

    Let's hand over to the MIDIbox-side:
    I use two cores. One of them only takes care of the keyboard scanning. It was very important to me to not make a compromise on this. This core is connected via MIDI-out to the MIDI-In of the other core. Both cores are STM32F4 based. I used my own PCBs for that. @TK. Is it a problem if I publish those schematics and layouts for the core? I know that the official core is not published yet to cover the costs for PCB production and development. The PCB I developed only contains the connectors I need: it has J8/9, J19, J10A, J11 and J30 (as far as I remember... don't have it right in front of me at the moment). I tried to get a smaller footprint of the whole PCB. It also features a MicroSD-card slot instead of the SD-card-slot in the official PCB.

    My keyboard has nine analog faders build in... they are not motorized. I don't need that for now as they are much more expensive and also take more space. Also they are more difficult to wire up and connect. At first I did some tests with the AINSER8. But after a while I gave AINSER64 a try with the result, that it has less jitter than the AINSER8. The faders are a lot more quiet than with AINSER8. As I needed more than 16 analog inputs this was needed anyway. I power the AINSER64 through the core and the core receives it's power directly from the seasonic-power supply and NOT via USB.

    I needed some LEDs to visualize the status of my faders. A long long time ago I wanted to start another LED-fader-project but never finished it. So I had a lot of those LED-bars laying around... I took them and putted them into the board... works and feels great! On the next revision I'd try to use one big PCB for all 9 LED-bars to safe wiring and time for mounting. Now I used two 10pin IDC connectors (with only 8 pins of each are connected to the LED-bars = 16 LEDs). I did some mistakes when assembling the LED-PCBs... now sometimes some LEDs don't work... anyway... I can live with that for now.
    @TK. How about the WS2812 or APA102-LEDs? Do you think it's worth using them as LED-rings? I'm not sure what the status is and if they are supported in that way by MIDIbox. Would be a great alternative but they take a lot more space than 0603 SMD LEDs of course.

    The LED-bars are connected to small modules I did based on @novski designs. Those small modules are equipped with one or two DIN / DOUT modules. They work great and the advantage is, that I can stack them directly on the pinheader of the PCB... no cables needed! A bit hotglue and you are ready to go.

    I also have 8 encoders on each side of the keyboard. The right side is not connected yet... not sure if I do need so many encoders ;-) Of course they are also equipped with LED-rings. While the LED-bars where assembled by factory (I think I used SEEED) the encoder-rings came blank... so it took me a looooooong time adding 128 0805 SMD LEDs to all PCBs... at this time I had not have my reflow-oven... with this one that might be an easy task :-)
    The encoders (and the switches of the encoders) are connected to a 4xDIN board from novski. I'm not sure if this board really works well. Sometimes if I set debug on, MIOS lists tons of EVENT_BUTTONS. I'll need to investigate that. Maybe it has something to do with RC1 / RC2 lines.

    Underneath the faders I have a set of 2x8 buttons. I'm not really happy with them. I did the caps by myself and this was a really shitty work... next time I will use tact-switches that already come with caps f.e. TC011 like I did in the 1x8 button-row right in front of the player / underneath the display.
    For the buttons I designed a DIO-breakout-board. This breakout-board splits the matrix configuration of the 2x8 pinheader of the DIO-module to a more usable 2x5pin header-configuration with the row on pin 1 and the switch-lines on 3-10. With this way it's very easy to connect tons of buttons to a MIDIbox. . Same for the LEDs of the buttons. I used a DOUT-module with ULN2803 as LED driver (btw. I drive all LEDs with ULN2803 and do NOT use a resistor before or after the LEDs. As those LED-lines are scanned, a limiting resistor doesn't seem to be necessary). 

    That's mainly it... the keyboard has two MIDI I/Os on the back as well as four pedal connectors for two switches and two expression pedals. 

    The touchscreen in the middle is a 10" capacitive screen... that works awesome!!

    That's the story for now... like I said I'll try to keep this thread alive and add the PCB layouts and schematics later on.

    Thanks for reading!!

    Best,
    Chris

    Foto 09.12.16, 22 36 43-min.jpg

    Foto 21.12.16, 15 29 01-min.jpg

    Foto 21.12.16, 15 29 19-min.jpg

    Foto 21.12.16, 18 58 55-min.jpg

    Foto 21.12.16, 18 59 00-min.jpg

    Foto 21.12.16, 18 59 09-min.jpg

    Foto 21.12.16, 19 00 13-min.jpg

    Foto 21.12.16, 19 00 29-min.jpg

    Foto 26.11.16, 16 43 32-min.jpg

    • Like 2
  15. Hi TK,

    I try to load automatically another NGC file when the MIDIbox boots up. I tried to use a NGR-script which includes the load-command (like documented on ucapps). But if I do so, the terminal gives me the message, that the LOAD-command is no longer supported... hm... I remember that this worked some time ago...
    Is there any other command that replaces the load-command?

    Thanks,
    Chris

  16. Dear TK,

    yes! The only reason why I asked is the speed. I know.. 1ms is not much... but I try to save latency whereever possible. So if you could provide such a feature, that would be really great!

    Thanks,

    Chris

  17. Hey people,

    I have a keyboard that has two MIDIbox cores build in. It's because I use one running MB_KB for highspeed-keyboard scanning and the other one running NG for the controllers. So I'd like to ask if there is a way to chain those MIDIboxes without using a MIDI OUT -> IN - chain! 

    Thanks,
    Chris

×
×
  • Create New...