Zam

Hi all Updated first post about HUI protocol for Protools ready So far so good I'll update soon Best Zam

IIRC it's the same command as NGR: type=meta meta=LOAD<setup> ??? also I remember the function was deleted, then implemented again, not sure the downloadable NG1.035 have it, you may probably build 1.036 from the source. LOAD will load a "full" config NGC + NGR etc, if you just need to change .NGC you have to duplicate your NGR and just change the name according to both config Best Zam

Hey Fantom Don't know about Norbim usecase. In my case it was to select a config at start up, before all buttons get busy for other task. Your option need a spare/unused button or a conditional flow by hitting two buttons. Anyway, it's not a critical function for me any more Best Zam

Hello Andy Interesting !!! I come back later with questions :) Best Zam

Man.... for sure it hurt I don't get the way this discussion go so far. Please fellas, just stop complain and criticism. OPEN YOUR EYES a look at what you have access for FREEEEEEE here. And for all things not "open" or not "yet, at the second" available, it's just a matter of YOUR work if you want it to happen. Best Zam

Hello Theoretically, but what can do a small community or a lone designer if stolen, law pursuit is not free... Then you have to technically prove it and have access to the pcb using the stolen (hardware) design. All around Midibox and other great DIY community not many complex PCB manufacturing files are available, it's a good practice, and in fact the safer solution to protect things. Still the concept, shemo, build threads and many info OPEN to anyone. I'm always sceptical when discussions complain about what is not available when you'll find hundreds pages of info and ready to use design concept. In french we say "the butter, the money of the butter, and the ass of the farmer..." if the translation make sense Now TK is clear here, the PCB designer is free to release the manufacturing files..., he just ask a restricted proto run to ensur, everting is fine, it's just some respect to potential builder for less issue possible, as respect to all the community which will take time help to troubleshoot... At my side I take more than two years and thousands bucks designing a tool around midibox system, then more than 6 month crash test before a release (without manufacturing files) so I completely understand Wilba and Tim and all other spending so much time to make things possible. @TK. nice to see you again around the forum, summer holiday ? Best Zam

Hello Any app launched at macbook startup ? like audio/midi sequencer, DAW, or any midi driver/remote software, possibly sending midi data for initialisation on a studio setup that might confuse your midibox hardware configuration ? Best Zam

Ok, it's a special feature for the SEQ only Thanks for info. Best Zam

You'r welcome Chris Keep us informed of your progress Best Zam

Hello There is a CPU monitor at MIOS for STM32F4 ??? Sorry for the off topic. Best Zam

Hello Chris Ok it's not the 2m ribbon I see with 288 leds ! I think you already spot the problem so yes the answer is your led and AIN don't like to be close together. I'm not used to this color LEDs but they use PWM to acheave 20% power and color change right ? PWM can introduce noise which can also be the reason you notice jitter, in conjunction with voltage drop if there is any ? Can't say about PSU choice, you have to measure current and pick one accordingly By the way, what for the 19V rail is? because you can maybe use this on to add a small regulator (like LM317L) for the critical AIN and slider Vref My first test will be to locally separate AINSER circuit and LED circuit, not sharing VDD/VSS locally, but only at PSU terminal in the manner of star power distribution, if your design allow it. Sense detection, is a sense input that some PSU have to attach at the load, tracking voltage at that point, an maintain it. Best Zam

Hey Chris Ok, that make sense, good you find the issue I just have a look at this led ribbon. 288 leds... 20mA/led it's close to 6A all ON and 300mA idle. Your 7bit jitter represent more than 50mV which is not a surprise then To handle this without voltage drop you need a very strong PSU at 5V rail, with sens detection... Keep in mind that 11bit with 5V ref represent 2.5mV per step, if you have ripple/Vdrop bigger than that you will have problems Try to use (if your design can handle it) two separate rail/psu, one for "power" and one for "precision" circuit. Also local regulation can be an option. Best Zam

Hello As AINSER64 is a multiplexed solution to one AIN mcp3208 I don't think it is possible. Just set the device at 11bit (max if possible regarding jitter), then your event_ainser definition will take care of the effective bit depth you specify here. I don't see the reason/use case you need to scale this at chips ? Best Zam

Hey Chris I have no idea about this. But at MB_NG if your event definition is à 7bit one (note or cc) the Ain data is scaled accordingly. If that's the question you ask ? Best Zam

Hello and welcome here Don't know yet what will be the best strategy , I see two options for now. At NGC with "emu_enc_hw", or with a script at NGR (meta=runsection @ NGC) with basic incremental(decremental) math Best Zam

Hello You should be able to delay anything using .NGR with delay_ms 3000 Best Zam

Hello Chris I have a quick look at your pcb few things in mind: -J1 and J2 only use one wire (ribbon) for 5v and 0v, ribbon is very thin wire... you can expect voltage drop/change/instability anytime you have small load change. Try cut the ribbon at 0 and 5v and replace with 0.25 or 0.5 mm2 wire (direct soldering at connector pin for test) -what side is your ground plane ? -Did all fader have same jitter or position in the PCB have impact ? -IIRC unused 4051 pin are better clamped to ground ! Best Zam

Just to add that in my design the safe "don't send when not used" function is handled at .NGC with a if_equal linked to touch sensor of the respective fader/slider EVENT_AINSER. I suspect you don't have touch detection at your slider, but you can use button for this.

Hello I will say you have a design/layout/PSU problem that cause unexpected jitter I don't now about mux with distant wire, maybe buffer is requested for strong data over long trace, is your "jitter" random regarding value or "around" the actual pot position ? Also, how is the layout of your 5V trace used for 3208 analogue Vref and slider servo track ? The expectation is to have a separated trace for this, without power distribution for anything else from Vref at 3208 to sliders You can check with DMM at lower mV setting what you get between 3208 0V and slider 0v, you can then monitor how "stong" is you 0V ref as consistency over the plane/wire, change the load by on/off led and button state if you have some. Do the same between 3208 Vref and slider 5V. Another idea is maybe to check how reliable are your slider ? replace one with two resistor in series (equivalent serial value as slider) use the middle as wiper and check if jitter is better ? By the way what is the ref and stroke length of you fader/slider ? For "critical" operation, like 11bit low or no jitter, and in some circumstance, local precision regulation is a good option... I don't think being concerned about jitter at 7bit is too perfect , you can for sure improve your result !!! we will find out where we can do it better. Best Zam

Hello Chris The pinrange= is the deadband setting it has noting to do with jitter. At what bit depth did you configure your AINSER module ? Only 7 bit for CC ? If you have jitter at 7bit you may have a hardware problem... double check wire, strong 0V ref as 5V ref jitter at 7bit is more than 50mV moving somewhere Proper design/wiring should allow 11bit without jitter, even with 50cm cable from pot to AD input Best Zam

I bought the board at Mouser, here is the link.... Is that the good board ? I'll send decent pictures or videos when I come back home too ! Cheers, Tom. Hello Tom Yep, good board Best zam

Hello Fantom Tks for your reply. I think I'm aware about what you find at source code IIRC. The point at the time I look at this is to understand where the default files generated get his definitions, to generate a default file with my specification. It's not an major topic now for me, but still interested to understand the (soft) mechanic :) Best Zam

Ok Do you need continuous parameter access and adjust, or parameter flip ? I never use keyboard but IIRC MB_KB is MB_NG ? If configuration flip is enough you can have a load (file) command at .NGR called from receiver (full config including .NGK I think) But I suspect you want direct continuous control :/ Don't know enough about KB to efficiently help on this. Best Zam

Hi Chris If the functions you want to change are part of .NGC configuration, you can use event receiver (from external note or CC) that set/select/change bank. Then your event_x can have different setup depending of selected bank. Best Zam

Hello That's for sure, I report the same observation with different baudrate, it's massive, like every packet/data At 20x it's just sometimes, apparently not affecting the system to work, so... I don't investigate more at my side for the moment, if you do, feedback welcome :) Best Zam