transport and phasor~ issues
hi all,
i have been working on a new sequence patch for someone and i knew about [transport]s lack of hitting in timing, or hitting things right on the money, it was always a little off, i have included a audio demo.
the hits are just happening as 1-5-9 etc, just a simple 4/4 beat, but it does go off.
the same is also happening with [phasor~] set with the @lock 1 attribute with 16n, and having different clocks available. but even when i play withe [phasor~] is sets all my sequencers completely off, not staying on the same path, after about half way through the sequence.
i have put a screen shot of it when you first start the sequence, but leave it a few more second and they all trail from each other.
i know the difference between max and msp timing, but seems to be having trouble with both at the moment. does anyone have an alternative or a patch which can solve this problem.
basically a fool proof transport which actually hits the sequences on proper times and does not mess with the timing as well.
i will be working on more alternative and searching around, but even when i found a few possible answers, they all cam e up the same
cheers
lewis edwards
------
smokingbunny.co.uk
thanks
right here is the audio demo with the 'not quite on time transport, i could not post it up on the forum.
Assuming that all sequencers are controlled from global transport there is no reason for different timings.
Maybe you can post the patch here (or at least the part which is relevant for timing).
its not that they are so much as different timings with [transport]m, its more that they are not hitting in time, always this slight delay before a hit, much like in the audio demo.
here is a [phasor~] type of transport i have been messing with. i have noticed though that max timing is slightly off from msp timing. max seems to lag a little
In my experience phasor~ doesn't always behave as expected.
But transport (with quantized metro) works perfectly for me.
i was using the global transport for everything before, but it does have the problems of falling behind or speeding when not messed with, its strange really
From a quick look at your patch I guess that the problem is caused by 'qlim' and 'pvar position'.
Handling real time data on low-priority threads will inevitably lead to sloppy timing.
aye, i was looking at it and am going to work on a slick and broken down version of transport with the necessary.
but thanks for your interest as well, it helps to get second opinions
im revisiting this thread as i still seem to be having major issues with transport.
im working on some new patches for a client
now i am just using the global one that is in max, but still having this strange lag for some reason, and this is when im just doing test.
any thoughts?
lewis
Can you show us what you mean with a commented, stripped down patch?
-A
this is just a snippet and first steps of an fm-ish sequencer. but does have a transport which talks to the global one.
was wondering whether to try msp trasport again... maybe
but would be great if you could help
lew
For more accurate timing you need Overdrive and SIAI on and a low buffer size.
-A