Zam

here is the HUI modification at MB_NG

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

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

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

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

Hello Patrick I was able to use HUI with my DAW (which is not PT), but never go further nor perform test in PT, for various reason. Best Zam

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

@Antichambre OK! Best Zam

Hello I'm back with two questions Is there any code modification for various MCP320x in muxed configuration ? Color TFT is so great, how this is handled ? I suppose there is massive special driver for it... Anyway I'll have a look when code available again, un grand bravo ! Best Zam

Hello Bruno Nothing to say...just great... Best Zam ps: I'll come back later with maybe more to say

Hello I guess it's all metric... so M3 if 3mm Best Zam

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

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 Ok, I'll see Best Zam

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

OK

If you say it I trust you 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)

interesting too, but honestly you can't find less DIY friendly device... thermal pad under body... you need a reflow to solder it I'm nor afraid of SMD but this is a no go, like QFN (eventually ?) or BGA Best Zam

I found datasheet unclear. absolute max rating say 90mA for Iout (1 or 16 ?) But max Ignd is 1.6A, look that the device can sink more than 90mAx16out, which tend to say you'r right Best Zam

Interesting wonder if 90mA for 16 led is enough for all application. I suppose code need adaptation to consider it as two DOUT for shift register update Best Zam

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 Best Zam

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

Hello Chris If PC1 work for CS 1 the pin configuration should be ok 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

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

I just have a deeper look even if i'm not confident with code... pin C1 is already used at J5, maybe you have to deactivate/remove something in the code, also it's the 32F4 ADC Why don't you use a free pin at j10 ? Best Zam

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