Jump to content

Zam

Members
 View Profile  See their activity

  • Posts

    625

  • Joined

  • Last visited

  • Days Won

    26

 Content Type 

Posts posted by Zam

  6. Fader Automation

    in MIDIbox HUIs

    Posted

    If you don't need fader with audio track forget the TKD, or look at other series with only servo and touch.

    The "old priner sound" is not due to fader nor the fitted motor, it's linked to the PWM and H bridge.

    Zam

  9. Newbie help midi from daw to multi LCD

    in MIDIbox HUIs

    Posted

    I still can't follow your topix here. Do you have digital or analog VU meters?

    quite the same for me :)

     

    The only way I can imagine now is to use HUI meter data (CC? PB? note and velocity??), send them to AOUT, then to some buffer/calibration amp/ tension to current converter, and in some case depending of the galvanometer characteristic you have to add a time circuit to match Vu or PPM ballistic specification.

    I'm not sure it worth the effort...

    Zam

  12. various SRIO questions and NG hadware design

    in MIDIbox NG

    Posted

    Tks a lot for your input on this

    Your right, I need for sure more literature around this, especially layout. I will.

     

    The actual layout is close to 8 "DIOmatrix" (but with only one165 and one 595) daisy chained with 20cm wire between each (2x 10cm ribbon and 4 connector :wacko: ).

    Maybe it's little ambitious, but for the moment it's my first option due to hardware restriction.

     

    I have to check thing to be sure it's possible at my side, but second option is to run the long ribbon between diode/buttons and shift register in/out

     

    Tks again, your so helpful. :sorcerer:

    Best

    Zam

  13. various SRIO questions and NG hadware design

    in MIDIbox NG

    Posted · Edited by Zam

    hello Thorsten

     

    tks for clarification !!!

     

    I still have a problem to see the difference between:

     

                             --> J1 Dinx1 J2--> J1 Dinx1 J2 --> etc...

    J8/9 -->Ycable

                             --> J1 Doutx1  J2--> J1 Doutx1 J2 --> etc...

     

    And:

     

    J8/9-->J1 Dinx1 (with direct link J1SO-->J2SO) J2-->J1 Doutx1 (with direct link J1SI-->J2SI) J2--> etc...

     

     

     

    Anyway i'm not sure you say there is some? maybe I don't ask the question in the right way, you just say this could run some data transfer qualities problems

     

    Best

     

    Zam

  14. various SRIO questions and NG hadware design

    in MIDIbox NG

    Posted

    hey all

     

    I'm just starting some "bus board" design for my moving fader and I just want to be sure about some details

     

    I have some questions regarding SRIO chain, J8/9 and J1 J2

    -Is it right that only RC1 is used for all Din and Dout? Why then rev5 Din/Dout fitted with J1/J2 have RC1 and RC2 linked ???

    -If they are no use now for RC2, can I remove it from the line driver and use the channel for SI data?

    -Do I understand right the only reason Din and Dout use Y cable is because, SI is not linked betwin J1 and J2 at the Dout pcb, and SO is not linked between J1 and J2 at the Din pcb,

    Resulting for example, that I can just add a jumper-wire between SI J1 and SI J2 at a Dout card and link a Din at J2 in place of Y cable at J1

     

    Due to design restriction I'm not able to respect J1/J2 spec for my bus connection, but I think i'm able to have J1 at start and J2 at end so the whole thing should be compatible in a global chain :smile:

     

    Best

     

    Zam

  17. Converting two CC as sigle data (9bit)

    in MIDIbox NG

    Posted

    Hey Thorsten

     

    No pb, don't put this on your "to do" list, the future is most in eucon protocol for protools... if i'm right they already announced the end of HUI support soon (in the mean time it's a real shame !!!)

     

    BUT YOU KNOW WHAT !!!!

    i think i'm close to fine a solution, for the moment THIS work:

     

    EVENT_AINSER id= 1   hw_id=1 ain_mode=direct type=Sysex  chn= 1  range=0:16383 stream=" 0xb0 0x00 ^val_h"
    EVENT_AINSER id= 10 hw_id=1 ain_mode=direct type=Sysex  chn= 1  range=0:16383 stream=" 0xb0 0x20 ^val"

     

    I'm able to move the DAW fader according to physical one :)

    Like HUI, two CC for position, In fact it's 14bit but DAW only retain what he need

     

    Now I have to handle the touch (seems to be two CC too) and the AOUT which should be same faked stream as AIN

     

    Best

    Zam

  18. Converting two CC as sigle data (9bit)

    in MIDIbox NG

    Posted

    hey Thorsten

     

    Tks for reply

     

    As I say Mackie control work here, I can leave with this :smile:

    The idea using HUI is for two reason

    -Protools compatible

    -How the solo and mute is managed

     

    With MC the mute  (using note) is send instantly to DAW which is fine when I press a physical button to mute DAW track

    But I drive a relay with DOUT to achieve a real mute at audio side, unfortunately the returned mute note is delayed (scanned and sent each sec, originally just to light up a led)

    I can't use it for "automation", It just work for soloing and muting when working a mix, not for final mixdown.

    When tracking data with HUI mode it seem that solo and mute data is send as soon as something is pressed, useful "real time" bidirectional data

     

    anyway you say it's not possible so I have to put this out of my mind and accept some limitation/restriction regarding my initial "specification sheet" :rolleyes:

     

    Best

    Zam

     

  20. Converting two CC as sigle data (9bit)

    in MIDIbox NG

    Posted

    Hello

     

    I'm playing with my midobox_NG system, which is a moving fader prototype.

    I'm able to set up a fine .NGC file over mackie control protocol. This protocol use PB as fader data.

    But I want to try a .NGC configuration to be HUI compatible, I just don't know how to manage the fader movement data

    HUI use two CC in a 9 bit configuration. First (say CC1) in the 0-127 range. Second (say CC2) in 4 step range 0,32,64,96.

    Ending in a 128*4 value, 9bit.

    How can I listen to this and convert them to a single data (PB? nrpn?) that I can use for AIN and AOUT event.

    I read and read ngc configuration user manual and also search at the forum but find nothing, maybe I'm just missing something?

    Best

    Zam

  21. Fader Automation

    in MIDIbox HUIs

    Posted · Edited by Zam

    Proto 2

    here it is !!!

     

    quick spec:

    -motor analogue PI driver

    -analogue touch detection

    -512 steep (9bit) without jitter (can be better with shielded cable from AOUT and to AINSER)

    -cross talk digital/motor to audio ... less than my console noise floor !!!

    -acoustic noise... did the fader move ?

    -response time better than 120ms for 100%travel 100mm

    -response time better than 80ms for 100% travel 33mm

    -never over shoot

    -two automation pass with complex audio material result in null phase test 50dB below my line level, in static condition of course (when fader reach the target)

    -to null audio under my console noise floor with two automation pass, I don't need to trim one more than +/- 0.01 dB !!!

     

    I stop talking, this is better than words https://www.dropbox.com/s/o6v29atn209kyxi/proto%20II.mov?dl=0

     

    Best

     

    Zam

  22. Fader Automation

    in MIDIbox HUIs

    Posted

    Master Thorsten !!!

    tks :)

    I confirm the bug correction, 1.033 pre6 work fine here

    Now I need to lower the jitter :)

    Best

    Zam

  24. Upcoming MBHP_MF_NG module

    in MIDIbox HUIs

    Posted

    Thanks for taking the time to send a response. In my situation, I'm not editing audio real time. I'll simply be quickly moving them to a position and they'll be staying there. Are you having EMI problems even when the fader is stationary? Or does it occur with the motor is moving?

     

    I think the fuzz factory may take the motor brush noise while moving quite well as an addition to the effect :thumbsup:

     

    If your goal is to use motor just for "recall" purpose it's fine.

    Motor and H bridge make noise when swiching and rotating

    In another other hand, building a system like this (assuming less than 5 pot pedal FX) just for recall/snapshoot purpose is quite huge, an hand writing recall sheet take 10 sec...

    Interest come with the automation.

     

    Another idea is to have double track pot (audio + servo) without motor, but with a snapshoot system /preset recall with comparator from stored and actual value with just one led per pot that light up when both value are matched, you just manually move the pot until the stored value match.

    This implies a smaller system without all that stuff for motor, other pple will confirm but I think it's fine to do this with midibox

    Zam

  25. Fader Automation

    in MIDIbox HUIs

    Posted

    Nobody for my AIN resolution problem ? I have a look around here but find nothing

     

    another "disappointment" I have since yesterday, It has nothing to do with MB_NG but it's about the MCU protocol,

    I discover that all the led for solo, mute, etc are updated in a 1/2 sec range, not when you press a button...

    Consequence is that I can't use any of this data to drive a relay driving an analog mute system.

    By now my working solution is to use another midi port (not the same as MCU) and automate my mute in a midi track with midi note.

    The less ... it's not user friendly like having the mute directly in the DAW channel, the same as fader and audio file

    The more ... as it is separate midi track, I can insert midi FX like time triming, or arpeggio like a pattern sequencer for mute automation

     

    Zam

×
×
  • Create New...