Jump to content

Zam

Members
  • Posts

    625
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by Zam

  1. 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

     

  2. 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

     

  3. 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

     

  4. 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

     

  5. 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

  6. 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

     

  7. 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

     

  8. 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

  9. 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

     

     

  10. Hello Chris

    If PC1 work for CS 1 the pin configuration should be ok

    21 hours ago, FantomXR said:

    and ainser.h:

    
    // 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
    #endif

    Are you sure about the pin value here?

     

    also did you define modules number ? (ainser.h)

     
    // Maximum number of AINSER modules (1..255)
    // (Number of modules can be changed via soft-configuration during runtime.)
    #ifndef AINSER_NUM_MODULES
    #define AINSER_NUM_MODULES 1
    
    #endif

    and ainser.c

     
    /////////////////////////////////////////////////////////////////////////////
    // Internal function to set CS line depending on module
    /////////////////////////////////////////////////////////////////////////////
    static s32 AINSER_SetCs(u8 module, u8 value)
    {
    switch( module ) {
    case 0: return MIOS32_SPI_RC_PinSet(AINSER_SPI, AINSER_SPI_RC_PIN_MODULE1, value); // spi, rc_pin, pin_value
    case 1: return MIOS32_SPI_RC_PinSet(AINSER_SPI, AINSER_SPI_RC_PIN_MODULE2, value); // spi, rc_pin, pin_value
    
    #if AINSER_NUM_MODULES > 2
    # error "CS Line for more than 2 modules not prepared yet - please enhance here!"
    #endif
    }
    
    
    return -1;
    
    }

    Best

    Zam

  11. Hello

    MCU is just a remote, standard protocol use a single encoder row with flip button to assign them to DAW function

    The aux(send) count is dependant of DAW.

    What I mean is that the protocol (at DAW side) can't handle more than 8 encoder at a time, if you put more you won't gain in direct function in hand as you have to send flip command to access DAW function and this will deactivate encoder that are not assigned to the actual selected function

    Maybe with NG you can add conditional and script that automatically flip (it's a midi note) according to your dedicated row (let say "send one" encoder row) where any move of any encoder in this row engage the whole row (8 encoder)

    But what will happen if you move two encoder in two different row at the same time...probably lag and overflow as you'll send continuous flip function...

    Best

    Zam

     

     

  12. Hello Chris

    For AINSER8 you have to define muxed=0 at NGC because it's set to 1 by default, but not sure it's your issue here

    Can I ask for what reason you need more lines? because you already have two line (if not using AOUT) for 16ch

    Also it may be a better workaround to use a muxed MCP3202 for 16ch or MCP3204 for 32ch, I suspect it will request less change at soft side...

    I have this in mind since time, but don't start yet...for potential project that need intermediate ADC count and to gain room compared to an AINSER64 with disabled channels.

    Best

    Zam

×
×
  • Create New...