Forums > MaxMSP

plugsync~ beat division accuracy


f.e
August 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|



f.e
August 19, 2007 | 2:00 pm



f.e
August 19, 2007 | 2:26 pm



f.e
August 20, 2007 | 8:29 am


August 20, 2007 | 9:50 am


August 20, 2007 | 9:52 am



f.e
August 20, 2007 | 10:30 am


August 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



f.e
August 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
>



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


July 7, 2011 | 11:37 am

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


July 7, 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.


July 8, 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???


Viewing 13 posts - 1 through 13 (of 13 total)