Zam
-
Posts
625 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by 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
-
4 minutes ago, Zeke said:
code?
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
-
32 minutes ago, Zeke said:
how do I lower the refresh scan to 30 or 50Hz?
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
16 hours ago, Zeke said:J1 is the power inputs I can't tell which is positive and which is negative. I looked at the schematics and I think that the left pin is positive and right pin is negative. is this correct? (see attached pic)
The pcb you show have rectifier and regulator, so the input is AC
16 hours ago, Zeke said:Also, I'm not sure which is the positive side for the LED. I assume its the left also. (see attached pic).
anode is positive, the silkscreen seem to show it on the left, as you assume
16 hours ago, Zeke said:is the LED status of the board being powered on or does it blink for midi transmission?
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
- 1
-
Hello
19 hours ago, FantomXR said:I've just noticed, I've used the PIC18F4520 instead of PIC18F452. Could that be the problem?
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
-
1 hour ago, Antichambre said:
Maybe time to update your design ;)
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
On 08/11/2018 at 11:49 AM, FantomXR said:And this is the NGR part:
if ^section == 1 delay_ms 500 if BUTTON:1 == 127 SEND CC USB1 1 1 127 exit endif if BUTTON:1 == 0 SEND CC USB1 1 2 0 exit endif endif
This code wait's 500ms and checks if the button is still pressed. If yes it sends on channel 1, if not it sends on channel 2.
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
1 hour ago, ssp said:If i have a series of values i want to control from 3 knobs, so there are two lines of values, and 8 on each line, what i want to do to reduce the amount of encoders is have one for moving in the y direction between line 1 and line 2, then one to move in the "x" direction to step between 1 to 8 in the line, then a final encoder to change the value of the selcted cc#.
Is it possible to do this in the .ngc?
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
- 1
-
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
SysEx STREAM_MAX_SIZE / timeout problem
in MIDIbox NG
Posted
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