Zam

I don't get why it don't work ? Did you follow the calibration procedure ? I guess in your use case you need to measure which note is 0V when playing your KB (should be the one in the centre of the key...), then play this note from midi and adjust offset trim to read 0V at DMM, or a tuner at audio out to read the same note as KB play. Then via midi send the lower note your KB is able to produce, and adjust the gain pot to match (at this point you should read close to -4.5V at DMM). Check with the higher note KB is able to produce. Check again with 0V note and if requested do the process again. In the mean time I find the schemo, your moog is mainly +/-9V, I don't see why after calibration you can't send lower and higher note/CV to your oscillators (up to +/- 9V), if your AOUT_NG modules is supplied with higher bipolar (+/-12 or 15V), you can zener limit at your gain opamp FB. By the way, important point, where are you inputting the external CV ? Best Zam

Hello I suspect you "only" have to define your specific table for AOUT modules, so that the full scale DAC output (rescaled from +/-4.5V) give a 3 octave range (if that's what I get for your usecase) aout_hz_v_table.inc http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Faout%2F OR you use the actual HW and SW and scale/offset (buffer/opamp gain) to the step you need, which will over scale (at extreme high and low midi note play) your moog CV input. A schemo will say if it can handle without trouble the extra voltage (maybe just more octave to be played...) or if you need a voltage protection at CV input, you can also just power your AOUT modules with same bipolar voltage as the moog... Best Zam

Hello With 68 midi I/O guess Vangelis just joint the forum Joke aside, I'm not sure you will gain in connector count by using RTPM in your use case, RJ45 will replace USB wire, but not all DIN5... If you build some boxes that route let say 8 midi i/o to RTPM it will more or less equal to what you already have Still RTPM have benefit over USB. Why don't you dispatch your midi i/o devices in various FX/syth rack at the first place ? Best Zam

Hi all My next midibox project concern my juno60 There is two topic, all the CV handling for all slider parameter, no test yet, but I have a clear view about what I'll do about it. Then the keyboard, note on/off to remote play the JU60 via midi note... I try interfacing a matrix "reader" with 1 DIN scanning the JUNO CPU output (to KB), and a "return" with 1 DOUT to the JUNO CPU, with "result" but not usable. The idea is to active a DOUT pin at the proper instant compared to DIN scan (which row is scanned) so the JU60 CPU know which note is virtually pressed... I guess my issue here is the time sensitivities (as maybe component and clock between two system) The question is simple, what is the fastest possible loopback latency with mios (MB_NG in my case) to trig a DOUT pin according to a DIN status ? For what I see so far in my Oscope, the JUNO seem to scan the KB (and other buttons...) within 1ms so I guess I should send a DOUT trig in less than 100us (and for less than 100us) after the DIN "read" a row. I think a lot about the method and end up with this idea, a matrix reading a matrix, but I don't know if my approach is the good one... Input welcome Best Zam ps: I also think about DCB emulator with midibox, but I'm not good enough to code this...

Hi Oops yes you'r right, I don't take attention to the requested output voltage value, IIRC TL07x are not rail to rail Datasheet need to be checked.. Best Zam

Hello There is no mystery to calculate opamp gain, feed the resistor you need for the correct output range. Best Zam

Hello 55 DA is a lot, as say MB_NG only support 32 AOUT (per core) So far there is no MUX option for AOUT_NG. AINSER scan is not a issue, we have the muxed version for 64 pot So you need two core, which can be a good option, or even 3, two for data scanning and HW handling and one master for Midi IO and multicore dialling, MCAN connection between all Midi offer 16384 control with 16384 steps (14bit)... we call this NRPN At NG side, I'll recommand to use NRPN data for all your "more than 7 bit" data, and just use map definition to scale to/from whatever bit deph or range you need. Best Zam

Hi all NAMM 2019, midi 2.0 prototyping announced. Should concern midibox at some point in the future, I guess. https://www.midi.org/articles-old/the-midi-manufacturers-association-mma-and-the-association-of-music-electronics-industry-amei-announce-midi-2-0tm-prototyping Best Zam

Hey To me it look like... There is not that many part at AOUT_NG... the weakest being the DAC Just double check your measure at TLV5630 output with the TL074s removed Best Zam

Hello I'm talking about AOUT_NG http://www.midibox.org/dokuwiki/aout_ng#the_pcb Have a search in the forum, someone do the test times ago and it work (MB_NG) You have to chain the TLV at DOUT pin and enable 32CV at .ngc file configuration (supposed you run MB_NG on a stm32F4) Best Zam

Hello Welcome here ! IIRC you can chain 4 AOUT _NG (12bit TLV5630), meaning 32 analog out, but core are small now, you can have two (even linked in the same box) for 64 CV out Most 80' synths (for those I know) use multiplexing and low def DAC, not realy comparable with modern DAC Best Zam

Great if it's fine... at some point I realise that maybe I push a little as uncomfortable to "ask" because I can't really help community on this subject (except beta testing...) I'm sure it will be useful for many pple as soon as it get full implementation at MB_NG Best Zam

Hello Thank to both of you to take care of this So far MCAN seem a great feature !! Best Zam

Hello TK (and happy new year ) based on @Antichambre trunk (he share with me for beta test) I mod and compile MB_NG here is notes of what I do to have port accessible from .NGC (don't remember yet if router work...) I test all this weeks ago, but EVENT send/receive proper midi data between cores linked at MCAN pin with the extra 4 digit definition at port= So far I don't succeed to use MCAN port at .NGR (don't remember why I do this at mbng_file_r...) The idea is simply to have MCAN fully integrated at MB_NG like any other midi port. Best Zam

Hi all I played last month with mios32 MCAN implementation from @Antichambre I basically make it work with MB_NG at .ngc but not at .ngr (yes I'm not good at this...) Any -official- agenda planed to add those ports natively for MB_NG ? I'm very pleased with the first test I performed Best Zam

Hello Despite I don't really have a need for this great tool, I'm happy to see the community releasing new toys Big BRAVO to all of you involved in this development Best Zam

Hello Sorry but no, differential mean the signal is duplicated with 180° flip at sender, meaning at the reconstruction side (receiver) interference and external noises will be nulled. Then there is various "option" if you want to isolate both side, like opto or transformer But in DC coupling case you better have the same reference. About the general topic and "distant" communication between our lovely MB_HP tools I'll hope @Antichambre will chime in and talk about MCAN I don't want to spoil his work, but I partially beta test it (MB_NG) with very promising result Best Zam

Ho merci Bruno ! yes this one work particularly good Best Zam

Hello Midiboxers I usually produce albums and tracks for other so I don't post /communicate that much personally in the web/forums about these works. This is a particular one, I do with a great friend of mine. Hope you'll enjoy it Nachtwächter Best Zam ps:there is some midibox tools involved, GOOM ported to midibox in one track, as my fader automation at mix (analog) running on MB_NG

Hello Differential don't mean floating, so far MC3486/3487 are not isolated (trafo or opto)...so I suppose you need a proper and common 0V ref at both sides... Also shield and 0V are two different things (even if it connect together somewhere eventually) Best Zam

Hello I guess max525 have better spec than tlv5630 Best Zam

following with interest... can be merged with this: best Zam

Hello This compact modular core is so attractive... Nice work ! Best Zam

Hello Chris That's a nice way to have blinking LED, I use this kind of strategy in my NG The drawback is that you can't run another script and keep the blinking. I start a topic/request long time ago to have a blinking mode at lower code level in mios, like a dynamic dimmed= mode Hopefully one day Best Zam

Thanks a lot... I don't know how I miss this... single wire TX/RX it's perfect (my 0v is already shared by all cores) Did you already try the max length of the cable ? Is there some disadvantage compared to uart midi (direct J11 connection) with 10x speed at mios32, or only advantage? latency etc... Ok I stop here MBNet it's not the purpose of this topic Best Zam