Zam

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

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

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

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

Hello I'm not sure to understand what logic/function you want to achieve by reading your NGC code. Can you describe the user level logic you need ? (I see CC definitions type=cc, but without number definition: cc= ) Best Zam

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

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

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

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

Somewhere in the code, but I don't remember where, it was long time ago

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

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

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

Hello and welcome here The pcb you show have rectifier and regulator, so the input is AC anode is positive, the silkscreen seem to show it on the left, as you assume 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

Hello Not expert at all for the question, but I find this: http://ww1.microchip.com/downloads/en/DeviceDoc/39647a.pdf I suspect it deserve a read Best Zam

Unfortunately not enough interest for my "highend", costly, and complex automation to justify another hundreds hours of "R&D", despite I still have in mind a "simplified" version...but still in standby for the moment. Best Zam

Hello Bruno Look great ! If only I got this 4 years ago, my midibox design would have the core directly on the main board... Bravo Zam

Hello 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

brilliant edit Best Zam

Hello 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

Hello Assuming you set your led type and value according to MCU chart (CC for Vpot/encoder IIRC) it should work... side note: MCU Vpot have flip function, you'll have feedback according to selected layer (pan, aux etc...) Best Zam

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

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

Great work Thorsten !! Side question, is it possible to hook ESP32 and STM32F4 cores with direct midi/UART connection (high speed without opto like I do between 3 STM core here) And use it as a RTPM wifi bridge ? Best Zam

Happy new year to all ! Cheers Zam