plugsync~ ticks?
I'm finding the tick output of plugsync~ (PPQ) to be pretty wobbly -- i.e., it seems to wander on consecutive playbacks of the same sequence a fair bit, sometimes even changing its mind about whether a note starts on a downbeat, or at the end of the previous upbeat. Is there any way to get an accurate, or more importantly, reproducible output from the ticks outlet of plugsync~? I'm guessing that this has to do with the scheduler rate in pluggo, tempo, sample rate, rounding errors...?? dunno. I've tried both "accurate" and the default mode, but haven't been able to improve matters. Is there some sort of mysterious mathematical trick to produce useful ticks?
J.
okay, an update...
It appears to be consistent if playback is always started from the same bar. That is, the tick count for a given note entry remains the same when starting playback from the same bar. When I change the start point, the tick start point of the note changes, and then remains consistent on all subsequent plays from that marker. Yes, this is pretty obviously something to do with varied and exciting interactions going on between tempo, sampling rate, and so on... But what's the math? It really seems as though there should be some way of quantizing this all to make it possible to play from any point and still have events "land" on the same tick. But with my bowling-ball-smooth brain I can't seem to work it out...
J.
>Is there some sort of mysterious mathematical
>trick to produce useful ticks?
good question. maybe a mechanism where you
add ticks consequently to the bars and beats,
they are a bit better and update properly on
location move, start, stop events in most hosts.
if you is on steinberg, the PPQ thing can be
changed in the host too. maybe a 1/millionth
ressoltuion is too fast for pluggo runtime ;)
- i am just guessing here.
i try to stay aways from it and use samples
and beats only.
i just posted the same question about 5 times with no
luck
my problem is as follows:
I'm using OS 10.3.9 and Logic Gold 6.3.1.
the problem I'm having is with both hostsync~ and
plugsync~.
neither gives an accurate transport position. If I
make a loop in Logic , between ,say, bar 3 and 4, the
value from hostsync~ or plugsync~ loops too early,
from about 2.9 to 3.9. Its more innacurate at faster
bpms.
consequently i can't reliably sync logic and max
together to a specific point in a timeline , though
plugphasor~ and hostphasor~ seem ok for beatmatching.
what software are you running your plugin, what OS,
which versions etc.?
please help if anyone has experience of synching play
position in MSP to a rewire or plug in host......
cheers
james
I'll check it again, but I think the bar count is off by the same amount. Or at least, I have noticed that, on the PPQ readout, the beat is sometimes coming early (naturally, when the ticks run out!). But I'll try to check the beat count more carefully. I have had success with sample count, so using beats and samples would be fine for my application.
It would be nice to figure this out, though. There certainly appears to be a pattern to it; the deviation is entirely reproducible.
Any thoughts from C74 themselves, other than "don't use Logic"?
J.
yeah... I just remembered (again -- I've been through this a dozen times today) that I can't use samples because I really want song position. I tried using an accum and resetting the sample count to 0 at each new beat, but that didn't prove any more consistent than the ticks.
Please, if anyone knows a way around this one, let me know what's up. Or, if you know for a fact that it can't be done in Logic, let me know, and I'll stop wasting my time.
J.
Actually, are there any mxj~ classes that can access song position info?
Not that I know of.
You may get somewhere by tightening down the buffer settings for the interface you are running Logic with.
Also - if you have an example patch of the sort of thing you are trying and a small Logic project we could have a look at it. Send it all in to support@cycling74.com
Please include as many details about your setup as possible.
-A
making the buffer setting smaller makes it
considerably worse...
if i run a small buffer on core audio, the raw ticks
start drifting backwards towards zero , faster for
smaller buffers.
at higher buffer sizes, the values coming out of
hostsync~ or plugsync~ are stable, but slightly too
small. a loop between bar 3 and 4 might give values
cycling between 2.9 and 3.9
I'm not using a special patch, just the help file for
hostsync~ with a peak and trough object to see what
the range of tick values is. I'm using a new empty
autoload Logic 6.3.1 song on OS 10.3.9, with a loop
running
cheers
james
I'm sacking the hostsync~ object.....it can't dance
with Logic....
On this thread
https://cycling74.com/forums/index.php?t=msg&th=19623
theres a possible solution
if you make an automation track, maybe with the value
of the pp into the plugin equal to the bar number, you
could then combine with plugphasor~ to get accurate
ticks....midi seems better than this sync stuff
or maybe some kind of midi clock? i'm not sure how
that would work
has anyone actually got this to work?
cheers
james
Roman was doing something along these lines. I may try it myself, but I was hoping for a cleaner, built-in solution. Whether it's Logic's fault or not, the object doesn't work as advertised...
After way too much screwing around, I found that it's cumulative. This patch shows it, and sort of tries to fix it (not loops, though, which seem to lose in both + and - values). It's a pluggo, so you'll have to build it:
If anyone can find a good way of fixing the deviations, feel free to try -- this is just a quick attempt, and a general way of showing that it is, in fact, cumulative. Maybe it will trip some ideas at c74(??). I made another patch for simply counting the events in each beat, which is actually fine for my current purposes, so I'm giving up on this for now.
J.
What sort of results are you seeing with this patch?
On PC in SX 3.1 I am seeing regular deviations of the order of
.000092
On Mac, in Logic 7.2, the regular deviations are considerably more, around .01
And like you say, it does seem to be cumulative.
Cool patch, thanks - I'll look into it some more
-A
Groovy! Hopefully a fix comes out of it at some point.
cheers,
J.
i get a similar deviation in Mac Logic 6.3.1, about
.005. if i make that patch with hostsync~ its the same
deviation, about .005
to be honest though, i dont understand what that patch
is doing.
what is it deviating from? the main problem i noticed
was the ticks loop between points slightly before what
they should.
what is your patch showing?
cheers
j
sorry... the patch doesn't work with loops.
The patch is a guess/experiment, really. I was just pulling the first tick following zero (the beat), and watching how that value changed. I noticed that it was not consistent, and that the consecutive first-tick-sizes seemed to add up, roughly, to the amount of deviation I was seeing in the tick location reported for my test note event (on 1 of the 2nd bar). I tried putting in an accumulator, to accumulate these reported first-tick-sizes, and adding the accumulated value (what I imagined to be a "loss") to the reported tick time of the midi note. It wasn't perfect, or totally consistent, but it was much better.
Anyway, it still strikes me as a sort of interference pattern, or modulation, caused by two slightly different periodic patterns starting together, drifting apart, and coming back together again. But I'm seriously mathematically challenged, so I leave it to Andrew to (hopefully) figure out what's going on. There certainly seems to be a pattern, which suggests to me that it can be tweaked back into shape with the right number juggling...
cheers,
J.
I'm not sure i quite understand the significance of
the first tick. is the beat supposed to be on zero or
on the first tick?
anyway..... I've been trying to use an audio file to
synchronize a plugin
i made a file that ramps from 0 to .5 over 30
seconds, and then the plugin uses that incoming audio
to create signal rate bar position info and a synched
phasor.
however, i get exactly the same problem! a loop will
still give values that are too early. Its like Logic
is sarting its loop too early, maybe it compensates
for some internal latency or something, but it sure
gives me some crap data into my plugin....or am i
totally misunderstanding something?
heres the patches...
this one makes the audio file
and this one needs to be compiled as a plugin
Send instant messages to your online friends http://uk.messenger.yahoo.com
> I'm not sure i quite understand the significance of
> the first tick. is the beat supposed to be on zero or
> on the first tick?
>
Well, the beat should be zero, and the first tick would show the float size of each tick, assuming it's consistent... it should at least be very close to consistent. Again, the first tick thing was just me trying to find something to explain the drift -- grasping at straws, basically. The main thing is that, as I understand it, if the tick doesn't come out evenly to zero on each beat, then something's awry.
J.
jbmaxwell wrote:
> Please, if anyone knows a way around this one, let me know what's up.
> Or, if you know for a fact that it can't be done in Logic, let me
> know, and I'll stop wasting my time.
I don't use Logic, and as i seems there is a bug in Logic causing that,
probbaly giving the information not more precise than the some
buffersize, vectorsize intermodulation, who knows.
Beside kicking Emagic for something you paid for, I'd try to get around
by adding a stereo track with one channel containing a sawtooth of
exactly 1 Hz, the other of a sort of second counter. That way you'd be
able to track the time position exactly within the song.
Maybe this could be a workaround till Emagic sorted out the problems.
Stefan
--
-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----
Thanks, Stefan.
That seems a bit like what Roman was suggesting. Nice patch for building the time track as well!
I've got a system, for the time being, that works on bars and beats (which seem fine when read from the "bar count" and "beat count" outlets in plugsync~), and just counts the incoming events within each beat. It's not great, but it could be worse. As long as playback starts on a beat, everything will be fine. If playback starts between beats, things will come together on the following beat. Not great, but workable.
Scanning around the forum and email list, it does look as though it's emagic/apple's deal -- David Z. points it out pretty emphatically, at one point. Anyway, I'll struggle along with the system I've got, and if it's really not working I'll probably give yours a try.
thanks again,
J.
I thought I'd just suggested synching to an audio timecode track in my last post/patch? as I said...you get EXACTLY the same problem with the values coming intop MSP, wheteher thru plugsync~ or hostsync~, which suggests to me some kind of latency/compensation thing going on that only Logic can understand
Quote: bin wrote on Thu, 11 May 2006 10:03
----------------------------------------------------
> I thought I'd just suggested synching to an audio timecode track in my last post/patch? as I said...you get EXACTLY the same problem with the values coming intop MSP, wheteher thru plugsync~ or hostsync~, which suggests to me some kind of latency/compensation thing going on that only Logic can understand
----------------------------------------------------
Sorry,
I didn't actually look at your patches last time, since I wasn't really into the idea of using a sync track anyway. But yes, it's the same basic model. I don't get why this doesn't work, but I wonder if it's something to do with pluggo's implementation for AU. Roman mentioned using a sync track approach in Cubase, which is obviously VST, not AU. So, a pluggo AU problem, maybe?
J.
bin - who has 1 post - wrote:
>> I thought I'd just suggested synching to an audio
>> timecode track in my last post/patch?
but serious, using click tracks has a little
disadvantage in plug-ins which also need audio
input because they are effect plug-ins.
erst denken, dann ... :)
Roman Thilenius wrote:
> but serious, using click tracks has a little
> disadvantage in plug-ins which also need audio
> input because they are effect plug-ins.
but you could send them along a pluggobus~
> erst denken, dann ... :)
erst weiterdenken, dann... ||;---))))
wo ist eigentlich 110?, wir sollten uns mal zum Essen verabreden...
Stefan
--
Stefan Tiedje------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()-----www.ccmix.com
i am bin, but i was chirokopter... just registered on the forum.
has anyone tried any of these suggestions on other sequencers like cubase? abelton live wouldnt give me any hostsyc~ info
the patch i posted gives me the same error in the loop points using a long ramp of audio as a kind of timecode, into a plugin as with plugsync~ or hostsync~ . does that mean anything to anyone?
I would think that if you're using the AU version it might mean something... But Live could be Mac or PC, and on Mac VST/AU. Which platform and plugin format are you using?
J.
Quote: Andrew Pask wrote on Fri, 05 May 2006 18:35
----------------------------------------------------
> What sort of results are you seeing with this patch?
>
> On PC in SX 3.1 I am seeing regular deviations of the order of
>
> .000092
>
> On Mac, in Logic 7.2, the regular deviations are considerably more, around .01
>
> And like you say, it does seem to be cumulative.
>
> Cool patch, thanks - I'll look into it some more
>
> -A
----------------------------------------------------
Sorry, Andrew. I never actually got back to you on this. I've only tried it on Mac, and get the same average error as you: .01.
cheers,
J.
Just for the hell of it I messed around a bit with Live, using AU and VST. The errors are less, about .001, but still there, and are present using both VST and AU. I am testing by placing a midi event on the timeline, starting playback at various points before the note, and simply checking when the tick readout thinks it occurred. I would think that, in theory, it should always occur at the same point in time -- the same tick.
The other thing I've noticed is that Live always thinks the note happens slightly before the beat on which it's entered, whereas Logic wanders a little on both sides of the beat. (Also, curiously, Live resets the sample count on "stop", whereas Logic resets it on "start"... who knows, who cares?)
Anyway, this all makes me wonder whether it can even be made consistent...(??) It would certainly be nice, at least in my situation, but maybe it will always wander with the current implementation. But it does appear to free Logic from being the only one to show the error, though it does suffer the highest average deviation.
This brings me to the question (to Andrew, mostly): Is it possible to allow a user-defined "tick" size argument that would take care of rounding errors, and the like, and give us a consistent and predictable tick readout; a sort of tick quantization? I realize this may be a huge problem, as tick sizes vary greatly between sequencers, but could there be a workaround within pluggo?
J.
I'm not quite sure what youre trying to do with logic. when i tried midi triggering plugin AU instruments that I've made, i got very good timing, or at least it sounded tight enough to not care.
my problem is that when you create a loop in Logic, as i do all the time when i am composing a track, logic always tells max msp (whether using hostsync~ or plugsync~) it is looping slightly before the loop points i have set e.g. a loop of bar 3 to bar 4 will tell max it is looping between 2.95 to 3.95. this also happens if i create an audio ramp that defines the ticks. i get an almost identical error.
I'd guess that logic starts a little before any start point and then leaves a little latency so it can get all the audio working, then plays audio from the loop point , but if you interrupt its workings, you are out of synch, by some unknowable quantity....
the only way I've found to synch the two programs accurately, is to make a loop, get the loop points from hostsync~, and then use the start/stop output to trigger a phasor~ which (when multiplied by the looplength and added to the loop startpoint) outputs what shoud be coming from the ticks output. but i always have to make a loop....
OS 10.3.9 Logic 6.3.1 rewired to latest Max MSP version, and i've tried building AU's giving similar problems..
Quote: bin wrote on Fri, 12 May 2006 11:42
----------------------------------------------------
> I'm not quite sure what youre trying to do with logic. when i tried midi triggering plugin AU instruments that I've made, i got very good timing, or at least it sounded tight enough to not care.
In my case, I'm trying to build a plugin instrument that knows where I am in the piece. That's why I'm dealing with the tick count specifically, since it _could_ give me a precise indication of where the locator is in the song. Originally, I was actually hoping to basically timestamp my events with tick values when recording, then recall them using the tick readout during playback. Unfortunately, that's not possible with the current state of pluggo, since the tick values won't necessarily repeat on each playback, and thus won't necessarily "recall" anything.
J.
Getting back to this briefly... I've made a simple little utility to allow recall of "timestamps" based on plugsync~/hostsync~. I've only tested it with hostsync~, and it appears to work. Note that it has "record" and "playback" modes, and it's not affecting actual timing in any way, only allowing one to use the "recorded" timestamps as indices for recalling whatever you want to recall. It's solved a big problem for me, so maybe it will be handy for others. Dunno.
cheers,
J.
Sorry for the repost... I couldn't edit the last one for some reason.
Anyway, I forgot to provide output for the timestamps during recording. ouch.
O, the perils of premature and hasty sharing.
I'm not going to post the patch again, since I doubt anybody will even use it, but I noticed a problem. I was trying to stop it from outputting as soon as I moved the locator in my host, so I put a triggered [int] on the output of [change]. This messes things up. If you do find a use for this patch, just delete that int box and connect [change] directly to inlet 3 of the [switch] at the bottom.
Apologies to all who've received this tutorial on ineptitude in their email.
J.
I've given up on this whole project, as the Logic tick thing makes my patch completely useless. So, I'm just checking in to see whether Andrew (I think it was Andrew who was looking into it??) managed to make any progress on getting reliable ticks from Logic and plugsync~.
Any news?
J.
well, I solved this problem ages ago. Perfect ticks, no ASIO muck ups, etc. I could share it. Hrm.... Its not hopeless. I don't want to share something I spent so long working to perfect. The reason why I believe plugsync~ is wobbly is because sequencers start/stop and looping are wobbly. Check out the hostsync~ information that comes in from a variety of sequencers.... ala, for me, I've checked cubase/logic/fruity loops. The most fucked up by far has to be fruity loops. It must have been programmed incredibly poorly because the locater information that comes out of the 2nd from right outlet [loop info] of hostsync is anythig but consistent.
My advice would be...
a. use the loop info to make a min/max number box for bars.
b. use the tempo (as sample to ms) to create a 4 series of pipes that make subdivsions per beat. You generally only get 4 beats in for 4/4, you'll have to make subdivisions depending on what resolution you want your project to be.
c. store the bar for output only when the first beat comes in, ie bang it out then send the tick.
what you're trying to do is possible. To get it to create consistent, recreatable everytime results requires some craftiness. I might post a patch one day, but its "copious use of third party externals" may put some off.
well, keep at it. I know for a fact its possible to get perfect bars and beats into remote computers from a host computer using plugsync~/hostsync~. give it another go!
bine0zr
--- binez0r wrote:
> I don't want to share something I
> spent so long working to perfect.
I would have thought that was a very compelling reason
to share something. Unless you're planning to make
commercial use of the it, if you really have
'perfected' the thing, your hard work could make
another Maxer very happy, and will cost you nothing
that you haven't already spent!
Shared knowledge (with or without 3rd party externals)
is always welcome on this list,
cheers
Roger
Well, sorry!
I'm a max elitist 8-)
Really, I think its best for people to figure these things out. I only posted to give encouragement!!
Good luck!
hmm... cute reply.
Somewhere between the use of two number boxes and 4 pipes I started to sweat. In all the time I spent programming the patch I was referring to, I _never_ had a good experience running pipe. Not even 1 pipe, let alone 4 (scheduler backlog -> Max hang). Might be worth a shot, I suppose -- maybe to just build a common Master clock that feeds all plugin instances with sync info, but it will have to wait until my faith in Max is restored (which you could possibly do by posting your patch: hint, hint). For now, I'm intensely skeptical. Too bad.
Also, I'm not using loops. I want a predictable, reproducible timeline from start to finish coming from Logic, and yes, that's on a Mac. Though I'd imagine that, since it works for loops, whatever you've done will probably also work for a whole piece, I've nowhere near the patience to approach this problem again any time soon. I already wasted a good year on this project, battling the dark corners of Max... I'll leave Max for much more Max-friendly projects.
On a brighter note, I did learn Java in the process! (Well, sort of.)
J.
well, I will post my current solution to maybe see if it gets the ball rolling. unfortunately plugsync~ lacks one all important outlet which hostsync~ has and thats the loop info outlet [second from right I think]... using the information from this outlet one can prevent muckups using the min/max messages into a numbox. without this, sometimes the bars outlet goes one over the loop locaters [or one below] when in loop mode on a sequencer. So, if you're looping bars 2-4, sometimes 1 or 5 might slip through the cracks. I am testing this in Cubase. I hear in Ableton Live they have the looping ticks down to a T, so that may be a place where you could use plugsync~ without worry of any overlapping notes. Anyway, for starters I will post my rewire solution using hostsync~ instead and from there if you want to adapt it into a plusync~ plugin, be my guest. I've done the port, and in my opinion hostsync~ is the better if you want pretty solid ticks.
Anyways, the following externs are needed...
cnmat = osc-route.mxe
f0 = f0.one_block_gate
jasch_objects = _.mxe
lmaths = ldiv.mxe
lmaths = ladd.mxe
lmaths = lround.mxe
lmaths = lmult.mxe
lpack_2 = Lswap.mxe
lpack_4 = leftgate.mxe
lpack_3 = lrepeat.mxe
max_beta = udpreceive.mxe
max_beta = udpsend.mxe
Also check out the spacing between ticks. Its not perfect, at 120 bpm, at a 1/16 note resolution each tick should be like 125 ms... sometimes you'll see ticks of 124.950 and 125.0300 or what not, but usually this happens when the loop locaters go back to the start of a loop. Anyways, heres the link to the file...
Oh, and naturally you need to open up logic/cubase/live first and then open the max patch so rewire will enable itself correctly.
binez0r
this is a great thread! are there any developments with any of this?