plugsync~ beat division accuracy

Aug 19, 2007 at 12:37pm

plugsync~ beat division accuracy

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|

#33320
Aug 19, 2007 at 2:00pm

#110849
Aug 19, 2007 at 2:26pm

#110850
Aug 20, 2007 at 8:29am

#110851
Aug 20, 2007 at 9:50am

#110852
Aug 20, 2007 at 9:52am

#110853
Aug 20, 2007 at 10:30am

#110854
Aug 20, 2007 at 10:54am

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

#110855
Aug 20, 2007 at 12:42pm

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

#110856
Aug 24, 2007 at 9:23pm

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~…………….

#110857
Jul 7, 2011 at 11:37am

sorry – can you explain how you are driving hostsync with a metro object?

#110858
Jul 7, 2011 at 1:01pm

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.

#110859
Jul 8, 2011 at 10:50am

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???

#110860

You must be logged in to reply to this topic.