plugsync~ beat division accuracy


    Aug 19 2007 | 12:37 pm
    Hello,
    Just a simple question. Looking for beat divisions out of the 4th outlet of plugsync~ (a 0. to 1. float), may i rely on a thing like [expr ($f1/0.25)+1] if i want steady semiquavers ? Is it real or loose ? What should i use instead ? [delay] ?
    best wishes
    f.e
    -- f.e chanfrault | aka | personal computer music >>>>>>> http://www.personal-computer-music.com >>>>>>> |sublime music for a desperate people|

    • Aug 19 2007 | 2:00 pm
    • Aug 20 2007 | 8:29 am
    • Aug 20 2007 | 9:52 am
    • Aug 20 2007 | 10:54 am
      i dont think plugsync~ derives its clock from midi clock. i think it should be more accurate than that... for instance midi clock outputs tic msg 96 times per bar, whereas the sample count output of plugsync should output a value for every sample that has been calculated by the host.
      as to the 2 problems you outlined:
      timing accuracy - need to see patch to make any suggestions.
      clock delay - this sounds like some form of plugin delay compensation, which you could try and fix by making a timing offset in the sequencer pluggo. alternatively you might find some settings in cubase...
      j
    • Aug 20 2007 | 12:42 pm
      > > clock delay - this sounds like some form of plugin delay compensation, which you could try and fix by making a timing offset in the sequencer pluggo. alternatively you might find some settings in cubase... > Oh yeah, justin, you're right. Delaying from one whole measure. I'll try that. There's a delay estimation in Cubase vst window. Cool.
      f.e
      > j >
    • Aug 24 2007 | 9:23 pm
      f.e., from my own tests... I've found that plugsync~ is not very accurate at all. Something to do with ASIO/coreaudio I would guess... buffers on a more general level. hostsync~, however, with audio OFF and driven by a "metro 1" will produce the most accurate of the available options. in order to keep audio off, though, you may need to make a standalone just to gather time information which you could then send to pluggos via OSC or udpsend!! That's the best solution for pretty good timing versus the sloppy timing I was getting with just plugsync~................
    • Jul 07 2011 | 11:37 am
      sorry - can you explain how you are driving hostsync with a metro object?
    • Jul 07 2011 | 1:01 pm
      its ok - i figuired it out - and yes i can confirm that hostsync~ driven by a metro 1 is as accurate as you will get. unless we can sick my sample number? ie at the sample level, rather than the tick level.
    • Jul 08 2011 | 10:50 am
      i am having a nightmare with hostsync and hostcontrol over udp
      keep crashing, getting this
      Thread 11 Crashed: 0 com.cycling74.MSPReWireDevice 0x1d823e71 rewiredevice_copyevents(_mceventbuf const*, ReWire::ReWireDriveAudioOutputParams*, long, ReWire::ReWireDriveAudioInputParams const*) + 177 1 com.cycling74.MSPReWireDevice 0x1d824947 RWDEFDriveAudio + 473 2 ...opellerheads.rewire.library 0x1dbe1d0a 0x1dbe0000 + 7434 3 ...opellerheads.rewire.library 0x1dbe6a89 RWPUnregisterDeviceImp + 1767 4 ...opellerheads.rewire.library 0x1dbe5798 RWM2DriveAudioImp + 64 5 com.ableton.live 0x004eca00 std::map, std::allocator > >::map() + 3583398 6 com.ableton.live 0x004ecc4c std::map, std::allocator > >::map() + 3583986 7 com.ableton.live 0x005063a2 std::map, std::allocator > >::map() + 3688264 8 com.ableton.live 0x001eb7c0 std::map, std::allocator > >::map() + 432998
      any ideas???