Jump to content

Zam

Members
  • Posts

    625
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by Zam

  1. 18 hours ago, goyousalukis said:

    I did try the opamp to increase the voltage by 3, but I couldn't get a scale  in tune.

    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

     

     

  2. 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

     

  3. Hello

     

    2 hours ago, Antichambre said:

    Just by curiosity, how many MIDI gears you have in your setup?

    With 68 midi I/O guess Vangelis just joint the forum :happy:

    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

     

  4. 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...

     

  5. 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 :happy:

     

    2 hours ago, macsaif said:

    If there is any solution to transfer 8 bit signal via MIDI this can be a solution (MSB+LSB).

    Midi offer 16384 control with 16384 steps (14bit)... we call this NRPN :decayed:

    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

  6.  

    Hey

    1 hour ago, goyousalukis said:

    Do you guys think I fried these two pins on the DAC?

    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

     

     

  7. Hello

     

    5 hours ago, Ivan Petrov said:

    32 is far better than 8 (it says "limited to 8 CV output channels maximum" in both cv1 and cv2 descriptions) but where can i get info about this? Is it supported by existing software?

    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

  8. 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

  9. Just now, Antichambre said:

    It's fine, you obliged me to share it correctly and learn a good way to do it :)

    Great if it's fine... at some point I realise that maybe I push a little :decayed:

    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 :cheers:

    Best

    Zam

     

    • Like 1
  10. Hello TK (and happy new year :cheers:)

     

    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=

     

    Quote

    at mbng_file_c
    line1480:
          if( (value=get_bin(value_str, 24, 0)) < 0 || value > 0xffffff ) {
    replace
          if( (value=get_bin(value_str, 20, 0)) < 0 || value > 0xfffff ) {

     

    at mbng_event.c
    line 3787 3827 and 3844
    for(i=0; i<24; ++i, mask <<= 1)
    replace
    for(i=0; i<20; ++i, mask <<= 1)


    at mbng_file_r
    line 1180 and 1512
        if( out_port == 0xffffff && ((out_port=parseValue(line, command, port_str, tokenize_req)) < 0 || out_port > 0xffffff) ) {
    replace
        if( out_port == 0xff && ((out_port=parseValue(line, command, port_str, tokenize_req)) < 0 || out_port > 0xff) ) {

    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

  11. 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 :happy:

     

    Best

    Zam

  12.  

    Hello

    19 hours ago, latigid on said:

    the differential input means that there is no need for each side to reference the others' power rail

    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 :rolleyes:

     

    Best

    Zam

  13. 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 :happy:

    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

    :cheers:

    • Like 2
  14. Hello

    17 hours ago, latigid on said:

    I suppose if we were being super fastidious it would be smart to not keep the 0V common (differential driver/receiver) and probably only connect the shield at one end

    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

     

  15. 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 :rolleyes:

    Best

    Zam

  16. 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 :rolleyes:

    Best

    Zam

×
×
  • Create New...