Jump to content

Zam

Members
  • Posts

    625
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by Zam

  1. Hello

    Baudrate setting is a mios32_uart.h

    But you obviously need to change this at both side of the wire, so won't work if you have a hardware synth where you can't change this setting. (31250 is a midi compliance)

    Only useful if you hook two midibox devices and you want to gain some data speed/density

     

    Have you try to change optocoupler ? I have vague memory to read around some issue with. But don't remember the context.

     

    I also notice timeout error in my early mios experimentations when the core is really busy.

    like lot of data IO stream, which can be exponential if you have the debug on at the same time

    Have you tryed sending/receiving the sysex message with minimal activity around (no other midi message, no event value change, no NGR script runing)

     

    Just another guess, but what is the data a your pos 52 ? maybe it's a conflict with some MIOS terminal command ?

     

    Best

    Zam

     

  2. Hello Micha

    Not a direct answer, but some observation at my side.

    I'm used to this time out message when in the past I play around with midi baudrate speed (for multicore direct connection in a project)

    what is sure is you need same RX/TX speed at both side of the midi wire, I suppose that's not your issue,

    but I also notice that wire length can have impact, in other hand the TX/RX quality and potential data lose.

    In your case I suppose you have optocoupler, investigating that side of hardware and data integrity might be an option.

    Best

    Zam

  3. Hello

    You can load files with LOAD command in .NGR

    And you can call the section with load command via an event in .NGC (meta=runsection) which can be a button.

    Now if you use let say an encoder with value change or a radiogroup button you can define a value to a dummy LED (NGC), value that can be the condition for each config you want to load.

    if value =1 load X

    if value =2 load Y

    You'll have to do this at all .NGC/.NGR you'll hypothetically load, to be able to "navigate" from and to each config files

    Best

    Zam

     

  4. Hello

    For some dedicated purpose I'll like to activate a DOUT pin depending of some midi activity.

    In fact lit a led if there is no incoming pitchbend data since 1 second, an turn it off as soon as new incoming data happen

    I think I can do this with NGR script, but as the script will run all time it's not an viable option (I have other run section in my NGC), I'll give it a try and see if I can accept script interruption.

    I don't see right now how it's possible with NGC only as I need a delay/timer, if someone have an idea ?

    Best

    Zam

     

  5. Use the material you want for the visual finish you want ! row alu is ugly for front panel and easy to scratch...

    I'm just saying this in the manner that you should anticipate your enclosure design and be sure all metal part have good electrical connection between them, a recessed screw or countersunk head screw that fix front panel to frame should be enough (as milling will remove the surface anodization )

    "basically" your pcb 0V should be hooked at one (and only one) solid screw at the frame (common ground), preferably close to the main entry, where you also connect the safety earth ground from the (close) main connector.

    In your particular usecase I think fader screw mount (countersunk) will do the job to connect fader metal can to common ground.

    Your fader 0V audio should not share the fader box common ground, it's already connected at console rack module via trace, pcb and local chassis common ground.

    Try to imagine the audio part of the fader as an isolated extension from outside the fader box.

    Best
    Zam

  6. Hello Zeke

    Good you find solutions to your problem

    It seem (I can be wrong) that you misunderstood  the concept of ground, the thickness of a case have noting to do with it, I suspect in your fist attempt you just connect together your Vref (0V here), fader can and metal case, without path to safety/earth ground, meaning everything stay floating. As soon as you connect all this to rack frame you create a path via rail and other equipments, I suggest your fader rack get it's own path to main ground to not interfere with other equipment (otherwise parasitic current might flow trough them)

    technical note: powder coating as anodization (surface only) are non conductive !

    for example you have to mask before coating or scratch surface after, if you want proper conduction between metal part in rack assembly.

    Best

    Zam

     

  7. OK, to be more constructive...

    I just have close (zoom) look at your last picture with all the faders

    Be sure to not share fader 0V at your sub25... each fader should have it's own ref closest as possible to buffer ref

    Are the fader actually connected to console ? you should reduce at maximum the wire length

    I suspect the whole digital side (MF_NG) is currently floating ? I'll definitely put a path to chassis ground/earth.

    100n across motor leg should improve a little current peak.

     

    As a global rules, as it is for console integration, I'll suggest to build the thing as close as possible to final integration, to minimise bad surprise at the end as loosing time to fix issue that will not happen in the proper frame/mechanical integration.

    Best

    Zam

  8. 4 minutes ago, Zeke said:

    code? :cry:

    yes.. for this you have to go one programming layer lower in the system ...

    as for the great map/table that @TK. add by the time for the PIC/MIOS8, which offer possibility to "match" DAW fader value to real fader attenuation :happy:

    Best

    Zam

     

  9. Hello Zeke

    So...lot to say...welcome to the real world of digital electronic...

    Have a search here, I talk a lot about this 4 or 5 years ago, that's why I give up the PWM driver and design an analogue PID motor driver.

    You'll have to try to chassis ground fader metal part to minimize EMI leaking and motor sparkle

    IIRC the SR scan at 1kHz for the touch detection also give me ugly noise at audio side, I partially solve this by lowering the refresh scan to 30 or 50Hz (which still fast enough for most situation)

    Fader construction might also have impact of digital lines leaking to audio trace/wire. As how 0v audio is hooked at fader buffer side (that's another whole topic and maybe not the good place here to talk about)

     

    Your recorded noise look like PSU hum and harmonics ?

     

    Noisy supply + noisy digital lines + fast H-bridge switching + Motor EMI emission.

    This is lot of tricky topic to solve if you want to put all this in analogue desk.

     

    Best

    Zam

  10. Hello Zeke

    Again check ref (servo) voltage stability, what voltage do you send to the board ? IIRC vref is 5V standard regulator, you need 3 more V to ensure "proper" regulation and minimum ripple

    What happen if you disconnect motor (EMI suppression) ?

    With HUI protocol, there is a constant call to ensure device is connected, C2 might be this ?

    Don't remember how the upload to the PIC is done in MIOS studio.

    Best

    Zam

     

  11. Hello

    Seem you have Vref and servo track instability/jitter.

    Check servo voltage.

    What is your fader ? how it is connected ? did you hook the motor ? if yes did the physical fader jump too ?

    Not sure 100% how it is handled at MF_NG code, but IIRC data transmission should run only when fader touched (for obvious reason). No touch connected might cause issue ?

    Best

    Zam

     

  12. Hello and welcome here

    16 hours ago, Zeke said:

    J1 is the power inputs I can't tell which is positive and which is negative. I looked at the schematics and I think that the left pin is positive and right pin is negative. is this correct? (see attached pic)

    The pcb you show have rectifier and regulator, so the input is AC

    16 hours ago, Zeke said:

    Also, I'm not sure which is the positive side for the LED. I assume its the left also. (see attached pic).

    anode is positive, the silkscreen seem to show it on the left, as you assume

     

    16 hours ago, Zeke said:

    is the LED status of the board being powered on or does it blink for midi transmission? 

    I don't remember well but I think it's connected to a pic output, so should show some activity.

     

    Have a search, @TK. work on a wireless PIC replacement for this board , also @Antichambre have a super small STM32 board with PIC pinout compatibility IIRC

    should not be that complicated (for those who know how to) to make this MIOS8 app running on MIOS32

    Best

    Zam

    • Like 1
  13. Hello

     

    On 08/11/2018 at 11:49 AM, FantomXR said:

    And this is the NGR part:

    
    if ^section == 1 
    
        delay_ms 500
    
        if BUTTON:1 == 127
          SEND CC USB1 1 1 127
          exit
        endif
    
        if BUTTON:1 == 0
          SEND CC USB1 1 2 0
          exit
        endif
    
    endif

    This code wait's 500ms and checks if the button is still pressed. If yes it sends on channel 1, if not it sends on channel 2.

    You can reduce the time for the short push to only wait the processing when long time press

     

    if ^section == 1 
    
        delay_ms 50
    
        if BUTTON:1 == 0
          SEND CC USB1 1 2 0
          exit
        endif
    
        delay_ms 500
    
        if BUTTON:1 == 127
          SEND CC USB1 1 1 127
          exit
        endif
    
    endif

    By this you can handle both situation time in any time respond configuration you want

    Note that first condition will in fact be the time you manually release the button (if shorter than second delay) + the first delay as the script will re-trig when button is off ( due to button_mode=onoff)

    Best

    Zam

     

  14. Hello

     

    1 hour ago, ssp said:

    If i have a series of values i want to control from 3 knobs, so there are two lines of values, and 8 on each line, what i want to do to reduce the amount of encoders is have one for moving in the y direction between line 1 and line 2, then one to move in the "x" direction to step between 1 to 8 in the line, then a final encoder to change the value of the selcted cc#.

    Is it possible to do this in the .ngc?

    Don't know if you can do this without a script (NGR) to handle the 8 possible two CC toggle (equivalent to Y axis in a 2x8 pattern)

    You can maybe simply with toggle scan X(16,17...23,24, 31,16....) and Y (16,24,17,25....31,16...) with 2 MAP

    But in a strict "user friendly" interface I personally won't use two encoder to select data in a 2x8 matrix display (for a 8x8 OK...)

    A single continuous scan will be as fast for only 16 slot (assuming you can go both direction, most distant data is only at 8 encoder tick) , OR you can use the encoder button to switch X/Y scan axis

    Only two encoder, data and value

    Best

    Zam

  15. Hello

    The purpose is to have on up and one down button cycle trigging 0 21 41 61 81 with dedicated led for each steps right ?

    Maybe a script(runsection + .NGR) will be better strategy, especially to retrigg/update the "opposit" button value to match actual CC value

    Otherwise you push button 1 few time (let say 2, CC val=61) but button 2 stay at 0, and if you push it once you send 21...

    Best

    Zam

    • Like 1
  16. Hello

    All your sender have same id...

    Define hw_id=1 for all event AND id=100..101..102... (or whatever numbering strategy you choose)

    Don't know if it's the reason of your issue (but it might, same events with different conditional may behave strange and conflict...), you better make a correct config first :decayed:

    Best

    Zam

×
×
  • Create New...