Jump to content

Zam

Members
  • Posts

    625
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by Zam

  1. hey are you sure you don't need dual throw switching??? max4066 (or similar dual or quad DT) deserve a try. opto like 4N25 is 30c...I don't call this expensive :)
  2. Hello Phat Not sure to understand everything. What I see, is a DPDT switches for each note (pedal). Transistor act as SPST, plus you don't want your digital DC signal going at audio side. One thing I have in mind now is an optoisolator switch driving 4 FET (2P and 2N chanel) ??? Also have a look for "analog switch" IC, some ships are "rail-to-rail" for the analog side switching, but it still in most case 0/5v supply so your 6v sin (pk? rms?) will clip... Zam
  3. Zam

    Fader Automation

    Hi I still have digital noise crosstalk, it's "acceptable", but I really like to do better I think I find the EMI sources, with the CLK at ribbon cable to J1. I have some result with a grounded copper screen around the ribbon, but I would like to try to reduce the clock noise upstream. So my question is simple, I scope a 1.4us square wave (giving me 71.4kHz clock right ?), is that the SR scanning??? I'm little confused because at audio side I'v got 4.6kHz peak noise, with ALL the harmonics coming with So if someone can confirm me the SR clock so I can calculate and try some filter in the clock line Zam
  4. Zam

    Fader Automation

    Hi Novski What do you want to know ? The config is the same as the begining. the improvements are more in the interaction with analog side to reduce digital/analog cross talk. Like shielded wire, frontpanel grounding etc. it's so specific to my console mechanical integration, I don't know what to say ? Best Zam
  5. Zam

    Fader Automation

    Hey all Long time without update on this topic, sorry for that. In fact I just take the past few month to evaluate the prototype...daily use in a full album production. The best possible crash test ! It's a positive experience, even if it need little improvement here and there (I'm working on it!!!) , the whole system run rock solid :) Zam
  6. Do you try with lower base limiting resistor value ? Look little hi to me but I don't do the math... And as you say load maybe too low? As a start try to swap the two value Zam
  7. mmm! Do you share the same 0v (ground) ref at both side ? or is you output floating ? Aslo 1.5V sound like two diode voltage drop, like a darlington... should be a coincidence... Zam
  8. Do you try transistor switching yet? with npn ? As John say you can use darlington array ! Zam
  9. depending of fader, there is a report somewhere, at my side I confirm ALPS work fine with MF_NG
  10. Zam

    Fader Automation

    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
  11. Zam

    Fader Automation

    Hello For the CP line, as I say, it's 5x the price of ALPS, around 110euros Look at website http://www.tkd-corp.com/index-en.html you will find distributors depending of your location. Best Zam
  12. Hello I'm not familiar with cubase, but you should have a setup somewhere for control surface, be sure to use same protocol at both side. best Zam
  13. 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
  14. Hello Fred analog is analog... if you want to drive analog meter (Vu or PPM) you have to send your 2bus soundcard analog out to the meter (with at least buffer circuit) Best Zam
  15. Hey Arno Count me in for two pair Best Zam
  16. 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
  17. 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
  18. 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
  19. Zam

    Fader Automation

    Some update I just test the TKD fader Amazing! For those who can afford 5x the price of the cheap ALPS and need high-end spec, i recommend it. It's completely another league :) Best Zam
  20. You'r right... I'm unable to make data coming back and drive the AOUT... That was a short euphoria :rofl: I forget all this and concentrate to the next step, high end TKD fader coming tomorrow !!! Best Zam
  21. 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
  22. 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
  23. 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
×
×
  • Create New...