Zam

Members
  • Content count

    554
  • Joined

  • Last visited

Posts posted by Zam


  1. Just now, Antichambre said:

    really? then how do you get the position from the faders?

    By using highend dual track motor fader with one servo track (linear taper) and one audio log track :rolleyes:

    Best

    Zam

    1 person likes this

  2. 29 minutes ago, Thomasch said:

    My english is not the best, , so what means 15/100 error at tangent?

    sorry, I mean 15/100 millimeter, If you draw a (quarter) circle of 1mm diameter inside a 90° angle

    44 minutes ago, Thomasch said:

    Because of tolerances a little bit of gap between hole and LED might be necessary. Just enough, that it don't needs any force to slide the LEDs in.

    That's what I say, add 3/10 mm and you'll be fine for a soft mount, dust won't come in that much and aestheticly it's not noticeable

    Best

    Zam


  3. 42 minutes ago, piepermd said:

    So that is the actual app that you posted 8/30/17?

    yep... almost two years back :decayed: (thinking about one)

    but more precisely, this is not the app (.hex) but the change in code.

    You can copy/replace that at the correct place, IIRC the only change I made to "fake" raw dual CC as NRPN (note that standard NRPN won't work any more but HUI don't use it) I can also provide the compiled app which should be based on NG1.035 or 1.036 (don't remember what's up at that time), so not up to date regarding newer implementations.

    Best

    Zam

    ps: I sent you an email earlier today

     

     


  4. 19 minutes ago, piepermd said:

    I might also order a TKD MF-9101 A to see how I like it

    That's the replacement of my MF914, same CP track with slightly different mechanical... this is very good fader !

    Just check twice mechanical room in the MCI... TKD have motor at top (or bottom) and not below like ALPS (which make the fader short)... that's the only advantage of the ALPS, compact size!

    25 minutes ago, piepermd said:

    One thing that I don’t understand yet- will I have to write my own code for HUI handling of mutes and automation read-write and run that with MB_NG on a separate core? MF_NG and it’s application are strictly for motor control of faders, correct?

    MF_NG  only handle fader data and touch with various protocol, including HUI when used via DIN5

    If you want extra button and led (DIN/DOUT) you need MB_NG and core32, as connect MF_NG to core where you lost the HUI option (MIOS32 don't handle as is the HUI raw midi "double CC" data) this is more or less what I design except the linear motor driver in place of the MF_NG PWM driver

    I have compiled a special MB_NG app which handle HUI data, as config files (.NGR .NGC) for it, but I don't look into this since a year I think... I have no issue to share this files, but there is no "official" support for it (nor extensive and long run test)

    Best

    Zam

     


  5. 14 hours ago, piepermd said:

    I am working on a “flying faders” type retrofit for my MCI 416A console to use with Protools. So far I have an Alps dual track fader working with the MF NG module, and I have nice two-way fader communication with Protools but have not tried to pass audio through the fader yet. I understand my biggest challenges will be noise in the audio from the fader control system and the implementation of mutes and automation read/write from the hardware fader. I thought your system might work for me, but I realize you are not using Protools...

    Feel free to email me at pgpieper@yahoo.com

    Hello

    Before going further you have to fit the fader in the console and test audio with it...

    You'll see if FM_NG work for you regarding noise, both EMI and sliding (from my experience the cheap ALPS  with carbon track have lot of wiper sliding noise)

    As already say I was able to use HUI protocol (special MB_NG compilation to handle HUI dual CC which is not NRPN ), but not tested with PT. I also test long time ago (don't remember details...) to run the system in MCU and use miditranslator to convert the data to raw midi HUI (wile the DAW set to HUI) which worked.

    Anyway, my system is way more expensive than a MF_NG + alps fader, so if what you achieve with this setup fit your need you better stick with it.

    Best

    Zam

     


  6. 3 hours ago, Thomasch said:

    But i realized quickly, that traditional CNC milling will always make rounded edges on the cutouts in the panel, with the size of the diameter of the milling tool.

    The "round" with 1mm milling tools represent 15/100 "error" at tangent

    also, 5x3mm milling for 5x3mm LED will probably not fit, you need anyway little room for "soft" mounting

    5.3x3.3 mm cutout with 1mm tool (0.5mm round at corner) is fine and you'll probably never notice 15/100mm room around the led.

    Then there is the option to mill "inside" the corner, don't know the name of this technic, but it work too, close to unnoticeable by eyes with 1mm tool

    Best

    Zam

     


  7. 11 hours ago, piepermd said:

    Are you selling the PCB for the project?

    I have one spare set (for me...) left , and I don't plane to sold blank pcb anymore

    What is your need and for what purpose (console retrofit ?)

    We can discuss further via PM and mail

    Best

    Zam

     


  8. 14 hours ago, weasel said:

    @Zam would you mind shedding some light on your midi router/merger thing? i see you keep calling it USB midi, but if i just hijack the J11 pins to connect boards directly, it still is UART midi right? i would enable the second set of 4 midi ports in NG events?

    I have a 3 cores "chain"

    one master to/from computer and DAW via USB midi (4 port enabled)

    Two slaves, both connected to master via direct J11 connection, uart midi (same PSU and short cable).

    Using NG, master have global router function enabled, UART1 to/from USB2 and UART2 to/from USB3, USB1 being master

    I also have few special routing at master (via sender/receiver) to handle functions that I have at slave HW and requested as master events (USB1) for DAW (like transport)

    So my computer/DAW see 4 midi USB port at my "MCU device", my DAW talk with each one and the master core handle routing to slave


    Best

    Zam

     


  9. Thank's Bruno

    I'll look at soft when it's time, for the moment I'm at the schematic, pcb not designed yet.

    But this definitely make me decide to implement AINSER to scan the time constant CV, whatever happen next.

    At worst it will avoid me to design an extra analogue bargraph meter driver, and I can light leds with this (I don't need any fancy scaling it's strait V<=>dB reading), 1ms lag is OK for gain reduction meter. I have to add a buffer anyway so again even if I don't populate the MCP I'll can drive an analogue meter.

    At best I'll be able to manage special time constant/condition depending on actual gain reduction... like compression amount limiting, or automatic ratio change depending of reduction amount (all time constant RC network and ratio have analogue switches/multiplexer drived by 595...)

    Best

    Zam


  10. 21 minutes ago, Antichambre said:

    The AINSER is usually called every ms, but! if you are using the 64 version, it's one multiplexed line every ms then scanning the 64 inputs takes 8ms.

    meaning mios can handle at least 125uS scan (8kHz sampling rate) "if" I speed up the AINSER8 scan (like a AINSER64 but with only 8 input)

    this should be enough as my fastest time constant rise is 300us

    39 minutes ago, Antichambre said:

    This is something easy to do in a regular App, using the AINSER_Handler, but in NG I don't know.

    Ok, I'll see

    Best

    Zam

     


  11. Hi All

    I working since few weeks on a new project that involve midibox (to make it short a quad stereo VCA compressor with digital/midi remote)

    I have most of things shorted out, and just have a new idea for it...

    Using AINSER to read my DC sidechain that initially feed an analogue meter (for gain reduction monitoring)

    Timing is not that critical in this area but now I'm thinking I can do some other processing depending of this input (VCA have parallels  controls from AOUT modules across the analogue time constant processing)

    The question is simple what is the AINSER sapling rate if I want to proceed fast DC or rectified AC, also what is the round trip from AIN to AOUT if I want to process something in between (like midi or NG conditional)

    Best

    Zam

     


  12. 1 minute ago, Antichambre said:

    Hot air station is enough.

    If you say it I trust you :cheers:

    Best

    Zam

    ps: "extended side question" is it possible to solder QFN with hot air ?

    my deeper skill is SOIC with larger tip as possible (true !! it work better)


  13. 10 minutes ago, FantomXR said:

    No but I followed up the logic in the code above:

    
    // Which RC pin of the SPI port should be used for the first module
    // allowed values: 0 or 1 for SPI0 (J16:RC1, J16:RC2), 0 for SPI1 (J8/9:RC), 0 or 1 for SPI2 (J19:RC1, J19:RC2)
    #ifndef AINSER_SPI_RC_PIN_MODULE1
    #define AINSER_SPI_RC_PIN_MODULE1 0
    #endif
    
    // Which RC pin of the SPI port should be used for the second module
    // allowed values: 0 or 1 for SPI0 (J16:RC1, J16:RC2), 0 for SPI1 (J8/9:RC), 0 or 1 for SPI2 (J19:RC1, J19:RC2)
    #ifndef AINSER_SPI_RC_PIN_MODULE2
    #define AINSER_SPI_RC_PIN_MODULE2 1
    #endif
    
    // Which RC pin of the SPI port should be used for the third module
    // allowed values: 0 or 1 for SPI0 (J16:RC1, J16:RC2), 0 for SPI1 (J8/9:RC), 0 or 1 for SPI2 (J19:RC1, J19:RC2)
    #ifndef AINSER_SPI_RC_PIN_MODULE3
    #define AINSER_SPI_RC_PIN_MODULE3 2

    Ok, the logic is "0, 1 or 2 for SPI2 (J19:RC1, J19:RC2, J5A:A0(nowRC3) )", I have something else(wrong) in mind sorry.

     

    I'm afraid I can't help more on this, miss some skill, let wait for a programmer :happy:

    Best

    Zam


  14. Hello

    HUI is not a closed protocol, it's midi, with unusual data structure

    In "standard" midi mode you can do whatever you want, but with MCU you have protocol priority and task specification

    the limit is not the midi, but the way Mackie implement it as an universal DAW mixer remote which is followed by all DAW dev.

    Another limit in you usecase is data feedback, the MCU Lcd update data according to flip condition

    If your encoder are PAN mode LCD show PAN value if you flip in SEND Lcd show send value etc...

    If you put 32 encoders (8 pan, 8 send ....) you won't be able to print 32 different value type, whatever you have room for it in a big LCD, or again with heavy config trick at .NGC .NGR like banking LCD lines updating the good one, but then you'll have issue if you update data from DAW, DAW will only send fedback data valu of the actual flip status.

    In short, in encoder pan mod the DAW won't update SEND data value (moved at DAW) until you flip (and call for data value update) at MCU hardware...

    Best

    Zam